6 حقائق مزعجة عن Apache Airflow (وماذا يجب أن تفعل حيالها)

تحب فرق البيانات التي تعمل مع عمليات الاستيعاب المعقدة Apache Airflow.

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

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

يُعد Airflow بمثابة “حصان عمل كادح يضع غمامات على عينيه”. فهو لا يتخذ أي إجراء لتصحيح المسار إذا حدث خطأ ما في البيانات، بل يقتصر دوره على إدارة خط المعالجة—فقط. وقد مرّ كل مستخدم تقريبًا بتجربة يُعطيه فيها Airflow إشعارًا بأن المهمة قد اكتملت بنجاح، ليفاجَأ عند فحص البيانات بأن هناك عمودًا مفقودًا وأن النتيجة خاطئة تمامًا، أو أنه لم يتم تمرير أي بيانات فعليًا عبر الأنظمة.

ينطبق هذا بشكل خاص عندما تصل مؤسسة البيانات إلى مرحلة النضج، وتنتقل من إدارة 10 رسوم بيانية موجهة غير دورية (DAGs) إلى الآلاف. ففي هذه الحالة، من المرجح أنك تستخدم هذه الرسوم البيانية الموجهة غير الدورية لاستيعاب البيانات من مصادر خارجية وواجهات برمجة التطبيقات (APIs)، ما يجعل التحكم في جودة البيانات داخل Airflow أكثر صعوبة. إذ لا يمكنك “تنظيف” مجموعة البيانات في المصدر نفسه أو تطبيق سياسات الحوكمة الخاصة بك هناك.

على الرغم من أنه يمكنك إنشاء تنبيهات Slack للتحقق من كل تشغيل يدويًا، لتضمين Airflow كجزء مفيد من مجموعة هندسة البيانات لديك وتحقيق اتفاقيات مستوى الخدمة (SLA)، فإنك بحاجة إلى أتمتة عمليات فحص الجودة. وللقيام بذلك، تحتاج إلى إمكانية الرؤية، ليس فقط لمعرفة ما إذا كانت المهمة قيد التشغيل أم لا، ولكن لمعرفة ما إذا كانت تعمل بشكل صحيح. ولمعرفة سبب ومكان نشأة الخطأ إذا لم يتم تشغيلها بشكل صحيح. وإلا، فستجد نفسك عالقًا في حلقة مفرغة تتكرر فيها المشكلات نفسها يوميًا، أشبه بأحداث فيلم Groundhog Day.

هذا ليس تحديًا بسيطًا، وإذا كنا صريحين، فهذا هو السبب وراء إنشاء IBM® Databand . لم يتم تصميم معظم أدوات قابلية الملاحظة مثل Datadog وNew Relic لتحليل المسارات ولا يمكنها عزل موضع بدء المشكلات أو تجميع المشكلات المتزامنة لاقتراح السبب الأساسي أو اقتراح الإصلاحات.

ومع ذلك، فإن الحاجة إلى قابلية الملاحظة لا تزال غير مفهومة تمامًا، حتى داخل مجتمع Airflow. اليوم، يقول 32% فقط إنهم طبقوا قياس جودة البيانات، رغم أن سؤال صانعي الاستبيان هو مؤشر على التحسن. ولم يطرحوا هذا السؤال في استطلاعات عام 2019 أو 2020.

كيف يمكننا مراقبة جودة البيانات في Airflow ؟ في الحقيقة، Airflow يوصلك إلى منتصف الطريق. كما يشير القائمون على صيانته، “عندما يتم تعريف مسارات العمل على أنها تعليمات برمجية، فإنها تصبح أكثر قابلية للصيانة والإصدار والاختبار والتعاون.”

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

نجد أن هناك العديد من المراحل التي تمر بها المؤسسات الهندسية في رحلتها نحو تحقيق النضج الكامل لقابلية الملاحظة:

• الوعي المسبق: عدم مراقبة جودة البيانات (68% من مجتمع Airflow).
• شريط لاصق وسلك ربط: استعارة أدوات قابلية ملاحظة المنتج وجعلها تعمل، على الرغم من أنها قد لا تكون مثالية.
• حل مصمم لغرض معين: اعتماد أدوات قابلية الملاحظة الكاملة للمسارات مثل Databand لأتمتة التنبيهات وعزل الأسباب الأساسية وإصلاح المشكلات بشكل أسرع. قم بتوظيف التعلّم الآلي لمراقبة معايير البيانات المتوقعة، وتلقَّ تنبيهات عبر Slack تشير إلى وجود بيانات مفقودة أو تغييرات في المخطط داخل Airflow Scheduler، مع إمكانية تتبع أصل المشكلة وتطورها وإجراء اختبارات بأثر رجعي باستخدام البيانات التاريخية.

يتطلب تعلم Airflow استثمارًا للوقت. توثق العديد من المقالات وسلاسل النقاش على موقع Stack Overflow معاناة المطورين الذين يتعثرون في أسئلة أساسية، مثل: "لماذا لم تبدأ المهمة التي قمتُ بجدولتها؟" (والإجابة الشائعة هي: أن Airflow Scheduler يبدأ الجدولة في نهاية الفترة الزمنية المحددة، وليس في بدايتها. وسنتطرق للمزيد من التفاصيل حول هذا الأمر لاحقًا).

علاوة على ذلك، لكي تصبح ماهرًا في استخدام Airflow، ستحتاج إلى تعلم Celery Executor وإما RabbitMQ أو Redis، ولا يوجد مفر من ذلك.

تُشكل هذه الصعوبات عائقًا كافيًا لدرجة أن بعض المؤسسات، مثل شركة برمجيات نظام إدارة المحتوى Bluecore، قررت أنه من الأسهل برمجة واجهة Airflow خاصة بها. وبهذه الطريقة، لن يضطر أي مطور جديد يتم تعيينه أو تكليفه بالعمل إلى تعلّم كافة المُشغِّلات الجديدة، وبدلاً من ذلك، يمكنه الاعتماد على مُشغِّلات Kubernetes التي يألفها بالفعل.

وتُعد عقبات التعلّم هذه مشكلة متكررة بالنسبة إلى المجتمع، لدرجة أن "مشكلات تأهيل المستخدمين الجدد" استدعت تخصيص سؤال خاص بها في استبيان مجتمع Airflow لعام 2021 (الموضح في الصورة أدناه).

وكان من بين أهم شكاوى المستخدمين "الافتقار إلى أفضل الممارسات في تطوير الرسوم البيانية الموجهة غير الدورية (DAG)" و"عدم وجود خيار سهل للبدء". وقد تمت معالجة المشكلة الأخيرة جزئيًا في الإصدار 2.0 من Airflow (الذي صدر بعد الاستبيان)، إلا أن هذا الإصدار يعمل على قاعدة بيانات SQLite حيث لا تتوفر إمكانية المعالجة المتوازية، ويتم تنفيذ كل شيء بشكل تسلسلي.
وكما يشير دليل البدء السريع الخاص بـ Airflow، فإن "هذا الوضع مُقيِّد للغاية" و"من المفترض أن تتجاوز احتياجاتك هذا المستوى بسرعة كبيرة".

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

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

ولكي تتمكن من تشغيل تلك المهام المجدولة بشكل صحيح، سيتعين عليك استيعاب الفروقات الدقيقة الخاصة بـ Airflow بين المُشغِّلات والمهام وكيفية عمل الرسوم البيانية الموجهة غير الدورية (DAG) والحجج الافتراضية وقاعدة بيانات البيانات الوصفية الخاصة بـ Airflow، والمجلد الرئيسي لنشر الرسوم البيانية الموجهة غير الدورية، وغير ذلك الكثير.

