Data lake yang baru dipasang masih berupa bucket kosong dengan satu pertanyaan menunggu: data mentah dari puluhan sumber itu diletakkan di mana, dan siapa boleh membacanya? Tanpa arsitektur, jawaban default adalah menumpuk semuanya di satu prefix — keputusan yang membuat lake sulit dipakai dalam hitungan bulan. Arsitektur data lake menjawab pertanyaan tersebut dengan tiga keputusan: membagi storage menjadi zona berdasarkan tingkat kematangan data, mencatat setiap dataset di katalog, dan membatasi akses per zona.
Zona dalam Data Lake #
Pembagian zona mengikuti perjalanan data: dari mentah di saat masuk hingga siap saji di saat dikonsumsi. Empat zona berikut adalah pola yang paling sering dipakai:
| Zona | Isi | Format umum | Konsumen |
|---|---|---|---|
| Raw | data persis dari sumber, belum divalidasi | JSONL, Avro, CSV, apa adanya | data engineer, audit |
| Staging | data yang sedang divalidasi dan dibersihkan | Parquet sementara | job transformasi |
| Curated | data bersih berschema stabil, kontrak untuk konsumen | Parquet terpartisi | analyst, data scientist |
| Serving | agregat dan fitur siap pakai | Parquet, tabel warehouse | dashboard, model ML |
Dunia industri juga mengenal penamaan medallion architecture untuk pola yang serupa: bronze untuk raw, silver untuk staging dan curated, gold untuk serving. Definisi resminya terdokumentasi di arsitektur medallion Databricks — nama zona boleh berbeda antar perusahaan, yang penting tingkat kematangan datanya konsisten.
Alur dari Ingestion sampai Serving #
Setiap zona hanya menerima data dari zona sebelumnya. Urutan tersebut menjaga arah transformasi tetap searah sehingga kegagalan di satu tahap tidak menular ke data yang sudah jadi:
Job ingestion menulis ke zona raw sekali, lalu tidak pernah menyentuhnya lagi — zona raw bersifat immutable sehingga proses ulang selalu bisa memulai dari data asli. Job berikutnya membaca raw, memvalidasi, dan menulis hasilnya ke staging; job transformasi membaca staging dan menulis curated dengan schema yang dijanjikan ke konsumen; terakhir, job penyaji menyiapkan agregat di zona serving. Ketika sebuah laporan diragukan, kita bisa menelusuri balik: serving dibuat dari curated tertentu, curated dari berkas raw tertentu — penelusuran semacam ini disebut lineage.
Metadata dan Catalog #
Semakin banyak zona, semakin besar kebutuhan menjawab pertanyaan seperti “tabel transaksi ini berasal dari berkas mana dan diperbarui kapan terakhir”. Jawabannya disimpan sebagai metadata di sebuah catalog. Catalog mencatat paling tidak tiga hal: lokasi fisik dataset, schema beserta riwayat perubahannya, dan informasi tambahan seperti pemilik serta jadwal pembaruan. Beberapa katalog yang umum dipakai adalah Hive Metastore di ekosistem Hadoop, AWS Glue Data Catalog di AWS, dan katalog yang melekat pada table format modern seperti Apache Iceberg — kita akan bertemu katalog jenis ini pada chapter Table Formats.
Kontrol Akses per Zona #
Tingkat kepekaan data berbeda antar zona: berkas mentah di raw bisa memuat nomor telepon pelanggan, sedangkan tabel di serving mungkin hanya berisi agregat aman. Kontrol akses karena itu dipasang per zona, bukan satu kebijakan untuk seluruh lake. Dua lapis yang lazim dipakai:
- Kontrol storage: kebijakan pada bucket/prefix membatasi akun mana yang boleh membaca
raw/— biasanya hanya akun job ingestion dan pipeline validasi. - Kontrol data: pada zona curated dan serving, kontrol turun ke tingkat baris dan kolom lewat layanan tata kelola, misalnya AWS Lake Formation untuk S3, sehingga tim analis hanya melihat kolom yang relevan bagianya.
Zona adalah kerangka logika; membuat zona raw dan curated bekerja dalam praktik — berkas apa adanya di satu sisi, Parquet berschema di sisi lain — adalah materi chapter Zona Data Raw dan Curated.