الانتقال إلى المحتوى الرئيسي

لماذا تستخدم ClickHouse Cloud بدلًا من BigQuery؟

باختصار: لأن ClickHouse أسرع وأقل تكلفة وأكثر كفاءة من BigQuery في تحليلات البيانات الحديثة:

تحميل البيانات من BigQuery إلى ClickHouse Cloud

مجموعة البيانات

كمثال على مجموعة بيانات يوضّح عملية ترحيل نموذجية من BigQuery إلى ClickHouse Cloud، نستخدم مجموعة بيانات Stack Overflow الموثقة هنا. تحتوي هذه المجموعة على كل post وvote وuser وcomment وbadge على Stack Overflow من عام 2008 حتى أبريل 2024. يظهر المخطط الخاص بـ BigQuery لهذه البيانات أدناه: بالنسبة إلى المستخدمين الذين يرغبون في تعبئة مجموعة البيانات هذه في مثيل BigQuery لاختبار خطوات الترحيل، فقد وفرنا بيانات هذه الجداول بتنسيق Parquet في حاوية GCS، كما تتوفر أوامر DDL لإنشاء الجداول وتحميلها في BigQuery هنا.

ترحيل البيانات

يندرج ترحيل البيانات بين BigQuery وClickHouse Cloud ضمن نوعين رئيسيين من أحمال العمل:
  • تحميل مجمّع أولي مع تحديثات دورية - يجب ترحيل مجموعة بيانات أولية، إلى جانب تحديثات دورية على فترات زمنية محددة، مثل يوميًا. وتُعالَج التحديثات هنا بإعادة إرسال الصفوف التي تغيّرت، مع الاستدلال عليها من خلال عمود يمكن استخدامه للمقارنة (مثل التاريخ). أمّا عمليات الحذف فتُعالَج عبر إعادة تحميل كاملة ودورية لمجموعة البيانات.
  • النسخ المتماثل في الوقت الفعلي أو CDC - يجب ترحيل مجموعة بيانات أولية. ويجب أن تنعكس التغييرات التي تطرأ على هذه المجموعة في ClickHouse بزمن شبه فوري، بحيث لا يُقبل سوى تأخير لبضع ثوانٍ. وهذا يُعَدّ فعليًا عملية التقاط بيانات التغيير (CDC)، حيث يجب مزامنة الجداول في BigQuery مع ClickHouse؛ أي إن عمليات الإدراج والتحديث والحذف في جدول BigQuery يجب أن تُطبَّق على جدول مكافئ في ClickHouse.

التحميل المجمّع عبر Google Cloud Storage (GCS)

يدعم BigQuery تصدير البيانات إلى مخزن الكائنات من Google ‏(GCS). بالنسبة إلى مجموعة البيانات في مثالنا:
  1. صدِّر الجداول السبعة إلى GCS. الأوامر اللازمة لذلك متاحة هنا.
  2. استورد البيانات إلى ClickHouse Cloud. ويمكننا استخدام دالة الجدول gcs لهذا الغرض. تتوفر أوامر DDL واستعلامات الاستيراد هنا. لاحظ أنه نظرًا لأن مثيل ClickHouse Cloud يتكوّن من عدة عُقد حوسبة، فإننا نستخدم دالة الجدول s3Cluster بدلًا من دالة الجدول gcs. وتعمل هذه الدالة أيضًا مع حاويات GCS، كما تستفيد من جميع عُقد خدمة ClickHouse Cloud لتحميل البيانات على التوازي.
يتميّز هذا النهج بعدد من المزايا: قبل تجربة الأمثلة التالية، نوصي المستخدمين بمراجعة الأذونات المطلوبة للتصدير وتوصيات مواقع البيانات لتحقيق أفضل أداء لعمليتَي التصدير والاستيراد.

النسخ المتماثل في الوقت الفعلي أو CDC عبر الاستعلامات المجدولة

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

تصميم المخططات

تتضمن مجموعة بيانات Stack Overflow عددًا من الجداول المرتبطة. نوصي بالتركيز أولًا على ترحيل الجدول الأساسي. وليس بالضرورة أن يكون هذا أكبر الجداول، بل الجدول الذي تتوقع أن يستقبل أكبر عدد من الاستعلامات التحليلية. سيتيح لك ذلك التعرّف على مفاهيم ClickHouse الأساسية. وقد يتطلب هذا الجدول إعادة تصميم مع إضافة جداول أخرى للاستفادة الكاملة من إمكانات ClickHouse وتحقيق أفضل أداء. نستعرض عملية النمذجة هذه في وثائق نمذجة البيانات الخاصة بنا. وانسجامًا مع هذا المبدأ، نركز على جدول posts الأساسي. يوضّح أدناه مخطط BigQuery لهذا الجدول:

تحسين الأنواع

ينتج عن تطبيق العملية الموضحة هنا المخطط التالي:
يمكننا ملء هذا الجدول باستخدام INSERT INTO SELECT بسيط، وذلك بقراءة البيانات المُصدَّرة من gcs باستخدام دالة الجدول gcs. لاحظ أنه في ClickHouse Cloud يمكنك أيضًا استخدام دالة الجدول s3Cluster المتوافقة مع gcs لتنفيذ التحميل بالتوازي عبر عدة عقد:
لا نحتفظ بأي قيم nulls في المخطط الجديد. ويحوّل أمر insert أعلاه هذه القيم ضمنيًا إلى القيم الافتراضية لأنواعها المقابلة: 0 للأعداد الصحيحة وقيمة فارغة للسلاسل النصية. كما يحوّل ClickHouse تلقائيًا أي قيم رقمية إلى الدقة المستهدفة لها.

كيف تختلف المفاتيح الأساسية في ClickHouse؟

كما هو موضح هنا، ومثل BigQuery، لا يفرض ClickHouse تفرّد قيم أعمدة المفتاح الأساسي في الجدول. وعلى غرار التجميع في BigQuery، تُخزَّن بيانات جدول ClickHouse على القرص مرتبةً حسب أعمدة المفتاح الأساسي. ويستفيد مُحسِّن الاستعلامات من ترتيب الفرز هذا لتجنّب إعادة الفرز، وتقليل استخدام الذاكرة في عمليات JOIN، وتمكين الإيقاف المبكر لعبارات LIMIT. وعلى خلاف BigQuery، ينشئ ClickHouse تلقائيًا فهرسًا أساسيًا (متناثرًا) استنادًا إلى قيم أعمدة المفتاح الأساسي. ويُستخدم هذا الفهرس لتسريع جميع الاستعلامات التي تتضمن عوامل تصفية على أعمدة المفتاح الأساسي. وتحديدًا:
  • تُعد كفاءة الذاكرة والقرص أمرًا بالغ الأهمية على النطاق الذي يُستخدم فيه ClickHouse عادةً. وتُكتب البيانات إلى جداول ClickHouse على هيئة أجزاء تُعرف باسم جزء، مع تطبيق قواعد لدمج هذه الأجزاء في الخلفية. في ClickHouse، لكل جزء فهرسه الأساسي الخاص. وعند دمج الأجزاء، تُدمج أيضًا الفهارس الأساسية الخاصة بالجزء المدمج. لاحظ أن هذه الفهارس لا تُبنى لكل صف. وبدلًا من ذلك، يحتوي الفهرس الأساسي لكل جزء على مُدخل فهرسة واحد لكل مجموعة من الصفوف — وتُسمى هذه التقنية بالفهرسة المتناثرة.
  • تصبح الفهرسة المتناثرة ممكنة لأن ClickHouse يخزّن صفوف جزء على القرص مرتبةً حسب مفتاح محدد. وبدلًا من تحديد الصفوف المفردة مباشرةً (كما في فهرس يعتمد على B-Tree)، يتيح الفهرس الأساسي المتناثر تحديد مجموعات الصفوف التي قد تطابق الاستعلام بسرعة (عبر binary search على مُدخلات الفهرس). ثم تُمرَّر مجموعات الصفوف التي يُحتمل أن تكون مطابقة، بالتوازي، إلى ClickHouse engine للعثور على النتائج المطابقة. ويتيح تصميم الفهرس هذا أن يكون الفهرس الأساسي صغيرًا (بحيث يلائم الذاكرة الرئيسية بالكامل) مع تسريع أزمنة تنفيذ الاستعلامات بشكل ملحوظ، خاصةً في استعلامات النطاق الشائعة في حالات استخدام تحليلات البيانات. ولمزيد من التفاصيل، نوصي بهذا الدليل المتعمق.
لا يحدد المفتاح الأساسي المختار في ClickHouse الفهرس فقط، بل يحدد أيضًا ترتيب كتابة البيانات على القرص. ولذلك، يمكن أن يؤثر بشكل كبير في مستويات الضغط، مما قد ينعكس بدوره على أداء الاستعلامات. فمفتاح الترتيب الذي يجعل قيم معظم الأعمدة تُكتب بترتيب متجاور يسمح لخوارزمية الضغط المحددة (وترميزات الضغط) بضغط البيانات بفاعلية أكبر.
ستُرتَّب جميع الأعمدة في الجدول استنادًا إلى قيمة مفتاح الترتيب المحدد، بغض النظر عمّا إذا كانت مُضمَّنة في المفتاح نفسه أم لا. على سبيل المثال، إذا استُخدم CreationDate كمفتاح، فسيطابق ترتيب القيم في جميع الأعمدة الأخرى ترتيب القيم في العمود CreationDate. ويمكن تحديد عدة مفاتيح ترتيب — وسيؤدي ذلك إلى الترتيب بالدلالات نفسها لعبارة ORDER BY في استعلام SELECT.

