يمكن نشر ClickPipes لـ Kinesis وإدارتها يدويًا عبر ClickPipes UI، وكذلك برمجيًا باستخدام OpenAPI وTerraform.
يُفترض أنك اطّلعت على مقدمة ClickPipes وأعددت بيانات اعتماد IAM أو دور IAM. اتبع دليل الوصول المستند إلى الأدوار في Kinesis للحصول على معلومات حول كيفية إعداد دور يعمل مع ClickHouse Cloud.
- انتقل إلى SQL Console لخدمة ClickHouse Cloud الخاصة بك.
- حدِّد زر
Data Sources من القائمة الجانبية اليسرى، ثم انقر على “Set up a ClickPipe”
- حدِّد مصدر البيانات.
- املأ النموذج بإدخال اسم لـ ClickPipe ووصف (اختياري) ودور IAM أو بيانات الاعتماد، بالإضافة إلى تفاصيل الاتصال الأخرى.
- حدِّد Kinesis Stream وإزاحة البدء. ستعرض واجهة المستخدم مستندًا نموذجيًا من المصدر المحدد (Kafka topic، وما إلى ذلك). يمكنك أيضًا تمكين Enhanced Fan-out لـ Kinesis streams لتحسين أداء ClickPipe واستقراره (يمكنك العثور على مزيد من المعلومات حول Enhanced Fan-out هنا)
- في الخطوة التالية، يمكنك اختيار ما إذا كنت تريد إدخال البيانات إلى ClickHouse table جديدة أو إعادة استخدام جدول موجود. اتبع الإرشادات الظاهرة على الشاشة لتعديل اسم الجدول والمخطط والإعدادات. ويمكنك رؤية معاينة فورية لتغييراتك في الجدول النموذجي في الأعلى.
يمكنك أيضًا تخصيص الإعدادات المتقدمة باستخدام عناصر التحكم المتاحة
- بدلاً من ذلك، يمكنك اختيار إدخال بياناتك في ClickHouse table موجودة. في هذه الحالة، ستتيح لك واجهة المستخدم تعيين الحقول من المصدر إلى حقول ClickHouse في جدول الوجهة المحددة.
- أخيرًا، يمكنك تهيئة الأذونات لمستخدم ClickPipes الداخلي.
الأذونات: سينشئ ClickPipes مستخدمًا مخصصًا لكتابة البيانات إلى جدول الوجهة. يمكنك تحديد دور لهذا المستخدم الداخلي باستخدام دور مخصص أو أحد الأدوار المحددة مسبقًا:
Full access: مع وصول كامل إلى الـ عنقود. قد يكون ذلك مفيدًا إذا كنت تستخدم عرض مُجسَّد أو Dictionary مع جدول الوجهة.
Only destination table: مع أذونات INSERT إلى جدول الوجهة فقط.
- بالنقر على “Complete Setup”، سيسجّل النظام ClickPipe الخاصة بك، وستتمكن من رؤيتها مدرجة في جدول الملخص.
يوفّر جدول الملخص عناصر تحكم لعرض بيانات نموذجية من المصدر أو من جدول الوجهة في ClickHouse
وكذلك عناصر تحكم لإزالة ClickPipe وعرض ملخص لمهمة الإدخال.
- تهانينا! لقد أعددت أول ClickPipe لك بنجاح. إذا كانت هذه ClickPipe من نوع streaming، فستظل تعمل باستمرار، وتُدخل البيانات في الوقت الفعلي من مصدر البيانات البعيد. وإلا فستُدخل الدفعة ثم تكتمل.
التنسيقات المدعومة هي:
يكتشف ClickPipes for Kinesis السجلات المضغوطة ويفك ضغطها تلقائيًا. وعلى عكس Kafka، حيث تتولى مكتبة العميل فك الضغط تلقائيًا وبشفافية، يرسل Kinesis بايتات خام — ويتولى ClickPipes هذه المهمة نيابةً عنك من دون الحاجة إلى أي إعدادات.
ترميزات الضغط التالية مدعومة:
- gzip
- zstd
- lz4
- snappy (تنسيق مؤطر)
يُكتشف الضغط تلقائيًا من خلال البايتات السحرية في كل سجل. وإذا لم يُعثر على توقيع ضغط معروف، فسيُعامَل السجل على أنه غير مضغوط. كما يظهر نوع الضغط المكتشَف أثناء استنتاج المخطط، بحيث تعرض معاينة بيانات العينة في UI البيانات المفكوكة الضغط بشكل صحيح.
يُعد الاكتشاف التلقائي آمنًا للتنسيقات النصية مثل JSON وCSV، لأن محارف ASCII القابلة للطباعة لن تتطابق أبدًا مع البايتات السحرية الخاصة بالضغط.
تدعم ClickPipes حاليًا أنواع البيانات التالية في ClickHouse:
- الأنواع الرقمية الأساسية - [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
الأعمدة الافتراضية التالية مدعومة لتدفق 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 تشغيل المستهلك تلقائيًا ويواصل معالجة الرسائل.
للوصول إلى تدفقات Amazon Kinesis، يمكنك استخدام بيانات اعتماد IAM أو دور IAM. ولمزيد من التفاصيل حول كيفية إعداد دور IAM، يمكنك الرجوع إلى هذا الدليل للاطلاع على معلومات حول كيفية إعداد دور يعمل مع ClickHouse Cloud.