Data Lake vs Data Warehouse vs Lakehouse: Tiga Arah Dibandingkan

Data lake nyimpen file mentah apa adanya, data warehouse nyimpen data yang udah dirapikan jadi tabel siap query, dan lakehouse gabungin keduanya di satu tempat penyimpanan murah.

Tiga istilah ini sering muncul di rapat, sering juga ketuker. Padahal salah pilih di awal bikin tim kamu bayar dua kali: sekali buat bikin, sekali lagi buat migrasi.

Aku bandingin ketiganya pakai satu kasus yang sama, yaitu toko_berkah, retail 12 cabang di Jawa Tengah yang datanya aku pakai buat latihan di ngulikdata.

Apa itu data lake?

Data lake adalah tempat penyimpanan yang nampung file dalam bentuk aslinya, tanpa dirapikan dulu. CSV, JSON, foto struk, log aplikasi, rekaman chat, semuanya masuk. Struktur datanya baru ditentukan waktu kamu baca file itu, bukan waktu nyimpan. Sifat ini yang bikin data lake murah dan fleksibel.

Secara teknis, data lake biasanya cuma storage objek. Amazon S3, Google Cloud Storage, atau Azure Blob. Kamu bayar per GB per bulan, dan angkanya kecil banget dibanding database.

Di toko_berkah, yang masuk data lake itu hal-hal yang nggak berbentuk tabel rapi. Log klik dari toko online, file JSON dari webhook marketplace, dan 3.400 foto bukti kirim dari kurir.

Masalahnya satu: nyimpen gampang, nyari susah. Tanpa katalog dan penamaan yang konsisten, setahun kemudian nggak ada yang tau file export_final_v3_fix.csv itu isinya apa.

Apa itu data warehouse?

Data warehouse adalah database yang dirancang khusus buat analisis. Datanya udah dibersihkan, distandarkan, dan disusun jadi tabel dengan kolom yang jelas. Struktur ditentukan di depan, sebelum data masuk. Hasilnya, query buat laporan jalan cepat dan angkanya konsisten antar tim.

Proses masukin datanya biasa disebut ETL, yaitu ambil data dari sumber, rapikan, lalu simpan ke warehouse.

Contoh produknya: BigQuery, Snowflake, Amazon Redshift, atau PostgreSQL biasa buat skala kecil.

Di toko_berkah, warehouse isinya tabel transaksi, produk, cabang, dan pelanggan. Semua kolom tanggal formatnya sama, semua nama cabang udah distandarkan, dan kolom total_belanja selalu dalam rupiah tanpa titik ribuan.

Kelemahannya biaya. Warehouse ngitung ongkos dari komputasi dan penyimpanan terstruktur, jadi nyimpen 500 GB log mentah di warehouse itu pemborosan.

Apa itu lakehouse?

Lakehouse adalah pola penyimpanan yang naruh file di storage objek murah, lalu nambahin lapisan format tabel di atasnya. Lapisan itu yang bikin file bisa di-update, dihapus baris tertentu, di-rollback ke versi kemarin, dan di-query pakai SQL kayak warehouse. Jadi kamu dapat harga data lake dengan kelakuan data warehouse.

Lapisan tabelnya biasanya Delta Lake, Apache Iceberg, atau Apache Hudi. File fisiknya sendiri format Parquet, yaitu format kolom yang ukurannya jauh lebih kecil dari CSV.

Aku pernah convert satu tahun transaksi toko_berkah dari CSV ke Parquet. Ukurannya turun dari 412 MB jadi 47 MB, dan query hitung total penjualan per cabang yang tadinya 9 detik jadi 1,4 detik di laptop yang sama.

Konsep lakehouse relatif baru dibanding dua lainnya, jadi ekosistem alatnya masih berubah cepat. Kalau tim kamu kecil, ini risiko yang perlu dihitung.

Apa bedanya kalau dibandingin langsung?

Aspek	Data Lake	Data Warehouse	Lakehouse
Bentuk data	File mentah apa adanya	Tabel terstruktur	File Parquet + lapisan tabel
Struktur ditentukan	Waktu dibaca	Waktu ditulis	Waktu ditulis, tapi bisa diubah
Biaya penyimpanan	Paling murah	Paling mahal	Murah
Kecepatan query laporan	Lambat	Cepat	Cepat
Cocok buat	Log, gambar, JSON, data mentah	Laporan, dashboard, KPI	Campuran keduanya
Pengguna utama	Data engineer	Analis dan tim bisnis	Keduanya
Risiko utama	Jadi tumpukan file tanpa arti	Biaya membengkak	Alatnya masih cepat berubah

Baris yang paling sering bikin salah pilih itu baris pengguna utama. Kalau yang bakal pakai setiap hari adalah analis yang jago SQL tapi nggak nyentuh Python, data lake murni bakal bikin mereka mandek.

Gimana milihnya buat tim data kecil?

Jawaban singkatnya: mulai dari warehouse, tambah lake kalau ada data yang bukan tabel, pindah ke lakehouse kalau biaya warehouse mulai kerasa.

1. Cek bentuk data kamu sekarang. Kalau 90 persen datanya udah berbentuk baris dan kolom, warehouse cukup.
2. Cek siapa yang bakal query. Analis SQL butuh tabel. Kalau tim kamu isinya analis, jangan kasih mereka folder berisi 2.000 file JSON.
3. Cek volume per bulan. Di bawah 100 GB per bulan, biaya warehouse masih wajar. Di atas itu, hitung ulang.
4. Cek kebutuhan data historis mentah. Kalau kamu wajib nyimpen data asli buat audit, kamu butuh lake atau lakehouse.
5. Cek kapasitas tim. Lakehouse butuh orang yang nyaman ngurus format tabel dan job pemrosesan. Kalau nggak ada, jangan dipaksa.

