نوصي بشدة باستخدام الضغط في موضوعات Kafka. إذ يمكن أن يوفّر خفضًا كبيرًا في تكاليف نقل البيانات، من دون أي تأثير يُذكر تقريبًا في الأداء.
لمعرفة المزيد عن ضغط الرسائل في Kafka، ننصح بالبدء بهذا الدليل.
DEFAULT غير مدعوم.
- يقتصر حجم الرسائل الفردية افتراضيًا على 16MB (غير مضغوط) عند التشغيل بأصغر حجم نسخة متماثلة (XS)، وعلى 32MB (غير مضغوط) مع أحجام نسخة متماثلة الأكبر. ستُرفض الرسائل التي تتجاوز هذا الحد مع ظهور خطأ. إذا كنت بحاجة إلى رسائل أكبر، يُرجى التواصل مع الدعم.
يوفّر ClickPipes for Kafka دلالات تسليم at-least-once (وهي من أكثر الأساليب شيوعًا). يسعدنا تلقّي ملاحظاتكم حول دلالات التسليم عبر نموذج التواصل. إذا كنتم بحاجة إلى دلالات exactly-once، فنوصي باستخدام sink الرسمي clickhouse-kafka-connect الخاص بنا.
بالنسبة إلى مصادر البيانات التي تستخدم بروتوكول Apache Kafka، تدعم ClickPipes المصادقة عبر SASL/PLAIN مع تشفير TLS، بالإضافة إلى SASL/SCRAM-SHA-256 وSASL/SCRAM-SHA-512. وبحسب مصدر البث (مثل Redpanda وMSK وغيرها)، سيتم تفعيل جميع آليات المصادقة هذه أو مجموعة فرعية منها وفقًا للتوافق. إذا كانت متطلبات المصادقة لديكم مختلفة، فيُرجى إرسال ملاحظاتكم إلينا.
تعتمد ClickPipes على إعداد Kafka max.fetch_bytes لتقييد حجم البيانات التي تُعالَج في عقدة واحدة من ClickPipes في أي وقت. في بعض الحالات،
لا يلتزم Warpstream بهذا الإعداد، ما قد يتسبب في تعطل أحد خطوط ClickPipes بشكل غير متوقع. نوصي بشدة بضبط الإعداد الخاص بـ Warpstream kafkaMaxFetchPartitionBytesUncompressedOverride
على 8MB (أو أقل) عند تهيئة وكيل WarpStream لديك، لتجنّب تعطل ClickPipes.
يدعم ClickPipes أساليب مصادقة AWS MSK التالية:
عند استخدام مصادقة IAM للاتصال بوسيط MSK، يجب أن يتضمن دور IAM الأذونات اللازمة.
فيما يلي مثال على سياسة IAM المطلوبة لواجهات برمجة تطبيقات Apache Kafka في MSK:
إذا كنت تُجري المصادقة مع MSK باستخدام دور IAM ARN، فستحتاج إلى إضافة علاقة ثقة إلى مثيل ClickHouse Cloud الخاص بك حتى يمكن تولّي هذا الدور.
لا يعمل الوصول المستند إلى الأدوار إلا مع مثيلات ClickHouse Cloud المنشورة على AWS.
يدعم ClickPipes for Kafka تحميل شهادات مخصصة لوسطاء Kafka الذين يستخدمون شهادات خادم غير عامة.
كما يدعم تحميل شهادات العميل والمفاتيح للمصادقة المستندة إلى TLS المتبادل (mTLS).
يُدرِج ClickPipes البيانات في ClickHouse على دفعات. ويهدف ذلك إلى تجنّب إنشاء عدد كبير جدًا من الأجزاء في قاعدة البيانات، مما قد يؤدي إلى مشكلات في الأداء داخل العنقود.
تُدرَج الدفعات عند استيفاء أحد المعايير التالية:
- بلوغ حجم الدفعة الحد الأقصى (100,000 صف أو 28MB لكل 1GB من ذاكرة الكبسولة)
- بقاء الدفعة مفتوحة للحد الأقصى من الوقت (5 ثوانٍ)
يعتمد الكمون (ويُقصد به الوقت بين إنتاج رسالة Kafka وإتاحتها في ClickHouse) على عدد من العوامل (مثل كمون الوسيط، وكمون الشبكة، وحجم الرسالة/تنسيقها). كما أن التجميع على دفعات الموضّح في القسم أعلاه يؤثر أيضًا في الكمون. نوصي دائمًا باختبار حالة الاستخدام الخاصة بك تحت أحمال اعتيادية لتحديد الكمون المتوقع.
لا يقدّم ClickPipes أي ضمانات تتعلق بالكمون. إذا كانت لديك متطلبات محددة لكمون منخفض، يُرجى التواصل معنا.
صُمم ClickPipes for Kafka ليدعم التحجيم أفقيًا وعموديًا. افتراضيًا، ننشئ مجموعة مستهلكين تضم مستهلكًا واحدًا. ويمكن تهيئة ذلك أثناء إنشاء ClickPipe، أو في أي وقت لاحق ضمن الإعدادات -> الإعدادات المتقدمة -> التحجيم.
يوفّر ClickPipes إتاحة عالية من خلال معمارية موزّعة على مناطق التوافر.
ويتطلب ذلك التحجيم إلى مستهلكين اثنين على الأقل.
وبغض النظر عن عدد المستهلكين قيد التشغيل، فإن تحمّل الأعطال متاح بحكم التصميم.
إذا تعطّل مستهلك أو البنية التحتية الأساسية التابعة له،
فسيعيد ClickPipe تشغيل المستهلك تلقائيًا ويواصل معالجة الرسائل.
فيما يلي بعض اختبارات الأداء غير الرسمية لـ ClickPipes for Kafka، ويمكن استخدامها لتكوين فكرة عامة عن الأداء المرجعي. من المهم معرفة أن هناك عوامل كثيرة قد تؤثر في الأداء، بما في ذلك حجم الرسائل، وأنواع البيانات، وتنسيق البيانات. وقد تختلف النتائج الفعلية من حالة إلى أخرى، وما نعرضه هنا لا يُعد ضمانًا للأداء الفعلي.
تفاصيل اختبار الأداء:
- استخدمنا خدمات ClickHouse Cloud في بيئة الإنتاج مع موارد كافية لضمان ألا يتأثر معدل النقل بعنق زجاجة في معالجة
insert من جانب ClickHouse.
- كانت خدمة ClickHouse Cloud، وعنقود Kafka (Confluent Cloud)، وClickPipe تعمل جميعها في نفس المنطقة (
us-east-2).
- جرى تكوين ClickPipe بنسخة متماثلة واحدة بحجم L (4 GiB من RAM و1 vCPU).
- تضمنت البيانات النموذجية بيانات متداخلة بمزيج من أنواع البيانات
UUID وString وInt. وقد تكون أنواع البيانات الأخرى، مثل Float وDecimal وDateTime، أقل كفاءة من حيث الأداء.
- لم يُلاحظ فرق يُذكر في الأداء عند استخدام البيانات المضغوطة وغير المضغوطة.