Temu Duga Kejuruteraan Data: Bagaimana Anda Mereka Bentuk Model Inkremental dbt yang Boleh Dipercayai?

Prompt dan Skop

Penemu duga memberi anda jadual peristiwa yang menerima penulisan berterusan dan meminta anda membina jadual fakta harian. Larian pertama mungkin mengimbas sejarah, tetapi larian seterusnya harus memproses data yang berubah sahaja. Peristiwa boleh tiba lewat, dikemas kini, atau diduplikasi, dan lajur model boleh berubah. Terangkan sempadan penapis, kunci unik, strategi inkremental, pelan pengisian semula (backfill), dan pemulihan selepas kegagalan.

Andaikan gudang data menyokong SQL, sasaran diagregatkan mengikut date_day, dan setiap peristiwa mempunyai event_at, updated_at, serta event_id yang stabil. Nyatakan andaian ini pada permulaan. Tanpa kunci yang stabil, semantik kemas kini dan penyahduplikasian akan berubah.

Perkara yang Dinilai oleh Penemu Duga

Penemu duga ingin melihat sama ada anda boleh mengurangkan data yang diimbas tanpa mengorbankan ketepatan. Jawapan asas menyebut is_incremental() dan penapis cap masa (timestamp). Jawapan yang kukuh menerangkan sebab penapis mesti merangkumi ketibaan lewat, sebab agregat memerlukan unique_key yang sepadan dengan butirannya (grain), dan bila --full-refresh adalah mandatori.

Mereka juga menguji sama ada anda memisahkan tiga risiko: terlepas peristiwa lewat, menulis baris pendua pada butiran perniagaan, dan mencampurkan logik lama dan baharu selepas transformasi sejarah berubah. Bahan temu duga kejuruteraan data semasa menganggap model inkremental, snapshot, dan graf kebergantungan sebagai topik persediaan praktikal; soalan ini menggabungkan SQL, pemodelan data, dan tadbir urus larian.

Soalan Penjelasan Sebelum Menjawab

Apakah butiran perniagaan (business grain)?

Jika satu baris mewakili satu hari, date_day boleh menjadi kunci unik. Jika satu baris mewakili seorang pengguna dan satu hari, kuncinya hendaklah (user_id, date_day). Butiran mengubah syarat cantuman (merge), semakan pendua, dan kos pengisian semula.

Berapa lewatkah data boleh tiba?

Jika peristiwa biasanya tidak lewat lebih daripada dua hari, kira semula tiga hari terkini. Jika tiada had atas yang berguna, tetingkap tetap tidak mencukupi; gunakan watermark, pembaikan partisi, atau penyesuaian penuh berkala. Tetingkap mesti merangkumi taburan kelewatan yang diterima.

Medan manakah yang mewakili kemas kini huluan?

event_at ialah masa perniagaan, manakala updated_at ialah masa pengubahsuaian terakhir. Menapis mengikut event_at sahaja akan terlepas peristiwa lama yang diperbetulkan kemudian. Utamakan updated_at atau jujukan perubahan yang boleh dipercayai dan sahkan bahawa sumber tidak mengundurkannya ke belakang.

Bagaimanakah perubahan model atau lajur dikeluarkan?

Menambah lajur, membuang lajur, dan mengubah logik pengiraan memerlukan pengendalian yang berbeza. Sahkan sama ada on_schema_change boleh menyegerakkan struktur, sama ada baris lama mesti diisi semula, dan sama ada penyegaran penuh boleh dijadualkan.

Rangka Kerja Jawapan 30 Saat

“Saya akan mengesahkan butiran sasaran dan had kelewatan terlebih dahulu. Larian pertama membina model daripada semua sejarah. Larian kemudian menggunakan is_incremental() untuk menapis mengikut updated_at dan melihat kembali merentasi tetingkap kelewatan. Sasaran mengisytiharkan unique_key yang sepadan dengan butirannya, jadi hari-hari terkini dikemas kini dan bukannya dilampirkan sebagai pendua. Saya menyahduplikasi tetingkap mengikut versi peristiwa sebelum mengagregat, kemudian menulis dengan merge atau setara gudang data. Saya menguji tingkah laku tetingkap, kunci, dan perubahan skema. Jika perubahan logik menjadikan hasil sejarah tidak konsisten, saya menjalankan --full-refresh yang terkawal dan membina semula model hiliran yang terjejas. Akhir sekali, saya memantau baris yang diproses, masa kemas kini maksimum, kunci pendua, dan perbezaan antara inkremental lawan penuh.”

Analisis Mendalam Langkah demi Langkah

1. Tentukan garis dasar ketepatan penyegaran penuh (full-refresh)

Tulis pertanyaan penuh terlebih dahulu: baca semua peristiwa dan agregatkan pada butiran sasaran. Itu adalah garis dasar ketepatan. Output inkremental mesti diselaraskan dengan pengiraan penuh bagi julat masa yang sama. Membuat pengoptimuman sebelum mewujudkan garis dasar ini menjadikan rekod yang terlepas sukar dikesan.

2. Pilih sempadan penapis inkremental

