Temu Duga Kejuruteraan Data: Bagaimanakah Anda Melakukan Pengisian Semula (Backfill) Data Sejarah Berskala Besar dengan Selamat?

Prompt dan Konteks yang Berkenaan

Satu saluran paip data pesanan membaca 2 TB data mentah yang tidak boleh diubah daripada storan objek setiap hari dan menghasilkan jadual orders_daily yang disekat mengikut business_date. Pasukan menemui kecacatan transformasi cukai yang menjejaskan 90 sekatan. Oleh itu, ia mesti mengira semula 180 TB dalam masa 5 hari. Saluran paip tokokan (incremental) harian tidak boleh berhenti; kesegaran P95-nya mesti kekal pada atau di bawah 45 minit. Bayaran balik lewat dan pembetulan pesanan juga mungkin mengemas kini kunci perniagaan yang sama seperti pengisian semula tersebut.

Reka bentuk pengisian semula yang boleh diulang, boleh disambung semula selepas dijeda, boleh diaudit, dan boleh dibalikkan. Rangkumi cara untuk menetapkan (pin) versi input dan kod, membahagikan dan menjadualkan sekatan, menghalang kerja sejarah daripada mengambil kapasiti pengeluaran, menyelesaikan pertindihan antara pengisian semula dan tokokan langsung, menentukan pengesahan yang menyekat penerbitan, dan memulihkan versi dipercayai yang terakhir selepas kegagalan.

Bahan temu duga kejuruteraan data awam baru-baru ini secara jelas menganggap pengisian semula sejarah, larian semula idempoten, dan pemeliharaan pemprosesan masa nyata sebagai soalan kebolehpercayaan saluran paip. Senario awam juga meminta calon mengendalikan input berskala terabait, pemprosesan semula sekatan, pengesahan, dan pengembalian semula (rollback). Dokumentasi saluran paip rasmi mendedahkan larian sejarah, dasar pemprosesan semula, dan had keserempakan yang berasingan. Niat carian adalah khusus: calon memerlukan pelan pengeluaran yang boleh dilaksanakan yang melangkaui titik masuk penjadualan "jalankan semula 90 hari yang lalu dalam Airflow."

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon mentakrifkan versi data yang boleh dihasilkan semula. Jawapan yang kukuh menetapkan selang pengisian semula, tarikh logik, syot kilat sumber atau versi sumber, kod transformasi, versi dimensi bergantung, dan skema sasaran. Jika dua percubaan membaca input yang berbeza, atau jika kod tersebut bergantung pada now(), nilai rawak, atau carian luaran yang boleh berubah, "selamat untuk dijalankan semula" tidak mempunyai makna yang boleh diuji.

Isyarat kedua ialah memisahkan kejayaan orkestrasi daripada ketepatan data. Pengorkestra boleh membuat larian untuk tarikh logik sejarah dan mengehadkan keserempakan. Ia tidak menjadikan penulisan perniagaan bersifat idempoten, dan ia tidak menyelesaikan konflik penulisan antara tokokan langsung dan pengisian semula sejarah. Calon harus memilih penggantian sekatan, MERGE berkunci stabil, atau sasaran berversi dan menerangkan prasyaratnya.

Isyarat ketiga ialah kapasiti dan pengasingan. Untuk menyelesaikan 180 TB dalam masa 5 hari, kadar bacaan mentah purata minimum ialah:

180 TB / (5 × 24 h) = 1.5 TB/h ≈ 417 MB/s

Itu adalah batas bawah untuk pelaksanaan berterusan tanpa percubaan semula. Ia tidak termasuk amplifikasi imbasan, kocokan (shuffle), penulisan sasaran, pengesahan, dan pengiraan semula yang gagal. Jawapan yang baik menanda aras satu sekatan terlebih dahulu, mengukur daya pemprosesan (throughput) dan sumber puncak mengikut peringkat, kemudian menetapkan barisan giliran atau kolam pengiraan yang berasingan, had keserempakan, dan keutamaan pengeluaran. Kesegaran saluran paip langsung menjadi isyarat maklum balas yang mengurangkan kadar pengisian semula.

