التبديل من Redshift إلى ClickHouse

لفترة طويلة ، استخدم iFunny Redshift كقاعدة بيانات للأحداث التي تحدث في الخدمات الخلفية وتطبيقات الأجهزة المحمولة. تم اختياره لأنه في وقت التنفيذ ، إلى حد كبير ، لم تكن هناك بدائل قابلة للمقارنة في التكلفة والراحة.

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

المشكلة

احتاج iFunny إلى خدمة مشابهة لـ Yandex.Metrica ، ولكن حصريًا للاستهلاك المحلي. ساوضح لماذا.

عملاء الخارجية كتابة الأحداث. يمكن أن يكون تطبيقات المحمول ، والمواقع الإلكترونية أو خدمات الواجهة الخلفية الداخلية. يصعب على هؤلاء العملاء توضيح أن خدمة استقبال الأحداث غير متاحة حاليًا ، "حاول إرسالها في غضون 15 دقيقة أو في ساعة". هناك العديد من العملاء ، يرغبون في إرسال الأحداث طوال الوقت ولا يمكنهم الانتظار على الإطلاق.

على عكس هذه الخدمات ، هناك خدمات داخلية ومستخدمون متسامحون للغاية في هذا الصدد: يمكنهم العمل بشكل صحيح حتى مع خدمة تحليلات يتعذر الوصول إليها. ومعظم مقاييس المنتج ونتائج اختبارات A / B منطقية عمومًا للمشاهدة مرة واحدة فقط يوميًا ، أو ربما أقل من ذلك كثيرًا. لذلك ، متطلبات القراءة منخفضة للغاية. في حالة وقوع حادث أو تحديث ، يمكننا تحمل صعوبة الوصول أو عدم الاتساق في القراءة لعدة ساعات أو حتى أيام (في حالة مهملة بشكل خاص).

إذا تحدثنا عن الأرقام ، فعلينا أن نأخذ حوالي خمسة مليارات حدث (300 جيجابايت من البيانات المضغوطة) يوميًا ، بينما نقوم بتخزين البيانات لمدة ثلاثة أشهر في شكل "ساخن" ، يمكن الوصول إليه لاستعلامات SQL ، وفي "بارد" لمدة عامين أو أكثر ، ولكن حتى في غضون بضعة أيام يمكننا تحويلها إلى "حار".

في الأساس ، البيانات هي مجموعة من الأحداث مرتبة حسب الوقت. هناك حوالي ثلاثمائة نوع من الأحداث ، ولكل منها مجموعة الخصائص الخاصة به. لا تزال هناك بعض البيانات من مصادر الجهات الخارجية التي يجب مزامنتها مع قاعدة بيانات التحليلات: على سبيل المثال ، مجموعة من عمليات تثبيت التطبيق من MongoDB أو خدمة AppsFlyer خارجية.

اتضح أننا بحاجة إلى حوالي 40 تيرابايت من القرص لقاعدة البيانات ، وحوالي 250 تيرابايت للتخزين "البارد".

Redshift الحل

لذلك ، هناك عملاء متنقلون وخدمات خلفية تحتاج إلى تلقي الأحداث منها. تقبل خدمة HTTP البيانات ، وتجري الحد الأدنى من التحقق من الصحة ، وتجمع الأحداث على القرص المحلي في ملفات مجمعة لمدة دقيقة واحدة ، وتضغطها على الفور وترسلها إلى دلو S3. يعتمد مدى توفر هذه الخدمة على مدى توفر الخوادم مع التطبيق و AWS S3. لا تخزن التطبيقات الحالة ، لذا فهي متوازنة بسهولة ، ومُقاسة ومتبادلة. S3 هي خدمة تخزين ملفات بسيطة نسبيًا وتتمتع بسمعة جيدة وتوافر ، لذا يمكنك الاعتماد عليها.

