6 kebenaran pahit tentang Apache Airflow (dan apa yang harus dilakukan terhadapnya)

Tim data yang bekerja dengan proses penyerapan kompleks menyukai Apache Airflow.

Anda dapat mendefinisikan alur kerja Anda dalam Python, sistem ini memiliki ekstensibilitas yang luas, dan menawarkan banyak sekali plug-in. Delapan puluh enam persen penggunanya mengatakan mereka senang dan berencana untuk terus menggunakannya di atas mesin alur kerja lainnya. Jumlah yang sama mengatakan bahwa mereka merekomendasikan produk tersebut.

Namun, seperti halnya semua perangkat lunak, terutama yang bersifat sumber terbuka, Airflow memiliki sejumlah kelemahan dan kekurangan yang perlu Anda atasi. Bagi pengembang yang baru mengenal hal ini, artinya awalnya lambat dan perjalanannya sulit. Dalam artikel ini, kita membahas masalah-masalah tersebut dan beberapa solusi alternatif yang mungkin dilakukan.

Airflow adalah alat tangguh dengan cakupan terbatas. Airflow tidak melakukan koreksi apa pun jika terjadi masalah dengan data—hanya pada pipeline. Hampir setiap pengguna pernah mengalami situasi di mana Airflow memberitahu mereka bahwa suatu tugas telah selesai, namun saat memeriksa data, ternyata kolom tertentu hilang dan data tersebut salah, atau bahkan tidak ada data yang sebenarnya melewati sistem.

Hal ini terutama berlaku ketika organisasi data sudah matang dan Anda beralih dari 10 grafik acyclic data (DAG) menjadi ribuan. Dalam situasi tersebut, Anda kemungkinan besar saat ini menggunakan DAGs tersebut untuk mengimpor data dari sumber data eksternal dan API, yang membuat pengendalian kualitas data di Airflow menjadi lebih sulit. Anda tidak dapat “membersihkan” kumpulan data sumber atau menerapkan kebijakan tata kelola Anda di sana.

Meskipun Anda dapat membuat peringatan Slack untuk memeriksa setiap proses secara manual, untuk menggabungkan Airflow sebagai bagian yang bermanfaat dari organisasi rekayasa data Anda dan mencapai SLA Anda, Anda ingin mengotomatiskan pemeriksaan kualitas. Dan untuk melakukannya, Anda memerlukan visibilitas tidak hanya apakah suatu tugas telah dijalankan, tetapi juga apakah tugas tersebut dijalankan dengan benar. Dan jika tidak berjalan dengan benar, mengapa, dan di mana kesalahan tersebut berasal. Jika tidak, Anda akan hidup dalam situasi seperti Groundhog Day.

Ini bukanlah tantangan yang sederhana, dan jika kita jujur, itulah mengapa IBM® Databand diciptakan. Sebagian besar alat observabilitas produk seperti Datadog dan New Relic tidak dirancang untuk menganalisis pipeline dan tidak dapat mengidentifikasi asal mula masalah, mengelompokkan masalah yang terjadi bersamaan untuk menyarankan akar masalah, atau menyarankan solusi perbaikan.

Namun, kebutuhan akan observabilitas masih belum sepenuhnya dipahami, bahkan di dalam komunitas Airflow. Hari ini, hanya 32% yang mengatakan mereka telah menerapkan pengukuran kualitas data, meskipun fakta bahwa para penyusun survei menanyakan hal ini merupakan indikasi adanya perbaikan. Pertanyaan ini tidak diajukan dalam survei tahun 2019 atau 2020.

Bagaimana cara memantau  kualitas data di Airflow? Sebenarnya, Airflow hanya membawa Anda setengah jalan. Seperti yang ditekankan oleh pengembangnya, “Ketika alur kerja didefinisikan sebagai kode, mereka menjadi lebih mudah dipelihara, dapat diubah versinya, dapat diuji, dan kolaboratif.”

Airflow menyediakan representasi formal dari kode. Yang Anda butuhkan adalah alat observabilitas yang dibuat khusus untuk memantau saluran data. Alat pemantauan produk yang dibangun sebagai langkah sementara, tetapi biasanya menjadi bagian dari proses karena mereka sudah memiliki lisensi tersebut.

