يمكن نشر ClickPipes لـ Kinesis وإدارتها يدويًا عبر ClickPipes UI، وكذلك برمجيًا باستخدام OpenAPI وTerraform.
يُفترض أنك اطّلعت على مقدمة ClickPipes وأعددت بيانات اعتماد IAM أو دور IAM. اتبع دليل الوصول المستند إلى الأدوار في Kinesis للحصول على معلومات حول كيفية إعداد دور يعمل مع ClickHouse Cloud.
- افتح SQL Console الخاصة بخدمة ClickHouse Cloud لديك.
- حدِّد زر
Data Sources من القائمة الجانبية اليسرى، ثم انقر على “إعداد ClickPipe”
- حدِّد مصدر البيانات.
- املأ النموذج بإدخال اسم لـ ClickPipe ووصف له (اختياري)، ودور IAM أو بيانات الاعتماد الخاصة بك، بالإضافة إلى تفاصيل الاتصال الأخرى.
- حدِّد تدفق Kinesis وإزاحة البدء. ستعرض واجهة المستخدم مستندًا نموذجيًا من المصدر المحدد (Kafka topic، إلخ). يمكنك أيضًا تمكين Enhanced Fan-out لـ تدفقات Kinesis لتحسين أداء ClickPipe واستقراره (يمكنك العثور على مزيد من المعلومات حول Enhanced Fan-out هنا)
- في الخطوة التالية، يمكنك اختيار ما إذا كنت تريد إدخال البيانات إلى جدول ClickHouse جديد أو إعادة استخدام جدول موجود. اتبع الإرشادات الظاهرة على الشاشة لتعديل اسم الجدول والمخطط والإعدادات. ويمكنك رؤية معاينة فورية لتغييراتك في الجدول النموذجي بالأعلى.
يمكنك أيضًا تخصيص الإعدادات المتقدمة باستخدام عناصر التحكم المتاحة
- أو يمكنك اختيار إدخال بياناتك في جدول ClickHouse موجود. في هذه الحالة، ستتيح لك واجهة المستخدم تعيين حقول المصدر إلى حقول ClickHouse في الجدول الوجهة المحدد.
- أخيرًا، يمكنك تهيئة الأذونات لمستخدم ClickPipes الداخلي.
الأذونات: سيُنشئ ClickPipes مستخدمًا مخصصًا لكتابة البيانات إلى الجدول الوجهة. يمكنك تحديد دور لهذا المستخدم الداخلي باستخدام دور مخصص أو أحد الأدوار المعرّفة مسبقًا:
Full access: وصول كامل إلى العنقود. قد يكون ذلك مفيدًا إذا كنت تستخدم materialized view أو Dictionary مع الجدول الوجهة.
Only destination table: مع أذونات INSERT على الجدول الوجهة فقط.
- عند النقر على “إكمال الإعداد”، سيسجّل النظام ClickPipe الخاص بك، وستتمكن من رؤيته مُدرجًا في جدول الملخص.
يوفر جدول الملخص عناصر تحكم لعرض بيانات نموذجية من المصدر أو من الجدول الوجهة في ClickHouse
بالإضافة إلى عناصر تحكم لإزالة ClickPipe وعرض ملخص مهمة الإدخال.
- تهانينا! لقد أعددت أول ClickPipe بنجاح. إذا كان هذا ClickPipe من نوع streaming، فسيستمر في العمل بشكل متواصل مع إدخال البيانات في الوقت الفعلي من مصدر البيانات البعيد لديك. أما إذا لم يكن كذلك، فسيُدخل الدفعة ثم يكتمل.
التنسيقات المدعومة هي:
يكتشف ClickPipes for Kinesis السجلات المضغوطة ويفك ضغطها تلقائيًا. وعلى عكس Kafka، حيث تتولى مكتبة العميل فك الضغط تلقائيًا وبشفافية، يرسل Kinesis بايتات خام — ويتولى ClickPipes هذه المهمة نيابةً عنك من دون الحاجة إلى أي إعدادات.
ترميزات الضغط التالية مدعومة:
- gzip
- zstd
- lz4
- snappy (تنسيق مؤطر)
يُكتشف الضغط تلقائيًا من خلال البايتات السحرية في كل سجل. وإذا لم يُعثر على توقيع ضغط معروف، فسيُعامَل السجل على أنه غير مضغوط. كما يظهر نوع الضغط المكتشَف أثناء استنتاج المخطط، بحيث تعرض معاينة بيانات العينة في UI البيانات المفكوكة الضغط بشكل صحيح.
يُعد الاكتشاف التلقائي آمنًا للتنسيقات النصية مثل JSON وCSV، لأن محارف ASCII القابلة للطباعة لن تتطابق أبدًا مع البايتات السحرية الخاصة بالضغط.
- الأنواع الرقمية الأساسية - [U]Int8/16/32/64، وFloat32/64، وBFloat16
- أنواع الأعداد الصحيحة الكبيرة - [U]Int128/256
- أنواع Decimal
- Boolean
- String
- FixedString
- Date وDate32
- DateTime وDateTime64 (المناطق الزمنية UTC فقط)
- Enum8/Enum16
- معرّف UUID
- IPv4
- IPv6
- جميع أنواع LowCardinality في ClickHouse
- Map بمفاتيح وقيم من أيٍ من الأنواع المذكورة أعلاه (بما في ذلك Nullable)
- Tuple وArray بعناصر من أيٍ من الأنواع المذكورة أعلاه (بما في ذلك Nullable، وبعمق مستوى واحد فقط)
- أنواع SimpleAggregateFunction (لوجهات AggregatingMergeTree أو SummingMergeTree)
يمكنك تحديد نوع Variant يدويًا (مثل Variant(String, Int64, DateTime)) لأي حقل JSON
في تدفق بيانات المصدر. ونظرًا إلى الطريقة التي يحدد بها ClickPipes النوع الفرعي الصحيح ضمن Variant لاستخدامه، لا يمكن استخدام أكثر من نوع عدد صحيح واحد أو نوع DateTime واحد
في تعريف Variant — على سبيل المثال، Variant(Int64, UInt32) غير مدعوم.
يمكن إسناد حقول JSON التي تكون دائمًا كائنات JSON إلى عمود وجهة من نوع JSON. سيتعين عليك تغيير عمود
الوجهة يدويًا إلى نوع JSON المطلوب، بما في ذلك أي مسارات ثابتة أو متجاهلة.
الأعمدة الافتراضية لـ Kinesis
Add Column.
يمكن استخدام الحقل _raw_message في الحالات التي تكون فيها الحاجة إلى سجل JSON كامل من Kinesis فقط (مثل استخدام دوال ClickHouse JsonExtract* لملء عرض مُجسَّد
لاحق). بالنسبة إلى مثل هذه الـ pipes، قد يؤدي حذف جميع الأعمدة “غير الافتراضية” إلى تحسين أداء ClickPipes.
- DEFAULT غير مدعوم.
- يقتصر حجم كل رسالة افتراضيًا على 16MB (غير مضغوط) عند التشغيل بأصغر حجم نسخة متماثلة (XS)، وعلى 32MB (غير مضوط) مع النسخ المتماثلة الأكبر. وستُرفض الرسائل التي تتجاوز هذا الحد مع ظهور خطأ. إذا كنت بحاجة إلى رسائل أكبر، يُرجى التواصل مع فريق الدعم.
تُدرِج ClickPipes البيانات في ClickHouse على دفعات. يهدف ذلك إلى تجنّب إنشاء عدد كبير جدًا من الأجزاء في قاعدة البيانات، ما قد يؤدي إلى مشكلات في أداء العنقود.
تُدرَج الدفعات عند تحقق أحد الشروط التالية:
- عندما يبلغ حجم الدفعة الحد الأقصى (100,000 صف أو 32MB لكل 1GB من ذاكرة النسخة المتماثلة)
- عندما تظل الدفعة مفتوحة للمدة القصوى (5 ثوانٍ)
يعتمد زمن الاستجابة (المُعرَّف بأنه الوقت بين إرسال رسالة Kinesis إلى التدفق وإتاحة الرسالة في ClickHouse) على عدد من العوامل (مثل زمن استجابة Kinesis، وزمن استجابة الشبكة، وحجم الرسالة/تنسيقها). كما أن التجميع على دفعات الموضَّح في القسم أعلاه سيؤثر أيضًا في زمن الاستجابة. نوصي دائمًا باختبار حالة الاستخدام الخاصة بك لفهم زمن الاستجابة المتوقع.
إذا كانت لديك متطلبات محددة لزمن استجابة منخفض، يُرجى التواصل معنا.
نوصي بشدة بحصر عدد الشظايا النشطة المتزامنة بما يتوافق مع متطلبات الإنتاجية لديك. بالنسبة إلى تدفق Kinesis من نوع “On Demand”، ستحدّد AWS تلقائيًا عددًا مطابقًا من الشظايا بناءً على الإنتاجية،
أما بالنسبة إلى التدفقات من نوع “Provisioned”، فقد يؤدي تخصيص عدد كبير جدًا من الشظايا إلى زيادة زمن الاستجابة كما هو موضح أدناه، فضلًا عن ارتفاع التكاليف لأن تسعير Kinesis لهذه التدفقات يُحتسب على أساس “لكل shard”.
إذا كان التطبيق المُنتِج يكتب باستمرار إلى عدد كبير من الشظايا النشطة، فقد يتسبب ذلك في زمن الاستجابة مرتفع إذا لم يكن الـ pipe لديك موسّعًا بالقدر الكافي لمعالجة تلك الشظايا بكفاءة. واستنادًا إلى حدود الإنتاجية في Kinesis،
تخصّص ClickPipes عددًا محددًا من “workers” لكل نسخة متماثلة لقراءة بيانات الشظايا. على سبيل المثال، عند أصغر حجم، سيكون لدى نسخة متماثلة في ClickPipes 4 من سلاسل التنفيذ العاملة هذه. وإذا كان التطبيق المُنتِج يكتب
إلى أكثر من 4 شظايا في الوقت نفسه، فلن تُعالَج البيانات من الشظايا “الإضافية” حتى تتوفر سلسلة تنفيذ عاملة. وعلى وجه الخصوص، إذا كان الـ pipe يستخدم “enhanced fanout”، فستشترك كل سلسلة تنفيذ عاملة في
شظية واحدة لمدة 5 دقائق، ولن تكون متاحة لقراءة أي شظية أخرى خلال تلك المدة. وقد يؤدي ذلك إلى “قفزات” في زمن الاستجابة بمضاعفات 5 دقائق.
صُمِّم ClickPipes for Kinesis ليدعم التوسّع أفقيًا وعموديًا. وبشكلٍ افتراضي، ننشئ مجموعة مستهلكين تضم مستهلكًا واحدًا. ويمكن تهيئة ذلك أثناء إنشاء ClickPipe، أو في أي وقت لاحق ضمن الإعدادات -> الإعدادات المتقدمة -> التوسّع.
يوفّر ClickPipes إتاحة عالية من خلال معمارية موزعة عبر مناطق التوفّر.
ويتطلّب ذلك التوسّع إلى مستهلكين اثنين على الأقل.
وبغضّ النظر عن عدد المستهلكين قيد التشغيل، فإن تحمّل الأعطال متوفّر بحكم التصميم.
فإذا تعطّل مستهلك أو البنية التحتية الأساسية التابعة له،
فسيُعيد ClickPipe تشغيل المستهلك تلقائيًا ويواصل معالجة الرسائل.
للوصول إلى تدفقات Kinesis من Amazon، يمكنك استخدام بيانات اعتماد IAM أو دور IAM. ولمزيد من التفاصيل حول كيفية إعداد دور IAM، يمكنك الرجوع إلى هذا الدليل للاطلاع على معلومات حول كيفية إعداد دور متوافق مع ClickHouse Cloud 