ما الحل إذن؟ ربما تفكر في الانضمام إلى نسبة الـ 6% من مستخدمي Airflow الذين يقومون بتطوير واجهات مستخدم رسومية (GUI) خاصة بهم، ويعيدون تسمية المُشغِّلات بمصطلحات تبدو أكثر منطقية بالنسبة إليهم.

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

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

مرة أخرى، يوفر Airflow التمثيل الرسمي للتعليمات البرمجية. التحدي الذي يواجهك هو تطبيق أدوات تطوير البرامج وعمليات التطوير الأخرى لملء الوظائف المفقودة.

ليس هناك الكثير لأقوله هنا. ما لم تستخدم ملفات Docker Compose محددة والتي لا تشكل جزءًا من المستودع الرئيسي، فلن يكون ذلك ممكنًا.

هل توقف Airflow Scheduler عن العمل؟ من الأفضل أن تعيد ملء فنجان القهوة. فقد يتعين عليك القيام بعملية تصحيح الأخطاء التي تتطلب وقتًا طويلاً.

ويعود ذلك -في رأينا- إلى أن Airflow لا يميز بشكل كافٍ بين المُشغِّلات المسؤولة عن التنسيق وتلك المسؤولة عن التنفيذ. فالعديد من المُشغِّلات تقوم بالدورين معًا. ورغم أن هذا قد ساعد خلال مرحلة البرمجة الأولية للمنصة، فإنه يُعد عيبًا تصميميًا قاتلاً يجعل عملية تتبع الأخطاء صعبة للغاية. فإذا حدث أي خطأ، فسيضطر المطورون لديك إلى فحص معاملات تدفق البيانات أولاً، ومن ثم فحص المُشغِّل نفسه في كل مرة تقع فيها مشكلة.

لهذا السبب، يمكن لأدوات مثل Databand أن توفر مساعدة كبيرة. تتميز أداة Databand بقدرتها على مساعدتك في فهم سلامة البنية التحتية الخاصة بك على جميع المستويات: Airflow العالمي والرسم البياني الموجه غير الدوري (DAG) والمهمة والمهام الموجهة للمستخدم. فبدلاً من استنزاف وقت هندسة البيانات في تعلّم ميزات دقيقة ومعقدة للغاية، تتيح Databand لمهندسي البيانات التركيز الفعلي على حل المشكلات التي تخدم الأعمال.

مثل أي مساهم في البرمجيات مفتوحة المصدر يكرس وقته لاقتراح تغييرات جديدة، نأمل أن يُفهم هذا المقال باعتباره رسالة محبة وتقدير، كما هو مقصود منه بالفعل. فنحن هنا في Databand مساهمون نشطون في مجتمع Airflow، ونتطلع بشغف لرؤيته يتطور ليتجاوز حدوده الحالية، وليخدم حالات استخدام الاستخراج والتحويل والتحميل (ETL) وعلم البيانات بشكل أفضل.

كما ذكرنا سابقًا، فإن 86% من المستخدمين يخططون للاستمرار في استخدامه بدلاً من محركات التشغيل الأخرى. وقال 86% آخرون إنهم يوصون به بشدة. يسعدنا أن نقول إننا ننتمي إلى كلتا المجموعتين—إنها أداة رائعة. وبالنسبة إلى أولئك الذين يتعرفون للتو على Airflow، فاعلم فقط أنه إذا واجهت المشكلات المذكورة أعلاه، فإن Airflow Scheduler يستحق هذا الجهد. اكتشف كيف تقوم Databand بتوحيد كافة أنشطة قابلية الملاحظة الخاصة بـ Airflow، بهدف تبسيط عمليات قابلية ملاحظة Apache Airflow الخاصة بك وإدارتها مركزيًا. إذا كنت مستعدًا لإلقاء نظرة أعمق، فاحجز عرضًا توضيحيًا اليوم.