Isyarat keempat ialah sempadan penerbitan dan pemulihan. Sembilan puluh tugasan yang berjaya tidak menjadikan versi baharu selamat untuk pengguna data. Sebelum penerbitan, sistem mesti membuktikan kesempurnaan sekatan, keunikan kunci, invarian perniagaan, penyesuaian sumber, dan perbezaan yang konsisten dengan kecacatan tersebut. Penerbitan harus menjadi satu peralihan versi yang terkawal. Simpan versi lama sepanjang tempoh pemerhatian supaya pengembalian semula bermaksud mengubah penuding (pointer), bukan mengira semula 180 TB sekali lagi.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah input mentah benar-benar tidak boleh diubah? Dapatkan versi objek, ID syot kilat, atau kedudukan log yang boleh dimainkan semula. Jika sumber mengubah data di tempatnya, cipta versi input yang boleh dirujuk terlebih dahulu.
• Jam manakah yang mentakrifkan selang 90 hari tersebut? Selaraskan business_date, masa peristiwa, masa penyerapan, dan zon masa. Tentukan juga sekatan mana yang memiliki bayaran balik lewat.
• Apakah butiran (grain) sasaran dan kunci stabil? Tetapkan sama ada satu baris ialah pesanan, item pesanan, atau agregat harian dan sama ada order_id, source_version, dan susunan konflik berketetapan wujud.
• Data boleh ubah manakah yang menjadi pergantungan transformasi? Kadar pertukaran, peraturan cukai, dimensi SCD, dan rekod pemadaman mesti dibaca setakat masa peristiwa sejarah, bukan digantikan secara senyap dengan nilai hari ini.
• Sekatan manakah yang boleh dikemas kini oleh tokokan langsung? Jika ia hanya menulis 7 hari terkini, pengisian semula boleh memiliki sekatan yang lebih lama. Jika sebarang pesanan sejarah boleh berubah, susunan versi atau pengejaran delta diperlukan.
• Apakah ciri pengasingan dan penerbitan atomik yang wujud? Gudang data yang berasingan, kolam sumber, barisan giliran keutamaan, transaksi sekatan, pengklonan jadual, peralihan paparan (view cutover), atau penuding katalog akan mengubah reka bentuk.
• Adakah 5 hari merupakan tarikh akhir yang ketat atau sekadar sasaran? Dapatkan sasaran kesegaran P95 langsung, kuota bacaan sumber, had kos, dan sebarang tetingkap peralihan singkat yang dibenarkan.
• Siapa yang menurunkan tandatangan pengesahan? Penegasan teknikal, penyesuaian kewangan, persampelan hiliran, dan tempoh pemerhatian masing-masing memerlukan pemilik dan ambang penyekatan.

Rangka Kerja Jawapan 30 Saat

"Saya akan menetapkan 90 tarikh perniagaan, syot kilat input, dan versi kod, kemudian menulis setiap sekatan tarikh logik ke kawasan pementasan (staging) yang terasing dengan manifes. Memproses 180 TB dalam masa 5 hari memerlukan sekurang-kurangnya kira-kira 417 MB/s, jadi saya akan membuat penandaarasan terlebih dahulu dan mendikit (throttle) apabila P95 langsung menghampiri 45 minit. Selepas mengisi semula W0, saya akan mengejar perubahan sehingga W1 dan beralih hanya selepas 90/90 sekatan, penyesuaian, dan semakan perniagaan lulus. Versi lama kekal tersedia untuk pengembalian semula."

Penerangan Mendalam Langkah Demi Langkah

Langkah 1: Takrifkan pengisian semula sebagai spesifikasi larian yang tidak boleh diubah

Cipta backfill_id dan rekod perkara berikut:

Sampaikan business_date ke dalam setiap larian sekatan. Jangan gantikan masa jam dinding (wall-clock time) untuk masa logik di dalam transformasi. Apabila kadar pertukaran sejarah atau dimensi SCD menjadi pergantungan, lakukan percantuman as-of pada masa peristiwa. Perubahan pada input, kod, atau sebarang versi pergantungan akan mencipta backfill_id baharu; jangan campurkan dua versi hasil di dalam satu larian.

Hasilkan pelan tanpa menulis pada sasaran pengeluaran. Senaraikan kesemua 90 sekatan, susunan pergantungan, anggaran bait input, keserempakan yang dicadangkan, dan laluan destinasi. Kesan jurang, tarikh pendua, sekatan di luar pengekalan sumber, dan kesan sampingan hiliran. Nyahdayakan kesan bukan data seperti e-mel, pengebilan, dan panggilan API luaran, atau halakan ia ke mod audit, supaya mainan semula sejarah tidak mencetuskan tindakan perniagaan sebenar sekali lagi.

Langkah 2: Gunakan manifes sekatan untuk jeda, sambung semula, dan audit