Sebelum mutusin arsitekturnya, aturan main soal siapa yang punya data mana harus jelas duluan. Aku bahas kerangkanya di data governance untuk tim data kecil.

Contoh kasus: toko_berkah pilih yang mana?

Toko_berkah punya 12 cabang, sekitar 4.800 transaksi per bulan, dan tim data isinya 2 orang. Satu analis, satu orang IT yang juga ngurus kasir.

Data yang mereka punya:

• Transaksi kasir: 115.000 baris untuk 2 tahun, total 38 MB dalam bentuk CSV
• Data produk dan stok: 2.100 baris, update harian
• Log webhook marketplace: sekitar 900 MB per bulan dalam JSON
• Foto bukti kirim: 3.400 file, total 6,8 GB

Keputusannya jadi jelas begitu dipisah. Transaksi, produk, dan stok masuk warehouse karena itu yang dipakai buat laporan mingguan. JSON webhook dan foto bukti kirim masuk storage objek murah, dan cuma diproses kalau ada keperluan tertentu.

Angka yang bikin keputusan ini gampang: kalau semua 6,8 GB foto plus log JSON dipaksa masuk warehouse, biaya penyimpanan bulanannya naik sekitar 14 kali lipat dibanding naruh file yang sama di storage objek. Sementara nilai analitiknya nyaris nol, karena nggak ada satupun laporan mingguan yang pakai foto.

Pola ini yang aku sebut warehouse dulu, lake nyusul. Untuk tim di bawah 5 orang, ini yang paling cepat jalan.

Kesalahan umum waktu milih arsitektur data

1. Bikin data lake karena keren, bukan karena butuh. Kalau semua data kamu berbentuk tabel dan volumenya di bawah 50 GB, data lake cuma nambah kerjaan.

2. Nyimpen semua data mentah ke warehouse. Log aplikasi yang 900 MB per bulan itu bakal jadi tagihan yang bikin kaget di bulan keempat.

3. Nggak bikin katalog dari hari pertama. Satu spreadsheet berisi nama dataset, isi, pemilik, dan tanggal update terakhir udah cukup buat awal.

4. Ngeskip pembersihan data. Mau arsitekturnya apapun, kalau nama cabang di sumbernya ditulis lima versi berbeda, laporannya tetap salah. Cek dulu soal kualitas data sebelum mikirin storage.

5. Ngira lakehouse bikin transformasi jadi nggak perlu. Tetap perlu. Datanya tetap harus dirapikan jadi tabel yang siap dipakai, dan alat kayak dbt yang ngerjain itu. Kalau belum pernah, coba dulu bikin model dbt pertama.

6. Nggak nentuin definisi metrik. Arsitektur nggak nyelesaiin masalah dua tim ngitung KPI yang sama dengan rumus berbeda.

FAQ

Data lake itu sama dengan database biasa?

Beda. Database biasa nyimpen data dalam bentuk tabel dengan struktur yang udah ditentukan di awal. Data lake nyimpen file apa adanya: CSV, JSON, foto struk, log aplikasi. Kamu baru nentuin strukturnya waktu mau baca. Makanya data lake fleksibel buat data yang bentuknya belum jelas, tapi butuh usaha ekstra sebelum bisa dipakai laporan.

UMKM kayak toko kecil butuh data lake nggak?

Kalau data kamu masih muat di spreadsheet dan semuanya berbentuk tabel, nggak butuh. Data lake baru masuk akal kalau kamu mulai nyimpen hal yang bukan tabel, misalnya rekaman chat CS, foto bukti kirim, atau log klik dari toko online. Sebelum itu, satu database plus spreadsheet udah cukup.

Lakehouse itu produk atau konsep?

Konsep, tapi ada produk yang ngejalanin. Intinya kamu simpan file Parquet di storage murah, lalu pakai format tabel kayak Delta Lake, Apache Iceberg, atau Apache Hudi biar file itu bisa di-update, di-rollback, dan di-query kayak tabel warehouse. Databricks, Snowflake, dan BigQuery sekarang sama-sama dukung pola ini.

Kalau tim aku cuma 3 orang, mulai dari mana?

Mulai dari warehouse kecil. Satu database analitik, satu skema mentah, satu skema rapi, dan alat transformasi kayak dbt. Pola ini yang paling cepat kasih hasil karena tim kamu bisa langsung nulis SQL. Data lake bisa nyusul kalau nanti ada data yang bentuknya bukan tabel.

Kenapa data lake sering disebut rawan jadi rawa data?

Soalnya nyimpen file itu gampang, ngerapiinnya yang susah. Kalau nggak ada katalog, penamaan yang konsisten, dan pemilik yang jelas per dataset, dalam setahun kamu punya ribuan file yang nggak ada yang tau isinya apa. Aturan main soal kepemilikan data harus jalan duluan sebelum volume filenya naik.

Penutup

Tiga hal yang perlu kamu inget:

• Warehouse buat data yang dipakai laporan, lake buat data mentah yang bentuknya bukan tabel, lakehouse kalau kamu butuh dua-duanya di satu tempat.
• Ukuran tim lebih menentukan dari ukuran data. Tim 2 orang jarang sanggup ngurus data lake dengan benar.
• Katalog dan definisi metrik harus jalan duluan. Arsitektur secanggih apapun nggak nolong kalau nggak ada yang tau isi datanya apa.

Buat detail teknis storage objek dan pola data lake, dokumentasi resmi AWS soal data lake penjelasannya cukup lengkap dan netral.

Sekarang giliran kamu. Buka daftar dataset yang tim kamu punya, tandai mana yang berbentuk tabel dan mana yang bukan. Dari situ pilihan arsitekturnya bakal kelihatan sendiri.