🍽️ 👩🏽‍🌾 🤞🏼 دلتا: مزامنة البيانات وإثراء النظام الأساسي 🍀 👨🏾‍⚕️ 👨🏻‍🌾

تحسبًا لإطلاق تيار جديد في دورة مهندس البيانات ، قمنا بإعداد ترجمة لمواد مثيرة للاهتمام.

نظرة عامة

سنتحدث عن نمط شائع إلى حد ما تستخدم فيه التطبيقات العديد من متاجر البيانات ، حيث يتم استخدام كل متجر لأغراضه الخاصة ، على سبيل المثال ، لتخزين الشكل الأساسي للبيانات (MySQL ، وما إلى ذلك) ، وتوفير إمكانات بحث متقدمة (ElasticSearch ، إلخ. .) ، التخزين المؤقت (Memcached ، إلخ) وغيرها. عادة ، عند استخدام العديد من مخازن البيانات ، يعمل أحدها كمخزن رئيسي ، والآخر كمخزن مشتق. المشكلة الوحيدة هي كيفية مزامنة مخازن البيانات هذه.

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

لحل هذه المشاكل ، تم تطوير دلتا. يعد Delta في النهاية نظامًا أساسيًا ثابتًا ومدفوعًا بالحدث لمزامنة البيانات وإثرائها.

الحلول الحالية

دخول مزدوج

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

مشاكل:

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

تغيير جدول السجل

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

المشاكل:

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

تكمن مشكلة أخرى في الحصول على تغييرات المخطط في الأنظمة التي لا تدعم تغييرات مخطط المعاملات [1] [2] ، مثل MySQL. لذلك ، لن يعمل دائمًا قالب لإجراء تغيير (على سبيل المثال ، تغيير نظام) وكتابته إلى جدول سجل التغيير.

المعاملات الموزعة

يمكن استخدام المعاملات الموزعة لتقسيم المعاملة بين العديد من مخازن البيانات غير المتجانسة بحيث يتم تنفيذ العملية في جميع المتاجر المستخدمة أو غير ملتزم بها في أي منها.

مشاكل:

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

دلتا

تم تصميم Delta لمعالجة قيود حلول مزامنة البيانات الحالية ، كما أنها تثري البيانات بسرعة. كان هدفنا هو تجريد كل هذه النقاط المعقدة من مطوري التطبيقات حتى يتمكنوا من التركيز بشكل كامل على تنفيذ وظائف الأعمال. بعد ذلك ، سنصف "Movie Search" ، حالة الاستخدام الفعلي لـ Delta Netflix.

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

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

الشكل 1. نظام الاقتراع قبل دلتا
بعد استخدام Delta ، تم تبسيط النظام إلى نظام يحركه الحدث ، كما هو موضح في الشكل التالي. يتم إرسال أحداث CDC (Change-Data-Capture) إلى مواضيع Keystone Kafka باستخدام موصل دلتا. يتلقى تطبيق Delta الذي تم إنشاؤه باستخدام إطار عمل Delta Stream (استنادًا إلى Flink) أحداث CDC من الموضوع ، ويثريها ، ويستدعي خدمات دقيقة أخرى ، وأخيرًا يمرر البيانات المخصّصة إلى فهرس البحث في Elasticsearch. تتم العملية برمتها في الوقت الفعلي تقريبًا ، أي بمجرد تسجيل التغييرات في مستودع البيانات ، يتم تحديث فهارس البحث.

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

CDC (Change-Data-Capture)

لقد قمنا بتطوير خدمة CDC تسمى Delta-Connector ، والتي يمكنها التقاط التغييرات الملتزم بها من مخزن البيانات في الوقت الفعلي وكتابتها إلى الدفق. تؤخذ التغييرات في الوقت الحقيقي من سجل المعاملات ومقالب التخزين. يتم استخدام عمليات التفريغ نظرًا لأن سجلات المعاملات لا تخزن عادةً سجل التغييرات بالكامل. عادةً ما يتم إجراء تسلسل للتغييرات على أنها أحداث دلتا ، لذا لا يجب على المستلم القلق بشأن مصدر التغيير.

