Dua chapter terakhir berakhir pada pola yang sama: tulis berkas baru, lalu hapus berkas lama. Di satu job hal itu masih terkendali; ketika lima job menulis bersamaan ke folder yang sama, siapa yang memastikan pembaca tidak melihat setengah proses? Object storage tidak menyediakan transaksi — operasi put dan delete berdiri sendiri. Table format hadir sebagai lapisan di atas berkas Parquet; lapisan ini mencatat versi tabel dalam metadata, sehingga penulis dan pembaca sepakat tentang keadaan data pada suatu titik waktu.
Masalah yang Diselesaikan #
Table format menjawab tiga masalah yang tidak bisa diselesaikan oleh format berkas ataupun object storage:
- ACID di object storage: beberapa job boleh menulis secara bersamaan; pembaca selalu melihat keadaan tabel yang utuh — hasil commit sebelumnya atau hasil commit baru, tidak pernah campuran keduanya.
- Schema evolution: kolom boleh ditambah atau diubah tipe tanpa menulis ulang seluruh data; tabel menjelaskan bagaimana berkas lama dan berkas baru dibaca dengan satu definisi.
- Time travel: setiap versi tersimpan, sehingga query bisa meminta keadaan tabel “kemarin sore” untuk audit atau membandingkan hasil sebelum dan sesudah perbaikan.
Ketiganya bermuara pada satu mekanisme: tabel bukan lagi sebuah folder, melainkan kumpulan berkas data plus metadata yang berversi.
Anatomi Table Format #
Metadata umumnya berlapis tiga. Puncaknya adalah metadata file yang menyimpan definisi tabel dan daftar manifest; setiap manifest mendaftar berkas data milik satu partisi beserta statistiknya. Catalog menyimpan penunjuk ke metadata versi terbaru:
Saat sebuah job menambahkan berkas, prosesnya berlangsung sebagai berikut: berkas data ditulis lebih dulu, kemudian manifest dan metadata baru dibuat dengan menunjuk metadata versi sebelumnya, dan terakhir catalog dialihkan ke versi baru melalui satu operasi atom — di S3 mekanismenya adalah put-if-absent pada key metadata. Pembaca lain yang sedang membaca versi 12 tidak terganggu; pembaca berikutnya melihat versi 13. Time travel bekerja karena metadata versi lama tidak dihapus: query meminta versi mana pun, manifest lama masih menunjuk berkas yang belum dibersihkan.
Tiga Format Besar #
Tiga nama mendominasi lapangan: Apache Iceberg, Delta Lake, dan Apache Hudi. Ketiganya open source, dan versi stabilnya per Oktober 2026 tercatat di catatan riset sebagai berikut:
| Aspek | Apache Iceberg | Delta Lake | Apache Hudi |
|---|---|---|---|
| Asal proyek | Netflix, kini proyek Apache | Databricks | Uber, kini proyek Apache |
| Versi stabil | 1.12.0 | 3.x | 1.x (1.0 rilis akhir 2024) |
| Ciri khas | hidden partitioning, spec paling matang | log sederhana, integrasi kuat di ekosistem Spark | upsert dan index level rekam |
Perbedaan tajamnya lebih terasa pada implementasi: Delta Lake menyimpan riwayat sebagai log JSON bernama _delta_log di folder tabel; Iceberg dan Hudi memakai struktur manifest yang lebih banyak lapisan. Hudi unggul pada beban tulis yang sering memperbarui baris tertentu, Iceberg unggul pada kebebasan mendesain partisi tersembunyi, sementara Delta menawarkan model mental paling sederhana untuk tim yang sudah memakai Spark.
Posisi Industri: Open Table Format #
Gelombang adopsi ini dikenal dengan istilah open table format: spesifikasi tabel yang terbuka, dipisahkan dari engine mana pun. Artinya, berkas data tetap berupa Parquet biasa di object storage, dan beberapa engine — Spark, Trino, Flink, hingga DuckDB lewat ekstensinya — dapat membaca tabel yang sama tanpa konversi. Vendor tidak terkunci pada satu engine karena tabelnya tidak dimiliki engine; inilah alasan ketiga format di atas menjadi komponen standar dalam arsitektur lakehouse modern, dan alasan pula mengapa ketiganya kini didukung lintas engine.
Dokumentasi resmi masing-masing tersedia untuk pendalaman: dokumentasi Apache Iceberg , dokumentasi Delta Lake , dan dokumentasi Apache Hudi .
Ketiga format tersebut kini tersedia di lingkungan lokal kita — pyiceberg dan deltalake dapat menulis tabel sungguhan tanpa cluster. Pembahasan mendalam dimulai dari chapter Apache Iceberg.