Proyek puncak menutup jalur ini dengan menyatukan materi modul-modul sebelumnya menjadi satu platform data yang benar-benar berjalan. Topik ini menetapkan kriteria pemilihan masalah, mengusulkan satu proyek konkret yang digunakan sepanjang modul, menilai usulan tersebut terhadap kriteria, serta menyediakan alternatif proyek. Setelah topik ini dibaca, arsitektur DAG, implementasi, dan penguatan operasional memiliki sasaran yang sama dan tidak berubah di tengah pengerjaan.
Kriteria pemilihan proyek puncak#
Masalah yang tepat untuk proyek puncak bukan sekadar tema yang menarik, melainkan masalah yang bentuknya memaksa seluruh materi jalur digunakan. Empat kriteria berikut menjadi tolok ukurnya.
- Masalah nyata berbentuk multi-pipeline. Masalahnya harus memuat lebih dari satu pipeline, yaitu lebih dari satu DAG dengan tanggung jawab dan pemicu yang berbeda. Satu skrip yang dijalankan sekali tidak memberi tempat bagi penjadwalan, dependensi antar DAG, maupun pembagian batas tanggung jawab yang menjadi inti Airflow.
- Data yang legal dan dapat diakses. Sumber data nyata wajib bebas dari kendala lisensi dan privasi sebelum digunakan. Apabila data nyata sulit diperoleh, data tiruan yang realistis dapat digunakan, yaitu data buatan yang meniru struktur kolom, jenis nilai, dan variasi data aslinya dalam volume kecil.
- Cakupan yang dapat dituntaskan. Jumlah sumber data, jumlah pemeriksaan, dan kedalaman transformasi dibatasi agar proyek selesai pada skala latihan. Proyek yang terlalu luas berhenti di tengah jalan sebelum materi operasional sempat dipraktikkan.
- Unsur materi jalur yang lengkap. Masalah yang dipilih harus memuat keempat kemampuan utama jalur ini, yaitu penjadwalan dengan data interval, sensor untuk menunggu kesiapan data, gerbang mutu data yang menahan alur, dan task idempoten yang aman dijalankan ulang.
Kriteria keempat layak diberi bobot paling besar. Proyek yang tidak menyediakan tempat bagi sensor atau gerbang mutu memaksa materi topik-topik berikutnya diterapkan pada masalah yang tidak membutuhkannya, sehingga latihannya terasa artifisial.
Proyek usulan: platform data statistik ujian sekolah#
Proyek yang digunakan sepanjang modul ini adalah platform data statistik ujian untuk satu sekolah. Setiap hari ujian, sekolah menghimpun tiga kelompok data dalam berkas CSV terpisah, yaitu nilai ujian per siswa, kehadiran siswa, dan catatan suhu ruang ujian dari termometer sederhana. Panitia ujian memerlukan ringkasan harian yang menyatukan ketiganya sebagai bahan evaluasi, dan pembuatan ringkasan itu tidak boleh bergantung pada pengumpulan manual.
Platform datanya terdiri atas empat tahap. Tahap ingesta menyalin ketiga CSV mentah ke folder kerja yang dipartisi per tanggal. Tahap pemeriksaan mutu menahan alur apabila ada nilai kosong atau di luar rentang yang wajar. Tahap agregasi menghitung rata-rata nilai dan tingkat kehadiran per kelas, lalu tahap ekspor menulis berkas ringkasan yang siap dibaca panitia. Sketsa berikut merangkum keempat tahap beserta pemicunya.
pipeline = {
"ingesta": {"pemicu": "jadwal harian pukul 06.00", "hasil": "CSV mentah terpartisi"},
"mutu": {"pemicu": "selesai ingesta", "hasil": "data yang tervalidasi"},
"agregat": {"pemicu": "selesai mutu", "hasil": "ringkasan per kelas"},
"ekspor": {"pemicu": "selesai agregat", "hasil": "berkas ringkasan siap pakai"},
}
for nama, rincian in pipeline.items():
print(f"{nama} <- {rincian['pemicu']}")ingesta <- jadwal harian pukul 06.00
mutu <- selesai ingesta
agregat <- selesai mutu
ekspor <- selesai agregatKeluaran tersebut memperlihatkan bahwa hanya tahap ingesta yang berpemicu jadwal, sedangkan tiga tahap lainnya berpemicu selesainya tahap sebelumnya. Pola inilah yang kelak menentukan pembagian DAG pada topik arsitektur. Data tiruannya juga sudah ditetapkan. Berkas nilai memuat kolom nis, nama, kelas, dan nilai, berkas kehadiran memuat kolom nis, tanggal, dan status, serta berkas suhu memuat kolom ruang, waktu, dan suhu_c. Ketiganya hanya berisi beberapa baris data, sehingga hasil setiap tahap mudah diperiksa dengan mata.
Penilaian proyek terhadap kriteria#
Usulan statistik ujian dinilai terhadap keempat kriteria pada tabel berikut.
| Kriteria | Penilaian pada proyek usulan |
|---|---|
| Masalah multi-pipeline | Empat tahap dengan pemicu berbeda, dari jadwal cron harian hingga pemicu selesainya tahap sebelumnya |
| Data legal dan dapat diakses | Ketiga sumber berupa CSV tiruan yang dibuat sendiri, tanpa kredensial maupun kendala lisensi |
| Cakupan yang dapat dituntaskan | Tiga sumber kecil, dua aturan mutu, dan satu ringkasan yang selesai dalam hitungan menit di komputer lokal |
| Unsur materi jalur | Cron untuk penjadwalan, pemeriksaan rentang untuk gerbang mutu, penulisan per partisi tanggal untuk idempotensi, dan pemicu antartahap untuk penghubung DAG |
Satu hal sengaja dikeluarkan dari cakupan, yaitu transformasi data yang berat. Agregasi pada proyek ini cukup dihitung dalam memori karena ukuran datanya kecil, sehingga perhatian tetap tertuju pada orkestrasi, bukan pada rumus statistiknya. Batasan semacam ini bukan kelemahan, melainkan cara menjaga agar proyek puncak tetap menguji materi Airflow.
Alternatif proyek#
Proyek usulan dapat diganti dengan salah satu alternatif berikut apabila variasi diinginkan, asalkan bentuk multi-pipelinenya dipertahankan agar topik-topik berikutnya tetap dapat diikuti tanpa penyesuaian.
- Arsip cadangan berkas harian. Pipeline pertama menyalin isi folder kerja ke arsip yang dipartisi tanggal, pipeline kedua memverifikasi kelengkapan arsip beserta ukurannya, sedangkan pipeline ketiga merangkum riwayat arsip mingguan. Unsur sensor muncul saat pipeline menunggu penyalinan selesai, sedangkan idempotensi muncul pada penimpaan arsip untuk tanggal yang sama.
- Catatan sensor suhu ruangan. Pipeline pertama menyerap log suhu dari beberapa ruang, pipeline kedua memeriksa rentang suhu yang wajar sebelum diterima, sedangkan pipeline ketiga menghitung nilai minimum, maksimum, dan rata-rata harian lalu mengekspornya. Bentuknya hampir sama dengan proyek usulan, yang berbeda hanya domain datanya.
Kedua alternatif memuat jadwal harian, data yang dibuat sendiri, dan tahap yang berpemicu selesainya tahap lainnya, sehingga kriteria pemilihan tetap terpenuhi tanpa perubahan arsitektur pada topik berikutnya.
Ringkasan#
- Proyek puncak dipilih dengan empat kriteria, yaitu masalah multi-pipeline, data yang legal atau tiruan yang realistis, cakupan yang tuntas, dan kehadiran unsur penjadwalan, sensor, mutu data, serta idempotensi.
- Proyek yang digunakan sepanjang modul ini adalah platform data statistik ujian sekolah dengan tahap ingesta, pemeriksaan mutu, agregasi, dan ekspor.
- Alternatif arsip cadangan berkas dan catatan sensor suhu tersedia apabila variasi diperlukan, dengan bentuk pipeline yang sama.
Referensi#
- Dags — Apache Airflow — Konsep DAG dan dag run yang menjadi satuan pipeline pada proyek ini.
- Best Practices — Apache Airflow — Praktik penulisan DAG resmi yang memengaruhi batasan cakupan proyek, termasuk aturan kode pada berkas DAG dan idempotensi.