Cabang inkremental hanya digunakan apabila jadual sasaran wujud, --full-refresh tiada, dan model dikonfigurasikan sebagai inkremental. Satu pilihan adalah menolak tetingkap kelewatan daripada masa kemas kini maksimum sasaran:

{{
  config(
    materialized = 'incremental',
    unique_key = ['date_day'],
    incremental_strategy = 'merge'
  )
}}

with source_events as (
  select *
  from {{ ref('app_events') }}
  {% if is_incremental() %}
    where updated_at >= (
      select coalesce(max(updated_at), '1900-01-01') from {{ this }}
    ) - interval '3 day'
  {% endif %}
)
select
  cast(event_at as date) as date_day,
  count(distinct event_id) as events,
  max(updated_at) as max_updated_at
from source_events
group by 1

Nilai tiga hari ialah andaian temu duga, bukan pemalar universal. Pilih tetingkap berdasarkan kelewatan, SLA, dan kos pengiraan semula. Sesuaikan ungkapan tarikh mengikut gudang data.

3. Jadikan kunci unik sepadan dengan butiran model

Untuk jadual harian, date_day ialah kuncinya. Untuk jadual pengguna-hari, gunakan ['user_id', 'date_day']. Lajur kunci tidak boleh mengandungi nilai null, atau merge mungkin gagal dipadankan dan menghasilkan pendua. Tanpa kunci, banyak penyesuai bertindak sebagai lampir sahaja (append-only), jadi pengiraan semula tetingkap boleh menulis berbilang baris untuk satu butiran.

4. Nyahduplikasi di dalam tetingkap sebelum pengagregatan

Kemas kini replay atau CDC boleh menghasilkan beberapa versi bagi satu peristiwa. Isih mengikut event_id dan masa kemas kini, kekalkan versi terkini, kemudian agregatkan:

with ranked_events as (
  select
    *,
    row_number() over (
      partition by event_id
      order by updated_at desc, ingest_seq desc
    ) as rn
  from source_events
),
deduped_events as (
  select * from ranked_events where rn = 1
)
select
  cast(event_at as date) as date_day,
  count(*) as events,
  max(updated_at) as max_updated_at
from deduped_events
group by 1

Gunakan ingest_seq hanya jika ia adalah pemutus seri yang stabil untuk cap masa yang sama. Jika tidak, anggap peraturan pemutus seri tersebut sebagai kontrak sumber yang belum selesai. Penyahduplikasian mesti mendahului pengagregatan, atau kedua-dua versi bagi satu peristiwa akan dikira.

5. Pilih merge, partition overwrite, atau append

merge sesuai dengan semantik kemas kini dan sisip (update-and-insert) yang berkuncikan butiran. Beban kerja pengiraan semula partisi boleh menggunakan insert_overwrite, yang bergantung pada partisi dan bukannya kunci baris. Append tulen adalah lebih mudah apabila peristiwa huluan tidak pernah berubah. Pilih berdasarkan semantik kemas kini, kos imbasan, dan sokongan penyesuai dan bukannya menganggap satu strategi sebagai universal.

6. Kendalikan perubahan skema dan logik

Menambah lajur tidak semestinya mengisi semula baris lama; lajur yang digugurkan dan perubahan jenis mungkin hanya muncul semasa masa larian. on_schema_change boleh menjadi ignore, fail, append_new_columns, atau sync_all_columns, tetapi ia hanya menjejaki lajur peringkat teratas dan tidak menggantikan pengisian semula sejarah. Jika logik pengiraan berubah, sejarah lama dan baharu mungkin mengikut peraturan yang berbeza, jadi jalankan --full-refresh dan bina semula model inkremental hiliran yang terjejas.

7. Reka bentuk pengisian semula dan pemulihan kegagalan

Catatkan tetingkap kelewatan, masa kemas kini maksimum sasaran, dan watermark sumber dalam metadata larian. Selepas larian tetingkap gagal, kira semula daripada watermark sasaran yang terakhir dikomitedkan; jangan anggap nilai dalam memori "diproses sehingga" sebagai kebenaran. Untuk pembaikan yang meluas, proses partisi tarikh dengan keserempakan terhad, kemudian selaraskan sampel terhadap pertanyaan penuh supaya satu penyegaran tidak membebankan gudang data.

8. Lengkapkan gelung pengesahan

Sahkan sekurang-kurangnya empat isyarat: setiap event_id muncul paling banyak sekali dalam tetingkap; kunci sasaran adalah unik; output inkremental terkini kekal dalam julat perbezaan yang dibenarkan daripada pengiraan semula penuh; dan baris yang diproses serta updated_at maksimum tidak melonjak secara tidak dijangka. Uji input kosong, peristiwa pendua, kemas kini kepada peristiwa lama, ketibaan lewat, cap masa yang sama dengan sempadan, dan larian inkremental selepas penyegaran penuh.

Contoh Jawapan Berkualiti Tinggi

