Warehouse yang kita rancang sepanjang section ini menuntut data berbentuk tabel relasional dengan skema tegas sebelum data boleh masuk. Kenyataannya, data organisasi jauh lebih beragam: log aplikasi per baris, event klik website dalam JSON, foto produk, dokumen PDF, hingga data sensor. Data lake lahir sebagai jawaban atas keterbatasan tersebut — menampung data apa pun bentuknya, apa adanya, dengan biaya penyimpanan rendah. Memahami perbedaan keduanya adalah keputusan arsitektur, bukan sekadar pilihan produk.
Struktur Terkurasi vs Mentah Semua Format #
Data warehouse menyimpan data yang sudah melalui pemodelan: tabel berdimensi, bertipe jelas, dan tervalidasi. Setiap baris yang masuk sudah melewati pipeline transformasi sehingga siap dianalisis begitu tiba. Data lake sebaliknya menyimpan data mentah dalam format aslinya — CSV hasil ekspor, file JSON per event, log teks, hingga biner — disimpan lebih dulu, diolah belakangan.
Karakter tersebut mengubah posisi kedua sistem dalam arsitektur. Warehouse berada di ujung pipeline sebagai tempat penyajian: datanya sedikit dibanding sumber, tetapi setiap kolomnya bermakna. Lake berada di awal pipeline sebagai tempat penampungan: datanya lengkap dan murah disimpan, tetapi belum tentu siap dipakai.
Schema-on-Write vs Schema-on-Read #
Perbedaan mendasar keduanya ada pada kapan skema diterapkan. Warehouse memakai schema-on-write: skema ditetapkan sebelum data ditulis, dan data yang tidak sesuai ditolak saat load. Harganya, perubahan kebutuhan analitik menuntut perubahan skema dan transformasi ulang; keuntungannya, query berjalan cepat dan konsisten karena struktur sudah dijamin sejak awal.
Data lake memakai schema-on-read: data disimpan dulu tanpa struktur, lalu skema diterapkan ketika data dibaca. Event baru dengan kolom tambahan langsung tersimpan tanpa migrasi; ilmuwan data bisa mencoba interpretasi berbeda atas data yang sama. Konsekuensinya, validasi dan pembersihan bergeser ke saat pembacaan — data kotor baru ketahuan ketika query gagal atau hasilnya janggal.
Perbandingan dan Kapan Memakainya #
| Aspek | Data Warehouse | Data Lake |
|---|---|---|
| Bentuk data | terstruktur, tabel relasional | mentah, semua format (CSV, JSON, log, gambar) |
| Penerapan skema | schema-on-write | schema-on-read |
| Kualitas saat tersimpan | tinggi, tervalidasi saat load | belum terjamin |
| Pengguna utama | analis BI, dashboard, pelaporan | data scientist, eksplorasi, pelatihan model |
| Biaya penyimpanan | relatif mahal per TB | murah, berbasis object storage |
| Kecepatan analitik | cepat dan terprediksi | bergantung format dan pemrosesan |
| Risiko khas | data bentuk baru sulit masuk | menjadi data swamp bila tanpa tata kelola |
Sebagai pedoman praktis: pilih warehouse ketika kebutuhan analitik sudah mapan, metrik terdefinisi (semantic layer membantu persis di titik ini), dan pengguna utamanya adalah dashboard serta laporan rutin. Pilih lake ketika volume data besar dan bentuknya beragam, ketika data disimpan untuk keperluan yang belum pasti, atau ketika data tersebut bahan baku pelatihan model machine learning. Format kolom seperti Parquet menjadi pilihan umum di lake karena kompresi baik dan tetap efisien dibaca mesin analitik seperti DuckDB .
Dari sisi biaya, warehouse menggabungkan storage dan compute yang keduanya teroptimasi untuk query cepat, sehingga harga per TB relatif tinggi; lake memisahkan keduanya — penyimpanan object storage murah, sementara compute hanya dibayar saat dipakai. Selisih struktur tersebut membuat lake unggul untuk retensi data jangka panjang yang jarang dibaca, dan warehouse unggul untuk data panas yang menyuplai dashboard setiap hari.
Banyak Organisasi Memakai Keduanya #
Keduanya bukan pesaing yang saling menggantikan. Pola umum industri: lake menampung data mentah dari seluruh sumber, lalu subset yang relevan ditransformasi ke warehouse untuk BI; ilmuwan data bekerja langsung di lake, analis bekerja di warehouse.
Pada diagram di atas, satu sumber operasional mengalir ke dua arah dengan perlakuan berbeda: jalur warehouse melakukan transformasi terlebih dahulu demi kualitas dan kecepatan, sedangkan jalur lake menyimpan apa adanya demi kelengkapan dan biaya rendah. Dua jalur tersebut kemudian melayani dua kelompok pengguna berbeda.
Perbandingan warehouse dan lake menyisakan satu gesekan: dua salinan data untuk dua kelompok pengguna berarti duplikasi biaya dan risiko inkonsistensi. Arsitektur lakehouse berupaya menyatukan keunggulan keduanya — pembahasan lanjutannya ada di Chapter Data Warehouse vs Lakehouse, sementara pendalaman konsep lake secara penuh menanti di Section Data Lake dan Lakehouse.