اختيار مفتاح الترتيب

للاطلاع على الاعتبارات والخطوات المتعلقة باختيار مفتاح الترتيب، باستخدام جدول Posts كمثال، راجع هنا.

تقنيات نمذجة البيانات

نوصي المستخدمين الذين ينتقلون من BigQuery بقراءة دليل نمذجة البيانات في ClickHouse. يستخدم هذا الدليل مجموعة بيانات Stack Overflow نفسها، ويستعرض عدة أساليب بالاستفادة من ميزات ClickHouse.

التقسيم

إذا كنت معتادًا على BigQuery، فستكون على دراية بمفهوم تقسيم الجداول لتحسين الأداء وسهولة الإدارة في قواعد البيانات الكبيرة، وذلك عبر تقسيم الجداول إلى أجزاء أصغر وأكثر قابلية للإدارة تُسمى أقسامًا. ويمكن تحقيق هذا التقسيم باستخدام نطاق على عمود محدد (مثل التواريخ)، أو قوائم محددة، أو باستخدام hash على مفتاح. ويتيح ذلك للمسؤولين تنظيم البيانات بناءً على معايير محددة مثل النطاقات الزمنية أو المواقع الجغرافية. يساعد التقسيم في تحسين أداء الاستعلامات من خلال تسريع الوصول إلى البيانات عبر استبعاد الأقسام غير اللازمة، إلى جانب فهرسة أكثر كفاءة. كما يدعم مهام الصيانة مثل النسخ الاحتياطية وحذف البيانات نهائيًا، إذ يتيح تنفيذ العمليات على أقسام منفردة بدلًا من الجدول بالكامل. بالإضافة إلى ذلك، يمكن أن يحسّن التقسيم قابلية التوسع في قواعد بيانات BigQuery بشكل كبير من خلال توزيع الحمل على عدة أقسام. في ClickHouse، يُحدَّد التقسيم للجدول عند تعريفه مبدئيًا عبر عبارة PARTITION BY. ويمكن أن تحتوي هذه العبارة على تعبير SQL على أي عمود أو أعمدة، وتحدد نتيجته القسم الذي يُرسَل إليه الصف. ترتبط أجزاء البيانات منطقيًا بكل قسم على القرص، ويمكن الاستعلام عنها بصورة مستقلة. في المثال أدناه، نقسم جدول posts حسب السنة باستخدام التعبير toYear(CreationDate). ومع إدراج الصفوف في ClickHouse، سيُقيَّم هذا التعبير على كل صف، ثم تُوجَّه الصفوف إلى القسم الناتج في صورة أجزاء بيانات جديدة تنتمي إلى ذلك القسم.

التطبيقات

للتقسيم في ClickHouse تطبيقات مشابهة لتلك الموجودة في BigQuery، ولكن مع بعض الفروق الدقيقة. وبشكل أكثر تحديدًا:
  • إدارة البيانات - في ClickHouse، ينبغي أن تنظر إلى التقسيم أساسًا على أنه ميزة لإدارة البيانات، لا أسلوبًا لتحسين الاستعلامات. فمن خلال فصل البيانات منطقيًا استنادًا إلى مفتاح، يمكن التعامل مع كل قسم بشكل مستقل، كحذفه مثلًا. ويتيح لك ذلك نقل الأقسام، وبالتالي المجموعات الفرعية، بين طبقات التخزين بكفاءة وفقًا للوقت أو انتهاء صلاحية البيانات/حذفها بكفاءة من العنقود. في المثال أدناه، نزيل المنشورات من عام 2008:
  • تحسين الاستعلامات - رغم أن الأقسام قد تساعد في تحسين أداء الاستعلامات، فإن ذلك يعتمد بدرجة كبيرة على أنماط الوصول. فإذا كانت الاستعلامات تستهدف عددًا قليلًا فقط من الأقسام (ويُفضَّل قسم واحد)، فقد يتحسن الأداء. ويكون هذا مفيدًا عادةً فقط إذا لم يكن مفتاح التقسيم ضمن المفتاح الأساسي وكنت تُجري تصفيةً بناءً عليه. ومع ذلك، فإن الاستعلامات التي تحتاج إلى تغطية عدد كبير من الأقسام قد يكون أداؤها أسوأ مما لو لم يُستخدم أي تقسيم (إذ قد ينتج عن التقسيم عدد أكبر من الأجزاء). كما أن فائدة استهداف قسم واحد ستكون أقل وضوحًا، وقد تنعدم تمامًا، إذا كان مفتاح التقسيم يقع أصلًا ضمن الأعمدة الأولى للمفتاح الأساسي. ويمكن أيضًا استخدام التقسيم لتحسين استعلامات GROUP BY إذا كانت القيم داخل كل قسم فريدة. ومع ذلك، ينبغي عمومًا التأكد من تحسين المفتاح الأساسي، وعدم النظر إلى التقسيم كتقنية لتحسين الاستعلامات إلا في حالات استثنائية تكون فيها أنماط الوصول متركزة على مجموعة فرعية محددة ومتوقعة من البيانات الزمنية، مثل التقسيم حسب اليوم، مع تركّز معظم الاستعلامات على اليوم الأخير.