Anggap setiap business_date sebagai unit kerja yang terikat. Manifes harus merekodkan sekurang-kurangnya:

backfill_id, business_date, input_snapshot, code_sha,
state, attempt, input_rows, output_rows, output_checksum,
staging_location, published_version, started_at, completed_at

Model keadaan yang berguna ialah PENDING → RUNNING → VALIDATED → PUBLISHED, dengan kegagalan memasuki FAILED. Tuntut unit melalui kemas kini bersyarat atau pajakan (lease) supaya sekatan hanya mempunyai satu pemilik aktif. Pajakan yang tamat tempoh boleh dituntut semula. Cuba semula hanya sekatan yang gagal dan tulis percubaan pementasan terasing yang lain untuk sekatan tersebut; jangan sekali-kali menambah data secara membuta tuli (blind append) ke jadual akhir.

Jika sekatan tarikh ditutup sepenuhnya, penulisan idempoten yang paling mudah adalah dengan membina sekatan yang lengkap dan kemudian menggantikan sekatan tersebut secara transaksi. Jika pesanan boleh dibetulkan merentas tarikh, gunakan kunci perniagaan yang stabil dan versi sumber dalam MERGE. Tentukan pemenang yang jelas, seperti source_updated_at diikuti oleh source_sequence monotonik untuk kes seri. MERGE menghalang rekod sejarah lama daripada menggantikan pembetulan baharu hanya apabila kunci utama, versi, dan semantik pemadaman semuanya boleh dipercayai.

Langkah 3: Dapatkan keserempakan daripada pengukuran dan bukannya meneka bilangan bebenang

Keperluan 180 TB/5 hari memberikan batas bawah bacaan mentah kira-kira 417 MB/s. Jalankan kenari (canary) pada 1 sekatan yang mewakili dan ukur bait, tempoh masa, CPU, memori, masa giliran gudang data, dan ruang sementara untuk pembacaan, penyahmampatan, kocokan, transformasi, penulisan, dan pengesahan. Jika satu sekatan memberikan r MB/s daya pemprosesan berkesan, batas bawah keserempakan teori adalah kira-kira ceil(417/r). Kuota sumber, puncak kocokan, kapasiti komit sasaran, dan had kos akan terus mengekang nilai sebenar.

Berikan pengisian semula kolam pengiraan atau barisan giliran yang berasingan pada keutamaan yang lebih rendah daripada tokokan harian. Hadkan keserempakan penjadual, bacaan sumber, penulisan sasaran, dan jumlah kos secara bersama; mengehadkan satu faktor sahaja biasanya tidak mencukupi. Pengawal memerhatikan kesegaran P95 saluran paip langsung, barisan giliran gudang data, dan pendikitan sumber. Apabila kesegaran menghampiri 45 minit, ia berhenti menuntut sekatan baharu atau menurunkan keserempakan. Ia meningkat secara beransur-ansur hanya selepas saluran paip langsung kembali ke julat yang selamat. Jangan mematikan secara paksa (hard-kill) sekatan yang sedang melakukan komit dan meninggalkan output separa. Isyarat pembatalan harus menghalang tuntutan baharu dan membiarkan kerja aktif selesai atau mengembalikan semula pementasan dengan selamat.

Selepas ujian kenari lulus, tingkatkan skala secara berkelompok: contohnya, mula-mula 1 sekatan, kemudian 3, kemudian keserempakan selamat yang diukur. Perhatikan kitaran tokokan langsung yang lengkap pada setiap tahap. Jika kapasiti tidak dapat memenuhi tarikh akhir, ubah tarikh akhir, kapasiti sementara, atau skop lebih awal. Jangan sembunyikan ralat anggaran dengan mengorbankan kesegaran langsung.

Langkah 4: Tentukan pemilikan penulisan antara saluran paip sejarah dan langsung

Mula-mula, kira semula selang sejarah daripada syot kilat sumber atau tanda air log W0 ke dalam versi baharu. Jika saluran paip langsung membetulkan hanya 7 hari terkini, biarkan pengisian semula memiliki secara eksklusif 83 hari yang lebih lama. Kekalkan 7 hari terkini di bawah pemilikan langsung, kemudian kira semula atau cantumkan tetingkap bertindih tersebut ke dalam versi baharu pada penghujungnya.

Jika pembetulan langsung boleh menyentuh sebarang pesanan sejarah, gunakan aliran syot-kilat-tambah-pengejaran-delta (snapshot-plus-delta-catch-up):

