Toko online menghasilkan data yang jauh lebih beragam daripada sekadar tabel transaksi. Ada jejak klik di situs, log server berformat teks, dokumen struk pembelian, foto produk, hingga event dari aplikasi mobile. Data warehouse klasik yang dirancang untuk data terstruktur dengan schema tetap kesulitan menampung semua bentuk data tersebut, sementara membuangnya berarti kehilangan bahan analitik yang berharga. Data lake lahir untuk menjawab masalah ini: satu wadah penyimpanan yang menerima data mentah dalam format apa pun, dengan struktur ditetapkan belakangan saat data dibaca.
Definisi Data Lake #
Data lake adalah repositori terpusat yang menyimpan data dalam kondisi mentah (raw) — apa adanya dari sumbernya — baik data terstruktur (tabel database), semi-terstruktur (JSON, XML, log), maupun tidak terstruktur (gambar, dokumen, audio). Prinsip intinya sederhana: simpan dulu semuanya, olah nanti. Definisi resmi dari penyedia cloud, misalnya penjelasan AWS tentang data lake , menekankan hal yang sama: satu tempat untuk semua data sebelum diproses lebih lanjut.
Perbedaan mendasar dengan pendekatan warehouse terletak pada kapan schema diterapkan:
| Aspek | Data Warehouse | Data Lake |
|---|---|---|
| Schema | ditetapkan saat menulis (schema-on-write) | ditetapkan saat membaca (schema-on-read) |
| Jenis data | terstruktur, sudah dibersihkan | semua format, kondisi mentah |
| Biaya simpan per GB | relatif mahal | murah (object storage) |
| Pengguna utama | analitik SQL dan BI | data engineer, data scientist, ML |
Kenapa Data Lake Muncul #
Tiga tekanan praktis mendorong lahirnya data lake. Pertama, biaya: penyimpanan berbasis object storage jauh lebih murah per gigabyte dibanding disk database, sehingga menyimpan data mentah dalam jangka panjang menjadi masuk akal secara ekonomi. Kedua, ragam data: mayoritas data baru perusahaan berupa semi-terstruktur dan tidak terstruktur yang tidak muat dalam tabel warehouse. Ketiga, ketidakpastian: nilai data sering baru terlihat bertahun-tahun kemudian — log yang tadinya dianggap sampah teknis ternyata menjadi bahan utama deteksi penipuan, sehingga menyimpan semuanya dianggap investasi, bukan pemborosan.
Schema-on-Read #
Pada warehouse, data harus sesuai schema sebelum boleh masuk; schema yang berubah berarti proses ingestion ikut diubah. Data lake membalik urutannya. File disimpan apa adanya, lalu saat sebuah query atau job membaca file tersebut, pembaca menerapkan struktur yang dibutuhkan: kolom mana yang diambil, tipe apa yang dipakai, dan baris mana yang diabaikan. Dua pembaca yang berbeda bisa menerapkan dua schema berbeda pada file yang sama — satu tim membaca kolom harga sebagai integer, tim lain mengabaikannya.
Konsekuensinya ada dua sisi. Sisi baik: ingestion menjadi cepat karena tidak ada pemeriksaan yang menghambat, dan data historis bisa dibaca ulang dengan definisi baru tanpa memuat ulang. Sisi buruk: galat pada data baru terasa saat membaca, bukan saat menulis, sehingga pemeriksaan kualitas harus dipindahkan ke proses pembacaan atau ke zona turunannya.
Risiko: Data Swamp #
Gejala data swamp biasanya muncul bertahap: folder bernama final_v2_fix, salinan data yang sama di sepuluh tempat berbeda, dan kolom yang tidak ada yang sanggup menjelaskan artinya. Obatnya bukan teknologi semata, melainkan tata kelola: katalog yang mencatat setiap dataset, metadata yang menjelaskan asal dan makna, kontrol akses per zona, serta kebijakan retensi yang menentukan kapan data dihapus. Kita akan bahas tata kelola ini lebih dalam pada section Keamanan dan Tata Kelola Data.
Posisi Data Lake dalam Platform Data #
Data lake jarang berdiri sendiri. Dalam sebuah platform data, data lake berperan sebagai lapisan penyimpanan di tengah: menerima dari berbagai sumber, lalu melayani berbagai konsumen. Diagram berikut memperlihatkan posisinya:
Sumber di sisi kiri mengirim data melalui pipeline ingestion; data lake menyimpan semuanya; konsumen di sisi kanan membaca dengan schema masing-masing. Perhatikan jalur ke data warehouse: pola umum di industri adalah lake menyimpan data mentah, lalu sebagian diproses menjadi tabel terstruktur di warehouse untuk pelaporan. Kombinasi keduanya — transaksi ACID dan schema yang dikelola di atas object storage — kemudian memunculkan arsitektur lakehouse yang kita bahas di ujung section ini.
Meski konsepnya menjanjikan, data lake tetap butuh fondasi teknis: tempat penyimpanan yang murah, tahan lama, dan bisa diakses layanan lain. Fondasi itu adalah object storage, yang menjadi materi chapter berikutnya.