Semua topik pada jalur ini bermuara pada satu kemampuan praktis, yaitu mengenali masalah yang layak dikerjakan dengan Spark dan menyusun pekerjaannya dari nol. Topik ini membuka modul terakhir dengan sisi yang sering dilewati, yaitu pemilihan proyek, karena proyek yang salah pilih membuat penguasaan teknis tidak pernah terlatih pada masalah yang nyata.
Ciri masalah yang layak Spark#
Masalah yang cocok untuk proyek pertama punya tiga ciri yang mudah diuji. Pertama, data yang terus bertumbuh atau sudah melebihi kenyamanan satu mesin, sebab itulah mesin terdistribusi ada. Kedua, transformasi yang sama dijalankan berulang, karena pekerjaan sekali jalan tidak mewarisi manfaat pipeline yang dirakit baik. Ketiga, ada konsumen hasil yang jelas, yaitu orang atau sistem yang bergantung pada keluaran pada jadwal tertentu, sebab konsumen inilah yang menentukan bentuk keluaran dan jadwal pemrosesan.
Contoh yang memenuhi ketiganya sering ditemukan dalam pekerjaan data sehari-hari. Rekap harian transaksi toko yang dibaca dari berkas ekspor dan ditulis ke tabel laporan adalah masalah batch klasik dengan konsumen berupa tim analis. Pemantauan suhu perangkat yang tiba tiap menit dan dirangkum per jendela waktu adalah masalah streaming yang cocok dengan pola modul streaming. Pengayaan profil pelanggan dengan gabungan beberapa sumber adalah masalah batch berkala yang menekan soal join dan kualitas data. Ketiganya membutuhkan hampir semua topik pada jalur ini tanpa menuntut fitur yang belum dipelajari.
Sebaliknya, dua jenis pekerjaan sebaiknya dihindari sebagai proyek pertama. Pekerjaan yang datanya muat nyaman di satu mesin mengajarkan seluruh kerumitan Spark tanpa manfaatnya, dan pekerjaan tanpa konsumen jelas tidak pernah selesai karena keberhasilannya tidak terdefinisi. Peta alternatif pada modul ekosistem menyediakan bingkai untuk menguji apakah Spark memang alat yang tepat sebelum komitmen dibuat.
Menyusun cakupan yang bisa tuntas#
Proyek pembelajaran yang paling sering gagal bukan karena teknis, melainkan karena cakupannya bocor. Cara menyekatkannya adalah menyatakan satu keluaran akhir yang konkret, misalnya tabel rata-rata nilai per kelas yang diperbarui harian, lalu menyebut sumber data yang benar-benar tersedia, bukan yang semestinya tersedia. Dari dua hal itu, seluruh tahap antara bisa digambar mundur, dan setiap tahap yang tidak mengantar data ke arah keluaran akhir layak dibuang dari versi pertama.
Ukuran data juga perlu disekat secara jujur. Data contoh pada jalur ini barisnya hitungan puluhan, dan prinsip yang sama berlaku pada proyek nyata, yaitu mulai dari sampel yang cukup besar untuk memunculkan masalah schema dan kualitas, lalu tumbuh setelah pipeline stabil. Menaikkan volume sebelum pola penanganannya benar hanya mempercepat menemukan masalah yang bisa ditemukan dengan murah, dan sandbox dua core pada jalur ini sudah membuktikan bahwa seluruh pola dapat dilatih tanpa cluster.
Jadwal adalah batas cakupan terakhir yang sering terlupa. Pipeline yang berjalan sekali dengan perintah manual, dijadwalkan berkala, atau dipicu kedatangan berkas adalah tiga tingkat kematangan yang berbeda biayanya, dan proyek pertama sebaiknya berhenti pada tingkat yang memenuhi kebutuhan konsumen tanpa menambah infrastruktur. Modul produksi sudah menyediakan pola trigger dan penjadwalan untuk tingkat terjadwal dan yang dipicu berkas.
Dokumen satu halaman sebelum menulis kode membantu menegakkan cakupan tersebut. Isinya sederhana, yaitu keluaran akhir, sumber data, jadwal, dan definisi selesai, dan dokumen ini menjadi tempat kembali ketika godaman untuk menambah tahap muncul di tengah pengerjaan. Proyek yang dokumennya bisa dibaca ulang dalam satu menit hampir selalu lebih mudah dituntaskan daripada yang rencananya hidup di ingatan, dan kebiasaan menulis dokumen kecil ini berpindah utuh ke pekerjaan profesional yang cakupannya jauh lebih luas.
Kesalahan umum#
Kesalahan pertama adalah memilih masalah karena teknologinya, bukan karena masalahnya. Membangun streaming untuk data yang berubah harian atau cluster untuk tabel yang kecil adalah dua wujud kesalahan ini, dan keduanya menghasilkan sistem yang benar secara teknik tetapi salah secara biaya. Uji tiga ciri pada bagian pertama sebelum menyusun rencana.
Kesalahan kedua adalah menunggu data sempurna sebelum mulai. Data nyata hampir selalu punya duplikat, nilai kosong, dan schema yang bergeser, dan justru itulah bahan latih yang berharga karena topik pembersihan pada modul transformasi menjadi terpakai. Proyek yang dikerjakan pada data tiruan sempurna hanya melatih setengah keterampilan.
Kesalahan ketiga adalah menyatakan cakupan tanpa keluaran yang terukur. Pernyataan seperti “memahami Spark untuk proyek berikutnya” tidak bisa dites, sedangkan tabel rata-rata per kelas yang terbarui tiap pagi bisa dites dengan satu kueri. Rumusan yang bisa dites juga membuat keputusan putaran optimasi pada topik terakhir menjadi jelas, karena ukuran keberhasilannya sudah ada.
Ringkasan#
- Masalah yang layak Spark memiliki data yang bertumbuh, transformasi berulang, dan konsumen keluaran yang jelas pada jadwal tertentu.
- Rekap harian, pemantauan sensor, dan pengayaan profil adalah tiga pola proyek yang memenuhi ciri tersebut dan melatih hampir semua topik jalur ini.
- Cakupan proyek disekat dari keluaran akhir yang terukur, sumber data yang benar-benar ada, dan tingkat jadwal yang memenuhi kebutuhan tanpa tambahan infrastruktur.
- Proyek pada data nyata yang kotor lebih bernilai latih daripada data tiruan yang sempurna, karena pembersihan dan schema bergeser adalah pekerjaan profesional yang memakan setengah hari.
Referensi#
- Spark SQL guide — Apache Spark — Panduan yang menjadi dasar teknis bagi pola proyek batch pada topik ini.
- Structured Streaming Programming Guide — Apache Spark — Panduan yang menjadi dasar pola proyek streaming berkelanjutan.
- Data engineering lifecycle — Fundamentals of Data Engineering — Buku rujukan tentang memilih arsitektur berdasarkan pola kebutuhan data.