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

نوصي بشدة باستخدام الضغط في موضوعات Kafka. إذ يمكن أن يوفّر خفضًا كبيرًا في تكاليف نقل البيانات، من دون أي تأثير يُذكر تقريبًا في الأداء. لمعرفة المزيد عن ضغط الرسائل في Kafka، ننصح بالبدء بهذا الدليل.

• DEFAULT غير مدعوم.
• يقتصر حجم الرسائل الفردية افتراضيًا على 16MB (غير مضغوط) عند التشغيل بأصغر حجم نسخة متماثلة ‏(XS)، وعلى 32MB (غير مضغوط) مع أحجام نسخة متماثلة الأكبر. ستُرفض الرسائل التي تتجاوز هذا الحد مع ظهور خطأ. إذا كنت بحاجة إلى رسائل أكبر، يُرجى التواصل مع الدعم.

يضمن ClickPipes for Kafka تسليمًا مرة واحدة على الأقل افتراضيًا، مع تتبّع تقدّم الاستيعاب عبر إزاحات مجموعة مستهلكي Kafka. كما يدعم اختياريًا دلالات التسليم مرة واحدة بالضبط، بحيث يُدرج كل سجل من Kafka في ClickHouse مرة واحدة فقط، حتى عند إعادة تشغيل الـ كبسولة أو إعادة موازنة المستهلكين أو فشل عمليات الإدراج.

لتحقيق التسليم مرة واحدة بالضبط، يسجل ClickPipes تقدّم كل قسم في مخزن حالته الداخلي باستخدام قيمتين:

• علامة الحد الأعلى — الإزاحة التي يُؤكَّد إدراج جميع السجلات في القسم حتى بلوغها في ClickHouse. عند إعادة التشغيل، يتجاهل ClickPipes أي سجل عند هذه العلامة أو قبلها، لذا لا تُرسل البيانات التي أُدرجت بالفعل مرة أخرى.
• النطاقات المعلّقة — نطاقات الإزاحات الخاصة بكتل الإدراج التي أُرسلت إلى ClickHouse، ولكن لم يُؤكَّد إدراجها بعد. بعد حدوث فشل، يعيد ClickPipes تشغيل هذه النطاقات تحديدًا.

تغطي كل كتلة إدراج نطاقًا متصلًا من الإزاحات وتحمل رمزًا مميزًا حتميًا لإزالة التكرار بالصيغة topic:partition:firstOffset-lastOffset. عند إعادة التشغيل، يعيد ClickPipes إنشاء نطاق الإزاحة نفسه، ومن ثم الرمز المميز نفسه، لذا يرفض ClickHouse النسخة المكررة. ولأن الرمز المميز يعتمد فقط على نطاق الإزاحة، تُزال تكرارات البيانات المعاد تشغيلها حتى عندما لا تكون الكتلة المعاد إنشاؤها متطابقة بايتًا ببايت.

المفاضلة الرئيسية هي حجم الجزء. تنتج كتل الإدراج الأكبر أجزاء أقل عددًا وأكبر حجمًا في ClickHouse، مما يحافظ على انخفاض عبء الدمج. يحتفظ ClickPipes بصفوف القسم في الذاكرة أثناء إنشاء الكتلة، لذا يعتمد حجم الجزء الذي يمكنه بلوغه على الذاكرة المتاحة لخط ClickPipes — وعندما تكون الذاكرة محدودة، ينشئ كتلًا أصغر ويتراكم في الجدول عدد أكبر من الأجزاء. يتيح تخصيص ذاكرة أكبر لخط ClickPipes إنشاء كتل أكبر وإنتاج أجزاء أقل.

يعمل خط ClickPipes بأفضل كفاءة عندما يكون عدد الأقسام قريبًا من عدد "workers" الداخلية للإدراج، إذ يتعامل كل worker حينها مع قسم واحد تقريبًا، وتتوفر له سعة إضافية في الذاكرة لإنشاء كتل كبيرة. يتوسع كل من عدد الـ workers والذاكرة المتاحة مع حجم الـ نسخة متماثلة وعددها، ويمكنك تكوينهما ضمن الإعدادات -> الإعدادات المتقدمة -> التحجيم.

بالنسبة إلى مصادر البيانات التي تستخدم بروتوكول 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 التالية:

• مصادقة SASL/SCRAM-SHA-512
• المصادقة باستخدام بيانات اعتماد IAM أو الوصول المستند إلى الأدوار

عند استخدام مصادقة IAM للاتصال بوسيط MSK، يجب أن يتضمن دور IAM الأذونات اللازمة. فيما يلي مثال على سياسة IAM المطلوبة لواجهات برمجة تطبيقات Apache Kafka في MSK:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect"
            ],
            "Resource": [
                "arn:aws:kafka:us-west-2:12345678912:cluster/clickpipes-testing-brokers/b194d5ae-5013-4b5b-ad27-3ca9f56299c9-10"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:DescribeTopic",
                "kafka-cluster:ReadData"
            ],
            "Resource": [
                "arn:aws:kafka:us-west-2:12345678912:topic/clickpipes-testing-brokers/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:AlterGroup",
                "kafka-cluster:DescribeGroup"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:12345678912:group/clickpipes-testing-brokers/*"
            ]
        }
    ]
}

إذا كنت تُجري المصادقة مع MSK باستخدام دور IAM ARN، فستحتاج إلى إضافة علاقة ثقة إلى مثيل ClickHouse Cloud الخاص بك حتى يمكن تولّي هذا الدور.

{
    "Version": "2012-10-17",
    "Statement": [
        ...
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::12345678912:role/CH-S3-your-clickhouse-cloud-role"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

يدعم 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، أقل كفاءة من حيث الأداء.
• لم يُلاحظ فرق يُذكر في الأداء عند استخدام البيانات المضغوطة وغير المضغوطة.