بعد ذلك ، تحتاج إلى تسليم البيانات بطريقة ما إلى Redshift. كل شيء بسيط للغاية هنا: لدى Redshift مستورد S3 مضمن ، وهو الطريقة الموصى بها لتحميل البيانات. لذلك ، مرة واحدة كل 10 دقائق ، يبدأ البرنامج النصي الذي يتصل بـ Redshift ويطلب منه تنزيل البيانات باستخدام بادئة s3://events-bucket/main/year=2018/month=10/day=14/10_3*

من أجل مراقبة حالة مهمة التنزيل ، نستخدم Apache Airflow : فهو يتيح لك تكرار العملية في حالة وجود أخطاء وسجل محفوظ للتنفيذ ، وهو أمر مهم بالنسبة لعدد كبير من هذه المهام. وفي حالة حدوث مشاكل ، يمكنك تكرار التنزيل لفواصل زمنية أو تنزيل البيانات "الباردة" من S3 قبل عام.

في نفس Airflow ، بالطريقة نفسها ، وفقًا للجدول الزمني ، تعمل البرامج النصية التي تتصل بقاعدة البيانات وتقوم بتنزيلات دورية من المستودعات الخارجية ، أو تنشئ مجموعات من الأحداث في شكل INSERT INTO ... SELECT ...

لدى Redshift ضمانات توفر ضعيفة. مرة واحدة في الأسبوع ، لمدة تصل إلى نصف ساعة (تم تحديد إطار الوقت في الإعدادات) يمكن لـ AWS إيقاف الكتلة من التحديث أو أي عمل مجدولة آخر. في حالة حدوث فشل على عقدة واحدة ، تصبح الكتلة غير متوفرة حتى تتم استعادة المضيف. هذا يستغرق عادة حوالي 15 دقيقة ويحدث مرة واحدة كل ستة أشهر. في النظام الحالي ، هذه ليست مشكلة ، فقد تم تصميمها في الأصل لتكون القاعدة غير متوفرة بشكل دوري.

تحت Redshift ، تم استخدام 4 مثيلات ds2.8xlarge (36 وحدة المعالجة المركزية ، 16 تيرابايت HDD) ، والتي تعطينا في المجموع 64 تيرابايت من مساحة القرص.

النقطة الأخيرة هي النسخ الاحتياطي. يمكن تحديد جدول النسخ الاحتياطي في إعدادات الكتلة ، ويعمل بشكل جيد.

ClickHouse الانتقال الدافع

بالطبع ، إذا لم تكن هناك مشاكل ، فلن يفكر أحد في الترحيل إلى ClickHouse. ومع ذلك ، كانوا كذلك.

إذا نظرت إلى نظام التخزين ClickHouse باستخدام محرك MergeTree و Redshift ، يمكنك أن ترى أن أيديولوجيتها متشابهة للغاية. كلا قواعد البيانات عمودية ، تعمل بشكل جيد مع عدد كبير من الأعمدة وضغط البيانات على القرص بشكل جيد للغاية (وفي Redshift يمكنك تكوين أنواع الضغط لكل عمود على حدة). حتى يتم تخزين البيانات بالطريقة نفسها: يتم فرزها حسب المفتاح الأساسي ، مما يتيح لك قراءة كتل محددة فقط وعدم الاحتفاظ بفهارس فردية في الذاكرة ، وهذا أمر مهم عند العمل بكميات كبيرة من البيانات.

الفرق الأساسي ، كما هو الحال دائما ، هو في التفاصيل.

الجدول اليومي

يحدث فرز البيانات على القرص وحذفها فعليًا في Redshift عند القيام بما يلي:

 VACUUM <tablename> 

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

التكرارات

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

الرصد والصيانة

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

التكلفة

وفقًا لحساباتنا ، فإن نشر ClickHouse على مثيلات AWS بنفس الموارد بالضبط هو نصف السعر تمامًا. بالطبع ، يجب أن يكون الأمر كذلك ، لأنه باستخدام Redshift ، يمكنك الحصول على قاعدة بيانات جاهزة يمكنك الاتصال بها مع أي عميل PostgreSQL مباشرة بعد النقر على اثنين من الأزرار في وحدة AWS ، وسوف تقوم AWS بالباقي لك. ولكن هل يستحق كل هذا العناء؟ لدينا بالفعل البنية التحتية ، ويبدو أننا قادرون على عمل نسخ احتياطية ومراقبة وتكوين ، ونحن نفعل ذلك لمجموعة من الخدمات الداخلية. لماذا لا تعالج دعم ClickHouse؟

