ضغط الرسائل
نوصي بشدة باستخدام الضغط في موضوعات Kafka. إذ يمكن أن يوفّر خفضًا كبيرًا في تكاليف نقل البيانات، من دون أي تأثير يُذكر تقريبًا في الأداء. لمعرفة المزيد عن ضغط الرسائل في Kafka، ننصح بالبدء بهذا الدليل.القيود
DEFAULTغير مدعوم.- يقتصر حجم الرسائل الفردية افتراضيًا على 16MB (غير مضغوط) عند التشغيل بأصغر حجم نسخة متماثلة (XS)، وعلى 32MB (غير مضغوط) مع أحجام نسخة متماثلة الأكبر. ستُرفض الرسائل التي تتجاوز هذا الحد مع ظهور خطأ. إذا كنت بحاجة إلى رسائل أكبر، يُرجى التواصل مع الدعم.
دلالات التسليم
يضمن ClickPipes for Kafka تسليمًا مرة واحدة على الأقل افتراضيًا، مع تتبّع تقدّم الاستيعاب عبر إزاحات مجموعة مستهلكي Kafka. كما يدعم اختياريًا دلالات التسليم مرة واحدة بالضبط، بحيث يُدرج كل سجل من Kafka في ClickHouse مرة واحدة فقط، حتى عند إعادة تشغيل الـ كبسولة أو إعادة موازنة المستهلكين أو فشل عمليات الإدراج. لتحقيق التسليم مرة واحدة بالضبط، يسجل ClickPipes تقدّم كل قسم في مخزن حالته الداخلي باستخدام قيمتين:- علامة الحد الأعلى — الإزاحة التي يُؤكَّد إدراج جميع السجلات في القسم حتى بلوغها في ClickHouse. عند إعادة التشغيل، يتجاهل ClickPipes أي سجل عند هذه العلامة أو قبلها، لذا لا تُرسل البيانات التي أُدرجت بالفعل مرة أخرى.
- النطاقات المعلّقة — نطاقات الإزاحات الخاصة بكتل الإدراج التي أُرسلت إلى ClickHouse، ولكن لم يُؤكَّد إدراجها بعد. بعد حدوث فشل، يعيد ClickPipes تشغيل هذه النطاقات تحديدًا.
topic:partition:firstOffset-lastOffset. عند إعادة التشغيل، يعيد ClickPipes إنشاء نطاق الإزاحة نفسه، ومن ثم الرمز المميز نفسه، لذا يرفض ClickHouse النسخة المكررة. ولأن الرمز المميز يعتمد فقط على نطاق الإزاحة، تُزال تكرارات البيانات المعاد تشغيلها حتى عندما لا تكون الكتلة المعاد إنشاؤها متطابقة بايتًا ببايت.
نافذة إزالة التكرارتقتصر إزالة التكرار بالرموز المميزة على
replicated_deduplication_window في الجدول الهدف (أحدث 10,000 كتلة إدراج افتراضيًا) وreplicated_deduplication_window_seconds (ساعة واحدة افتراضيًا). قد تستهلك خطوط ClickPipes ذات معدل النقل المرتفع نافذة عدد الكتل سريعًا، لذا نوصي بالتحقق من هذين الإعدادين في الجدول الهدف وزيادتهما عند الحاجة لتغطية أقصى تأخير محتمل لإعادة التشغيل. قد تُدرج البيانات المعاد تشغيلها بعد خروج رمزها المميز من النافذة مرة أخرى، لذلك لا يكون التسليم مرة واحدة بالضبط مضمونًا في هذه الحالة.لا يكون لـ
from_beginning أي تأثير إذا كانت لدى مجموعة المستهلكين إزاحة معتمدة بالفعللا تُطبَّق استراتيجية الإزاحة (from_beginning، from_latest، from_timestamp) إلا في المرة الأولى التي تقرأ فيها مجموعة مستهلكين قسمًا معينًا. ولا يكون لها أي تأثير إذا كان الوسيط يحتفظ بالفعل بإزاحة معتمدة لمجموعة المستهلكين تلك، وهذا تحديدًا ما يحدث عند حذف ClickPipe وإعادة إنشائه مع الإبقاء على اسم مجموعة المستهلكين نفسه (سواء أُنشئ هذا الاسم تلقائيًا أو ثُبِّت صراحةً، كما في Terraform مثلًا). عندها يستأنف الوسيط القراءة من آخر إزاحة معتمدة لديه بدلًا من إعادة القراءة من البداية، وتُتخطّى الرسائل التي أُنتجت أو احتُفظ بها قبل تلك الإزاحة بدلًا من إعادة استيعابها.إذا احتجت إلى إعادة قراءة الموضوع بالكامل من جديد عند إعادة الإنشاء، فاستخدم اسمًا جديدًا لمجموعة المستهلكين (أو أعد تعيين إزاحات مجموعة المستهلكين القديمة أو احذفها صراحةً من جهة الوسيط) بدلًا من الاكتفاء باستراتيجية الإزاحة وحدها.معالجة علامات الحذف
علامات الحذف في Kafka هي سجلات تحتوي على مفتاح وقيمة فارغة (null). يمكنك من خلال الإعدادات المتقدمة تهيئة الطريقة التي يتعامل بها Kafka ClickPipe معها:- حذف الصفوف المطابقة (Delete matching rows): يحذف الصفوف المطابقة من الجدول الوجهة باستخدام الحذف خفيف الوزن. لا يتوفر هذا الخيار إلا عند تفعيل دلالات التسليم مرة واحدة بالضبط (exactly-once). علمًا بأن عمليات الحذف خفيفة الوزن مكلفة ولا تناسب أعباء العمل الكبيرة.
- تمييز الصفوف كمحذوفة (Mark rows as deleted): يكتب كل علامة حذف في صورة صف. وهذا هو الخيار الموصى به لأعباء العمل الكبيرة: أنشئ جدولًا وجهة من نوع
ReplacingMergeTreeواختر العمود الافتراضي_is_deleted. وستتولى ClickPipes تهيئة هذا العمود الافتراضي ليكون عمودis_deletedالخاص بالمحرك.
المصادقة
بالنسبة إلى مصادر البيانات التي تستخدم بروتوكول Apache Kafka، تدعم ClickPipes المصادقة عبر SASL/PLAIN مع تشفير TLS، بالإضافة إلىSASL/SCRAM-SHA-256 وSASL/SCRAM-SHA-512. وبحسب مصدر البث (مثل Redpanda وMSK وغيرها)، سيتم تفعيل جميع آليات المصادقة هذه أو مجموعة فرعية منها وفقًا للتوافق. إذا كانت متطلبات المصادقة لديكم مختلفة، فيُرجى إرسال ملاحظاتكم إلينا.
حجم الجلب في Warpstream
تعتمد ClickPipes على إعداد Kafka max.fetch_bytes لتقييد حجم البيانات التي تُعالَج في عقدة واحدة من ClickPipes في أي وقت. في بعض الحالات،
لا يلتزم Warpstream بهذا الإعداد، ما قد يتسبب في تعطل أحد خطوط ClickPipes بشكل غير متوقع. نوصي بشدة بضبط الإعداد الخاص بـ Warpstream kafkaMaxFetchPartitionBytesUncompressedOverride
على 8MB (أو أقل) عند تهيئة وكيل WarpStream لديك، لتجنّب تعطل ClickPipes.
IAM
يدعم ClickPipes أساليب مصادقة AWS MSK التالية:- مصادقة SASL/SCRAM-SHA-512
- المصادقة باستخدام بيانات اعتماد IAM أو الوصول المستند إلى الأدوار
تهيئة علاقة ثقة
إذا كنت تُجري المصادقة مع 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، أقل كفاءة من حيث الأداء. - لم يُلاحظ فرق يُذكر في الأداء عند استخدام البيانات المضغوطة وغير المضغوطة.