Bagian 9: Mendokumentasikan Sistem

Sistem data yang tidak terdokumentasi adalah sistem yang hanya dipahami satu orang — dan orang itu akan cuti tepat saat pipeline berhenti. Bagian penutup ini merangkum seluruh proyek menjadi tiga artefak dokumentasi: diagram sistem yang menunjukkan alur data, runbook yang menjawab “bagaimana menjalankan dan memperbaiki ini”, serta kamus data yang menjelaskan setiap tabel. Pendekatannya mengikuti chapter Dokumentasi Model Data: dokumentasi hidup bersama kode, bukan dokumen terpisah yang cepat usang. Bagian ini sekaligus menutup section proyek course Data Engineering.

Diagram Sistem #

Satu gambar harus cukup untuk menjelaskan ke mana data mengalir dan berkas apa yang dihasilkan di tiap titik:

Setiap kotak pada diagram adalah tabel atau berkas yang benar-benar ada pada bundle, sehingga diagram ini sekaligus berfungsi sebagai peta navigasi folder. Dua hal yang gambar tersebut tekankan: validasi berdiri di antara tabel analitik dan seluruh keluaran (gold dan dashboard hanya terisi setelah delapan pemeriksaan lulus), dan data.json mengalir dari mart — bukan dari fact — sehingga dashboard selalu membaca angka pada grain penyajian.

Runbook Operasional #

Bila pipeline berhenti di tahap validasi, urutan penelusurannya tetap: buka data/gold/validation_report.json untuk melihat pemeriksaan yang gagal beserta rinciannya, periksa data/staging/karantina_*.csv bila penyebabnya baris mentah yang ditolak, lalu perbaiki sumber atau aturan pembersihan — jangan pernah melemahkan ambang validasi hanya agar pipeline lolos.

Peta Berkas dan Artefak #

Dokumentasi juga berarti tahu berkas mana yang dikarang tangan dan berkas mana yang dihasilkan mesin:

Aturan praktisnya satu kalimat: bila sebuah berkas bisa dibangun ulang dengan python3 -m src.pipeline, berkas itu bukan tempat menyimpan suntingan manual.

Kamus Data #

Tabel inti beserta grain dan perannya:

Kolom kunci fct_pesanan beserta tipenya dapat dibaca langsung dari DuckDB lewat DESCRIBE (rujukan resmi di https://duckdb.org/docs/); hasil berikut diambil dari DESCRIBE fct_pesanan:

pesanan_id     VARCHAR
tanggal        DATE
bulan          VARCHAR
pelanggan_id   VARCHAR
kanal          VARCHAR
produk_id      VARCHAR
nama_produk    VARCHAR
kategori       VARCHAR
kuantitas      INTEGER
harga_satuan   BIGINT
diskon         BIGINT
total          BIGINT
status         VARCHAR
is_selesai     BOOLEAN

Kolom mart mengikuti nama yang sama dengan keluaran Bagian 6, misalnya mkt_funnel memuat tahap, jumlah_event, jumlah_sesi, dan persen_dari_view.

Definisi keenam metrik tidak diulang di sini karena sudah menjadi berkas tersendiri: models/metric_definitions.yaml. Satu sumber kebenaran, satu tempat perawatan.

Memperluas Sistem #

Tiga arah pengembangan yang paling mungkin, beserta titik perubahannya:

• Metrik baru: tambah entri pada metric_definitions.yaml, lalu tambahkan kolom atau mart yang menghitungnya; uji idempotensi akan memastikan ekspor tetap deterministik.
• Sumber ketiga (misalnya data stok gudang): buat fungsi baca pada src/collect.py, aturan pembersihan pada src/clean.py, dan model staging baru pada models/ — pola enam tahap tidak berubah.
• Penjadwalan harian: bungkus python3 -m src.pipeline sebagai task pada orchestrator seperti Airflow atau cron; karena pipeline idempoten dan membangun ulang dari nol, jadwal ulang setelah kegagalan tidak memerlukan logika khusus.

Setiap perluasan mengikuti pola yang sama: ubah kode dan model, jalankan ulang pipeline, lalu jalankan pytest. Bila kedua perintah tersebut hijau, delapan pemeriksaan validasi otomatis menjadi hakim apakah perubahan tersebut layak sampai ke dashboard. Bila merah, runbook di atas sudah menunjukkan urutan penelusurannya.

Penutup Proyek dan Section #

Terakhir, satu kebiasaan yang layak dibawa pulang dari proyek ini: setiap angka pada halaman proyek berasal dari eksekusi nyata — keluaran pipeline, hasil kueri DuckDB, dan laporan pytest yang disalin apa adanya. Kebiasaan yang sama berlaku pada dokumentasi: perbarui diagram dan kamus data pada saat kodenya berubah, bukan pada saat ada yang bertanya.

Dari pesanan.csv dan events.jsonl di data/raw/, kita membangun sistem utuh: pembersihan yang meninggalkan jejak karantina, model analitik gaya dbt yang tereksekusi nyata di DuckDB, empat mart siap dashboard, validasi delapan pemeriksaan dengan hitung ulang independen, dashboard statis yang terverifikasi di penjelajah, dan dokumentasi yang membuat semuanya bisa dirawat orang lain. Delapan proyek sebelumnya menyumbang masing-masing satu keahlian — pipeline CSV, ingestion API, ETL terjadwal, data warehouse, orkestrasi, streaming, Spark, dan yang ini merangkai semuanya.

Perjalanan belajar tidak berhenti di sini. Section Sumber Belajar menyediakan rujukan lanjutan yang terkurasi: dokumentasi resmi tiap teknologi, daftar dataset terbuka untuk berlatih, dan glosarium istilah lintas chapter. Ketika tugas nyata menuntut kemampuan yang belum dipraktikkan pada proyek-proyek ini, mulailah dari sana.