Memahami Parquet, Iceberg, dan Data Lakehouse
(davidgomes.com)- Teknologi penyimpanan data bukan satu kesatuan tunggal, melainkan terbagi ke beberapa lapisan berbeda seperti format file, format memori, lapisan metadata tabel, dan arsitektur lakehouse
- Avro, Parquet, ORC, dan Arrow adalah format yang menentukan tata letak biner data; Parquet unggul untuk kompresi berbasis kolom dan pemrosesan analitik, sedangkan Avro lebih cocok untuk pemrosesan per baris
- Iceberg dan Delta Lake bukan format file, melainkan lapisan metadata tingkat atas yang memungkinkan pengelolaan tabel berskala besar di atas file seperti Parquet
- Data lakehouse adalah pendekatan yang menambahkan fungsi warehouse seperti query SQL, batch job, dan governance di atas file mentah pada penyimpanan seperti S3
- Seiring warehouse seperti Snowflake dan BigQuery juga mendukung format terbuka seperti Iceberg, batas antara data warehouse dan lakehouse makin kabur
Perbedaan format file dan format memori
- Format open source untuk mengefisienkan penyimpanan dan akses data memiliki cara penyimpanan dan tempat penggunaan yang berbeda
- Apache Avro: biner, penyimpanan baris (rowstore), file
- Apache Parquet: biner, penyimpanan kolom (columnstore), file
- Apache ORC: biner, penyimpanan kolom, file
- Apache Arrow: biner, penyimpanan kolom, memori
- Protocol Buffers: bahasa definisi struktur data yang netral bahasa pemrograman; tergantung implementasinya, penyimpanan baris atau kolom bisa berbeda
- CSV: berbasis teks dan strukturnya sangat sederhana
- Saat menyimpan dataframe Apache Arrow sebagai file di disk, Feather biasanya digunakan, dan data juga dapat dikonversi ke format lain seperti Parquet
- Sistem seperti Snowflake, Redshift, Athena, dan Hive mendukung baca/tulis format terbuka maupun format penyimpanan tertutup, tetapi cakupan dukungan format terbuka bisa berbeda-beda menurut produk
Apa yang sebenarnya ditentukan oleh format
- Format file adalah spesifikasi yang menentukan bagaimana data diurutkan dalam penempatan biner sebenarnya
- Parquet unggul dalam kompresi, sedangkan Avro, karena memakai penyimpanan baris, lebih cocok untuk membaca blok baris tertentu
- Parquet dan Avro sama-sama mendukung evolusi skema, sehingga skema data baru dapat diubah tanpa harus menulis ulang seluruh data lama
- Kedua format juga mendukung pemecahan file, yang penting untuk pemrosesan data paralel
- Repositori Apache Parquet mencakup spesifikasi format file sebenarnya dan implementasi referensi Java
- Parquet dapat dibaca dan ditulis oleh berbagai bahasa dan tool, dan di Pandas pun DataFrame dapat disimpan ke file Parquet lokal dengan
to_parquet - Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena, dan Apache Drill adalah contoh engine yang dapat menangani file Parquet
Pengelolaan data berskala besar tidak cukup hanya dengan format file
- Format file individual hanya mendefinisikan layout satu file, sehingga tidak cukup untuk mengelola dataset berskala besar yang terus berubah
- Untuk menyimpan banyak tabel, evolusi skema tiap tabel, query pada titik waktu tertentu, partitioning yang efisien, pembacaan skema oleh tool eksternal, dan penyimpanan statistik untuk optimisasi query berbasis biaya, diperlukan lapisan tingkat atas
- Lapisan ini mencakup format tabel dan schema registry atau metastore
- Confluent Schema Registry mendukung Avro dan Protobuf, dan lebih cocok untuk data streaming yang cenderung memakai penyimpanan baris
Posisi Hive, Iceberg, dan Delta Lake
- Facebook merilis Hive pada 2009 bersama format metadata tabelnya sendiri, dan sejak itu Hive mendukung berbagai format
- Netflix mengembangkan Iceberg untuk melampaui keterbatasan performa dan skalabilitas Hive
- Databricks mengembangkan Delta Lake sebagai alternatif Iceberg, lalu kemudian membukanya sebagai open source
- Iceberg dan Delta Lake sama-sama menggunakan Parquet sebagai format file individual
- Hive, Delta Lake, dan Iceberg semuanya mendukung konsep yang setara dengan schema registry atau metastore
- HMS (Hive MetaStore) milik Hive pada dasarnya dapat menggunakan RDBMS apa pun
- Iceberg memiliki Iceberg Catalogs
- Databricks memiliki Unity Catalog
- Catalog dan metastore semacam ini juga dapat digunakan untuk data governance, yaitu mengelola tim atau pengguna mana yang dapat mengakses tabel tertentu
Fungsi yang ditangani Iceberg dan Delta Lake
- Delta Lake dan Iceberg bukan query engine atau storage engine itu sendiri, melainkan spesifikasi terbuka yang memungkinkan query engine bekerja
- Keduanya menyelesaikan masalah yang sama dengan cara berbeda, dan ada perdebatan seputar keterbukaan Delta Lake karena keragaman kontributornya lebih rendah dibanding Iceberg
- Dukungan Iceberg berkembang cepat di berbagai data warehouse dan lakehouse seperti Redshift, BigQuery, Snowflake, Athena, dan Dremio
- Iceberg dan Delta Lake menyediakan fitur yang dibutuhkan untuk operasi tabel berskala besar
- Partitioning
- Evolusi skema
- Kompresi data
- Transaksi ACID untuk perubahan skema
- Optimisasi query yang efisien melalui column pruning, predicate pushdown, dan pengumpulan statistik
- Time travel untuk query pada titik waktu tertentu
- Iceberg mendukung evolusi partisi, sehingga cara partitioning tabel atau shard key dapat diubah tanpa harus menulis ulang seluruh data lama
- Di Netflix, perubahan partitioning adalah masalah besar, dan itu menjadi salah satu alasan Iceberg dibuat
Format tertutup dan tekanan untuk mendukung Iceberg
- Spesifikasi Iceberg dengan cepat menjadi populer sebagai format yang didukung banyak sistem
- Produk yang memakai format tertutup mendapat tekanan untuk tetap menghasilkan performa setinggi mungkin dari formatnya sendiri, sekaligus mendukung Iceberg atau Delta Lake dengan cara tertentu
- Iceberg bisa menjadi fitur checklist yang suatu saat harus didukung oleh setiap sistem database
- Karena alasan performa, Iceberg mungkin sulit sepenuhnya menggantikan format data tertutup
- Jika format data dikembangkan hanya untuk satu query engine, developer database dapat memaksimalkan efisiensi dan berinovasi lebih cepat
Data lake dan data lakehouse
- Data lake adalah tempat perusahaan menyimpan data dalam jumlah besar sebagai file mentah seperti Parquet dan CSV
- Data warehouse menyimpan data dengan cara yang lebih terstruktur, seperti tabel SQL berskema dan skema database
- Data lakehouse adalah bentuk yang menggabungkan data lake dengan fungsi seperti menjalankan query SQL, batch job, dan konfigurasi data governance
- Dengan menggunakan Iceberg bersama query engine dan komponen tambahan lainnya, data lakehouse dapat dibuat di atas data lake
- Di masa lalu, untuk fungsi semacam ini perusahaan harus mengadopsi data warehouse atau DBMS yang lebih tradisional
- Data lakehouse menggunakan HDFS atau cloud Blob Store seperti S3 sebagai lokasi penyimpanan semua data, lalu mengoptimalkan query engine agar berjalan cepat di atas penyimpanan tersebut
- Databricks dan Dremio adalah contoh produk data lakehouse
- Seiring warehouse seperti Snowflake dan BigQuery menambahkan format data terbuka seperti Iceberg, perbedaan antara data warehouse dan data lakehouse menjadi makin kabur
2 komentar
Saya sedang membandingkan Iceberg dan Delta Lake, dan ternyata bisa dirangkum dengan rapi seperti ini.
Pendapatnya hampir sama dengan pandangan yang saya lihat.
Benchmark yang dijalankan secara online menggunakan Spark, dan meski benchmark itu layak dijadikan referensi, Head of DevRel Tabular menulis bahwa itu tidak terlalu bermakna.
Jika harus memilih sebagai open source,
icebergtampaknya menjadi satu-satunya pilihan.Ringkasannya bagus, tetapi akan lebih baik jika ada juga tautan referensinya.
Pendapat di Hacker News
Apache Iceberg dan Delta Lake sering dikelompokkan bersama sebagai Open Table Format, tetapi sebenarnya terlihat cukup berbeda
Spesifikasi Iceberg ada di https://iceberg.apache.org/spec/, dan bagi orang yang memahami sistem basis data, dari situ tampaknya tidak terlalu sulit untuk membuat implementasi yang membuat dan mengkueri tabel Iceberg
Sebaliknya, untuk Delta Lake ada di https://github.com/delta-io/delta/blob/master/PROTOCOL.md, tetapi bahkan sulit memperkirakan jumlah pekerjaan yang diperlukan untuk mengimplementasikan spesifikasi saat ini secara penuh, apalagi mengikuti spesifikasi raksasa yang terus berubah ini
Terus terang, spesifikasi Delta Lake terbaca seperti dokumen hasil rekayasa balik atas kompromi implementasi yang muncul ketika Databricks membangun lakehouse dengan cepat untuk perusahaan Fortune 1000 yang sudah kapok dengan Hadoop
Saya belum yakin bahwa mengadopsi Delta Lake benar-benar berarti masuk ke ekosistem terbuka, dan saya berharap ada dasar yang meyakinkan untuk merasa tenang soal ini
Selain itu, riwayat GitHub-nya juga tidak menenangkan: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
Terlihat seperti alur di mana fitur dan perbaikan arbitrer diajukan sebagai PR oleh engineer Databricks, lalu langsung disetujui oleh senior engineer Databricks
Namun, dengan begitu mereka tidak bisa mengklaimnya sebagai format terbuka yang digerakkan komunitas. Kecuali kalau maksudnya versi ala Animal Farm: “sebagian pihak lebih setara”
Untuk memakai fitur seperti kolom terhitung atau check constraint, kita juga harus mendukung ekspresi Spark SQL, dan dokumentasi untuk bagian itu lebih buruk lagi
Menurut saya itu hanya mendekati open source secara nominal, dan tidak seharusnya dipercaya
Saya juga pernah memakai Delta Lake, dan dalam penggunaan nyata ada banyak keterbatasan yang menjengkelkan serta sudut-sudut tajam. Pada akhirnya proyek itu kami hentikan sepenuhnya, dan saat itu saya juga meneliti Iceberg
Iceberg dan Hudi memiliki susunan fitur yang dirancang lebih konsisten, tetapi dukungannya masih lebih sedikit, dan saya berharap bagian ini akan membaik ke depannya
Selama 6 bulan terakhir, saya mendapat kesan bahwa Iceberg kesulitan menyediakan alat untuk pengguna di luar ekosistem JVM, sementara Delta lebih unggul. Dari sisi itu, Delta jauh lebih mudah didekati
Sebagai perbandingan, di SQL Server hal ini diimplementasikan jauh lebih baik. Tabel penyimpanan berorientasi kolom (columnstore indexes, setara Parquet/ORC di internal engine) bersifat immutable, dan delta disimpan di B-Tree demi kompresibilitas, aksesibilitas, dan kecepatan
Pada titik tertentu, penyimpanan kolom didefragmentasi, digabung, atau dibangun ulang sebagian maupun seluruhnya, lalu B-Tree dihapus dan dimulai lagi saat perubahan baru menumpuk
Melakukan ini dengan JSON, kalau mau dikatakan secara halus, adalah tanda zaman yang buruk
Rasanya apa pun akan lebih baik daripada Delta Lake, dan Iceberg khususnya terlihat lebih baik
Artikel yang bagus. Saya sudah menangani file Parquet di atas S3 selama bertahun-tahun, tetapi tidak begitu tahu apa sebenarnya Iceberg; tulisan ini menjelaskannya dengan baik
Iceberg adalah format metadata basis data yang menjelaskan skema dan pemartisian dari kumpulan data dasar
Sebagian besar memakai konvensi pemartisian Hive seperti
/key3=000/key2=002/, tetapi Iceberg lebih baik karena mengekspos lebih banyak struktur ke query engineDalam DBMS tradisional seperti Postgres, skema, query engine, dan format penyimpanan disediakan sebagai satu paket
Namun dalam big data, komponen basis data bisa dirakit dari awal dan dicampur-padankan. Kita bisa memakai Iceberg sebagai format metadata, DuckDB sebagai query engine, Parquet sebagai format penyimpanan, dan S3 sebagai media penyimpanan
Ini merupakan perubahan besar di dunia database. Berkat Delta, Iceberg, dan Hudi, data umumnya disimpan dalam format open source di atas S3
Ketika sebagian besar penyimpanan dan pemrosesan distandardisasi, perpindahan antar-database menjadi lebih mudah, dan pada akhirnya hampir semua tool bisa menangani kumpulan file yang sama secara aman secara transaksional
Misalnya, saat Snowflake menulis ke file, seorang data scientist bisa melakukan query secara real time dari Jupyter notebook, sementara ClickHouse bisa menyediakan analitik untuk pengguna atas data yang sama dengan tetap menjaga jaminan konsistensi
Setelah itu, meskipun perusahaan memutuskan beralih dari Snowflake ke Databricks, hal itu tidak lagi menjadi masalah besar
Saat ini, kecepatan melakukan query terhadap format seperti ini di S3 belum secepat pemuatan native, tetapi tekanan pasar akan memaksa semua vendor database mengoptimalkan performa, dan pada akhirnya akan mendekati performa data yang dimuat secara native
Ini kemenangan besar bagi keterbukaan dan open source, serta bagi perusahaan yang memiliki data dalam format yang terbuka dan portabel
Lakehouse juga punya implikasi yang sama. Banyak perusahaan memiliki data lake sekaligus data warehouse, lalu akhirnya menyalin data di antara keduanya
Memiliki hanya satu sistem untuk melakukan query dan mengelola kumpulan data yang sama juga memberi dampak besar
Ini masa yang sangat menarik untuk berada di bidang data engineering
Ke depannya, terlihat masa depan saat rencana eksekusi query bisa dikirim tidak hanya ke berbagai engine di seluruh cloud, tetapi juga ke mesin lokal
Kalau Snowflake, mungkin lebih baik mereka menutup bisnis dan mengembalikan miliaran dolar kepada investor. Mengikat data ke ekosistem mereka adalah keseluruhan model bisnis mereka
Saya penasaran apakah ada contoh bagus ketika standar terbuka membuat perusahaan meninggalkan teknologi proprietari
Saya sangat tidak setuju dengan pernyataan bahwa “cara terbaik menyimpan dataframe Apache Arrow sebagai file di disk adalah Feather, dan juga bisa dikonversi ke Apache Parquet dan lainnya”
Jika ingin membuat lakehouse non-JVM sendiri, konfigurasi terbaik adalah memakai Iceberg sebagai metadata, Parquet sebagai data, DuckDB sebagai query engine, lalu melakukan query sebagai tabel Arrow
Biaya membaca Parquet langsung ke Arrow sangat rendah, lalu setelah itu bisa diteruskan ke Arrow→Pandas atau Polars. Bisa diteruskan langsung atau lewat layanan berbasis Arrow Flight
Jika Feather dimasukkan ke sini, seluruh stack lakehouse Python saat ini tidak akan bekerja dengan baik
Mungkin sekarang sudah berubah, tetapi Parquet masih terasa sebagai pilihan yang paling siap untuk masa depan
Saya pernah mendengar data lake, tetapi “data lakehouse” terdengar seperti tempat data kelas atas pergi memancing data dengan data boat saat musim panas
Banyak perusahaan menyimpan data di data lake dan memakai warehouse untuk menyediakan BI ke tool seperti Tableau atau PowerBI. Lalu mereka akhirnya menyalin data di antara keduanya
Data lakehouse yang melakukan query langsung ke lake sambil menerapkan transaksi dan tata kelola pada satu kumpulan data bisa sangat menyederhanakan stack dan juga menurunkan biaya
Setiap kali mendengar atau membacanya, rasanya cukup canggung di kepala saya
Saya sangat menaruh harapan pada Iceberg, terutama karena ini open source
Namun terakhir kali saya melihatnya, implementasinya hanya berupa library Spark, dan konektor Iceberg Trino (dulu Presto, SQL engine) sangat bergantung pada Hive
Rasanya seluruh industri kesulitan bercerai dari warisan MapReduce, Hive, dan—berani saya katakan—Spark
Sejak itu saya belum melihat Iceberg lagi, tetapi saya berencana segera melakukannya, dan sangat berharap bidang ini berkembang
Sekarang kita memiliki tool dan kemampuan komputasi untuk menangani data tanpa teknologi legacy, dan tidak semua data adalah big data
Karena itu, untungnya data engineering semakin mirip dengan pengembangan backend biasa, dan praktik pengembangan yang umum pun mulai mapan
Saya berharap dalam waktu sangat dekat akan muncul library Python Iceberg murni
Upaya yang sangat besar telah dilakukan untuk menghapus dependensi itu
Databend bisa saya jalankan dalam satu jam, dan saya melihat jika ada implementasi Rust, portabilitasnya dibanding Java/Hive akan lebih baik sehingga ke depan akan lebih mudah dipakai dengan benar
Saya tidak mengerti mengapa semua ini tidak bisa dijelaskan dengan lebih konkret
Akan lebih baik jika dijelaskan bagaimana data disimpan, bagaimana dihubungkan dan di-query, serta seberapa cepat query-nya. Misalnya perbedaan antara kecepatan transaksi dan kecepatan query analitik
Saat ini kami menangani sekitar 100 TB data di GCP, memakai BigQuery sebagai mesin kueri, dan menggunakan partisi Hive sederhana seperti
/key3=000/key2=002/Kami puas karena bisa menjalankan semua kueri yang diinginkan dan biayanya juga sangat murah
Hanya saja latensinya mulai cukup tinggi, meski bagi kami itu tidak terlalu penting. Namun tetap penasaran apakah mengadopsi Iceberg akan memperbaiki bagian ini
Saya penasaran apakah ada yang punya pengalaman seperti ini, dan secara umum arsitektur semacam ini benar-benar hebat
Tujuan utama teknologi seperti ini adalah manajemen data skala besar, tetapi juga memperluas kemampuan yang disediakan format penyimpanan mentah seperti Parquet. Jadi mungkin bisa membantu, tetapi perlu dipertimbangkan apakah benar-benar diperlukan
Saya belum pernah memakai BigQuery, tetapi mungkin ada fitur serupa
Pertama-tama perlu didefinisikan apa yang dimaksud dengan “latensi” di sini, dan seberapa tinggi “cukup tinggi” itu
Penyimpanan data analitik dirancang untuk pemrosesan batch yang efisien, dan mencari satu record bukanlah tujuan utama arsitektur ini. Untuk pencarian cepat diperlukan caching atau indexing
Dalam beberapa kasus, menambahkan
limit 1pada pencarian satu record saja sudah bisa menyelesaikan masalahPastikan Anda menggunakan format penyimpanan data yang efisien seperti Parquet, lalu periksa ukuran file untuk memastikan tidak ada "small file problem"
Setelah itu, pastikan juga apakah fitur BigQuery yang relevan sudah digunakan. Jalankan
explainpada kueri sebelum dan sesudah pemeriksaan ini, dan jika tidak memakai partition key atau kolom indeks, hasil pencarian tidak akan muncul seketika di sistem big data mana punJika tabel BigQuery tidak digunakan sebagai input untuk komputasi throughput tinggi, saya akan fokus pada mengoptimalkan alat BI atau membuat tabel analitik yang mencegah latensi bagi pengguna akhir
Misalnya, baru-baru ini kami mematerialisasikan join tabel fakta/dimensi dan operasi
COALESCEuntuk membuat tabel besar khusus analitikSecara konsep, ini berada “di luar” konfigurasi data warehouse biasa, tetapi karena ada di dalam dbt, kualitas data dan lineage tetap bisa dipertahankan
Hasilnya kami bisa menghilangkan kalkulasi tetap Tableau dan mengurangi waktu load/grouping bagi pengguna akhir sekitar 95%
Kalau itu federated query ke GCS/S3, mungkin bisa lebih cepat
Saya sangat menyukai sikap: “Tulisan ini tidak 100% mencakup semuanya, dan mungkin bukan titik awal terbaik bagi kebanyakan orang. Karena ini tulisan yang saya buat untuk diri saya sendiri. Saya merasa cara terbaik mempelajari hal baru adalah memaksa diri saya menjelaskannya kembali kepada orang lain”
Saya juga mulai menerapkan cara seperti ini di catatan kertas dan catatan di situs web saya
Saya sangat menantikan untuk menggali lebih dalam era Iceberg untuk penyimpanan Parquet yang lebih terkelola
Namun dukungan untuk I/O GPU cepat (GPUDirect/cuFile) masih tertinggal beberapa tahun
Jadi setiap kali mencoba membawanya ke pelanggan untuk beban kerja AI, saya selalu menabrak tembok itu
Pada akhirnya tampaknya ini akan terjadi, dan lebih merupakan soal “kapan” daripada “apakah mungkin”. Akan sangat keren jika akhirnya kita bisa mendapatkan keduanya
Untuk penyimpanan teks, Parquet saat ini sudah cukup
PyTorch Data Loader dan TF Data menyediakan klien multithread yang membaca lebih dulu secara paralel, mengisi buffer memori, lalu bertukar data dengan GPU
Saya setuju bahwa S3 bisa menjadi bottleneck di sini. Karena itu kami menempatkan HopsFS sebagai cache NVMe konsisten yang terdistribusi global di atas S3
Anyscale juga melakukan hal serupa dengan cache NVMe lokal untuk S3
Ada juga format file menarik bernama Lance, mirip Parquet tetapi untuk data gambar. Di dalam file ada indeks I/O acak cepat tambahan untuk menemukan gambar