يدعم Delta-Connector العديد من الميزات الإضافية ، مثل:

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

ندعم حاليًا MySQL و Postgres ، بما في ذلك عمليات النشر في AWS RDS و Aurora. نحن ندعم أيضًا كاساندرا (متعدد الأساتذة). يمكنك معرفة المزيد عن Delta-Connector في هذه المدونة .

كافكا ومستوى النقل

تم بناء طبقة Delta Event Transport على خدمة رسائل منصة Keystone .

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

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

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

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

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

لزيادة ضمان تسليم البيانات ، استخدمنا نظام تتبع الرسائل لاكتشاف أي فقد للرسائل في الظروف القاسية (على سبيل المثال ، مزامنة الساعة في قائد القسم).

إطار معالجة دفق

يعتمد مستوى المعالجة في Delta على النظام الأساسي Netflix SPaaS ، الذي يتيح تكامل Apache Flink مع النظام البيئي Netflix. توفر المنصة واجهة مستخدم تتحكم في نشر وظائف Flink وتنظيم مجموعات Flink فوق منصة Titus لإدارة الحاويات. تدير الواجهة أيضًا تكوينات المهام وتسمح للمستخدمين بإجراء تغييرات التكوين بشكل ديناميكي دون الحاجة إلى إعادة ترجمة مهام Flink.

توفر Delta إطار عمل معالجة دفق للبيانات المستندة إلى Flink و SPaaS ، والتي تستخدم التعليقات التوضيحيةDSL (لغة خاصة بالمجال) إلى تفاصيل تقنية مجردة. على سبيل المثال ، من أجل تحديد الخطوة التي سيتم إثراء الأحداث من خلالها عن طريق استدعاء الخدمات الخارجية ، يحتاج المستخدمون إلى كتابة DSL التالي ، وسوف يقوم إطار العمل بإنشاء نموذج بناءً على ذلك سينفذه Flink.

الشكل 3. مثال على إثراء DSL في دلتا

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

يتكون إطار معالجة دفق دلتا من وحدتين رئيسيتين ، وحدة DSL و API ووحدة وقت التشغيل. توفر وحدة DSL و API واجهات برمجة تطبيقات DSL و UDF (وظيفة معرفة من قبل المستخدم) بحيث يمكن للمستخدمين كتابة منطق المعالجة الخاص بهم (مثل التصفية أو التحويلات). توفر وحدة وقت التشغيل تطبيق محلل DSL ، الذي ينشئ تمثيلًا داخليًا لخطوات المعالجة في نماذج DAG. يفسر مكون التنفيذ نماذج DAG لتهيئة عبارات Flink الفعلية وتشغيل تطبيق Flink في النهاية. يتم توضيح بنية الإطار في الشكل التالي.

الشكل 4. بنية إطار معالجة دفق دلتا

هذا النهج له مزايا عديدة:

- Flink SPaaS.
, - (UDF).
Delta , , .

تم إنتاج Delta لأكثر من عام ولعبت دورًا رئيسيًا في العديد من تطبيقات Netflix Studio. ساعد الفريق في تنفيذ حالات الاستخدام مثل فهرسة البحث وتخزين البيانات وسير العمل الذي يحركه الحدث. فيما يلي نظرة عامة على البنية عالية المستوى لمنصة دلتا.

الشكل 5. العمارة رفيعة المستوى من دلتا.

شكر وتقدير

نود أن نشكر الأشخاص التاليين الذين ساهموا في إنشاء وتطوير Delta في Netflix: Allen Wang و Charles Zhao و Jaebin Yoon و Josh Snyder و Kasturi Chatterjee و Mark Cho و Olof Johansson و Piyush Goyal و Prashanth Ramdas و Raghuram Onti Srinivasan و Sandeep Gupta وستيفن وو وتارانجا جاميثيج ويون وانغ وتشين تشونغ شو.

المصادر

dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

: «Data Build Tool Amazon Redshift».

دلتا: مزامنة البيانات وإثراء النظام الأساسي