Databricks dan Konsep Lakehouse untuk Analis Data

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.

Apa itu lakehouse?

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: bagian yang bikin lakehouse jalan

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.

Bronze, silver, gold: mana yang boleh kamu pakai?

Di hampir semua lakehouse yang aku lihat, tabel disusun tiga lapis. Namanya medallion architecture.

• Bronze. Data mentah apa adanya dari sumber. Duplikat masih ada, tipe data masih teks semua, baris gagal masih nyangkut. Jangan dipakai buat laporan.
• Silver. Udah dibersihkan dan digabung. Satu baris satu transaksi, tipe data udah benar, duplikat udah dibuang. Pakai kalau kamu butuh detail.
• Gold. Udah diringkas sesuai kebutuhan bisnis. Definisi kolomnya udah disepakati. Ini yang dipakai dashboard dan laporan.

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: cara nyari tabel tanpa nanya orang

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:

1. Pencarian tabel. Ketik "penjualan" di kolom cari, dan kamu dapat semua tabel yang namanya atau deskripsinya nyambung. Ini ngirit banyak waktu nanya di grup.
2. Lineage. Tampilan yang nunjukin tabel gold ini dibikin dari tabel silver mana. Berguna waktu kamu mau tau angka di dashboard asalnya dari mana.
3. Izin akses. Kalau query kamu ditolak, di sini kelihatan siapa pemilik tabelnya, jadi kamu tau harus minta izin ke siapa.

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.

Contoh kasus: query penjualan toko_berkah di lakehouse

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 batal
• silver.transaksi: 3,7 juta baris, transaksi batal dan duplikat udah dibuang
• gold.penjualan_harian: 41 ribu baris, agregat per toko per produk per hari

Selisih 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.

Apa yang berubah buat kerjaan analis sehari-hari?

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.

Kesalahan umum waktu mulai pakai lakehouse

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.

FAQ

Apa bedanya lakehouse sama data warehouse biasa?

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.

Analis data perlu belajar Spark buat pakai Databricks?

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.

Apa itu Delta Lake dan kenapa penting buat analis?

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.

Kapan tabel bronze, silver, dan gold boleh dipakai?

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.

Berapa biaya pakai Databricks buat tim kecil?

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.

Penutup

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.