1. Rekod W0; pengisian semula hanya membaca input berketetapan tidak lewat daripada W0.
2. Saluran paip langsung terus menyediakan versi lama, manakala perubahan selepas W0 kekal dalam log yang boleh dimainkan semula.
3. Selepas kesemua 90 sekatan sejarah disahkan, rekod W1 dan gunakan perubahan dalam (W0, W1] pada versi baharu dengan peraturan versi yang sama.
4. Sebaik sahaja kelengahan (lag) berada dalam belanjawan peralihan, bekukan seketika penuding penerbitan atau dapatkan sekatan penulisan (write fence) dan gunakan delta terakhir.
5. Pindahkan pengguna data secara atomik ke versi baharu, kemudian jadikannya sasaran penulisan saluran paip langsung.

Reka bentuk ini memerlukan log perubahan yang lengkap, susunan yang stabil, dan primitif peralihan yang benar-benar atomik. Jika platform tidak mempunyai paparan atomik atau perubahan katalog, gunakan tetingkap penyelenggaraan yang jelas atau penggantian sekatan bertransaksi dengan sandaran sekatan lama. Dokumentasikan keadaan perantaraan yang kelihatan; jangan berjanji peralihan yang lancar secara lisan.

Langkah 5: Sahkan secara berlapis dan letakkan pintu kawalan ketat sebelum penerbitan

Jalankan tiga lapisan semakan selepas setiap sekatan pementasan selesai:

• Struktur dan kesempurnaan: skema serasi, medan wajib ada, kunci perniagaan unik, batas tarikh yang betul, dan tiada sekatan yang hilang atau pendua antara 90 sekatan tersebut.
• Penyesuaian sumber: bandingkan kiraan baris input dan output, pesanan berbeza (distinct), jumlah sebelum cukai, cukai, dan jumlah bersih mengikut tarikh, wilayah, mata wang, dan negeri. Untuk agregat, kekalkan perbezaan peringkat rekod yang boleh disiasat.
• Peraturan perniagaan dan perbezaan: pemuliharaan jumlah, bayaran balik dalam jumlah yang boleh dibayar balik, dan peralihan keadaan yang sah. Perbezaan versi baharu berbanding lama harus tertumpu pada pesanan yang terjejas oleh kecacatan; bahagian yang tidak terjejas tidak boleh berubah tanpa penjelasan.

Kiraan baris yang sama adalah bukti yang lemah: percantuman yang buruk boleh menambah dan meninggalkan baris pada masa yang sama. Kira juga checksum berbaldi mengikut kunci yang stabil, sampel kecacatan yang diketahui, tarikh sempadan, pembetulan lewat, dan pemadaman, serta minta pemilik kewangan atau produk data mengesahkan arah pembetulan. Versikan pertanyaan pengesahan dan kekalkan ambang, nilai sebenar, dan keputusan.

Pintu penerbitan global harus memerlukan sekurang-kurangnya: 90/90 VALIDATED dalam manifes; tiada sekatan aktif atau gagal; syot kilat input, kod, dan versi pergantungan yang konsisten; pengejaran sehingga W1; semua penegasan tegar lulus; saluran paip harian mengekalkan kesegaran P95 45 minit semasa pengisian semula; dan kelulusan pemilik. Sebarang kegagalan akan mengekalkan versi lama agar terus kelihatan.

Langkah 6: Beralih sekali sahaja, pantau secara berterusan, dan kembalikan semula dengan pantas

Simpan penuding bacaan dan versi output lama sebelum penerbitan. Peralihan hanya mengubah paparan stabil atau penuding katalog; ia tidak memindahkan 180 TB semasa peralihan. Jalankan segera suite pertanyaan pengguna data terhadap papan pemuka kritikal dan kerja hiliran, serta semak kependaman (latency) pertanyaan dan penulisan tokokan terkini. Teruskan membandingkan metrik penting antara versi lama dan baharu sepanjang tempoh pemerhatian.

Jika keunikan kunci, penyesuaian jumlah, kesegaran langsung, atau pertanyaan pengguna gagal, hentikan penerbitan ke versi baharu dan alihkan penuding kembali. Kekalkan versi yang gagal, manifes, dan bukti pengesahan untuk siasatan; jangan edit di tempatnya dan mempersembahkannya sebagai versi yang sama. Selepas membetulkan input atau kod, cipta spesifikasi larian baharu. Guna semula sekatan yang terbukti boleh dipercayai dan serasi dengan versi; kira semula sekatan yang versinya berbeza.