عملية الانتقال

أولاً ، قمنا برفع تثبيت ClickHouse صغير من جهاز واحد ، حيث بدأنا بشكل دوري ، باستخدام الأدوات المدمجة ، تنزيل البيانات من S3. وبالتالي ، تمكنا من اختبار افتراضاتنا حول سرعة وقدرات ClickHouse.

بعد أسبوعين من الاختبار على نسخة صغيرة من البيانات ، أصبح من الواضح أنه لاستبدال Redshift بـ Clickhouse ، يجب حل العديد من المشكلات:

• ما أنواع الحالات والأقراص التي سيتم نشرها ؛
• لاستخدام النسخ المتماثل؟
• كيفية تركيب وتكوين وتشغيل ؛
• كيفية القيام الرصد ؛
• ما نوع المخطط سيكون ؛
• كيفية توصيل البيانات من S3 ؛
• كيفية إعادة كتابة جميع الاستعلامات من SQL قياسي إلى غير قياسي؟

أنواع الحالات والأقراص . في عدد المعالجات ، القرص والذاكرة ، قرروا البناء على التثبيت الحالي لـ Redshift. كانت هناك العديد من الخيارات ، بما في ذلك مثيلات i3 مع أقراص NVMe المحلية ، ولكن قررت التوقف عند r5.4xlarge والتخزين في شكل 8T ST1 EBS لكل مثيل. وفقًا للتقديرات ، ينبغي أن يكون هذا قد قدم أداءً مشابهًا مع Redshift بنصف التكلفة. في الوقت نفسه ، نظرًا لاستخدام أقراص EBS ، نحصل على نسخ احتياطية بسيطة واسترداد من خلال لقطات للأقراص ، كما في Redshift تقريبًا.

النسخ المتماثل . منذ أن بدأنا مما هو بالفعل في Redshift ، قررنا عدم استخدام النسخ المتماثل. بالإضافة إلى ذلك ، هذا لا يجبرنا على دراسة ZooKeeper على الفور ، والتي لم تصل بعد إلى البنية التحتية ، ولكن من الرائع الآن أنه من الممكن إجراء نسخ متماثل عند الطلب.

التثبيت هذا هو أسهل جزء. دور صغير كافي لـ Ansible ، والذي سيقوم بتثبيت حزم RPM جاهزة الصنع ويقوم بنفس التكوين على كل مضيف.

الرصد لمراقبة جميع الخدمات ، يتم استخدام Prometheus مع Telegraf و Grafana ، وبالتالي ، فإنهم ببساطة يضعون وكلاء Telegraf على مضيفين مع ClickHouse ، وجمعوا لوحة أجهزة القياس في Grafana ، والتي أظهرت تحميل الخادم الحالي حسب المعالج والذاكرة والأقراص. من خلال المكوّن الإضافي إلى Grafana ، قدمنا ​​إلى لوحة القيادة هذه الطلبات النشطة الحالية للكتلة ، وحالة الواردات من S3 ، وغيرها من الأشياء المفيدة. اتضح أنه أفضل وأكثر إفادة (وأسرع بكثير) من لوحة القيادة التي أعطت وحدة التحكم AWS.

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

كانت المهمة التالية هي اختيار المحرك المناسب للتخزين والتقسيم.
لم يفكروا في التقسيم مرة أخرى ، لكنهم فعلوا الشيء نفسه كما حدث في Redshift - قسم لكل يوم ، ولكن الآن جميع الأقسام هي جدول واحد ، والذي
يسرع بشكل كبير الطلبات ويبسط الصيانة. تم أخذ محرك التخزين عن طريق ReplacingMergeTree ، لأنه يتيح لك إزالة التكرارات من قسم معين ، ببساطة عن طريق إجراء OPTIMIZE ... FINAL . بالإضافة إلى ذلك ، يسمح نظام التقسيم اليومي ، في حالة وجود أخطاء أو حوادث ، بالعمل فقط مع البيانات ليوم واحد ، وليس لمدة شهر ، وهو أسرع بكثير.

