Gesaan dan konteks
Tugasan huluan menghasilkan beberapa aset data setiap hari. Laporan dan semakan kualiti harus dijalankan selepas kebergantungannya dikemas kini. Terangkan cara anda memodelkan pengeluar, pengguna, pemetakan (partitions) dan pemulihan dengan penjadualan peka aset Airflow, serta perbezaannya daripada jadual berasaskan masa dan penderia luaran.
Perkara yang diuji oleh penemu duga
- Menganggap aset sebagai kebergantungan data logik yang dikemas kini oleh tugasan, bukan sekadar nama fail atau label cron.
- Membezakan peristiwa aset, jadual waktu (timetables) DAG, gubahan ungkapan dan pencetus peristiwa.
- Mengambil kira peristiwa pendua, data lewat, granulariti pemetakan, kawalan kualiti (quality gates) dan pengisian semula (backfills).
- Menerangkan pemantauan, pengesahan, keidempotetan (idempotency), percubaan semula (retries) dan tingkah laku jeda/sambung semula.
Soalan penjelasan untuk ditanya
- Adakah aset mewakili keseluruhan jadual, pemetakan atau laluan storan objek? Adakah peristiwa membawa identiti pemetakan dan kelompok (batch)?
- Adakah pengguna mesti menunggu setiap aset huluan, atau mana-mana satu kemas kini boleh mencetuskannya? Adakah ungkapan aset merentasi DAG diperlukan?
- Jika sesuatu peristiwa tiba tetapi semakan kualiti gagal, adakah pengguna perlu disekat, pengeluar dicuba semula, atau manusia melepaskannya secara manual?
- Adakah kita memerlukan pengisian semula sejarah, main semula peristiwa (event replay) atau keserasian dengan jadual cron sedia ada? Apakah kos pencetus pendua?
Jawapan 30 saat
Saya akan memodelkan produk data sebagai aset dengan kontrak kemas kini, kemudian membenarkan DAG pengeluar mengeluarkan kemas kini aset hanya selepas penulisan atomik dan semakan kualiti berjaya. DAG pengguna menggunakan kebergantungan atau ungkapan aset untuk menentukan syarat pencetusnya dan bukannya meneka kesediaan dengan selang cron yang lebih pendek. Saya akan mentakrifkan peraturan pemetakan, keidempotetan, peristiwa pendua, kemas kini lewat dan pengisian semula, kemudian memantau kependaman peristiwa, DAG yang menunggu, percubaan semula dan kesegaran data. Jika kemas kini berasal dari luar Airflow, saya akan menilai kebolehbagaian pemulihan dan sempadan keselamatan pencetus yang didorong peristiwa.
Analisis terperinci langkah demi langkah
1. Wujudkan kontrak aset
Dokumentasi rasmi Airflow Assets mentakrifkan aset sebagai kebergantungan data yang dikongsi antara DAG. Pengeluar harus mengemas kini aset hanya selepas komit data dan semakan kontrak berjaya; mencipta fail sementara, memulakan tugasan atau menulis sebahagian data bukanlah tanda kesediaan. Pastikan URI aset, pemilik dan granulariti pemetakan stabil supaya pengguna dapat membezakan data baharu daripada data lama.
2. Pilih logik pencetus
DAG pengguna boleh bergantung pada satu atau lebih aset. Dokumentasi rasmi Asset-Aware Scheduling menyokong gabungan logik yang menyatakan syarat seperti semua aset dikemas kini atau mana-mana aset dikemas kini; timetable boleh kekal sebagai kekangan bebas. Tentukan apa yang berlaku apabila syarat peristiwa dan masa bertindih, dan jangan silap menganggap ungkapan sebagai penapis ke atas kandungan baris.
3. Kendalikan pemetakan dan pendua
Peristiwa aset tidak menggantikan tanda aras (watermark) pemetakan data. Bawa identiti kelompok atau pemetakan yang boleh dikesan, dan gunakan jadual watermark, kunci unik atau penulisan transaksi untuk keidempotetan. Peristiwa pendua, percubaan semula tugasan dan pemulihan penjadual semuanya boleh menilai semula kebergantungan, jadi pengguna mestilah boleh dijalankan semula dengan selamat dan bukannya menganggap peristiwa berlaku tepat sekali sahaja.
4. Peristiwa luaran, kualiti dan pemulihan
Apabila kemas kini datang daripada barisan gilir (queue) atau sistem lain, gunakan dokumentasi penjadualan didorong peristiwa rasmi untuk memilih pencetus, kemudian sahkan semakan boleh pulih, kelayakan sambungan dan pelepasan sumber. Biarkan aset dalam keadaan belum sedia apabila kualiti gagal, dan cuba semula atau perlukan pelepasan eksplisit. Untuk pengisian semula, tentukan sama ada perlu mengeluarkan peristiwa, mengasingkan pemetakan sejarah dan menghalang main semula daripada menimpa hasil masa nyata.
Jawapan model
Mula-mula saya akan mentakrifkan kontrak aset: URI, kunci pemetakan, pengeluar, kawalan kualiti dan identiti kelompok. DAG pengeluar mengemas kini aset hanya selepas penulisan atomik dan semakan kualiti. DAG pengguna menggunakan kebergantungan atau ungkapan aset untuk syarat semua-huluan berbanding mana-mana-huluan, secara pilihan digabungkan dengan timetable. Peristiwa membawa identiti pemetakan dan kelompok; pengguna menggunakan watermark dan kunci keidempotetan untuk pendua, percubaan semula dan pemulihan penjadual. Kemas kini luaran menggunakan pencetus terkawal dengan kelayakan dan jangka hayat sumber yang terhad. Saya memantau kependaman peristiwa, tugasan yang menunggu, kesegaran data dan kegagalan main semula. Laluan pengisian semula dan masa nyata menggunakan sempadan kelompok yang berasingan supaya main semula sejarah tidak boleh menimpa hasil terkini.
Kesilapan biasa
- Menganggap aset sebagai laluan sewenang-wenangnya tanpa mentakrifkan pemilikan kemas kini dan kesediaan.
- Memendekkan selang cron tanpa isyarat kesediaan data, kontrak pemetakan atau kawalan kualiti.
- Mengandaikan peristiwa aset dihantar tepat sekali dan mengabaikan percubaan semula, pendua atau pemulihan penjadual.
- Menganggap ungkapan aset sebagai penapis kandungan baris dan meninggalkan watermark pemetakan sebenar.
- Membiarkan pencetus luaran memegang sambungan atau kelayakan selama-lamanya tanpa had masa tamat (timeout) dan pembersihan.
- Menggunakan semula DAG masa nyata untuk pengisian semula dan membenarkan main semula sejarah menimpa output langsung.
Soalan susulan dan jawapan
Bagaimana jika dua aset huluan tiba pada masa yang berbeza?
Tentukan sama ada pengguna menunggu semua aset atau boleh menerbitkan hasil separa. Untuk semantik semua aset, jejak watermark ketibaan setiap pemetakan dan berikan amaran apabila tamat masa. Untuk hasil separa, terbitkan versi supaya pengguna tahu aset yang menyusul kemudian mungkin mengemas kininya.
Bagaimanakah anda akan menguji peristiwa pendua?
Dalam persekitaran ujian, terbitkan kemas kini aset yang sama dua kali, cuba semula pengeluar dan mulakan semula penjadual. Sahkan kunci unik pengguna, watermark dan sempadan transaksi, termasuk kiraan baris, versi dan kesan sampingan luaran seperti pemberitahuan atau caj.
Bilakah anda akan mengekalkan penderia luaran?
Kekalkan penderia buat sementara waktu apabila sistem kebergantungan tidak dapat mengeluarkan peristiwa aset Airflow, hanya mendedahkan antara muka pengundian (polling) terkawal, atau mesti kekal serasi semasa migrasi. Catatkan tarikh akhir migrasi dan kos pengundian, kemudian gerakkan sistem huluan ke arah isyarat kemas kini aset yang boleh disahkan.