Kehendak soalan dan konteks
Sistem pembayaran melaporkan 1,000 pesanan semalam, tetapi laporan gudang data mencatatkan 998. Reka bentuk talian paip yang mencari perbezaan merentasi sumber, lapisan pendaratan (landing layer), model transformasi, dan laporan.
Jangan sandarkan jawapan hanya kepada dbt, Airflow, atau gudang data tertentu. Matlamatnya adalah untuk membina rantaian bukti yang boleh diulang yang membezakan rekod yang hilang, pendua, tidak sepadan, lewat, dan yang ditakrifkan secara berbeza.
Perkara yang diuji oleh penemu duga
Butiran penyelarasan (Reconciliation grain)
Tentukan kunci perniagaan (business key), semantik masa, dan ketepatan monetari sebelum memilih butiran pesanan, pedagang, hari, atau kelompok (batch). Semakan kiraan sahaja boleh menyembunyikan ralat yang saling mengimbangi (offsetting errors).
Semakan yang boleh dijelaskan
Semak kiraan, amaun, taburan status, keunikan kunci, dan sampel data terperinci. Kekalkan versi peraturan dan snapshot input supaya setiap keputusan boleh dihasilkan semula.
Insiden gelung tertutup (Closed-loop incidents)
Kelaskan perbezaan, tetapkan pemilik, kekalkan bukti, sokong main semula (replay), dan rekod penutupan. E-mel tanpa kes yang boleh dikesan bukanlah gelung operasi.
Operasi yang selamat
Kendalikan data lewat, larian semula idempoten, partisi, perubahan skema, kesegaran (freshness), dan sejarah audit tanpa menyebabkan pembaikan menghasilkan percanggahan baharu.
Soalan penjelasan yang perlu ditanya
- Zon masa dan takrifan masa peristiwa (event-time) yang manakah digunakan untuk "semalam"?
- Apakah kunci perniagaan pesanan, dan bagaimanakah bayaran balik (refund) serta pembatalan dikira?
- Bolehkah sumber menghantar kemas kini atau pemadaman lewat?
- Adakah gudang data berbentuk kelompok (batch), penstriman (streaming), atau hibrid?
- Mata wang dan ketepatan perpuluhan yang manakah terpakai?
- Patutkah pemulihan dilakukan secara automatik, dimainkan semula, atau diluluskan secara manual terlebih dahulu?
Rangka jawapan 30 saat
"Saya akan membekukan satu tetingkap masa dan snapshot, menyelaraskan kiraan, amaun, dan status mengikut kunci pesanan, kemudian meneliti ralat rekod yang hilang, pendua, belum tiba, dan ralat transformasi. Setiap perbezaan menyimpan versi peraturan, ringkasan sumber, ringkasan gudang data, dan pemilik. Penanda aras masa (watermark) dan tetingkap cuba semula memisahkan data lewat daripada kehilangan sebenar. Isian semula (backfill) atau main semula yang idempoten membaiki kes yang diluluskan, kemudian snapshot yang sama diselaraskan semula. Input, output, amaran, dan tindakan manusia dimasukkan ke dalam jadual audit."
Analisis mendalam langkah demi langkah
Langkah 1: Bekukan skop dan snapshot
Rekod kelompok sumber, julat masa peristiwa, masa pemprosesan, zon masa, dan ID snapshot. Keputusan mesti merujuk kepada set input yang sama dan bukannya berubah-ubah semasa sumber berubah.
Langkah 2: Normalkan kunci
Normalkan ID pesanan, ID pedagang, pemetaan status, mata wang, dan ketepatan amaun. Simpan cincangan (hash) atau ringkasan bagi setiap sisi; simpan hanya data sensitif minimum yang diperlukan untuk diagnosis.
Langkah 3: Jalankan semakan berlapis
Bandingkan kiraan dan jumlah amaun terlebih dahulu, kemudian kumpulkan mengikut pedagang, tarikh, dan status. Teruskan dengan semakan keunikan kunci, nilai nol (null), pendua, toleransi, dan anti-cantuman (anti-join) terperinci. Jumlah keseluruhan yang sama tidak membuktikan butiran adalah sama.
Langkah 4: Asingkan kelewatan daripada semakan semula
Gunakan masa peristiwa dan watermark untuk membezakan data yang belum tiba daripada data yang hilang. Kekalkan rekod sebagai tertangguh (pending) di dalam tetingkap backfill; eskalasikan hanya selepas tetingkap tersebut ditutup. Kira semula kemas kini, bayaran balik, dan pemadaman menggunakan versi atau masa perubahan.
Langkah 5: Kelaskan dan pulihkan
Nilaikan kes mengikut amaun, bilangan pesanan, impak perniagaan, dan tempoh masa. Pembaikan automatik dihadkan kepada backfill atau main semula yang idempoten. Perubahan takrifan kewangan memerlukan kelulusan serta bukti sebelum/selepas.
Langkah 6: Lari semula dan audit
Laksanakan secara idempoten mengikut ID snapshot, partisi, dan versi peraturan. Simpan skop input, versi pertanyaan, metrik, perbezaan butiran, amaran, pemilik, percubaan semula, dan masa penutupan untuk semakan.
Contoh jawapan berkualiti tinggi
"Saya akan menjana snapshot_id bagi setiap kelompok sumber dan membekukan tetingkap masa peristiwa UTC. Lapisan penormalan menyelaraskan ID pesanan, status, mata wang, dan ketepatan amaun. Kami membandingkan kiraan, amaun, dan taburan status, kemudian menggunakan anti-cantuman kunci utama untuk mencari rekod khusus sumber, khusus gudang data, pendua, dan ketidakpadanan amaun.
Watermark dan tetingkap backfill dua jam mengelaskan peristiwa lewat sebagai tertangguh; hanya perbezaan yang belum selesai selepas tetingkap ditutup akan dieskalasikan. Jadual perbezaan menyimpan versi peraturan, kedua-dua ringkasan rekod, perbezaan amaun, pemilik, dan bukti. Main semula yang diluluskan adalah idempoten berdasarkan snapshot_id ditambah kunci perniagaan. Selepas pembaikan, saya menjalankan semula snapshot yang sama dan menulis julat input, versi kod, amaran, dan masa penutupan ke dalam jadual audit."
Kesilapan biasa
- Perbandingan jumlah kiraan sahaja → ralat saling mengimbangi kekal tersembunyi → gunakan anti-cantuman kunci perniagaan dan kekalkan perbezaan butiran.
- Masa pemprosesan digunakan sebagai masa peristiwa → rekod lewat atau merentasi zon masa menganjakkan tetingkap → tentukan masa peristiwa, masa pemprosesan, dan zon masa secara berasingan.
- Semantik bayaran balik, pembatalan, kemas kini, dan pemadaman diabaikan → setiap lapisan menerangkan nombor yang berbeza → versikan pemetaan status dan peraturan rawatan data.
- Perbandingan wang menggunakan titik terapung (floating-point) → hingar perpuluhan menjadi insiden palsu → gunakan unit kecil integer, mata wang, dan toleransi eksplisit.
- Setiap rekod lewat mencetuskan amaran serta-merta → insiden yang bising mencetuskan pembaikan yang salah → gunakan watermark dan tetingkap backfill dengan status tertangguh.
- Pembaikan tidak idempoten → larian semula menduplikasi baris → lakukan upsert secara idempoten mengikut snapshot dan kunci perniagaan.
- Tiada pemilik, bukti, atau status penutupan → insiden tidak boleh diagihkan atau disemak → tambah kes dan rekod audit.
- Hanya nombor akhir disimpan → keputusan tidak boleh dihasilkan semula → simpan snapshot input, versi peraturan, dan versi kod.
Soalan susulan dan jawapan
Soalan susulan 1: Bagaimana jika jumlah keseluruhan sepadan tetapi rekod berbeza?
Gunakan anti-cantuman kunci perniagaan, semakan kunci pendua, dan taburan terkumpul untuk mencari penambahan dan pemadaman yang saling mengimbangi. Kekalkan perbezaan butiran untuk disemak.
Soalan susulan 2: Bagaimanakah anda mengelakkan amaran palsu bagi data lewat?
Gunakan masa peristiwa, watermark, dan tetingkap backfill yang eksplisit. Tandakan kes sebagai tertangguh di dalam tetingkap dan eskalasikan kes yang tidak selesai selepas tetingkap ditutup, sambil merekodkan versi tetingkap.
Soalan susulan 3: Bagaimanakah pembaikan boleh dijalankan semula dengan selamat?
Gunakan ID snapshot, partisi, dan kunci perniagaan sebagai kunci keidempotenan; lakukan upsert atau nyahduplikasi penulisan; bandingkan kiraan dan amaun sebelum dan selepas setiap percubaan semula.
Soalan susulan 4: Bagaimanakah anda menguji peraturan penyelarasan?
Cipta data ujian (fixtures) untuk kes data hilang, pendua, lewat, bayaran balik, dan mata wang. Uji versi peraturan, toleransi, tarikh sempadan, dan zon masa, kemudian pantau kadar positif palsu.
Soalan susulan 5: Bagaimanakah anda menghalakan amaran dan pemilikan?
Halakan mengikut amaun, kiraan, tempoh, dan tahap keterukan perniagaan. Pautkan setiap amaran kepada kelompok, bukti, dan tindakan pembaikan; penutupan memerlukan sebab dan kekal boleh diaudit.
Sumber 1: dbt sources dan ujian sumber
Dokumentasi dbt Developer Hub sources menerangkan tentang pengisytiharan sumber, membina salasilah (lineage), melampirkan ujian data, dan mengukur kesegaran (freshness)—corak tadbir urus yang berguna untuk input penyelarasan.
Sumber 2: Kesegaran dan tetingkap SLA
Panduan source-freshness dbt Developer Hub menunjukkan medan loaded-at, ambang amaran/ralat, dan keputusan snapshot untuk pengurusan kesegaran, yang membantu penetapan tetingkap data lewat dan eskalasi.
Sumber 3: Semakan kualiti data
Panduan kualiti data dbt Labs merangkumi keunikan, hubungan, semakan nol (null), dan kesegaran, yang menggambarkan bagaimana semakan automatik harus dihubungkan dengan model berversi dan amaran.