التوصيات

ينبغي النظر إلى التقسيم بوصفه أسلوبًا لإدارة البيانات. وهو مثالي عندما تكون هناك حاجة إلى إزالة البيانات من العنقود عند العمل مع بيانات السلاسل الزمنية؛ فعلى سبيل المثال، يمكن ببساطة حذف أقدم قسم. مهم: تأكد من أن تعبير مفتاح التقسيم لا ينتج مجموعة عالية التفرّد؛ أي ينبغي تجنّب إنشاء أكثر من 100 قسم. على سبيل المثال، لا تقسّم بياناتك بحسب أعمدة عالية التفرّد مثل معرّفات العملاء أو الأسماء. وبدلًا من ذلك، اجعل معرّف العميل أو الاسم هو العمود الأول في تعبير ORDER BY.
داخليًا، يقوم ClickHouse بإنشاء أجزاء للبيانات المُدرجة. ومع إدراج المزيد من البيانات، يزداد عدد الأجزاء. ولمنع ارتفاع عدد الأجزاء إلى مستوى مفرط، بما يؤدي إلى تراجع أداء الاستعلامات (بسبب زيادة عدد الملفات التي يجب قراءتها)، تُدمج الأجزاء معًا في عملية غير متزامنة تعمل في الخلفية. وإذا تجاوز عدد الأجزاء حدًا مُعدًا مسبقًا، فسيرمي ClickHouse استثناءً عند insert على شكل خطأ “too many parts”. لا ينبغي أن يحدث هذا في التشغيل العادي، ولا يحدث إلا إذا كان ClickHouse مُهيأً بشكل غير صحيح أو استُخدم بطريقة غير سليمة، مثل تنفيذ عدد كبير من عمليات insert الصغيرة. وبما أن الأجزاء تُنشأ لكل قسم بشكل مستقل، فإن زيادة عدد الأقسام تؤدي إلى زيادة عدد الأجزاء؛ أي إن عددها يكون مضاعفًا لعدد الأقسام. لذلك، قد تتسبب مفاتيح التقسيم عالية التفرّد في هذا الخطأ، وينبغي تجنّبها.

العروض المادية مقابل الإسقاطات

يتيح مفهوم الإسقاطات في ClickHouse تحديد عدة عبارات ORDER BY للجدول نفسه. في نمذجة البيانات في ClickHouse، نستعرض كيف يمكن استخدام العروض المادية في ClickHouse للحساب المسبق للتجميعات، وتحويل الصفوف، وتحسين الاستعلامات لأنماط وصول مختلفة. وفي الحالة الأخيرة، قدمنا مثالًا حيث يرسل العرض المادي الصفوف إلى جدول هدف ذي مفتاح ترتيب مختلف عن الجدول الأصلي الذي يستقبل عمليات الإدراج. على سبيل المثال، انظر إلى الاستعلام التالي:
يتطلب هذا الاستعلام فحص جميع الصفوف البالغ عددها 90m (وإن كان ذلك بسرعة) لأن UserId ليس مفتاح الترتيب. سبق أن حللنا هذه المشكلة باستخدام عرض مادي يعمل بمثابة lookup لـ PostId. ويمكن حل المشكلة نفسها باستخدام إسقاط. يضيف الأمر أدناه إسقاطًا مع ORDER BY user_id.
لاحظ أنه يجب أولاً إنشاء الإسقاط ثم مَوضَعته فعليًا. يتسبب هذا الأمر الأخير في تخزين البيانات مرتين على القرص وبترتيبين مختلفين. ويمكن أيضًا تعريف الإسقاط عند إنشاء الجدول، كما هو موضح أدناه، وسيُحفَظ تلقائيًا عند insert البيانات.
إذا أُنشئ الإسقاط باستخدام الأمر ALTER، فسيكون الإنشاء غير متزامن عند إصدار الأمر MATERIALIZE PROJECTION. يمكنك التحقق من تقدّم هذه العملية باستخدام الاستعلام التالي، مع انتظار is_done=1.
إذا أعدنا تنفيذ الاستعلام أعلاه، فسنلاحظ أن الأداء قد تحسّن بشكل ملحوظ مقابل مساحة تخزين إضافية.
وباستخدام أمر EXPLAIN، نؤكد أيضًا أن الإسقاط استُخدم لتنفيذ هذا الاستعلام:

متى تستخدم الإسقاطات

تُعد الإسقاطات ميزة جذابة للمستخدمين الجدد، إذ تُصان تلقائيًا عند إدراج البيانات. وعلاوة على ذلك، يمكن إرسال الاستعلامات ببساطة إلى جدول واحد، حيث تُستغل الإسقاطات متى أمكن لتسريع زمن الاستجابة. وهذا بخلاف العروض المادية، حيث يتعين على المستخدم اختيار الجدول الهدف المُحسَّن المناسب أو إعادة كتابة الاستعلام، وفقًا لعوامل التصفية. ويضع هذا عبئًا أكبر على تطبيقات المستخدم ويزيد من تعقيد جهة العميل. وعلى الرغم من هذه المزايا، فإن الإسقاطات تنطوي على بعض القيود الجوهرية التي ينبغي أن تكون على دراية بها، لذا يجب استخدامها بحذر. ولمزيد من التفاصيل، راجع “العروض المادية مقابل الإسقاطات” نوصي باستخدام الإسقاطات عندما:
  • تكون هناك حاجة إلى إعادة ترتيب كاملة للبيانات. ومع أن التعبير في الإسقاط يمكنه، من الناحية النظرية، استخدام GROUP BY, فإن العروض المادية أكثر فاعلية في الاحتفاظ بالتجميعات. كما أن مُحسِّن الاستعلامات يكون أكثر ميلًا إلى استغلال الإسقاطات التي تستخدم إعادة ترتيب بسيطة، أي SELECT * ORDER BY x. ويمكنك تحديد مجموعة فرعية من الأعمدة في هذا التعبير لتقليل بصمة التخزين.
  • يكون المستخدمون متقبلين للزيادة المصاحبة في بصمة التخزين والعبء الإضافي الناتج عن كتابة البيانات مرتين. اختبر التأثير على سرعة الإدراج وقيِّم عبء التخزين الإضافي.

إعادة صياغة استعلامات BigQuery في ClickHouse

فيما يلي استعلامات نموذجية للمقارنة بين BigQuery وClickHouse. وتهدف هذه القائمة إلى توضيح كيفية الاستفادة من ميزات ClickHouse لتبسيط الاستعلامات بشكل كبير. وتستخدم الأمثلة هنا مجموعة بيانات Stack Overflow الكاملة (حتى أبريل 2024). Users (الذين لديهم أكثر من 10 أسئلة) ويحصلون على أكبر عدد من المشاهدات: BigQuery ClickHouse
أي الوسوم تحصد أكبر عدد من المشاهدات: BigQuery
ClickHouse

الدوال التجميعية

حيثما أمكن، ينبغي الاستفادة من الدوال التجميعية في ClickHouse. نوضح أدناه استخدام الدالة argMax لحساب السؤال الأكثر مشاهدةً في كل عام. BigQuery ClickHouse

الشروط والمصفوفات

تجعل الدوال الشرطية ودوال المصفوفات الاستعلامات أبسط بكثير. يحسب الاستعلام التالي الوسوم (التي يتجاوز عدد مرات ظهورها 10000) ذات أكبر زيادة مئوية من 2022 إلى 2023. لاحظ مدى إيجاز استعلام ClickHouse التالي بفضل الشروط ودوال المصفوفات وإمكانية إعادة استخدام الأسماء المستعارة في عبارتي HAVING وSELECT. BigQuery ClickHouse
وبهذا نختتم دليلنا الأساسي للانتقال من BigQuery إلى ClickHouse. ننصحك بقراءة دليل نمذجة البيانات في ClickHouse للتعرّف أكثر إلى ميزات ClickHouse المتقدمة.
آخر تعديل في ٢ يوليو ٢٠٢٦