لماذا تستخدم ClickHouse Cloud بدلًا من BigQuery؟
تحميل البيانات من BigQuery إلى ClickHouse Cloud
مجموعة البيانات
post وvote وuser وcomment وbadge على Stack Overflow من عام 2008 حتى أبريل 2024. يظهر المخطط الخاص بـ BigQuery لهذه البيانات أدناه:
بالنسبة إلى المستخدمين الذين يرغبون في تعبئة مجموعة البيانات هذه في مثيل BigQuery لاختبار خطوات الترحيل، فقد وفرنا بيانات هذه الجداول بتنسيق Parquet في حاوية GCS، كما تتوفر أوامر DDL لإنشاء الجداول وتحميلها في BigQuery هنا.
ترحيل البيانات
- تحميل مجمّع أولي مع تحديثات دورية - يجب ترحيل مجموعة بيانات أولية، إلى جانب تحديثات دورية على فترات زمنية محددة، مثل يوميًا. وتُعالَج التحديثات هنا بإعادة إرسال الصفوف التي تغيّرت، مع الاستدلال عليها من خلال عمود يمكن استخدامه للمقارنة (مثل التاريخ). أمّا عمليات الحذف فتُعالَج عبر إعادة تحميل كاملة ودورية لمجموعة البيانات.
- النسخ المتماثل في الوقت الفعلي أو CDC - يجب ترحيل مجموعة بيانات أولية. ويجب أن تنعكس التغييرات التي تطرأ على هذه المجموعة في ClickHouse بزمن شبه فوري، بحيث لا يُقبل سوى تأخير لبضع ثوانٍ. وهذا يُعَدّ فعليًا عملية التقاط بيانات التغيير (CDC)، حيث يجب مزامنة الجداول في BigQuery مع ClickHouse؛ أي إن عمليات الإدراج والتحديث والحذف في جدول BigQuery يجب أن تُطبَّق على جدول مكافئ في ClickHouse.
التحميل المجمّع عبر Google Cloud Storage (GCS)
- صدِّر الجداول السبعة إلى GCS. الأوامر اللازمة لذلك متاحة هنا.
-
استورد البيانات إلى ClickHouse Cloud. ويمكننا استخدام دالة الجدول gcs لهذا الغرض. تتوفر أوامر DDL واستعلامات الاستيراد هنا. لاحظ أنه نظرًا لأن مثيل ClickHouse Cloud يتكوّن من عدة عُقد حوسبة، فإننا نستخدم دالة الجدول s3Cluster بدلًا من دالة الجدول
gcs. وتعمل هذه الدالة أيضًا مع حاويات GCS، كما تستفيد من جميع عُقد خدمة ClickHouse Cloud لتحميل البيانات على التوازي.
- تدعم وظيفة التصدير في BigQuery استخدام عامل تصفية لتصدير مجموعة فرعية من البيانات.
- يدعم BigQuery التصدير بتنسيقات Parquet وAvro وJSON وCSV وبعدد من أنواع الضغط — وكلها مدعومة في ClickHouse.
- يدعم GCS إدارة دورة حياة الكائنات، ما يتيح حذف البيانات التي تم تصديرها واستيرادها إلى ClickHouse بعد فترة زمنية محددة.
- تتيح Google تصدير ما يصل إلى 50 تيرابايت يوميًا إلى GCS مجانًا. ولا يدفع المستخدمون إلا مقابل تخزين GCS.
- تنتج عمليات التصدير عدة ملفات تلقائيًا، مع حد أقصى قدره 1 جيجابايت من بيانات الجدول لكل ملف. وهذا مفيد لـ ClickHouse لأنه يتيح تنفيذ عمليات الاستيراد على التوازي.
النسخ المتماثل في الوقت الفعلي أو CDC عبر الاستعلامات المجدولة
تصميم المخططات
posts الأساسي. يوضّح أدناه مخطط BigQuery لهذا الجدول:
تحسين الأنواع
INSERT INTO SELECT بسيط، وذلك بقراءة البيانات المُصدَّرة من gcs باستخدام دالة الجدول gcs. لاحظ أنه في ClickHouse Cloud يمكنك أيضًا استخدام دالة الجدول s3Cluster المتوافقة مع gcs لتنفيذ التحميل بالتوازي عبر عدة عقد:
كيف تختلف المفاتيح الأساسية في ClickHouse؟
- تُعد كفاءة الذاكرة والقرص أمرًا بالغ الأهمية على النطاق الذي يُستخدم فيه ClickHouse عادةً. وتُكتب البيانات إلى جداول ClickHouse على هيئة أجزاء تُعرف باسم جزء، مع تطبيق قواعد لدمج هذه الأجزاء في الخلفية. في ClickHouse، لكل جزء فهرسه الأساسي الخاص. وعند دمج الأجزاء، تُدمج أيضًا الفهارس الأساسية الخاصة بالجزء المدمج. لاحظ أن هذه الفهارس لا تُبنى لكل صف. وبدلًا من ذلك، يحتوي الفهرس الأساسي لكل جزء على مُدخل فهرسة واحد لكل مجموعة من الصفوف — وتُسمى هذه التقنية بالفهرسة المتناثرة.
- تصبح الفهرسة المتناثرة ممكنة لأن ClickHouse يخزّن صفوف جزء على القرص مرتبةً حسب مفتاح محدد. وبدلًا من تحديد الصفوف المفردة مباشرةً (كما في فهرس يعتمد على B-Tree)، يتيح الفهرس الأساسي المتناثر تحديد مجموعات الصفوف التي قد تطابق الاستعلام بسرعة (عبر binary search على مُدخلات الفهرس). ثم تُمرَّر مجموعات الصفوف التي يُحتمل أن تكون مطابقة، بالتوازي، إلى ClickHouse engine للعثور على النتائج المطابقة. ويتيح تصميم الفهرس هذا أن يكون الفهرس الأساسي صغيرًا (بحيث يلائم الذاكرة الرئيسية بالكامل) مع تسريع أزمنة تنفيذ الاستعلامات بشكل ملحوظ، خاصةً في استعلامات النطاق الشائعة في حالات استخدام تحليلات البيانات. ولمزيد من التفاصيل، نوصي بهذا الدليل المتعمق.
ستُرتَّب جميع الأعمدة في الجدول استنادًا إلى قيمة مفتاح الترتيب المحدد، بغض النظر عمّا إذا كانت مُضمَّنة في المفتاح نفسه أم لا. على سبيل المثال، إذا استُخدمCreationDateكمفتاح، فسيطابق ترتيب القيم في جميع الأعمدة الأخرى ترتيب القيم في العمودCreationDate. ويمكن تحديد عدة مفاتيح ترتيب — وسيؤدي ذلك إلى الترتيب بالدلالات نفسها لعبارةORDER BYفي استعلامSELECT.
اختيار مفتاح الترتيب
تقنيات نمذجة البيانات
التقسيم
PARTITION BY. ويمكن أن تحتوي هذه العبارة على تعبير SQL على أي عمود أو أعمدة، وتحدد نتيجته القسم الذي يُرسَل إليه الصف.
ترتبط أجزاء البيانات منطقيًا بكل قسم على القرص، ويمكن الاستعلام عنها بصورة مستقلة. في المثال أدناه، نقسم جدول posts حسب السنة باستخدام التعبير toYear(CreationDate). ومع إدراج الصفوف في ClickHouse، سيُقيَّم هذا التعبير على كل صف، ثم تُوجَّه الصفوف إلى القسم الناتج في صورة أجزاء بيانات جديدة تنتمي إلى ذلك القسم.
التطبيقات
- إدارة البيانات - في ClickHouse، ينبغي أن تنظر إلى التقسيم أساسًا على أنه ميزة لإدارة البيانات، لا أسلوبًا لتحسين الاستعلامات. فمن خلال فصل البيانات منطقيًا استنادًا إلى مفتاح، يمكن التعامل مع كل قسم بشكل مستقل، كحذفه مثلًا. ويتيح لك ذلك نقل الأقسام، وبالتالي المجموعات الفرعية، بين طبقات التخزين بكفاءة وفقًا للوقت أو انتهاء صلاحية البيانات/حذفها بكفاءة من العنقود. في المثال أدناه، نزيل المنشورات من عام 2008:
- تحسين الاستعلامات - رغم أن الأقسام قد تساعد في تحسين أداء الاستعلامات، فإن ذلك يعتمد بدرجة كبيرة على أنماط الوصول. فإذا كانت الاستعلامات تستهدف عددًا قليلًا فقط من الأقسام (ويُفضَّل قسم واحد)، فقد يتحسن الأداء. ويكون هذا مفيدًا عادةً فقط إذا لم يكن مفتاح التقسيم ضمن المفتاح الأساسي وكنت تُجري تصفيةً بناءً عليه. ومع ذلك، فإن الاستعلامات التي تحتاج إلى تغطية عدد كبير من الأقسام قد يكون أداؤها أسوأ مما لو لم يُستخدم أي تقسيم (إذ قد ينتج عن التقسيم عدد أكبر من الأجزاء). كما أن فائدة استهداف قسم واحد ستكون أقل وضوحًا، وقد تنعدم تمامًا، إذا كان مفتاح التقسيم يقع أصلًا ضمن الأعمدة الأولى للمفتاح الأساسي. ويمكن أيضًا استخدام التقسيم لتحسين استعلامات
GROUP BYإذا كانت القيم داخل كل قسم فريدة. ومع ذلك، ينبغي عمومًا التأكد من تحسين المفتاح الأساسي، وعدم النظر إلى التقسيم كتقنية لتحسين الاستعلامات إلا في حالات استثنائية تكون فيها أنماط الوصول متركزة على مجموعة فرعية محددة ومتوقعة من البيانات الزمنية، مثل التقسيم حسب اليوم، مع تركّز معظم الاستعلامات على اليوم الأخير.
التوصيات
ORDER BY.
داخليًا، يقوم ClickHouse بإنشاء أجزاء للبيانات المُدرجة. ومع إدراج المزيد من البيانات، يزداد عدد الأجزاء. ولمنع ارتفاع عدد الأجزاء إلى مستوى مفرط، بما يؤدي إلى تراجع أداء الاستعلامات (بسبب زيادة عدد الملفات التي يجب قراءتها)، تُدمج الأجزاء معًا في عملية غير متزامنة تعمل في الخلفية. وإذا تجاوز عدد الأجزاء حدًا مُعدًا مسبقًا، فسيرمي ClickHouse استثناءً عند insert على شكل خطأ “too many parts”. لا ينبغي أن يحدث هذا في التشغيل العادي، ولا يحدث إلا إذا كان ClickHouse مُهيأً بشكل غير صحيح أو استُخدم بطريقة غير سليمة، مثل تنفيذ عدد كبير من عمليات insert الصغيرة. وبما أن الأجزاء تُنشأ لكل قسم بشكل مستقل، فإن زيادة عدد الأقسام تؤدي إلى زيادة عدد الأجزاء؛ أي إن عددها يكون مضاعفًا لعدد الأقسام. لذلك، قد تتسبب مفاتيح التقسيم عالية التفرّد في هذا الخطأ، وينبغي تجنّبها.
العروض المادية مقابل الإسقاطات
ORDER BY للجدول نفسه.
في نمذجة البيانات في ClickHouse، نستعرض كيف يمكن استخدام العروض المادية
في ClickHouse للحساب المسبق للتجميعات، وتحويل الصفوف، وتحسين الاستعلامات
لأنماط وصول مختلفة. وفي الحالة الأخيرة، قدمنا مثالًا حيث
يرسل العرض المادي الصفوف إلى جدول هدف ذي مفتاح ترتيب مختلف
عن الجدول الأصلي الذي يستقبل عمليات الإدراج.
على سبيل المثال، انظر إلى الاستعلام التالي:
UserId
ليس مفتاح الترتيب. سبق أن حللنا هذه المشكلة باستخدام عرض مادي
يعمل بمثابة lookup لـ PostId. ويمكن حل المشكلة نفسها باستخدام إسقاط.
يضيف الأمر أدناه إسقاطًا مع ORDER BY user_id.
ALTER، فسيكون الإنشاء غير متزامن
عند إصدار الأمر MATERIALIZE PROJECTION. يمكنك التحقق من تقدّم
هذه العملية باستخدام الاستعلام التالي، مع انتظار is_done=1.
EXPLAIN، نؤكد أيضًا أن الإسقاط استُخدم لتنفيذ هذا الاستعلام:
متى تستخدم الإسقاطات
- تكون هناك حاجة إلى إعادة ترتيب كاملة للبيانات. ومع أن التعبير في الإسقاط يمكنه، من الناحية النظرية، استخدام
GROUP BY,فإن العروض المادية أكثر فاعلية في الاحتفاظ بالتجميعات. كما أن مُحسِّن الاستعلامات يكون أكثر ميلًا إلى استغلال الإسقاطات التي تستخدم إعادة ترتيب بسيطة، أيSELECT * ORDER BY x. ويمكنك تحديد مجموعة فرعية من الأعمدة في هذا التعبير لتقليل بصمة التخزين. - يكون المستخدمون متقبلين للزيادة المصاحبة في بصمة التخزين والعبء الإضافي الناتج عن كتابة البيانات مرتين. اختبر التأثير على سرعة الإدراج وقيِّم عبء التخزين الإضافي.
إعادة صياغة استعلامات BigQuery في ClickHouse
ClickHouse
الدوال التجميعية
argMax لحساب السؤال الأكثر مشاهدةً في كل عام.
BigQuery
ClickHouse
الشروط والمصفوفات
HAVING وSELECT.
BigQuery
ClickHouse