“Saya akan mengesahkan butiran model, had kelewatan, dan medan kemas kini sumber terlebih dahulu. Andaikan sasaran mempunyai satu baris setiap hari dan peristiwa mempunyai event_id serta updated_at yang stabil. Larian pertama membina daripada sejarah; larian kemudian menggunakan is_incremental() dan melihat kembali tiga hari daripada masa kemas kini maksimum sasaran. Tetingkap itu diterbitkan daripada kelewatan, bukan peraturan tetap.

Di dalam tetingkap, saya menyahduplikasi mengikut ID peristiwa dan versi, kemudian mengagregatkan mengikut hari. Sasaran mengisytiharkan date_day sebagai unique_key miliknya dan menggunakan merge supaya hari-hari terkini diganti dan bukannya diduplikasi. Untuk butiran pengguna-hari, saya akan menggunakan kunci komposit. Menapis mengikut masa peristiwa sahaja akan terlepas pembetulan kemudian kepada peristiwa lama, jadi saya lebih suka cap masa kemas kini atau jujukan perubahan yang boleh dipercayai.

Saya akan memantau saiz tetingkap, watermark, baris yang diproses, kunci pendua, dan penyesuaian inkremental lawan penuh. Tetapan perubahan skema boleh mengendalikan evolusi struktur, tetapi ia tidak mengisi nilai sejarah. Jika logik berubah atau sejarah memerlukan pembaikan, saya akan menjalankan penyegaran penuh terkawal atau pengisian semula berpartisi dan membina semula model hiliran yang terjejas. Saya akan menguji input kosong, peristiwa lewat dan pendua, cap masa sempadan, dan tingkah laku percubaan semula sebelum memanggil model itu boleh dipercayai.”

Kesilapan Biasa

Menapis mengikut event_at sahaja → kemas kini lama terlepas → gunakan updated_at atau watermark CDC yang jelas

Masa perniagaan tidak berubah apabila peristiwa lama diperbetulkan. Jika kemas kini dibenarkan, tapis mengikut masa kemas kini atau jujukan perubahan dan sahkan kontraknya.

Menggabungkan (merging) tanpa kunci → baris tidak dapat dipadankan secara boleh dipercayai → tentukan butiran dan kunci bukan null terlebih dahulu

Kunci mesti mengenal pasti tepat satu baris sasaran. Jika butirannya ialah pengguna-hari, menggunakan tarikh sahaja akan mencantumkan pengguna yang berbeza ke dalam satu baris.

Menganggap lajur baharu diisi semula secara automatik → nilai sejarah kekal kosong → rancang pengisian semula atau penyegaran penuh

Penyegerakan skema dan pengisian data sejarah adalah berasingan. Perubahan struktur mungkin ringan, tetapi baris lama yang diisi memerlukan kemas kini atau binaan semula yang jelas.

Memilih tetingkap tetap satu jam → data lewat jatuh di luar tetingkap → tentukur dengan persentil dan penyesuaian

Pilih tetingkap daripada taburan kelewatan, SLA, dan kos. Pantau ketibaan di luar tetingkap dan luaskan atau baiki apabila taburan berubah.

Soalan Susulan dan Maklum Balas

Jika 5% daripada peristiwa tiba lewat dua hari, bagaimanakah anda memilih tetingkap?

Mula-mula sahkan kelewatan kesegaran yang diterima. Jika laporan harian boleh diperbetulkan pada keesokan harinya, rangkumi dua hingga tiga hari dan selaraskan peristiwa lewat. Jika hasil hari pertama mestilah stabil, gunakan watermark berserta baris gilir pembaikan dan bukannya hanya tetingkap SQL yang lebih besar. Sahkan pilihan tersebut terhadap keluk kelewatan dan kos dan bukannya menyalin peratusan semata-mata.

Apakah yang berlaku jika unique_key diduplikasi dalam sumber?

Kunci pendua dalam input inkremental atau sasaran boleh menyebabkan penyesuai gagal atau menghasilkan keputusan yang tidak ditentukan. Semak keunikan di kedua-dua tempat, kenal pasti punca pendua, nyahduplikasi mengikut versi peristiwa, atau tentukan semula kunci komposit yang mewakili butiran sebenar. ID rawak tidak sepatutnya menyembunyikan kunci perniagaan yang tidak stabil.

SQL model telah berubah, tetapi anda hanya mahu mengira semula tujuh hari. Bolehkah anda terus menjalankan secara inkremental?

Hanya jika hasil sejarah tidak terjejas oleh logik baharu. Jika perubahan tersebut mempengaruhi semua sejarah, larian inkremental tujuh hari akan menghasilkan jadual dengan peraturan bercampur. Jalankan penyegaran penuh terkawal atau pengiraan semula berpartisi untuk julat yang terjejas dan bina semula model hiliran.

Jadual huluan telah dipotong (truncated). Bagaimanakah model inkremental pulih?

Hentikan pemajuan watermark, sahkan binaan semula sumber, dan mainkan semula daripada snapshot atau titik CDC yang boleh dipercayai. Jika sumber tidak lagi merangkumi sejarah yang diperlukan, larian inkremental akan menganggap sumber yang tidak lengkap sebagai garis dasar yang lengkap; pulihkan snapshot atau bina semula sasaran sepenuhnya.