Paparan pemantauan harus menunjukkan TB yang diproses dan baki TB, kiraan sekatan mengikut keadaan, daya pemprosesan, anggaran masa siap, percubaan semula dan kegagalan pengesahan, pendikitan sumber, barisan giliran kolam pengiraan, kependaman komit sasaran, dan kesegaran P50/P95 saluran paip langsung. Makluman harus merangkumi backfill_id, sekatan, versi kod, pintu kawalan yang gagal, dan pemilik supaya pengendali boleh memutuskan sama ada mahu mengurangkan keserempakan, mencuba semula sekatan, atau menghentikan keseluruhan penerbitan.

Contoh Jawapan Berkualiti Tinggi

"Saya akan membekukan pengisian semula ini terlebih dahulu sebagai larian berversi: 90 nilai business_date, syot kilat mentah dan tanda air W0, SHA kod, versi dimensi cukai, versi jadual sasaran, dan ambang penerimaan. Setiap hari adalah satu tugasan yang menulis output pementasan terasing. Manifes merekodkan PENDING/RUNNING/VALIDATED/PUBLISHED dan setiap percubaan. Transformasi hanya menggunakan masa logik. Sekatan tertutup dibina dan diganti sepenuhnya; pesanan yang boleh menerima pembetulan lewat menggunakan kunci utama yang stabil dan versi sumber dalam MERGE, jadi versi lama tidak boleh menulis ganti versi yang lebih baharu."

"Memproses 180 TB dalam masa 5 hari memerlukan sekurang-kurangnya kira-kira 417 MB/s purata bacaan mentah, sebelum percubaan semula dan pengesahan. Saya akan menanda aras satu sekatan yang mewakili, mengukur daya pemprosesan hujung ke hujung dan puncak setiap peringkat, kemudian meningkatkan keserempakan secara berperingkat. Pengisian semula mendapat kolam sumber terasing berkeutamaan rendah dengan had pada bacaan sumber, penulisan sasaran, dan keserempakan penjadual. Pengawal melindungi kesegaran P95 langsung: ia berhenti menuntut sekatan baharu apabila kelengahan menghampiri 45 minit dan meningkat semula secara perlahan selepas pemulihan."

"Untuk ketepatan serentak, saya membina versi baharu daripada syot kilat W0 sementara saluran paip langsung terus menyediakan versi lama. Selepas sekatan sejarah selesai, saya merekodkan W1, memainkan semula pembetulan (W0, W1] ke dalam versi baharu, kemudian menggunakan sekatan singkat untuk pengejaran akhir dan mengalihkan penuding secara atomik. Penerbitan memerlukan 90/90 sekatan, kunci unik, penyesuaian jumlah sumber, invarian perniagaan, perbezaan lama/baharu yang boleh dijelaskan, dan kesegaran pengeluaran yang sihat. Saya mengekalkan versi lama sepanjang pemerhatian. Pintu kawalan tegar atau pertanyaan pengguna yang gagal akan mengalihkan penuding kembali dan memelihara versi yang gagal untuk siasatan."

Kesilapan Biasa

• Menetapkan keserempakan penjadual kepada maksimum → Sumber, kocokan, komit sasaran, atau kerja harian menjadi kesesakan (bottleneck) sebenar → Dapatkan keserempakan daripada penandaarasan satu sekatan, batas bawah daya pemprosesan, dan SLO pengeluaran, kemudian dikit secara dinamik.
• Menganggap percubaan semula tugasan sebagai keidempotenan → Pengorkestra hanya melaksanakan tugasan itu sekali lagi; penambahan data secara membuta tuli tetap menduplikasi data → Gunakan input berketetapan dan masa logik, kemudian ganti sekatan atau cantumkan mengikut kunci dan versi stabil.
• Membiarkan kerja sejarah dan langsung menulis pada sekatan yang sama → Pengiraan lama yang selesai lewat boleh menulis ganti pembetulan baharu → Tetapkan pemilikan sekatan atau gunakan pengejaran delta W0/W1 dan susunan versi yang jelas.
• Menerbitkan selepas 90 tugasan berjaya → Keadaan berjaya tidak membuktikan rekod lengkap, jumlah yang betul, atau perbezaan yang munasabah → Gunakan pintu kawalan pada semakan sekatan, sumber, perniagaan, perbezaan, dan pengguna.
• Menulis ganti jadual dalam talian sebelum pengesahan → Pengesahan yang gagal menyebabkan pengiraan semula besar yang lain sebagai laluan pemulihan → Tulis output berversi, sahkan ia, lakukan peralihan sekali sahaja, dan kekalkan penuding lama.
• Hanya membandingkan jumlah kiraan baris → Pendua dan peninggalan data boleh saling membatalkan → Bandingkan juga kunci unik, checksum berbaldi, jumlah, taburan keadaan, dan perbezaan rekod.
• Memanggil now() dalam transformasi sejarah → Dua percubaan menghasilkan semantik sekatan yang berbeza → Sampaikan tarikh logik, syot kilat input, dan versi pergantungan sebagai parameter larian.
• Menjalankan semula semua 180 TB selepas kegagalan → Ini meningkatkan kos dan risiko serta membuang kemajuan yang telah disahkan → Sambung semula unit yang gagal daripada manifes sekatan; kira semula sekatan yang terjejas hanya apabila versi berubah.

