Chapter Data Warehouse vs Data Lake berakhir pada satu gesekan: pola dua salinan membuat organisasi membayar penyimpanan dua kali dan berisiko memelihara dua kebenaran. Lakehouse muncul untuk menutup gesekan tersebut — arsitektur yang menempatkan kekuatan warehouse (transaksi ACID, performa SQL, tata kelola) di atas fondasi murah milik lake (object storage dan format terbuka). Sekali pandang, lakehouse terlihat seperti warehouse yang dipindah lokasi; perbedaan sebenarnya ada pada tiga komponen yang menyusunnya.
Evolusi: Warehouse, Lake, lalu Lakehouse #
Gelombang pertama adalah data warehouse: terkurasi, cepat, dan mahal; data harus melalui transformasi sebelum diterima. Gelombang kedua adalah data lake: menerima data mentah apa adanya di atas object storage murah, tetapi kehilangan jaminan warehouse — tanpa transaksi ACID, tanpa enforce skema konsisten, dan query analitik harus menyisir file mentah.
Lakehouse adalah gelombang ketiga. Alih-alih memilih salah satu, lakehouse menaruh lapisan tabel bertransaksi di atas file di object storage: data tetap berupa file Parquet murah, namun kini punya katalog, skema, dan kemampuan transaksi seperti tabel database. Mekanisme time travel pada lapisan tersebut juga menyimpan riwayat versi tabel, sehingga query dapat membaca kembali keadaan tabel pada titik waktu lampau.
Tiga Komponen Lakehouse #
| Komponen | Peran | Contoh |
|---|---|---|
| Object storage | menyimpan file data secara murah dan tahan lama | Amazon S3, MinIO |
| Table format | metadata tabel: skema, partisi, snapshot, transaksi | Apache Iceberg, Delta Lake, Apache Hudi |
| Query engine | membaca tabel lewat standar terbuka | DuckDB, Trino, Spark |
Diagram di atas memperlihatkan pemisahan tanggung jawab: object storage hanya menyimpan file; table format menjaga metadata sehingga file mentah berperilaku seperti tabel; engine mana pun yang memahami format tersebut dapat membaca tabel yang sama tanpa salinan tambahan.
Keunggulan Lakehouse #
Keunggulan pertama adalah satu salinan data. SQL dan machine learning membaca tabel yang sama di tempat yang sama, sehingga tidak ada pipa sinkronisasi antar dua sistem dan tidak ada dua versi kebenaran yang harus didamaikan. Keunggulan kedua adalah format terbuka: data tersimpan sebagai Parquet plus metadata berstandar, bukan format privat vendor, sehingga engine dapat berganti tanpa memindahkan data. Keunggulan ketiga adalah satu tempat untuk seluruh beban kerja: analis menjalankan SQL, pipeline dbt membangun model, dan tim ML melatih model — semuanya di atas tabel yang sama.
Trade-off yang Perlu Diterima #
Lakehouse bukan tanpa harga. Operasinya lebih kompleks: file kecil perlu dikompaksi, snapshot metadata perlu dirawat, dan pemilihan table format menjadi komitmen jangka panjang. Untuk beban BI murni berskala kecil hingga menengah, warehouse terkelola (managed) tetap lebih sederhana: tanpa perawatan file, tanpa pemilihan format, dengan ekosistem yang sangat matang. Terakhir, kebebasan memilih engine berarti performa tidak dijamin seragam — dua engine membaca tabel yang sama bisa memberi hasil berbeda kecepatannya, dan penyetelan menjadi tanggung jawab tim data.
Posisi Industri 2026 #
Tiga table format mendominasi percakapan industri. Apache Iceberg versi 1.12.0 tumbuh menjadi standar de facto terbuka — didukung luas lintas engine, termasuk dukungan tabel Iceberg di platform seperti Databricks dan Snowflake. Delta Lake 3.x kuat di ekosistem Spark dan Databricks, sedangkan Apache Hudi 1.x unggul pada beban upsert dan CDC berfrekuensi tinggi. Sisi engine juga ramai: DuckDB 1.5.x mempopulerkan analitik ringan di laptop, Trino (versi terbaru) menandingi query federasi lintas sumber, dan Spark 4.2.0 tetap andalan pemrosesan skala besar.
| Aspek | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Penyimpanan | storage khusus vendor | object storage, file mentah | object storage + table format |
| Penerapan skema | schema-on-write | schema-on-read | schema enforcement di lapisan tabel |
| Transaksi ACID | ya | tidak bawaan | ya, lewat table format |
| Keterbukaan format | tertutup | terbuka | terbuka (Parquet + metadata) |
| ML dan SQL satu tempat | terbatas | perlu usaha | ya |
| Kompleksitas operasi | rendah (managed) | sedang | tinggi |
Dokumentasi resmi ketiga format tersebut tersedia di Apache Iceberg , Delta Lake , dan Apache Hudi . Perjalanan section ini berakhir di sini: dari dimensional modeling, surrogate key, SCD, snapshot, data mart, hingga semantic layer, kita membangun warehouse yang sehat — dan kini tahu kapan fondasinya layak digeser ke arsitektur lakehouse. Praktik membangun lakehouse itu sendiri, dari object storage hingga pemilihan arsitektur, menjadi fokus Section Data Lake dan Lakehouse.