تشخيص التكرار والتصحيحات المفقودة في incremental

افهم الأسباب المحتملة

• قد يستبعد مرشح المصدر تغييرات متأخرة مشروعة، وقد تكون المفاتيح NULL أومكررة، وقد تلحق الاستراتيجية الصفوف أوتطابقها على نحو مختلف عن المتوقع. لا تفرض unique_key تفرّد المصدر ولاتقارن المراجعات تلقائياً. كما أن مزامنة المخطط لا تملأ القيم التاريخية بأثر رجعي.

حدد أول مجتمع تختلف فيه النتيجة

قارن المصدر المعتمد وصفوف المرشحين المختارة والهدف القائم عند نقطة تحقق معلومة. لا يستطيع تصحيح مصدر بقيمة updated_seq تساوي98 اجتياز مرشح يبدأ عند أقصى هدف100. هذا نقص في اختيار المرشحين، لا فشل دمج بالضرورة. وفي المقابل، قد تنشئ مفاتيح مرشحين مكررة مشكلة في الهدف رغم صحة الحد. احتفظ بهوية المصدر الخام ومراجعة الحمولة، حتى يميز الفريق التسليم المكرر من الحالة القديمة ومن تعارض حمولتين للمراجعة نفسها. لا ينفذ الدليل استعلام قاعدة أوأمر تحديث تزايدي.

افحص المفتاح دون افتراض أن التكوين فرضه

يعيد الاستعلام التشخيصي معرّفات الإعارة غير NULL التي تتكرر في علاقة مرشحين مجهزة. ويحتاج غياب المفتاح إلى فحص إلزامية مستقل. قارن الخصائص نفسها في الهدف القائم أيضاً. المعروض SQL توضيحية للقراءة مع ref، وليس أمراً نُفذ. إذا نشأ التكرار في ربط بتاريخ الفروع، فأصلح تفصيل النموذج قبل ضبط الاستراتيجية. فقد يحذف التخلص الاعتباطي من صفوف مكررة المراجعة المعتمدة، مع بقاء عيب المصدر.

select loan_id, count(*) as candidate_rows
from {{ ref('stg_loan_changes') }}
where loan_id is not null
group by loan_id
having count(*) > 1

اكتب قاعدة الحالة المرغوبة قبل الإعادة

يحفظ النموذج المحلي المراجعة2 للإعارة L1 عند عودة المراجعة1 القديمة، ويدرج L2 بالمراجعة3. هذه قاعدة أعلى مراجعة مختارة صراحة، لا مخرجات dbt أصلية ولا سلوكاً توفره unique_key وحدها. تحقق من كيفية جمع المحوّل الفعلي للمرشحين والهدف، بما في ذلك تعارض المراجعات المتساوية والدفعات المعادة. قد يضاعف تحديث تراكمي قياساً عند الإعادة حتى إذا طابق المفتاح. وقد يجعل فقد إقرار التثبيت النتيجة مجهولة؛ فطابق هوية العملية الدائمة بدلاً من استنتاج التراجع من المهلة.

{"existing":{"L1":2},"incoming":[["L1",1],["L2",3]],"chosen_rule":"retain greatest source revision","expected":{"L1":2,"L2":3}}

اختر إصلاحاً محدوداً بمطابقة التاريخ

اختر تصميماً مبرراً لالتقاط التغييرات أونافذة رجوع أومطابقة للتأخر، وحدد معالجة الحذف صراحة. افحص هل يحتاج تعديل المخطط أوالتحويل إلى ملء تاريخي؛ فلا تحسب on_schema_change القيم القديمة وحدها. وقد يعيد full refresh بناء حالة هدف كبيرة ويؤثر في المستهلكين، بينما للقطات دلالات تاريخ مختلفة. ينبغي للمالك المخوّل اختيار مسار التعافي والتمرن عليه بعد حفظ أدلة المصدر والهدف. لا ينفذ الدليل دمجاً أوتحديثاً شاملاً أوملئاً أوحذفاً، ولا يدعي سلوك معاملات لمحوّل حقيقي.

امنع تكرار المشكلة

• انشر عقود وصول المصدر والمفتاح والمراجعة والحذف وتطور المخطط صراحة. احتفظ بتاريخ المصدر وسجل العمليات مدة تكفي للتعافي المدعوم، وراجع فرعي is_incremental ببيانات حدية تكشف الأخطاء.