Kami menemukan bahwa organisasi teknik melewati beberapa fase dalam perjalanan mereka menuju kematangan observabilitas penuh:

• Kesadaran awal: Tidak memantau kualitas data (68% dari komunitas Airflow).
• Solusi tambal sulam: Meminjam alat observabilitas produk dan membuatnya berfungsi, meskipun mungkin tidak ideal.
• Solusi yang dibuat khusus: Mengadopsi alat observabilitas pipeline penuh seperti Databand untuk mengotomatiskan peringatan, mengisolasi akar masalah, dan melakukan perbaikan masalah lebih cepat. Atur machine learning di sekitar parameter data yang diharapkan, dapatkan peringatan Slack yang menunjukkan data yang hilang atau perubahan skema di Airflow Scheduler, lacak asal-usul masalah kembali, dan uji ulang melalui data historis.

Belajar Airflow membutuhkan waktu dan usaha. Banyak artikel dan utas Stack Overflow mendokumentasikan kesulitan yang dihadapi para pengembang yang terjebak pada pertanyaan dasar, seperti, “Mengapa pekerjaan yang saya jadwalkan tidak dimulai?” (Jawaban umum: Airflow Scheduler mulai menjadwalkan pada akhir periode waktu yang dijadwalkan, bukan di awal. Lebih lanjut mengenai hal itu nanti.)

Selain itu, untuk menjadi mahir dalam menggunakan Airflow, Anda perlu mempelajari Celery Executor dan salah satu dari RabbitMQ atau Redis, dan tidak ada cara lain untuk menghindarinya.

Gesekan ini cukup besar sehingga beberapa organisasi, seperti perusahaan perangkat lunak CMS Bluecore memutuskan bahwa lebih mudah untuk pada dasarnya mengembangkan antarmuka Airflow mereka sendiri. Dengan cara itu, setiap pengembang baru yang mereka rekrut atau tugaskan tidak perlu mempelajari semua operator baru, melainkan dapat mengandalkan operator Kubernetes yang sudah mereka kenal.

Hambatan belajar ini sudah menjadi masalah yang berulang bagi komunitas, sehingga “masalah orientasi” layak mendapatkan pertanyaan tersendiri dalam survei komunitas Airflow tahun 2021 (seperti yang terlihat di bawah ini).

Di antara keluhan utama pengguna adalah “kurangnya praktik terbaik dalam mengembangkan DAG” dan “tidak adanya opsi yang mudah untuk meluncurkan.” Masalah ini telah sebagian diatasi dalam Airflow Versi 2.0 (yang dirilis setelah survei), tetapi versi ini berjalan pada basis data SQLite di mana paralelisasi tidak mungkin dilakukan dan semua proses terjadi secara berurutan.
Seperti yang dijelaskan dalam Panduan Memulai Cepat Airflow, “ini sangat membatasi” dan “Anda akan segera melampauinya.”

Penggunaan utama Airflow adalah untuk menjadwalkan batch secara berkala, bukan sering dijalankan, seperti yang dijelaskan dalam dokumentasinya sendiri : “Alur kerja diharapkan sebagian besar statis atau berubah secara perlahan.” Ini berarti ada sedikit kemampuan bagi mereka yang perlu mengambil sampel atau mendorong data secara ad hoc dan berkelanjutan, dan ini membuatnya kurang ideal untuk beberapa contoh penggunaan ETL dan ilmu data.

Masih ada lagi. Kami telah menyentuh topik ini sebelumnya, tetapi Airflow Scheduler menjalankan tugas schedule_interval pada akhir interval mulai Airflow Scheduler, bukan pada awalnya. Hal ini berarti Anda akan melakukan perhitungan manual lebih sering daripada yang Anda inginkan, dan sesekali akan merasa terkejut.

Dan untuk menjalankan tugas terjadwal tersebut dengan benar, Anda perlu memahami perbedaan spesifik Airflow antara operator dan tugas, cara kerja DAG, argumen default, basis data metadata Airflow, direktori utama untuk menerapkan DAG, dan masih banyak lagi.

