Get a free observability report to evaluate the potential savingsContact us →
تحليل التكاليف3 دقيقة قراءة

أطول استعلامات BigQuery مدةً

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

لماذا يهم هذا

وقت التنفيذ مهم أكثر من التكلفة وحدها. استعلام يعمل 30 دقيقة يحجب خط أنابيب بيانات ويؤخّر تحديثات لوحة التحكّم أو يجبر المحلل على تغيير السياق. في ظل تسعير Editions، تستهلك الاستعلامات طويلة التشغيل أيضاً ساعات فتحات أكثر (حدّ أدنى دقيقة واحدة للفوترة). يُحسّن تقليل مدة الاستعلام التكلفة والإنتاجية معاً.

كيف يعمل

يحسب الاستعلام وقت التنفيذ كـ TIMESTAMP_DIFF بين end_time وstart_time. كما يحسب نسبة الثواني لكل GiB: تشير القيم العالية إلى استعلامات بطيئة بالنسبة لكمية البيانات التي تعالجها، مما يُشير إلى إمكانية التحسين.

استعلام SQL

Fill in your details to get a ready-to-run query:

SQL
-- Slowest queries ranked by wall-clock execution time

DECLARE lookback_days INT64 DEFAULT 7;

WITH jobs AS (
  SELECT
    user_email,
    query,
    project_id,
    start_time,
    end_time,
    TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_sec,
    COALESCE(total_bytes_billed, 0) AS bytes_billed,
    total_slot_ms,
    ROW_NUMBER() OVER (PARTITION BY job_id ORDER BY end_time DESC) AS rn
  FROM `your-project`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_days DAY)
    AND job_type = 'QUERY' AND state = 'DONE' AND total_slot_ms IS NOT NULL
),
deduplicated AS (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY query ORDER BY bytes_billed DESC) AS qrn
  FROM jobs WHERE rn = 1
)
SELECT
  user_email,
  query,
  project_id,
  start_time,
  duration_sec,
  ROUND(SAFE_DIVIDE(total_slot_ms, duration_sec * 1000), 0) AS avg_slots,
...
استبدل your-project وregion-us بمشروع GCP الخاص بك ومنطقة مجموعة البيانات.

شرح الاستعلام

مستويان من إزالة التكرار: أولاً بـ job_id لإزالة إدخالات المهام المكررة، ثم بنص الاستعلام لإظهار التنفيذ الأغلى فقط لكل استعلام فريد. يقسم مقياس sec_per_gib وقت التنفيذ على البايتات المفوترة — تعني القيم العالية أن الاستعلام بطيء بالنسبة لكمية البيانات التي يقرأها.

رؤى أساسية

  • lightbulb

    الاستعلامات التي تتجاوز 10 دقائق تمسح على الأرجح جداول غير مقسّمة أو تُجري عمليات تبديل مكلفة.

  • lightbulb

    ارتفاع sec_per_gib يعني أن الاستعلام مقيّد بالحوسبة (JOINs معقدة وفرز ووظائف نافذة) لا بالإدخال/الإخراج.

  • lightbulb

    انخفاض sec_per_gib يعني أن الاستعلام يمسح الكثير من البيانات بسرعة — قد يستفيد من تقطيع الأقسام.

  • lightbulb

    قد تُفضي الاستعلامات طويلة التشغيل في خطوط الأنابيب إلى تأخيرات متتالية في جميع التبعيات النهائية.

أفضل الممارسات

  1. 1

    اضبط حدود مهلة الاستعلام لمنع الاستعلامات الجامحة من استهلاك الموارد إلى أجلٍ غير مسمى.

  2. 2

    لخطوط أنابيب ETL، قسّم الاستعلامات المونوليثية طويلة التشغيل إلى تحويلات أصغر وذات مراحل.

  3. 3

    استخدم EXPLAIN PLAN لتحديد أبطأ المراحل وتحسينها تحديداً.

  4. 4

    فكّر في وظائف التجميع التقريبي (APPROX_QUANTILES وAPPROX_TOP_COUNT) للاستعلامات الاستكشافية.

هل تريد من CloudClerk إيجاد هذه الوفورات تلقائياً؟

تتصل منصتنا بمشروع BigQuery الخاص بك وتُشغّل هذه التحليلات تلقائياً وتقدّم توصيات التحسين المدعومة بالذكاء الاصطناعي — مع إخفاء هوية بياناتك بالكامل.

أدلة ذات صلة