How We Validate Macro Data Accuracy Before Serving It

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

في FXMacroData نعامل جودة البيانات كاهتمام منتج من الدرجة الأولى. كل مؤشر من كل عملة يمر عبر خط أنابيب التحقق من الصحة الحتمي قبل كتابته إلى Firestore وتعريضها من خلال API. هذا المنصب يمر من خلال خط أنبوب الطبقة بطبقة من اللحظة التي يقوم فيها المُحضر بتنزيل استجابة خامة إلى اللحظات التي تصبح فيها القيمة قابلة للسؤال في نقاط النهاية مثل /v1/announcements/{currency}/{indicator}.

المرحلة 1 الإبتلاع: المُحصلون على المصدر المُنظم

يبدأ التحقق من الصحة قبل استخراج قيمة واحدة. كل عملة لديها فئة استلام مخصصة تستهدف مصدر أساسي رسمي موقع البنك المركزي أو مكتب الإحصاء الوطني أو بوابة بيانات الحكومة. نحن نتجنب عمداً المجمعات الثانوية في مسار الابتلاع: فترة تأخيرها وشروط الترخيص، والتحديثات الصامتة العرضية تخلق عدم اليقين الذي لا يمكننا التحكم فيه.

المُحْصِلَانِ فصولٌ غير متزامنةٌ من Python تُنفّذُ async with في الدخول يفتحون aiohttp.ClientSession مع واقعية User-Agent ويتم التحكم في المدة الزمنية؛ عند الخروج يغلقون بشكل نظيف بغض النظر عما إذا كان الحصول على نجح أو رفعت. داخل كل حاصد، تحليل صارم: يتم تحليل HTML مع lxml أو BeautifulSoup باستخدام مختار العنصر الدقيق بدلاً من الاختبارات الاحتياطية للـ Regex ضد العلامة الخام ، ويتم الوصول إلى واجهات برمجة التطبيقات JSON عبر مفاتيح الوصال المكتوبة التي ترتفع على الفور إذا كان الحقل غائباً أو تم تغيير اسمه في المرافق العليا.

{
    "date": "2026-03-31",          # سلسلة التاريخ ISO-8601
    "val": 3.5,                    # يطفو  لا يصلح
    "announcement_datetime": "..." # UTC ISO-8601 إذا كان متاحاً
}

يتم تنفيذ عقد الخروج عند حدود المُحضر: أي سجلات مفقودة date أو val يتم التخلص منها قبل أن تصل إلى المرحلة التالية. announcement_datetime اختيارية عند الإدخال ولكن مطلوبة لمواقع نهاية تواجه النشر التي تعرض توقيت الحدث لمستهلكي واجهة برمجة التطبيقات.

المرحلة 2 فحص المخطط: التحقق من نوع وامتثال

يتم تسليم مخرجات المُحصل الخام إلى معتمد مخطط يطبق أربعة عمليات فحص على كل سجل:

يتم عرض فشل المخططات كإدخالات سجل سحابة منظمة severity=ERROR- لا stage=schema_check، و اسم المُستلم الأصلي. هذا يجعل التمييز بين التشغيل المتقاطع سهلاً في وحدة تحكم GCP.

المرحلة 3 تصفية النطاق والمتفاوت

الصلاحية الهيكلية ضرورية ولكن ليست كافية. 250.0 في المرحلة الثالثة، يتم تطبيق فحصين مكملين لالتقاط هذه الأخطاء الدلالية.

حدود المدى الصعب

كل مؤشر له إدخال كتالوج يتضمن اختيارية min_val و max_val الحدود المستمدة من نطاقات تاريخية معقولة بالإضافة إلى هامش سلامة سخي. -5.0 و 30.0 في عام على العام يتراوح معدل التضخم بين -30.0 و 300.0 % واسعة بما فيه الكفاية لاستيعاب حلقات التضخم المفرط دون تقييد بيانات الأسواق الناشئة المشروعة. يتم الحجر الصحي للقيم خارج هذه الحدود بانتظار مراجعة يدوية.

الكشف عن النقاط الفارغة لدرجة z المتداولة

بالنسبة للمؤشرات التي لديها تاريخ 24 شهرًا على الأقل في Firestore ، يحسب خط الأنابيب متوسطًا متداولًا لمدة 36 شهرًًا والانحراف المعياري ويعلن أي سجل جديد تتجاوز درجة z |4.0|على عكس الحدود الصلبة، لا تتخلص علامات درجة Z تلقائيًا من السجلات، فهي تخلق إدخالًا للمراجعة وتعلق outlier_flag: true الموقع المستخدم في Firestore حتى يتمكن مستخدمي واجهة برمجة التطبيقات من تصفية السجلات التي تحمل علامة النقاط المتطرفة في سير العمل الخاص بهم.

المرحلة 4 التوفيق بين المصادر

بالنسبة لمجموعة فرعية من المؤشرات ذات الأهمية العالية أسعار سعر الفائدة السياسية للبنوك المركزية، مؤشر أسعار المستهلكين الرئيسي، والبطالة يحتفظ خط الأنابيب بمصدر ثانوي للاقتراح. هذا ليس احتياطًا مباشرًا في وقت الطلب (تأتي جميع البيانات المقدمة للمستخدمين حصريًا من Firestore) ؛ إنه فحص للاستمرارية في وقت الاستهلاك.

عندما تكون القيم الابتدائية والثانوية لنفس الشيء (currency, indicator, date) إذا اختلفت أكثر من نسبة تسامح قابلة للتكوين، يتم إطلاق إنذار وتحتفظ القيمة الأساسية بانتظار التحقيق. 5 basis pointsبالنسبة لمؤشر أسعار المستهلكين 0.1 percentage points. تكون التسامحات ضيقة عمدا لهذه المؤشرات لأن حتى الاختلافات الصغيرة غالبا ما تشير إلى خطأ في تحليل، وتأخير في الإبلاغ، أو صراع التحديث الأولي مقابل النهائي.

