معالجة الاستعلامات الكبيرة في مهام سير العمل التفاعلية

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

Query Watchdog هي عملية تمنع الاستعلامات من احتكار موارد الكتلة عن طريق فحص الأسباب الأكثر شيوعا للاستعلامات الكبيرة وإنهاء الاستعلامات التي تمر عبر عتبة. توضح هذه المقالة كيفية تمكين وتكوين "مراقبة الاستعلام".

هام

يتم تمكين "مراقبة الاستعلام" لكافة الكتل لجميع الأغراض التي تم إنشاؤها باستخدام واجهة المستخدم.

مثال على استعلام معطل

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

import org.apache.spark.sql.functions._
spark.conf.set("spark.sql.shuffle.partitions", 10)

spark.range(1000000)
  .withColumn("join_key", lit(" "))
  .createOrReplaceTempView("table_x")
spark.range(1000000)
  .withColumn("join_key", lit(" "))
  .createOrReplaceTempView("table_y")

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

في التعليمات البرمجية التالية، المحلل هو الانضمام إلى هذين الجدولين على مفاتيح الخاصة بهم، والتي تنتج الناتج من نتائج تريليون واحد،ويتم إنتاج كل هذه على منفذ واحد (المنفذ الذي يحصل على المفتاح):

SELECT
  id, count()
FROM
  (SELECT
    x.id
  FROM
    table_x x
  JOIN
    table_y y
  on x.join_key = y.join_key)
GROUP BY id

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

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

تمكين وتكوين "مراقبة الاستعلام"

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

spark.conf.set("spark.databricks.queryWatchdog.enabled", true)
spark.conf.set("spark.databricks.queryWatchdog.outputRatioThreshold", 1000L)

التكوين الأخير بتعريف أن أي مهمة معينة يجب أن تنتج أبدا أكثر من 1000 مرة عدد صفوف الإدخال.

تلميح

نسبة الإخراج قابلة للتخصيص بالكامل. نوصي بالبدء بشكل أقل ورؤية العتبة التي تعمل بشكل جيد بالنسبة لك ولفريقك. مجموعة من 1000 إلى 10000 نقطة انطلاق جيدة.

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

SELECT
  join_key,
  sum(x.id),
  count()
FROM
  (SELECT
    x.id,
    y.join_key
  FROM
    table_x x
  JOIN
    table_y y
  on x.join_key = y.join_key)
GROUP BY join_key

إليك ما قد تراه:

Query watchdog

انها عادة ما تكون كافية لتمكين الاستعلام مراقبة وتعيين نسبة عتبة الانتاج / الإدخال ، ولكن لديك أيضا خيار لتعيين اثنين من خصائص إضافية : spark.databricks.queryWatchdog.minTimeSecs و spark.databricks.queryWatchdog.minOutputRows . تحدد هذه الخصائص الحد الأدنى من الوقت الذي يجب أن يتم فيه تشغيل مهمة معينة في استعلام قبل إلغائها والحد الأدنى لعدد صفوف الإخراج لمهمة في هذا الاستعلام.

على سبيل المثال، يمكنك تعيين minTimeSecs قيمة أعلى إذا كنت تريد منحها فرصة لإنتاج عدد كبير من الصفوف لكل مهمة. وبالمثل، يمكنك تعيين spark.databricks.queryWatchdog.minOutputRows إلى عشرة ملايين إذا كنت تريد إيقاف استعلام فقط بعد أن أنتجت مهمة في هذا الاستعلام عشرة ملايين صف. أي شيء أقل ونجح الاستعلام، حتى لو تم تجاوز نسبة الإخراج/الإدخال.

spark.conf.set("spark.databricks.queryWatchdog.minTimeSecs", 10L)
spark.conf.set("spark.databricks.queryWatchdog.minOutputRows", 100000L)

تلميح

إذا قمت بتكوين "مراقبة الاستعلام" في دفتر ملاحظات، لا يستمر التكوين عبر إعادة تشغيل نظام المجموعة. إذا كنت ترغب في تكوين "مراقبة الاستعلام" لكافة مستخدمي نظام مجموعة، نوصي باستخدام تكوين نظام مجموعة.

الكشف عن الاستعلام على مجموعة بيانات كبيرة للغاية

استعلام كبير نموذجي آخر قد تفحص كمية كبيرة من البيانات من جداول كبيرة / مجموعات البيانات. قد تستمر عملية المسح الضوئي لفترة طويلة وتشبع موارد الكتلة (حتى قراءة البيانات الوصفية لجدول خلية كبيرة يمكن أن يستغرق قدرا كبيرا من الوقت). يمكنك تعيين maxHivePartitions لمنع جلب أقسام كثيرة جدا من جدول خلية كبيرة. وبالمثل، يمكنك أيضا تعيين maxQueryTasks إلى الحد من الاستعلامات على مجموعة بيانات كبيرة للغاية.

spark.conf.set("spark.databricks.queryWatchdog.maxHivePartitions", 20000)
spark.conf.set("spark.databricks.queryWatchdog.maxQueryTasks", 20000)

متى يجب تمكين "مراقبة الاستعلام"؟

يجب تمكين Query Watchdog لمجموعات التحليلات المخصصة حيث يشارك SQL المحللين وعلماء البيانات مجموعة معينة ويحتاج المسؤول إلى التأكد من أن الاستعلامات "تلعب بشكل جيد" مع بعضها البعض.

متى يجب تعطيل "مراقبة الاستعلام"؟

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