Perintah dan konteks
Pekerjaan upstream menghasilkan beberapa aset data setiap hari. Laporan dan pemeriksaan kualitas harus dijalankan setelah dependensinya diperbarui. Jelaskan bagaimana Anda memodelkan produsen, konsumen, partisi, dan pemulihan dengan asset-aware scheduling Airflow, serta perbedaannya dari jadwal berbasis waktu dan sensor eksternal.
Hal yang diuji oleh pewawancara
- Memperlakukan aset sebagai dependensi data logis yang diperbarui oleh tugas, bukan sekadar nama file atau label cron.
- Membedakan peristiwa aset, timetable DAG, komposisi ekspresi, dan pemicu peristiwa.
- Memperhitungkan peristiwa duplikat, data terlambat, granularitas partisi, quality gate, dan backfill.
- Menjelaskan pemantauan, otorisasi, idempotensi, percobaan ulang (retry), dan perilaku jeda/lanjutkan (pause/resume).
Pertanyaan klarifikasi yang perlu diajukan
- Apakah aset mewakili keseluruhan tabel, sebuah partisi, atau jalur penyimpanan objek? Apakah peristiwa membawa identitas partisi dan batch?
- Haruskah konsumen menunggu setiap aset upstream, atau pembaruan tunggal mana pun dapat memicunya? Apakah ekspresi aset lintas-DAG diperlukan?
- Jika sebuah peristiwa tiba tetapi pemeriksaan kualitas gagal, apakah konsumen harus diblokir, produsen dicoba ulang, atau dilepaskan secara manual oleh manusia?
- Apakah kita memerlukan backfill historis, pemutaran ulang peristiwa (event replay), atau kompatibilitas dengan jadwal cron yang ada? Berapa dampak/biaya dari pemicu duplikat?
Jawaban 30 detik
Saya akan memodelkan produk data sebagai aset dengan kontrak pembaruan, lalu membiarkan DAG produsen memancarkan pembaruan aset hanya setelah penulisan atomik dan pemeriksaan kualitas berhasil. DAG konsumen menggunakan dependensi atau ekspresi aset untuk menentukan kondisi pemicunya alih-alih menebak kesiapan data dengan memperpendek interval cron. Saya akan menetapkan aturan partisi, idempotensi, peristiwa duplikat, pembaruan terlambat, dan backfill, kemudian memantau latensi peristiwa, DAG yang menunggu, percobaan ulang, serta kesegaran data. Jika pembaruan berasal dari luar Airflow, saya akan mengevaluasi kemampuan pemulihan dan batas keamanan dari pemicu berbasis peristiwa.
Pembahasan mendalam langkah demi langkah
1. Menetapkan kontrak aset
Dokumentasi resmi Airflow Assets mendefinisikan aset sebagai dependensi data yang dibagikan antar-DAG. Produsen harus memperbarui aset hanya setelah commit data dan pemeriksaan kontrak berhasil; membuat file sementara, memulai tugas, atau menulis data sebagian bukanlah kesiapan. Jaga agar URI aset, pemilik, dan granularitas partisi tetap stabil sehingga konsumen dapat membedakan data baru dari data lama.
2. Memilih logika pemicu
DAG konsumen dapat bergantung pada satu atau beberapa aset. Dokumentasi resmi Asset-Aware Scheduling mendukung kombinasi logis yang mengekspresikan kondisi seperti semua aset diperbarui atau salah satu aset diperbarui; sebuah timetable dapat tetap menjadi batasan independen. Tentukan apa yang terjadi ketika kondisi peristiwa dan waktu terjadi bersamaan, dan jangan salah mengartikan ekspresi sebagai filter terhadap konten baris.
3. Menangani partisi dan duplikat
Peristiwa aset tidak menggantikan watermark partisi data. Sertakan identitas batch atau partisi yang dapat dilacak, dan gunakan tabel watermark, kunci unik, atau penulisan transaksional untuk menjamin idempotensi. Peristiwa duplikat, percobaan ulang tugas, dan pemulihan scheduler dapat mengevaluasi ulang dependensi, sehingga konsumen harus dapat dijalankan ulang dengan aman alih-alih mengasumsikan tepat satu peristiwa.
4. Peristiwa eksternal, kualitas, dan pemulihan
Ketika pembaruan berasal dari antrean atau sistem lain, gunakan dokumentasi resmi penjadwalan berbasis peristiwa untuk memilih pemicu, lalu verifikasi pemeriksaan yang dapat dipulihkan, kredensial koneksi, dan pelepasan sumber daya. Pertahankan aset dalam status belum siap ketika kualitas gagal, dan lakukan percobaan ulang atau minta pelepasan eksplisit. Untuk backfill, putuskan apakah akan memancarkan peristiwa, mengisolasi partisi historis, dan mencegah pemutaran ulang menimpa hasil real-time.
Contoh jawaban model
Pertama, saya akan menentukan kontrak aset: URI, kunci partisi, produsen, quality gate, dan identitas batch. DAG produsen memperbarui aset hanya setelah penulisan atomik dan pemeriksaan kualitas. DAG konsumen menggunakan dependensi atau ekspresi aset untuk kondisi semua-upstream vs salah-satu-upstream, yang secara opsional dikombinasikan dengan timetable. Peristiwa membawa identitas partisi dan batch; konsumen menggunakan watermark dan kunci idempotensi untuk menangani duplikat, percobaan ulang, dan pemulihan scheduler. Pembaruan eksternal menggunakan pemicu terkontrol dengan kredensial dan masa pakai sumber daya yang dibatasi. Saya memantau latensi peristiwa, tugas yang menunggu, kesegaran data, dan kegagalan pemutaran ulang. Jalur backfill dan real-time menggunakan batas batch terpisah sehingga pemutaran ulang historis tidak dapat menimpa hasil terbaru.
Kesalahan umum
- Memperlakukan aset sebagai jalur arbitrer tanpa menentukan kepemilikan pembaruan dan kesiapan.
- Memperpendek interval cron tanpa sinyal kesiapan data, kontrak partisi, atau quality gate.
- Mengasumsikan peristiwa aset dikirimkan tepat satu kali (exactly-once) dan mengabaikan percobaan ulang, duplikat, atau pemulihan scheduler.
- Memperlakukan ekspresi aset sebagai filter konten baris dan menghilangkan watermark partisi yang sebenarnya.
- Membiarkan pemicu eksternal menahan koneksi atau kredensial tanpa batas waktu tanpa timeout dan pembersihan.
- Menggunakan kembali DAG real-time untuk backfill dan membiarkan pemutaran ulang historis menimpa keluaran langsung (live output).
Pertanyaan lanjutan dan tanggapan
Bagaimana jika dua aset upstream tiba pada waktu yang berbeda?
Putuskan apakah konsumen harus menunggu semua aset atau dapat memublikasikan hasil parsial. Untuk semantik semua-aset, lacak watermark kedatangan setiap partisi dan buat peringatan jika terjadi timeout. Untuk hasil parsial, publikasikan versi sehingga konsumen mengetahui bahwa aset yang datang kemudian dapat memperbaruinya.
Bagaimana Anda menguji peristiwa duplikat?
Di lingkungan pengujian, publikasikan pembaruan aset yang sama dua kali, coba ulang produsen, dan mulai ulang scheduler. Verifikasi kunci unik konsumen, watermark, dan batas transaksi, termasuk jumlah baris, versi, serta efek samping eksternal seperti notifikasi atau tagihan.
Kapan Anda akan mempertahankan sensor eksternal?
Pertahankan sensor untuk sementara waktu jika sistem dependensi tidak dapat memancarkan peristiwa aset Airflow, hanya menyediakan antarmuka polling terkontrol, atau harus tetap kompatibel selama migrasi. Catat batas waktu migrasi dan biaya polling, kemudian arahkan sistem upstream menuju sinyal pembaruan aset yang dapat diverifikasi.