Soalan Susulan dan Respons

Susulan 1: Bagaimanakah pengisian semula boleh diulang jika sumber tidak mempunyai syot kilat yang tidak boleh diubah?

Utamakan eksport sejarah berversi yang dicipta sebelum larian, atau rekod kedudukan syot kilat pangkalan data, kedudukan log CDC, dan ID versi objek. Jika satu-satunya sumber ialah jadual boleh ubah, rekod masa bacaan, tanda air, dan checksum setiap sekatan dalam manifes dan tangkap perubahan secara berterusan semasa larian untuk pengejaran kemudian. Apabila input asal tidak dapat dibina semula, dedahkan jurang kebolehulangan tersebut; jangan mendakwa dua percubaan pasti serupa.

Susulan 2: Dimensi SCD yang dibetulkan menyalurkan data ke jadual fakta. Yang manakah harus diisi semula terlebih dahulu?

Bina subgraf salasilah (lineage) yang terjejas dan proseskannya mengikut susunan topologi. Cipta versi dimensi baharu terlebih dahulu, kemudian cantumkan jadual fakta ke versi tersebut setakat masa peristiwa, dan akhirnya bina semula agregat dan mart data. Setiap lapisan berkongsi satu pengecam versi pengisian semula; jangan terbitkan dimensi lama dengan jadual fakta baharu. Sahkan kunci perniagaan dimensi, selang berkesan yang tidak bertindih, kadar padanan kunci asing fakta, dan agregat kritikal.

Susulan 3: Bagaimanakah anda menerbitkan jika platform tidak mempunyai pertukaran jadual atomik?

Utamakan penulisan jadual versi bebas dan halakan pengguna melalui paparan yang stabil. Jika takrifan paparan boleh digantikan secara atomik, tukar paparan sahaja. Jika itu pun tidak tersedia, gunakan penggantian kelompok kecil bertransaksi dengan sandaran sekatan lama atau tetingkap penyelenggaraan yang jelas yang menjeda bacaan dan penulisan berkaitan untuk peralihan dan penerimaan. Nyatakan keadaan perantaraan yang kelihatan dan masa pengembalian semula; jangan gambarkan penulisan ganti berbilang langkah sebagai atomik.

Susulan 4: Versi lama dan baharu mempunyai kiraan baris dan jumlah amaun yang sama. Apakah perkara lain yang perlu diperiksa?

Kira checksum berbaldi mengikut kunci perniagaan yang stabil dan periksa perbezaan rekod. Bandingkan taburan mengikut wilayah, mata wang, keadaan pesanan, jalur cukai, dan tarikh sempadan. Sahkan contoh buruk yang diketahui telah berubah dan contoh yang tidak terjejas tidak berubah. Semak kunci utama, integriti rujukan, peralihan keadaan, dan had siling bayaran balik. Jumlah keseluruhan yang sama boleh menyembunyikan terlebih kira yang membatalkan peninggalan data.

Susulan 5: Patutkah larian bermula dengan tarikh paling lama atau paling baharu?

Ia bergantung pada pergantungan dan nilai perniagaan. Jika sekatan yang terkemudian bergantung pada keadaan daripada sekatan yang lebih awal, jalankan ke hadapan. Jika sekatan adalah bebas dan laporan terkini mempunyai kecemasan yang lebih tinggi, susunan terbalik boleh membantu. Dalam kedua-dua kes, pintu penerbitan masih meliputi selang yang lengkap melainkan pemilik produk meluluskan penerbitan berfasa secara jelas dengan versi berasingan, skop pengguna, dan sempadan pengembalian semula untuk setiap fasa.