Apache Airflow / المتقدم: المعالجة التاريخية والنشر وأدلة التعافي / الدرس 13
الملء التاريخي والأقسام والبيانات المتأخرة
تخطيط إعادة المعالجة التاريخية كعملية عمل محدودة بتغطية فترات وسلوك استبدال واضحين.
في هذه الصفحة
أهداف الدرس
- تمييز لحاق المجدول وإعادة المهمة والملء التاريخي الصريح.
- مراجعة سياسة الإعادة والتزامن وأدلة التصحيح المتأخر.
تسمية النتيجة التاريخية المعاد بناؤها
ينشئ الملء التاريخي تشغيلات لسير العمل في تواريخ مجدولة سابقة وفق الجدول الزمني القائم على الوقت. ويختلف ذلك عن إعادة محاولة مهمة واحدة فاشلة، وعن catchup الذي ينشئ الفترات المجدولة الفائتة. حدد سبب إعادة بناء التاريخ: فتصحيح الحساب ووصول بيانات متأخرة وغياب ناتج تتطلب أدلة قبول مختلفة. لا تستطيع مهمة تقرأ latest دائماً إعادة بناء قسم قديم بأمان لمجرد وجود تاريخ قديم في اسم تشغيلتها. وضح إصدار المصدر وفترة العمل وإصدار الحساب. وإذا انتهت صلاحية المدخلات الأصلية، فأعلن فجوة التغطية بدلاً من اعتبار لقطة أحدث إعادة إنتاج للوقائع التاريخية الأصلية.
تغير حالة التشغيلات الموجودة الخطة
تميز خيارات إعادة المعالجة في Airflow 3.1 إنشاء التواريخ المفقودة فقط، وإعادة النظر في التشغيلات الفاشلة، وإعادة النظر في المكتملة أو الفاشلة. ولا تكرر هذه الخيارات ببساطة أحدث تشغيلة إذا ظلت queued أو running. راجع السياسة الموثقة بدقة مقابل الحالات الموجودة قبل توقع التواريخ التي ستنشأ. قائمة التواريخ التي يعرضها dry run دليل تخطيط، وليست وعداً بنتيجة التنفيذ اللاحق المعتمدة على الحالة. وفي هذا الأساس، يطبق max_active_runs للملء التاريخي مستقلاً عن إعداد DAG العادي؛ لذا تستلزم حماية نظام خارجي مراجعة قبول الملء مع حدود الجدولة المعتادة.
حصر نطاق عمل محدود محلياً
يعدد مثال Python ثلاثة أقسام يومية معلنة، مستخدماً بداية مشمولة ونهاية مستبعدة بصورة صريحة. هذه اتفاقية التخطيط في المقرر وليست تعريف حدود خيارات CLI في Airflow. تنتج قائمة قابلة للمراجعة دون إنشاء تشغيلات أو الاتصال بقاعدة التنسيق. قارن القائمة ببيانات المصدر المتوقعة وأقسام الوجهة الموجودة قبل أي تنفيذ مصرح به. تحتاج المتطلبات التقويمية في مناطق زمنية محلية معالجة حدود مستقلة؛ ويستخدم المثال تواريخ بسيطة عمداً. سجل حد توقف وأقصى عدد عناصر متوقع كي لا يحول خطأ في المدى تصحيحاً صغيراً إلى سنوات من العمل غير المقصود.
from datetime import date, timedelta
start = date(2026, 10, 1)
end_exclusive = date(2026, 10, 4)
partitions = []
current = start
while current < end_exclusive:
partitions.append(current.isoformat())
current += timedelta(days=1)
assert partitions == ['2026-10-01', '2026-10-02', '2026-10-03']
print(len(partitions))3تحصر ثلاثة تواريخ؛ ولا تحاكي حدود أمر Airflow أو تنشئ تشغيلات.
اختيار الاستبدال أو التعديل أو الناتج بإصدار
قد تغير البيانات المتأخرة النتيجة الصحيحة لفترة سبق نشر تقريرها. حدد هل تستبدل إعادة المعالجة الفترة ذرياً، أم تنشر إصدار تقرير جديداً، أم تضيف تعديلاً معرفاً بوضوح. تؤدي الإضافة العمياء غالباً إلى تكرار الصفوف الأصلية. يجب أن يعرف القراء الإصدار المرجعي وكيف يستعاد نشر انقطع في منتصفه. يسمي سجل التصميم نية استبدال بإصدار وهوية قسم ثابتة، لكنه لا ينفذ ذرية تخزين بعيد. قد يتطلب سير عمل حقيقي بوابة اعتماد أو نشر؛ ومع ذلك ينبغي أن ينتج منطق المهمة دليلاً محدداً على مصالحة الإجماليات القديمة والمصححة.
{"business_partition":"2026-10-01","calculation_version":"v2","publication":"versioned-replacement","source_manifest":"lab-manifest-17","expected_previous_version":"v1"}تصف الحقول نية العمل ويجب تنفيذها ببروتوكول نشر تدعمه الوجهة.
التحقق من التغطية قبل إعلان الاكتمال
قد يهم ترتيب التشغيل إذا اعتمدت أقسام تاريخية على نتائج أقدم؛ فلا يكون الترتيب العكسي آمناً دائماً لمجرد أن الأداة توفره. فضل منطق أقسام مستقلة حيث أمكن، ووضح الاعتمادات المتبقية. يقارن القبول الأقسام المطلوبة وهويات العمل الفريدة وإصدارات الحساب والآثار المنشورة، بما فيها الفترات الفاشلة والمستبعدة عمداً. لا يكفي نجاح التشغيلات إذا لم ينشأ تاريخ مطلوب أصلاً. لا ينفذ المقرر أمر ملء أو مسح مهام أو تعديل حالة. يختبر محلياً تعداد التواريخ المحدود وسجل JSON فقط، ويبقى سلوك التنسيق وتعافي الوجهة غير مختبرين.
الأخطاء الشائعة وإصلاحها
إعادة كتابة كل التواريخ بأحدث المصدر.
- لماذا يحدث؟
- عدم ربط التسميات التاريخية بأقسام المدخلات.
- كيف تصلحه؟
- اختر تغطية مصدر بإصدار لكل فترة.
- كيف تتجنب تكراره؟
- اختبر قسماً قديماً ينفذ في يوم لاحق.
إرهاق الملء لنظام رغم حد التشغيلات العادية.
- لماذا يحدث؟
- إغفال قبول الملء المستقل من السعة.
- كيف تصلحه؟
- راجع تزامن الملء والأحواض المشتركة معاً.
- كيف تتجنب تكراره؟
- أدرج الحمل التاريخي في ميزانية المورد.
فقد تاريخ مطلوب في ملء ناجح ظاهرياً.
- لماذا يحدث؟
- عدم مصالحة سياسة الحالات مع التغطية.
- كيف تصلحه؟
- قارن الأقسام المطلوبة بالمخرجات المقبولة.
- كيف تتجنب تكراره؟
- احفظ قائمة تغطية محدودة مع النتيجة.
اختبر فهمك
1. لماذا لا تكفي قائمة تواريخ من خطة dry run لإثبات إنشاء كل التشغيلات عند التنفيذ؟
اعرض الحل المشروح
يعتمد الإنشاء أيضاً على سياسة إعادة المعالجة وحالات التشغيلات الموجودة لحظة التنفيذ. فقد تكون للتاريخ تشغيلة مكتملة أو منتظرة أو نشطة تختلف معاملتها وفق السياسة. راجع المدى المقصود والقواعد المعتمدة على الحالة معاً، ثم تحقق من تغطية مخرجات العمل النهائية، بدلاً من اعتبار عدد أسطر الخطة دليلاً على إنشاء التشغيلات أو اكتمالها.
2. هل ينبغي أن يضيف التقرير المصحح صفوف الفترة الأصلية مرة أخرى بصورة افتراضية؟
اعرض الحل المشروح
لا. عرّف استبدالاً، أو نشراً بإصدار، أو قاعدة تعديل صريحة. يجب أن يوضح الاختيار النتيجة المرجعية للقراء وأن يجعل إعادة المحاولة آمنة. صالح الإجماليات القديمة والمصححة، واحفظ إصدار الحساب والمصدر، وتحقق من السلوك إذا نجح النشر لكن فقد إقراره؛ فلا تعني الاستجابة المفقودة أن الوجهة لم تتغير.
أهم ما تعلمته
- يحدد النطاق والحالة والتغطية الملء التاريخي معاً.
- تحتاج الإعادة عقد نشر يتحمل التكرار.