Solusinya? Anda dapat mempertimbangkan untuk bergabung dengan 6% pengguna Airflow yang mengembangkan antarmuka pengguna grafis mereka sendiri dan mengganti nama operator dengan istilah yang lebih masuk akal bagi mereka.

Anda akan menemukan banyak praktik pengembangan perangkat lunak tradisional dan DevOps yang tidak tersedia di Airflow, dan salah satu yang paling menonjol adalah kemampuan untuk mengelola versi pipeline Anda. Tidak ada cara mudah untuk mendokumentasikan semua yang telah Anda bangun dan, jika diperlukan, kembali ke versi sebelumnya. Jika, misalnya, Anda menghapus sebuah Tugas dari DAG Anda dan menginstalnya kembali, Anda akan kehilangan metadata yang terkait dengan Instans Tugas tersebut.

Hal ini membuat Airflow menjadi cukup rentan, dan kecuali Anda telah menulis skrip untuk menangani hal ini sendiri, hal ini akan membuat proses debugging masalah menjadi jauh lebih sulit. Tidak mungkin dilakukan pengujian ulang kemungkinan perbaikan terhadap data historis untuk memvalidasinya.

Sekali lagi, Airflow memang menyediakan representasi kode formal. Tantangan Anda adalah menerapkan pengembangan perangkat lunak lain dan alat DevOps untuk mengisi fungsionalitas yang hilang.

Tidak banyak yang bisa dikatakan di sini. Kecuali Anda menggunakan file Docker compose tertentu yang bukan bagian dari repositori utama, itu tidak mungkin dijalankan.

Airflow Scheduler tidak berfungsi? Lebih baik isi ulang kopi Anda. Anda mungkin memiliki beberapa debugging yang memakan waktu di depan Anda.

Itu karena, menurut kami, Airflow tidak cukup membedakan antara operator yang mengoordinasikan dan operator yang mengeksekusi. Banyak operator melakukan keduanya. Meskipun hal itu mungkin telah membantu dalam tahap awal pengembangan platform, penambahan tersebut merupakan kesalahan fatal yang membuat proses debugging menjadi sangat sulit. Jika terjadi kesalahan, pengembang Anda harus memeriksa parameter DataFlow mereka terlebih dahulu, lalu operator itu sendiri, setiap saat.

Untuk alasan ini, alat seperti Databand dapat sangat membantu. Databand unggul dalam membantu Anda memahami kesehatan infrastruktur Anda di setiap tingkatan: Airflow global, DAG, tugas, dan antarmuka pengguna. Alih-alih menghabiskan waktu rekayasa data untuk mempelajari fitur-fitur yang sangat spesifik, Databand memungkinkan insinyur data untuk benar-benar fokus pada pemecahan masalah untuk bisnis.

Seperti kontributor sumber terbuka mana pun yang meluangkan waktu untuk mengusulkan perubahan baru, kami berharap artikel ini ditafsirkan sebagai catatan cinta. Kami di Databand adalah kontributor aktif untuk komunitas Airflow dan ingin melihatnya tumbuh melampaui keterbatasan yang ada dan untuk melayani lebih banyak contoh penggunaan ETL dan ilmu data.

Seperti yang kami katakan sebelumnya, 86% pengguna berencana untuk tetap menggunakannya di atas mesin operasi lainnya. 86% lainnya mengatakan mereka akan sangat merekomendasikannya. Dengan gembira kami katakan bahwa kami termasuk dalam kedua kelompok—ini adalah alat yang hebat. Dan bagi Anda yang baru berkenalan dengan Airflow, ketahuilah bahwa jika Anda memikirkan masalah yang disebutkan di atas, Airflow Scheduler bisa sangat berharga. Lihat bagaimana Databand menyatukan semua aktivitas observabilitas Airflow Anda untuk menyederhanakan dan memusatkan observabilitas Apache Airflow Anda. Jika Anda siap untuk melihat lebih dalam, pesan demo hari ini.