وبالإضافة إلى التحقق المتقاطع لكل سجل، يمر خط الأنابيب أيضاً فحص الاستمرارية من شهر إلى آخر: إذا كان سجل جديد يمثل تغييراً لأكثر من N الاختلافات المعدنية من المتوسط المتوسط الـ 12 شهراً الأخير، يتم التعامل معها على أنها تضارب مراجعة مرشح. revised علامة عند تحديث قيمة التاريخ بعد النشر الأولي.

المرحلة 5 سلامة يوم العمل

مرحلة التحقق من الصحة النهائية تعالج قيوداً خفية ولكنها مهمة: كل announcement_datetime يجب أن تقع في يوم عمل صالح في منطقة زمنية السوق من العملة التي يتم نشرها. مكاتب الإحصاءات والبنوك المركزية لا تنشر الإعلانات في عطلات نهاية الأسبوع أو العطلات الرسمية لذلك إذا كان خط الأنابيب ينتج ختم زمني يصل في يوم السبت في طوكيو أو عطلة مصرفية في سيدني، حدث خطأ في المداخل.

المُحقق يتصل is_valid_announcement_date(currency, local_date)، والتي تحقق من التاريخ مقابل تعريفات المنطقة الزمنية لكل عملة وتقويمات العطلات الكاملة التي يتم الاحتفاظ بها في قاعدة الرموز. كل عملة تخدمها API AUD ، EUR ، GBP ، JPY ، USD ، CAD ، CHF ، NZD ، وجميع الآخرين لها منطقة زمنية مستقلة جدا جدا جدا وجدول العطل. لا ترث العملات من جلسة العملات الأجنبية الخاصة بها ؛ يمكن أن يكون يوم الجمعة في نيويورك يوم السبت في سيدني ، ويتعامل مع ذلك المصدق بدقة.

def هو_صحيح_الإعلان_التاريخ(currency: str, local_date: date) -> bool:
    tz = CURRENCY_TIMEZONE[currency]
    # رفض عطلة نهاية الأسبوع
    if local_date.weekday() >= 5:
        العودة False
    # رفض العطل العامة
    if local_date in _build_holiday_set(currency, local_date.year):
        العودة False
    العودة True

عندما يُفشل التاريخ المحسوب في هذا التحقق، next_valid_announcement_date يقدم ذلك إلى يوم العمل التالي على سبيل المثال ، بتحريك إعلان عيد الميلاد إلى يوم الاثنين التالي. وهذا يضمن أن نقطة نهاية تقويم الإصدار التي يتم تقديمها لمستهلكي واجهة برمجة التطبيقات تحتوي دائمًا على تواريخ يمكن استخدامها مباشرة في تقويمي التداول دون تنظيف يدوي. يتم تطبيق قواعد يوم العمل هذه أيضًا بواسطة مجموعة اختبار CI التي تفشل في البناء إذا كانت أي عملة في الكتالوج تفتقد منطقة زمنية أو بيانات عطلة.

مراقبة مستمرة وتنبيه

لا يكفي تمرير خط الأنابيب للتحقق من صحته مرة واحدة. يدور خط الأنبوب على جدول زمني يتم تشغيله بواسطة مهام السحابة وتدفقات العمل الاحتياطية وكل عملية تنتج تقييمًا عن بعد منظمًا يغذي طبقة المراقبة.

عندما يفشل المُستلم في إرجاع البيانات وقت انتهاء شبكة، تغيير موقع في المُنتصف، أو تغيير هيكل الاستجابة لا يعود خط الأنابيب إلى المكالمات المباشرة في وقت الطلب. بدلاً من ذلك يصدر فشل التحقق من صحة البيان ويعيد نتيجة فارغة أو نتيجة منظمة. DataUnavailableError هذا يمنع البيانات القديمة أو المؤكدة جزئيا من الوصول إلى طبقة API، حتى لو كانت مؤقتة.

التعامل مع المراجعات والإصدارات الجديدة

تعتبر مراجعات البيانات الكبرى حقيقة من حقائق الحياة. يتم مراجعة تقديرات الناتج المحلي الإجمالي الأولية مرتين أو ثلاث مرات. يتم إعادة بيان الرواتب بشكل كبير. يتم التعامل مع الخطوط التنفيذية للمراجعات صراحة بدلاً من إعادة كتابتها بصمت:

• تخزين الطباعة الأولى: يحتفظ خط الأنابيب بالقيمة الأولى لمؤشر معين (currency, indicator, date) مع revised: false العلم
• كشف التغييرات: في عمليات التناول اللاحقة، إذا تغيرت قيمة التاريخ بأكثر من عتبة مراجعة المؤشر، يتم تحديث الوثيقة و revised: true تم تعيينها
• الحفاظ على التاريخ: يتم الحفاظ على قيمة الطباعة الأولى الأصلية في prior_val المجال لأغراض التدقيق والمقارنة.
• شفافية واجهة برمجة التطبيقات: - ... revised يتم تعريض هذا المجال في استجابات واجهة برمجة التطبيقات حتى تستهلك التطبيعات يمكن التمييز بين القراءات الأولية من النهائية.

هذا يهم أكثر بالنسبة للمؤشرات مثل الرواتب غير الزراعية حيث يمكن أن تختلف الطباعة الأولية والمراجعة اللاحقة عن عشرات الآلاف من الوظائف النقطة النهائية لـ "أجور غير الزراعية".

ما الذي يعنيه هذا للمستهلكين API

النتيجة العملية لهذا الخط للجميع الذين يسألون عن API:

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