Data lake modern berdiri di atas tiga lapisan: object storage sebagai fondasi, format berkas kolomar sebagai wadah data, dan table format sebagai lapisan metadata yang memberi jaminan transaksi. Section Data Lake dan Lakehouse membahas ketiganya secara konseptual; bab ini menghimpun dokumentasi resmi setiap lapisan sebagai rujukan lanjutan. Seluruh tautan diverifikasi hidup saat course ini ditulis dan berasal dari domain resmi masing-masing proyek dan penyedia cloud.
Table Format: Iceberg, Delta Lake, dan Hudi #
Ketiga table format open source ini adalah pilihan utama industri saat membangun lakehouse — perbandingan lengkapnya ada di chapter Table Formats, dan masing-masing punya bab praktik tersendiri. Dokumentasi di bawah disusun dari halaman induk ke halaman topik spesifik:
| Sumber | Untuk apa | Tingkat |
|---|---|---|
| Apache Iceberg Documentation | Panduan resmi Iceberg: arsitektur metadata, partition evolution, dan cara kerja catalog | Menengah |
| Iceberg Schema Evolution | Cara Iceberg menambah, menghapus, dan mengganti nama kolom lewat field id yang stabil | Menengah |
| Iceberg Partitioning | Hidden partitioning, transform days() dan bucket(), serta partition evolution | Lanjutan |
| Iceberg Reliability | Jaminan yang diberikan Iceberg: commit atomik, snapshot isolation, dan validitas | Lanjutan |
| pyiceberg Documentation | API Python resmi Iceberg — pustaka yang kita pakai di chapter Apache Iceberg | Menengah |
| Delta Lake Documentation | Panduan resmi Delta Lake: ACID transaction log, MERGE, dan integrasi Spark | Menengah |
| Delta Lake: Table Batch Reads dan Writes | Operasi baca/tulis, update, dan merge pada tabel Delta — pasangan chapter Delta Lake | Menengah |
| Delta Lake: Streaming Reads dan Writes | Menjadikan tabel Delta sebagai sumber dan tujuan streaming — pasangan chapter Time Travel dan Versioning Data | Lanjutan |
| Apache Hudi Documentation | Panduan resmi Hudi: timeline, tabel, dan konfigurasi writer | Lanjutan |
| Hudi Table Types | Perbedaan Copy-on-Write dan Merge-on-Read beserta trade-off keduanya | Lanjutan |
| Hudi Indexing | Mekanisme index yang mempercepat upsert: bloom filter, bucket, dan record-level | Lanjutan |
| Hudi Quick Start Guide | Langkah cepat membuat tabel Hudi pertama dengan Spark | Menengah |
Tiga format tersebut menyelesaikan masalah yang sama — transaksi ACID di atas object storage — dengan rekayasa metadata yang berbeda. Tabel ringkas berikut merangkum perbedaan yang dibahas tuntas di course ini:
| Aspek | Iceberg | Delta Lake | Hudi |
|---|---|---|---|
| Asal proyek | Netflix, kini Apache | Databricks | Uber, kini Apache |
| Bentuk metadata | Pohon metadata.json, manifest list, dan manifest file | Satu berkas log JSON per transaksi di direktori _delta_log | Timeline berkas commit plus index per tabel |
| Fitur khas | Hidden partitioning dan partition evolution | Integrasi erat dengan ekosistem Spark | Upsert cepat berkat index dan record key |
| Bab course terkait | Apache Iceberg | Delta Lake | Apache Hudi |
Kolom terakhir sengaja menunjuk bab praktik course ini karena perbedaan nyata ketiga format paling mudah dirasakan lewat tangan: membuat tabel, menulis data, lalu memindai berkas metadata yang dihasilkan masing-masing.
Format Berkas: Parquet, Avro, ORC, dan Protobuf #
Pemilihan format berkas menentukan ukuran penyimpanan dan kecepatan pembacaan — trade-off yang kita bedah di chapter Memilih Format Data dan Kompresi Data. Untuk format kolomar, baca dulu halaman induknya; untuk format berbasis schema, mulai dari halaman spesifikasinya:
| Sumber | Untuk apa | Tingkat |
|---|---|---|
| Apache Parquet | Spesifikasi format kolomar Parquet: encoding, statistik min/max, dan row group — fondasi chapter Parquet | Menengah |
| Parquet File Format | Anatomi dalam berkas Parquet: page header, data page, dan page index | Lanjutan |
| Apache Avro | Format berbasis schema untuk serialisasi cepat, umum di pipeline Kafka — materi chapter Avro | Menengah |
| Avro Specification | Spesifikasi wire format dan resolving schema saat producer dan konsumen berbeda versi | Lanjutan |
| Apache ORC | Format kolomar dengan index bawaan, lazim di ekosistem Hadoop | Lanjutan |
| Protocol Buffers | Skema bahasa-netral dari Google untuk pertukaran data antar sistem — materi chapter Protobuf | Menengah |
| PyArrow Documentation | API Python Apache Arrow yang kita pakai untuk membaca dan menulis Parquet secara programatik | Semua |
Satu kebiasaan yang layak dibentuk: setiap kali menulis Parquet, buka berkasnya kembali dengan pembaca metadata (misalnya lewat PyArrow) dan amati row group, statistik, dan skema yang tersimpan. Kebiasaan ini membuat trade-off di chapter Memilih Format Data terasa konkret, bukan teoretis.
Untuk format serialisasi, kebiasaan yang sama berlaku: simpan schema Avro atau .proto di repositori dan perlakukan berkas schema itu sebagai kode yang di-review, bukan sekadar lampiran pipeline.
Object Storage Resmi #
Object storage adalah fondasi fisik data lake — konsep yang dibahas di chapter Object Storage dan Zona Data Raw dan Curated. Tiga penyedia cloud berikut mendominasi implementasi produksi, dan ketiganya punya dokumentasi resmi yang lengkap:
| Sumber | Untuk apa | Tingkat |
|---|---|---|
| Amazon S3 User Guide | Panduan resmi S3: bucket, objek, lifecycle policy, dan storage class | Semua |
| S3 Performance Guidelines | Pola akses cepat: partisi awalan nama objek dan request rate per prefiks | Menengah |
| Google Cloud Storage | Pengenalan resmi GCS: bucket, kelas penyimpanan, dan operasi objek | Semua |
| GCS Storage Locations | Pemilihan region dan multi-region — relevan untuk latensi dan kepatuhan data | Menengah |
| Azure Blob Storage | Dokumentasi resmi Azure Blob Storage: container, blob, dan tier penyimpanan | Semua |
| Azure Data Lake Storage | Lapisan hierarchical namespace di atas Blob Storage yang dirancang khusus untuk analitik besar | Lanjutan |
Praktik Lokal Sebelum Naik ke Cloud #
Seluruh konsep di bab ini bisa dipraktikkan tanpa akun cloud dan tanpa biaya, karena ketiga lapisan lakehouse punya implementasi yang berjalan di laptop:
- Object storage lokal: gunakan filesystem biasa dengan skema
file://— pyiceberg dan Spark sama-sama menerimanya sebagai gantis3://. - Parquet dan Avro: pyarrow serta pustaka
fastavro/avromenulis dan membaca berkas asli tanpa server. - Table format: pyiceberg dengan catalog
sqldi SQLite — persis pola yang dipakai di chapter Apache Iceberg. - Query di atas tabel: DuckDB membaca tabel Iceberg dan berkas Parquet lokal secara langsung.
Setelah pola kerjanya stabil di lokal, berpindah ke cloud hanya mengganti lokasi bucket dan kredensial — bukan mengubah logika pipeline. Bab Referensi Cloud berikutnya memetakan layanan tempat bucket itu disewa.
Jalur Belajar yang Disarankan #
Urutan berikut menghubungkan tiga lapisan lakehouse dari bawah ke atas, mengikuti urutan section Data Lake dan Lakehouse di course ini:
- Pelajari S3 User Guide (atau GCS/Azure sesuai platform pilihan) sampai paham bucket, objek, dan penamaan kunci.
- Baca Apache Parquet sambil membandingkan isi row group dengan hasil praktik chapter Parquet.
- Coba PyArrow Documentation untuk menulis dan membaca ulang Parquet secara programatik.
- Pahami Apache Avro sebagai perwakilan format berbasis schema untuk pipeline streaming.
- Masuk ke table format: mulai dari Iceberg Documentation , lanjut Schema Evolution dan Partitioning .
- Bandingkan dengan Delta Lake Documentation dan Hudi Documentation — fokus pada cara tiap format menyimpan metadata.
- Tutup dengan Iceberg Reliability untuk memahami jaminan yang sebenarnya diberikan lakehouse.
Lapisan penyimpanan dan pemrosesan berjalan di atas infrastruktur yang dalam praktiknya disewa dari penyedia cloud. Peta referensi layanan cloud AWS, Google Cloud, dan Azure tersusun di chapter Referensi Cloud.