TL;DR
Data warehouse nyimpen data yang udah dirapihin dan dibentuk sesuai struktur tabel, jadi langsung bisa dipakai buat dashboard dan laporan. Data lake nyimpen data mentah apa adanya (CSV, JSON, foto, log server) dan bentuknya baru ditentukan pas mau dipakai. Buat sebagian besar perusahaan Indonesia yang datanya di bawah 1 TB dan kebutuhannya laporan bisnis, data warehouse aja udah cukup dan jauh lebih murah dirawat.
Data warehouse nyimpen data yang udah dirapihin jadi tabel. Data lake nyimpen file mentah apa adanya.
Konsekuensinya besar. Warehouse cepat buat laporan tapi kaku. Lake fleksibel tapi gampang berantakan sampai gak ada yang tau isinya apa.
Aku jelasin dua-duanya, terus kasih panduan konkret buat milih: berdasarkan ukuran data dan tipe pertanyaan yang mau kamu jawab.
Data warehouse adalah tempat penyimpanan data yang isinya udah dibentuk jadi tabel dengan kolom dan tipe data yang jelas. Data masuk ke sini setelah dibersihin dan disesuaikan dengan struktur yang udah ditentukan.
Istilahnya: schema on write. Kamu tentuin bentuknya duluan, baru datanya boleh masuk.
Isi warehouse toko_berkah kira-kira gini:
penjualan: kolom tanggal, id_produk, jumlah, total_harga.produk: kolom id_produk, nama, kategori, harga.customer: kolom id_customer, nama, kota, tanggal_daftar.Rapi. Dan karena rapi, query-nya cepat.
SELECT
p.kategori,
SUM(j.total_harga) AS omzet
FROM penjualan AS j
JOIN produk AS p ON p.id_produk = j.id_produk
WHERE j.tanggal >= DATE '2026-06-01'
GROUP BY p.kategori
ORDER BY omzet DESC;Query kayak gini jalan dalam hitungan detik di warehouse, bahkan buat puluhan juta baris.
Contoh warehouse: BigQuery, Snowflake, Redshift. Dan buat data yang belum gede, Postgres biasa pun udah bisa jadi warehouse yang layak.
Data lake adalah tempat penyimpanan file mentah apa adanya. CSV, JSON, foto produk, rekaman call center, log aplikasi. Semuanya masuk tanpa dibentuk dulu.
Istilahnya: schema on read. Bentuknya baru ditentuin pas kamu mau baca datanya.
Kenapa ada yang mau nyimpen data berantakan? Tiga alasan:
Murah. Nyimpen 1 TB di object storage kayak S3 atau GCS jauh lebih murah dari nyimpen 1 TB di warehouse.
Nerima apa aja. Data yang bentuknya gak beraturan (log aplikasi, rekaman video, JSON dari API pihak ketiga) gak perlu dipaksa masuk tabel.
Gak buang data. Kamu belum tau data itu bakal berguna buat apa. Simpan aja dulu, bentuknya nanti.
Yang jarang diomongin: alasan ketiga itu juga yang bikin data lake gagal.
| Aspek | Data Warehouse | Data Lake |
|---|---|---|
| Bentuk data | Tabel terstruktur | File mentah apa adanya |
| Kapan bentuk ditentukan | Sebelum masuk (schema on write) | Pas dibaca (schema on read) |
| Cara akses | SQL | Spark, Python, atau query engine di atasnya |
| Biaya penyimpanan | Lebih mahal per GB | Murah |
| Kecepatan query bisnis | Cepat | Lebih lambat |
| Siapa yang pakai | Analis, tim bisnis | Data engineer, data scientist |
| Risiko utama | Kaku, ubah struktur ribet | Jadi data swamp |
| Cocok buat | Laporan, dashboard, KPI | Data gak terstruktur, machine learning |
Data swamp adalah data lake yang gak diurus sampai gak ada yang tau isinya apa.
Gejalanya khas: ratusan file dengan nama penjualan_final.csv, penjualan_final_v2.csv, penjualan_final_v2_FIX.csv. Gak ada dokumentasi. Gak ada yang berani hapus karena takut ternyata kepakai.
Aku pernah lihat satu perusahaan retail dengan 4 TB data lake yang cuma 6 persennya pernah dibaca ulang. Sisanya biaya penyimpanan tanpa manfaat.
Pencegahannya bukan tool. Tapi aturan:
sumber/tahun/bulan/tanggal/.toko_berkah punya 3 cabang, 84.000 transaksi setahun, plus toko online. Total datanya sekitar 2 GB.
Pertanyaan yang sering muncul dari owner:
Ketiganya pertanyaan terstruktur. Jawabannya ada di tabel penjualan, produk, dan customer. Data lake gak bantu apa-apa di sini. Malah bikin lebih ribet karena kamu harus nulis kode buat baca file mentah.
Yang toko_berkah butuh: satu Postgres, tiga tabel, dan query yang bisa dipakai ulang. Biaya Rp 150.000 sebulan di VPS.
Kapan itu berubah? Kalau owner mulai nanya hal kayak ini:
Tiga pertanyaan itu butuh data yang gak muat di tabel: teks bebas, gambar, video. Di situ data lake mulai masuk akal.
Aturan praktis yang aku pakai:
Data kamu di bawah 1 TB dan semuanya terstruktur (transaksi, customer, produk)? Data warehouse. Bahkan Postgres biasa udah cukup. Jangan bikin data lake cuma karena kedengeran canggih.
Kamu punya data gak terstruktur dalam jumlah besar (log, gambar, teks bebas) dan mau dipakai buat model? Data lake, dengan warehouse di sebelahnya buat laporan bisnis.
Kamu udah punya lake yang besar tapi analis kamu maunya query pakai SQL? Ini kasus di mana lakehouse masuk akal: pendekatan yang ngasih lapisan tabel di atas file mentah. Yang populer: Apache Iceberg dan Delta Lake.
Buat mayoritas perusahaan Indonesia yang aku lihat, jawabannya yang pertama. Dan itu bukan hal yang memalukan. Warehouse sederhana yang dipakai tiap hari jauh lebih berguna dari lake canggih yang gak ada yang buka.
Bikin data lake karena datanya "bakal gede nanti". Nanti itu kapan? Kalau data kamu tumbuh 2 GB setahun, kamu punya waktu bertahun-tahun sebelum warehouse kewalahan.
Mikir lake itu pengganti warehouse. Di perusahaan yang punya dua-duanya, lake nyimpen data mentah, dan hasil olahannya tetep masuk warehouse buat dipakai analis. Bukan pilih salah satu.
Numpuk data mentah tanpa katalog. Ini jalan tercepat menuju data swamp. Tulis dokumentasi dari file pertama, bukan dari file kelima ratus.
Ngukur kesuksesan dari volume data. "Kita punya 10 TB data" itu bukan pencapaian. "Kita bisa jawab 8 pertanyaan bisnis dalam 5 menit" itu baru pencapaian.
Lupa bahwa dua-duanya butuh SQL. Baik warehouse maupun lakehouse modern, cara ambil datanya SQL. Kalau kamu bingung mulai dari mana buat karir data, mulai dari SQL, bukan dari milih arsitektur.
Data warehouse nyimpen data yang udah dibentuk jadi tabel rapi dengan kolom dan tipe data yang jelas, siap langsung diquery. Data lake nyimpen file mentah apa adanya (CSV, JSON, gambar, log) tanpa struktur tetap, dan bentuknya baru ditentukan pas dibaca. Warehouse cepat buat laporan bisnis. Lake fleksibel buat data yang bentuknya belum ketahuan mau dipakai buat apa.
Hampir pasti nggak. Data lake masuk akal kalau kamu punya data yang bentuknya gak beraturan dalam jumlah besar: rekaman video, log aplikasi jutaan baris per hari, atau data sensor. Kalau data kamu isinya transaksi, customer, dan produk, itu semua terstruktur, dan data warehouse jauh lebih murah plus lebih gampang dirawat.
Data lake yang gak diurus sampai gak ada yang tau isinya apa. Ini kegagalan paling umum dari proyek data lake. Gejalanya: ratusan file dengan nama kayak data_final_v3_fix.csv, gak ada dokumentasi, dan gak ada yang berani hapus karena takut kepakai. Pencegahannya: katalog data dan aturan penamaan yang ditegakkan sejak file pertama masuk.
Lakehouse itu pendekatan yang nyimpen data mentah kayak lake, tapi ngasih lapisan tabel dan transaksi di atasnya kayak warehouse. Yang populer: Databricks Delta Lake dan Apache Iceberg. Berguna kalau kamu udah punya lake yang besar dan pengen bisa query pakai SQL biasa. Buat perusahaan yang baru mulai, ini terlalu berlebihan.
Pindah ke database dulu, bukan ke data lake. Postgres gratis dan sanggup nangani puluhan juta baris. Sinyal buat pindah: file Sheets kamu udah lemot dibuka, atau lebih dari dua orang ngedit file yang sama dan angkanya sering beda. Data warehouse cloud kayak BigQuery baru masuk akal pas datanya lewat ratusan giga.
Apa pun yang kamu pilih, cara ambil datanya sama: SQL. Latihan sampai lancar di NgulikSQL, itu skill yang gak berubah walaupun arsitekturnya ganti.
Lanjut baca: ETL vs ELT, gimana data-nya sampai ke warehouse atau lake kamu.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Cara pakai pandas rolling buat hitung moving average dan haluskan data time series yang naik-turun. Lengkap dengan contoh penjualan harian UMKM.
Data transaksi harian sering terlalu ramai buat dilihat. Pandas resample ngeringkasnya jadi total per minggu atau per bulan cuma dengan satu baris, asal indeksnya tanggal.
Kolom tanggal yang kebaca sebagai teks bikin sortir dan hitung selisih hari jadi kacau. Ini cara pd.to_datetime ubah teks jadi tanggal asli, plus tangani format berantakan.