تسليم البيانات من s3 إلى ClickHouse . كانت هذه واحدة من أطول العمليات. لم ينجح الأمر في إجراء التحميل بواسطة أدوات ClickHouse المضمنة ، لأن البيانات الموجودة على S3 في JSON ، يجب استخراج كل حقل في jsonpath الخاص به ، كما فعلنا في Redshift ، وفي بعض الأحيان نحتاج أيضًا إلى استخدام التحويل: على سبيل المثال ، UUID لرسالة من سجل قياسي في النموذج DD96C92F-3F4D-44C6-BCD3-E25EB26389E9 تحويل إلى بايت ووضع في FixedString نوع (16).

كنت أرغب في الحصول على خدمة خاصة مماثلة لما كان لدينا في Redshift كأمر COPY . لم يجدوا أي شيء جاهزًا ، لذلك اضطررت للقيام بذلك. يمكنك كتابة مقالة منفصلة حول كيفية عملها ، ولكن باختصار ، هذه خدمة HTTP يتم نشرها على كل مضيف باستخدام ClickHouse. يمكنك الرجوع إلى أي منهم. تحدد معلمات الطلب بادئة S3 التي يتم أخذ الملفات منها ، وقائمة jsonpath للتحويل من JSON إلى مجموعة من الأعمدة ، فضلاً عن مجموعة من التحويلات لكل عمود. يبدأ الخادم الذي جاء إليه الطلب في فحص الملفات على S3 وتوزيع توزيع العمل على مضيفين آخرين. في الوقت نفسه ، من المهم بالنسبة لنا أن تتم إضافة الصفوف التي لا يمكن استيرادها ، بالإضافة إلى الخطأ ، إلى جدول ClickHouse منفصل. يساعد هذا كثيرًا في استكشاف المشكلات والأخطاء في خدمة تلقي الأحداث والعملاء الذين ينشئون هذه الأحداث. مع وضع المستورد مباشرة على مضيفي قاعدة البيانات ، استخدمنا هذه الموارد ، والتي ، كقاعدة عامة ، خامدة ، لأن الطلبات المعقدة لا تدوم على مدار الساعة. بالطبع ، إذا كان هناك المزيد من الطلبات ، يمكنك دائمًا نقل خدمة المستورد لفصل المضيفين.

لم تكن هناك مشاكل كبيرة في استيراد البيانات من مصادر خارجية. في تلك النصوص التي كانت ، قاموا فقط بتغيير الوجهة من Redshift إلى ClickHouse.

كان هناك خيار للاتصال MongoDB في شكل قاموس ، وعدم القيام بنسخ يومية. لسوء الحظ ، لم يكن هذا مناسبًا ، لأنه يجب وضع القاموس في الذاكرة ، ولا يسمح حجم معظم المجموعات في MongoDB بهذا. لكن القواميس كانت مفيدة لنا أيضًا: استخدامها مناسب جدًا لتوصيل قواعد بيانات GeoIP من MaxMind واستخدامها في الاستعلامات. لهذا نستخدم تخطيط ip_trie وملفات CSV التي توفرها الخدمة. على سبيل المثال ، يبدو تكوين القاموس geoip_asn_blocks_ipv4 كما يلي:

 <dictionaries> <dictionary> <name>geoip_asn_blocks_ipv4</name> <source> <file> <path>GeoLite2-ASN-Blocks-IPv4.csv</path> <format>CSVWithNames</format> </file> <\/source> <lifetime>300</lifetime> <layout> <ip_trie /> </layout> <structure> <key> <attribute> <name>prefix</name> <type>String</type> </attribute> </key> <attribute> <name>autonomous_system_number</name> <type>UInt32</type> <null_value>0</null_value> </attribute> <attribute> <name>autonomous_system_organization</name> <type>String</type> <null_value>?</null_value> </attribute> </structure> </dictionary> </dictionaries> 

