دلتا: منصة مزامنة البيانات وتخصيبها

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

مراجعة

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

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

تم تطوير دلتا لحل هذه المشاكل. توفر دلتا في النهاية منصة متسقة تعتمد على الأحداث لمزامنة البيانات وإثرائها.

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

دخول مزدوج

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

المشاكل هي:

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

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

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

المشاكل هي:

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

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

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

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

المشاكل هي:

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

دلتا

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

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

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

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

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

CDC (تغيير-التقاط البيانات)

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

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

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

نحن ندعم حاليًا MySQL وPostgres، بما في ذلك عمليات النشر على AWS RDS وAurora. نحن ندعم أيضًا Cassandra (متعدد الماجستير). يمكنك معرفة المزيد من التفاصيل حول Delta-Connector هنا блоге.

كافكا وطبقة النقل

تم بناء طبقة نقل الأحداث الخاصة بشركة Delta على خدمة مراسلة النظام الأساسي حجر العقد.

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

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

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

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

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

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

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

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

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

الشكل 3. مثال للتخصيب على DSL في دلتا

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

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

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

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

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

استخدام الإنتاج

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

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

شكر وتقدير

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

مصادر

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. مارتن كليبمان، أليستر ر. بيريسفورد، بورج سفينجن: معالجة الأحداث عبر الإنترنت. مشترك. ايه سي ام 62(5): 43-49 (2019). معرف الهوية الرقمي: doi.org/10.1145/3312527

قم بالتسجيل للحصول على ندوة مجانية على الويب: "أداة بناء البيانات لتخزين Amazon Redshift."

المصدر: www.habr.com