مشاركة عبر

اعتبارات الإنتاج للبث المنظم

  • مقالة

تحتوي هذه المقالة على توصيات لجدولة أحمال عمل Structured Streaming باستخدام الوظائف على Azure Databricks.

توصي Databricks دائما بالقيام بما يلي:

  • إزالة التعليمات البرمجية غير الضرورية من دفاتر الملاحظات التي من شأنها إرجاع النتائج، مثل display و count.
  • لا تقم بتشغيل أحمال عمل Structured Streaming باستخدام الحوسبة لجميع الأغراض. جدولة التدفقات دائما كوظائف باستخدام حساب الوظائف.
  • جدولة المهام باستخدام Continuous الوضع.
  • لا تقم بتمكين التحجيم التلقائي للحساب لمهام Structured Streaming.

تستفيد بعض أحمال العمل من ما يلي:

قدمت Azure Databricks جداول Delta Live لتقليل تعقيدات إدارة البنية الأساسية للإنتاج لأحمال عمل الدفق المنظم. توصي Databricks باستخدام Delta Live Tables للبنية الأساسية لبرنامج ربط العمليات التجارية الجديدة للتدفق المنظم. راجع ما هي جداول Delta Live؟.

إشعار

يحتوي التحجيم التلقائي للحساب على قيود على تقليص حجم نظام المجموعة لأحمال عمل Structured Streaming. توصي Databricks باستخدام Delta Live Tables مع تغيير الحجم التلقائي المحسن لأحمال العمل المتدفقة. راجع تحسين استخدام نظام المجموعة لخطوط أنابيب Delta Live Tables مع التحجيم التلقائي المحسن.

تصميم أحمال عمل الدفق لتوقع فشل

توصي Databricks دائما بتكوين مهام الدفق لإعادة التشغيل تلقائيا عند الفشل. تفترض بعض الوظائف، بما في ذلك تطور المخطط، تكوين أحمال عمل Structured Streaming لإعادة المحاولة تلقائيا. راجع تكوين مهام Structured Streaming لإعادة تشغيل استعلامات الدفق عند الفشل.

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

إشعار

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

إذا قمت بتغيير التكوينات بين عمليات التشغيل، تنطبق هذه التكوينات على الدفعة الجديدة الأولى المخطط لها. راجع الاسترداد بعد التغييرات في استعلام Structured Streaming.

متى تتم إعادة محاولة المهمة؟

يمكنك جدولة مهام متعددة كجزء من مهمة Azure Databricks. عند تكوين مهمة باستخدام المشغل المستمر، لا يمكنك تعيين التبعيات بين المهام.

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

  • مهام متعددة: حدد وظيفة ذات مهام متعددة تقوم بتشغيل أحمال عمل الدفق باستخدام المشغل المستمر.
  • استعلامات متعددة: تعريف استعلامات دفق متعددة في التعليمات البرمجية المصدر لمهمة واحدة.

يمكنك أيضا الجمع بين هذه الاستراتيجيات. يقارن الجدول التالي هذه الأساليب.

مهام متعددة استعلامات متعددة
كيف تتم مشاركة الحساب؟ توصي Databricks بنشر حساب الوظائف بحجم مناسب لكل مهمة دفق. يمكنك اختياريا مشاركة الحساب عبر المهام. تشترك جميع الاستعلامات في نفس الحساب. يمكنك تعيين استعلامات اختيارية إلى تجمعات المجدول.
كيف تتم معالجة عمليات إعادة المحاولة؟ يجب أن تفشل جميع المهام قبل إعادة محاولة المهمة. تعيد المهمة المحاولة إذا فشل أي استعلام.

تكوين مهام Structured Streaming لإعادة تشغيل استعلامات الدفق عند الفشل

توصي Databricks بتكوين جميع أحمال العمل المتدفقة باستخدام المشغل المستمر. راجع تشغيل المهام باستمرار.

يوفر المشغل المستمر السلوك التالي بشكل افتراضي:

  • يمنع أكثر من تشغيل متزامن واحد للوظيفة.
  • بدء تشغيل جديد عند فشل تشغيل سابق.
  • يستخدم التراجع الأسي لإعادة المحاولة.

توصي Databricks دائما باستخدام حساب الوظائف بدلا من الحوسبة لجميع الأغراض عند جدولة مهام سير العمل. عند فشل المهمة وإعادة المحاولة، يتم نشر موارد الحوسبة الجديدة.

إشعار

لا تحتاج إلى استخدام streamingQuery.awaitTermination() أو spark.streams.awaitAnyTermination(). تمنع الوظائف تلقائيا اكتمال التشغيل عندما يكون استعلام الدفق نشطا.

استخدام تجمعات المجدول للاستعلامات المتدفقة المتعددة

يمكنك تكوين تجمعات الجدولة لتعيين سعة الحوسبة للاستعلامات عند تشغيل استعلامات دفق متعددة من نفس التعليمات البرمجية المصدر.

بشكل افتراضي، يتم تشغيل جميع الاستعلامات التي بدأت في دفتر ملاحظات في نفس تجمع الجدولة العادلة. تعمل مهام Apache Spark التي تم إنشاؤها بواسطة المشغلات من جميع استعلامات الدفق في دفتر ملاحظات واحدة تلو الأخرى بترتيب "الدخول أولا، أولا للخارج" (FIFO). يمكن أن يؤدي هذا إلى تأخيرات غير ضرورية في الاستعلامات، لأنها لا تشارك موارد نظام المجموعة بكفاءة.

تسمح لك تجمعات المجدول بتعريف استعلامات Structured Streaming التي تشترك في موارد الحوسبة.

يعين query1 المثال التالي إلى تجمع مخصص، بينما query2 يشارك تجمع query3 مجدول.

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

إشعار

يجب أن يكون تكوين الخاصية المحلية في نفس خلية دفتر الملاحظات حيث تبدأ تشغيل استعلام البث.

راجع وثائق Apache fair scheduler لمزيد من التفاصيل.