يكفي وضع هذا التكوين في /etc/clickhouse-server/geoip_asn_blocks_ipv4_dictionary.xml ، وبعد ذلك يمكنك إجراء استعلامات في القاموس للحصول على اسم الموفر حسب عنوان IP:

 SELECT dictGetString('geoip_asn_blocks_ipv4', 'autonomous_system_organization', tuple(IPv4StringToNum('192.168.1.1'))); 

تغيير مخطط البيانات . كما ذكرنا أعلاه ، قررنا عدم استخدام النسخ المتماثل حتى الآن ، نظرًا لأننا الآن لا يمكننا الوصول إليه في حالة وقوع الحوادث أو العمل المخطط له ، وهناك نسخة من البيانات موجودة بالفعل على s3 ويمكننا نقلها إلى ClickHouse في فترة زمنية معقولة. إذا لم يكن هناك نسخ متماثل ، فلن يقوموا بتوسيع ZooKeeper ، ويؤدي غياب ZooKeeper أيضًا إلى عدم القدرة على استخدام تعبير ON CLUSTER في استعلامات DDL. تم حل هذه المشكلة عن طريق برنامج نصي بيثون صغير يتصل بكل مضيف ClickHouse (هناك ثمانية منهم فقط حتى الآن) وينفذ استعلام SQL المحدد.

دعم SQL غير كامل في ClickHouse . تمت عملية نقل الطلبات من بناء جملة Redshift إلى بناء جملة ClickHouse بالتوازي مع تطور المستورد ، وتم التعامل معها بشكل أساسي بواسطة فريق من المحللين. بشكل غريب ، لكن الأمر لم يكن حتى في JOIN ، ولكن في وظائف النافذة. لفهم كيفية القيام بذلك من خلال المصفوفات ووظائف lambda ، استغرق الأمر عدة أيام. من الجيد أن يتم تناول هذه المشكلة غالبًا في تقارير حول ClickHouse ، والتي يوجد بها عدد كبير ، على سبيل المثال ، events.yandex.ru/lib/talks/5420 . في هذه المرحلة ، تمت كتابة البيانات بالفعل مرة واحدة في مكانين: في كل من Redshift و ClickHouse الجديد ، لذلك عندما قمنا بنقل الطلبات ، قمنا بمقارنة النتائج. كان من الصعب مقارنة السرعة ، نظرًا لأننا أزلنا عمودًا كبيرًا من الخصائص ، وبدأت معظم الاستعلامات في العمل فقط مع الأعمدة الضرورية ، والتي ، بالطبع ، أعطت زيادة كبيرة ، لكن تلك الاستعلامات التي لم يشارك فيها عمود الخصائص ، أو عملت بنفس الطريقة ، أو أسرع قليلاً.

نتيجة لذلك ، حصلنا على المخطط التالي:

النتائج

في الخلاصة ، حصلنا على الفوائد التالية:

• جدول واحد بدلا من 90
• يتم تنفيذ طلبات الخدمة بالمللي ثانية
• لقد انخفضت التكلفة إلى النصف
• سهولة إزالة الأحداث المكررة

هناك أيضًا عيوب نجهزها:

• في حالة وقوع حادث ، سوف تضطر إلى إصلاح الكتلة بنفسك
• يلزم إجراء تغييرات المخطط الآن على كل مضيف بشكل منفصل
• التحديث إلى الإصدارات الجديدة سيتعين عليك القيام بذلك بنفسك

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

استغرقت كل الهجرة إلى جانب الإعداد حوالي ثلاثة أشهر. مشيت من بداية يوليو إلى نهاية سبتمبر وطالبت بمشاركة شخصين. في 27 أيلول (سبتمبر) ، قمنا بإيقاف تشغيل Redshift ومنذ ذلك الحين نعمل فقط على ClickHouse. اتضح ، بالفعل ما يزيد قليلا عن شهرين. المصطلح قصير ، لكن حتى الآن لم تصادف أبدًا أي فقد للبيانات أو خلل حرج ، نظرًا لأن المجموعة بأكملها ستستيقظ. أمامنا ينتظرون التحديثات على الإصدارات الجديدة!