TL;DR
Lakehouse adalah data lake yang dikasih lapisan tabel transaksional supaya bisa diperlakukan kayak database. Di Databricks, lapisan itu namanya Delta Lake, dan aksesnya lewat SQL biasa. Buat analis, artinya kamu bisa nulis SELECT dan JOIN di atas file Parquet di object storage tanpa harus nunggu data dipindah ke warehouse dulu. Tiga hal yang paling kepakai sehari-hari: SQL Warehouse buat jalanin query, Unity Catalog buat nyari tabel dan ngecek izin akses, dan pola bronze silver gold buat tau tabel mana yang aman dipakai buat laporan.
Lakehouse adalah data lake yang dikasih lapisan tabel, supaya file mentah di object storage bisa kamu query pakai SQL biasa. Nggak perlu dipindah dulu ke database terpisah.
Databricks adalah platform yang paling sering disebut waktu orang ngomongin lakehouse, karena mereka yang mempopulerkan istilahnya lewat format tabel bernama Delta Lake.
Masalahnya, hampir semua penjelasan lakehouse ditulis buat data engineer. Isinya soal cluster, Spark, dan pipeline. Padahal kalau kamu analis, yang kamu butuhin cuma tau tiga hal: di mana tabelnya, mana yang boleh dipakai, dan gimana nulis query-nya.
Aku bahas dari sisi itu.
Lakehouse adalah cara nyimpan data di mana file mentah tetap disimpan di object storage yang murah, tapi ditambahin catatan metadata supaya kumpulan file itu kebaca sebagai satu tabel yang punya kolom, tipe data, dan riwayat perubahan. Hasilnya kamu bisa nulis SELECT dan JOIN di atas data yang secara fisik masih berupa file Parquet.
Buat ngerti kenapa ini muncul, gampangnya lihat dua pendahulunya.
| Aspek | Data warehouse | Data lake | Lakehouse |
|---|---|---|---|
| Format simpan | Internal, tertutup | File terbuka (CSV, Parquet, JSON) | File terbuka + lapisan tabel |
| Bisa di-SQL langsung | Ya | Susah dan lambat | Ya |
| Data tak terstruktur | Nggak cocok | Bisa | Bisa |
| Jaminan transaksi | Ada | Nggak ada | Ada |
| Biaya penyimpanan | Mahal | Murah | Murah |
Data lake awalnya menarik karena murah. Tapi begitu isinya jutaan file, nyari data jadi susah, dan nggak ada yang jamin file yang kamu baca itu lengkap.
Pernah ngalamin query yang hasilnya beda tiap dijalanin, padahal datanya sama? Di data lake tanpa lapisan tabel, itu kejadian biasa, karena proses tulis dan proses baca jalan barengan tanpa saling tahu.
Lakehouse nutup celah itu tanpa balik ke warehouse yang mahal.
Delta Lake adalah format tabel yang nyimpan catatan transaksi di samping file datanya. Tiap kali ada penulisan, catatan itu bertambah satu versi.
Tiga efek yang kerasa buat analis.
Query kamu nggak baca data setengah jadi. Kalau ada proses yang lagi nulis 2 juta baris, query kamu tetap lihat versi terakhir yang lengkap sampai proses itu selesai.
Kamu bisa lihat isi tabel di masa lalu. Ini yang namanya time travel:
-- lihat isi tabel di versi tertentu
SELECT * FROM silver.transaksi VERSION AS OF 118;
-- atau berdasarkan waktu
SELECT * FROM silver.transaksi
TIMESTAMP AS OF '2025-10-01 00:00:00';Fitur ini paling kepakai waktu angka laporanmu berubah tanpa kamu ngapa-ngapain. Tinggal bandingkan versi kemarin sama versi hari ini.
Kamu bisa lihat siapa dan kapan tabel diubah.
DESCRIBE HISTORY silver.transaksi;Perintah ini keluarin daftar versi, operasi yang dilakukan, dan jumlah baris yang kena. Waktu ada laporan yang selisih, ini tempat pertama yang aku cek.
Detail sintaksnya ada di dokumentasi resmi Databricks soal riwayat tabel Delta.
Di hampir semua lakehouse yang aku lihat, tabel disusun tiga lapis. Namanya medallion architecture.
Kesalahan yang paling sering aku lihat dari analis baru: langsung query ke bronze karena namanya kelihatan paling lengkap. Hasilnya angka penjualan kelebihan 12 sampai 20 persen gara-gara duplikat retry dari sistem sumber.
Aturan praktisnya begini. Kalau kamu bikin angka yang bakal dilihat orang lain, pakai gold. Kalau angkanya aneh, telusuri turun ke silver, baru bronze.
Konsep bersih-bersih data ini aku bahas lebih umum di glosarium data quality, dan alur pemindahan datanya di glosarium ETL.
Unity Catalog itu daftar isi lakehouse. Tempat semua tabel didaftarkan, dikasih deskripsi, dan diatur siapa yang boleh baca.
Penamaan tabelnya tiga tingkat: catalog.schema.tabel. Contoh: retail_prod.gold.penjualan_harian.
Yang paling kepakai buat analis:
Satu kebiasaan yang aku saranin: sebelum nulis query panjang, buka dulu deskripsi kolom tabelnya. Banyak selisih angka lahir dari kolom bernama total yang ternyata belum termasuk diskon.
Aku pakai dataset ngulikdata buat gambaran nyata. Ada 3 cabang toko_berkah yang datanya ditarik tiap malam dari sistem kasir masing-masing.
Struktur tabelnya:
bronze.pos_raw: 4,1 juta baris, hasil ekspor mentah, termasuk transaksi yang batalsilver.transaksi: 3,7 juta baris, transaksi batal dan duplikat udah dibuanggold.penjualan_harian: 41 ribu baris, agregat per toko per produk per hariSelisih bronze ke silver 400 ribu baris, atau sekitar 9,8 persen. Itu semua transaksi batal dan kiriman ulang dari kasir yang koneksinya putus.
Kalau kamu query omzet dari bronze, angkanya kelebihan sekitar Rp 214 juta per bulan dibanding hitungan yang benar. Cukup buat bikin rapat jadi ribut.
Query harian yang biasa dipakai buat laporan:
SELECT
nama_toko,
SUM(total) AS omzet
FROM gold.penjualan_harian
WHERE tanggal >= '2025-09-01'
GROUP BY nama_toko
ORDER BY omzet DESC;Dan buat lihat produk mana yang nyumbang paling besar bulan lalu:
SELECT
kode_produk,
SUM(qty) AS qty_total,
SUM(qty * harga) AS nilai
FROM gold.penjualan_harian
WHERE tanggal BETWEEN '2025-09-01' AND '2025-09-30'
GROUP BY kode_produk
HAVING SUM(qty) > 500
ORDER BY nilai DESC
LIMIT 20;Perhatiin bahwa sintaksnya SQL biasa. Nggak ada yang khas Databricks di dua query ini. Itu memang inti dari lakehouse: kamu nulis SQL standar di atas file yang disimpan murah.
Jujur, nggak sebanyak yang dijanjiin brosur.
Yang beneran berubah: kamu bisa akses data yang dulunya "nanti ya, nunggu di-load ke warehouse". Data log aplikasi, data klik, data JSON dari API, semua bisa langsung di-query begitu masuk lakehouse.
Yang berubah kecil: cara nulis query. SQL tetap SQL. GROUP BY, JOIN, window function jalan sama kayak di PostgreSQL atau MySQL.
Yang perlu kamu biasakan: nama tabel jadi tiga tingkat, dan kamu harus tau lapisan mana yang kamu sentuh. Ini kebiasaan baru, bukan skill baru.
Yang nggak berubah: tanggung jawab kamu buat ngecek angka sebelum dikirim. Lakehouse nggak bikin data jadi benar sendiri.
Query langsung ke bronze. Udah aku sebut di atas, tapi ini penyebab selisih angka nomor satu. Cek dulu lapisan tabelnya sebelum nulis SELECT.
SELECT * di tabel besar. File Parquet nyimpan data per kolom, jadi query yang cuma ambil 3 kolom jauh lebih murah dari yang ambil semua. Di tabel 4 juta baris, bedanya bisa belasan kali lipat.
Lupa filter partisi. Kalau tabelnya dipartisi per tanggal, tulis kondisi tanggal di WHERE. Tanpa itu, mesin baca semua file dari awal waktu.
SQL Warehouse dibiarkan nyala. Biaya Databricks dihitung dari waktu komputasi. Warehouse yang nyala semalaman tanpa dipakai tetap kena hitung. Atur auto stop.
Nganggap semua tabel gold udah benar. Gold berarti udah disepakati, bukan berarti bebas salah. Kalau angkanya aneh, tetap telusuri.
Data warehouse nyimpan data dalam format internal miliknya sendiri, jadi kamu harus muat data ke dalamnya dulu sebelum bisa query. Lakehouse nyimpan data sebagai file terbuka, biasanya Parquet, di object storage murah, lalu nambahin lapisan metadata supaya file itu kebaca sebagai tabel. Praktisnya buat kamu sebagai analis, dua-duanya sama saja: nulis SELECT dan dapat hasil.
Nggak wajib. Kalau kerjaanmu query dan bikin laporan, SQL editor dan SQL Warehouse udah cukup. Spark baru kepakai kalau kamu nulis pipeline transformasi atau ngolah data yang formatnya susah dibaca SQL. Banyak analis kerja bertahun-tahun di Databricks tanpa pernah nulis satu baris PySpark.
Delta Lake adalah format tabel yang nambahin catatan transaksi di atas file Parquet. Efek yang kerasa buat kamu: query nggak baca data setengah jadi waktu ada proses tulis yang lagi jalan, dan kamu bisa lihat isi tabel di versi sebelumnya. Kalau angka laporan tiba-tiba berubah, kamu bisa bandingkan versi lama dan baru buat nyari penyebabnya.
Pakai gold buat laporan dan dashboard, karena itu tabel yang udah dibersihkan dan disepakati definisinya. Pakai silver kalau kamu perlu detail per transaksi yang belum diringkas. Hindari bronze buat analisis, karena isinya data mentah apa adanya, termasuk duplikat dan baris gagal. Bronze gunanya buat nelusuri kalau ada angka yang mencurigakan.
Biayanya dihitung dari pemakaian komputasi, bukan lisensi tetap, jadi angkanya beda-beda tergantung ukuran cluster dan berapa lama nyala. Yang paling sering bikin tagihan membengkak itu SQL Warehouse yang lupa dimatikan. Atur auto stop di menit terendah yang masih nyaman, dan cek dokumentasi resmi Databricks buat rincian penagihan terbaru.
Tiga hal yang perlu kamu ingat.
Lakehouse itu data lake plus lapisan tabel, dan buat kamu sebagai analis artinya SQL biasa di atas data yang dulunya susah disentuh. Delta Lake yang bikin itu mungkin, dan fitur time travel-nya paling kepakai waktu ngecek selisih angka. Selalu tau kamu lagi query lapisan bronze, silver, atau gold sebelum kirim laporan.
Kalau kamu mau nyoba, Databricks punya versi gratis buat belajar. Bikin satu tabel dari CSV penjualan yang kamu punya, lalu coba jalanin DESCRIBE HISTORY setelah kamu ubah isinya. Fitur itu paling cepat bikin kamu ngerti bedanya sama file biasa.
Lanjut baca beda data analyst dan data engineer kalau kamu penasaran bagian mana yang jadi tanggung jawab siapa, atau daftar tools data analyst buat gambaran perkakas lain yang sering satu paket sama Databricks.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.