Get best of the week

DBLog - إطار مشترك لتغيير التقاط البيانات

تحية للجميع! نقدم لك قراءة ترجمة المقالة التي قمنا بإعدادها خصيصًا لطلاب دورة "High Load Architect" .



المقدمة


يتيح لك تتبع تغييرات البيانات (تغيير التقاط البيانات ، CDC) تلقي التغييرات الملتزم بها في قاعدة البيانات في الوقت الفعلي وتوزيعها على مختلف المستهلكين [1] [2]. تزداد شعبية CDC عند الحاجة إلى التزامن بين تخزين البيانات غير المتجانسة (على سبيل المثال ، MySQL و ElasticSearch) وهو بديل للطرق التقليدية مثل الكتابة المزدوجة والمعاملات الموزعة [3] [4].

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

هذا قادنا إلى تطوير DBLog.مع نهج موحد لمعالجة السجلات ومقالب النفايات. لدعم ذلك ، يجب تنفيذ عدد من الوظائف في DBMS ، الموجودة بالفعل في MySQL و PostgreSQL و MariaDB وعدد من قواعد البيانات الأخرى.

بعض ميزات DBLog:

  • تتم معالجة أحداث السجل بالترتيب الذي تحدث فيه.
  • يمكن إجراء عمليات التفريغ في أي وقت لجميع الجداول ، أو لجدول واحد أو لمفاتيح أساسية محددة للجدول.
  • بدائل معالجة السجل مع معالجة التفريغ ، وتقسيم التفريغ إلى كتل. وبالتالي ، يمكن أن تتم معالجة السجل بالتوازي مع معالجة التفريغ. إذا انتهت العملية ، فيمكن استئنافها بعد آخر كتلة مكتملة دون الحاجة إلى البدء من جديد. كما يسمح لك بتعديل الإنتاجية عند إنشاء ملف تفريغ ، وإذا لزم الأمر ، قم بإيقاف إنشائه مؤقتًا.
  • , .
  • : , API.
  • . , .


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

لمزامنة البيانات ومعالجة الأحداث ، بالإضافة إلى قدرتنا على تتبع التغييرات في الوقت الفعلي ، نحتاج إلى تلبية المتطلبات التالية:

  • الحصول على الحالة الكاملة . يجب أن تخزن المتاجر المشتقة (مثل ElasticSearch) في النهاية الحالة الكاملة للمصدر. نقوم بتنفيذ هذا من خلال مقالب قاعدة البيانات الأصلية.
  • ابدأ استرداد الحالة في أي وقت. بدلاً من اعتبار التفريغ عملية لمرة واحدة فقط للتهيئة الأولية ، يمكننا القيام بذلك في أي وقت: لجميع الجداول أو لجدول واحد أو لمفاتيح أساسية محددة. هذا مهم جدا لاسترداد المستهلكين في حالة فقدان أو تلف البيانات.
  • - . . , (, ). - . , - .
  • . . API, , , . , , , .
  • . Netflix , Kafka, SQS, Kinesis, Netflix, Keystone. , (, ), (, ). . API.
  • . Netflix , (MySQL, PostgreSQL) AWS RDS. .



قمنا بفحص العديد من الحلول المفتوحة المصدر القائمة ، بما في ذلك: Maxwell و SpinalTap و Yelp MySQL Streamer و Debezium . من حيث جمع البيانات ، تعمل جميعها بطريقة مماثلة ، باستخدام سجل المعاملات. على سبيل المثال ، استخدام بروتوكول النسخ المتماثل binlog في MySQL أو فتحات النسخ المتماثل في PostgreSQL.

ولكن عند معالجة مكبات النفايات ، لديهم واحد على الأقل من القيود التالية:

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

في النهاية ، قررنا اتباع نهج مختلف للعمل مع مكبات النفايات:

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

إطار DBLog


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

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

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

بعد ذلك ، نعتبر بمزيد من التفصيل معالجة السجلات ومقالب النفايات.

السجلات


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

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

مقالب


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

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

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


الشكل 1. تفاصيل الجدول مع 4 أعمدة c1-c4 و c1 كمفتاح أساسي (pk). المفتاح الأساسي لنوع صحيح ، حجم الكتلة 3. يتم تحديد الكتلة 2 بواسطة الشرط c1> 4.

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

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

يتم إنشاء مقالب بالماء على النحو التالي:

  1. نعلق مؤقتًا معالجة أحداث السجل.
  2. إنشاء علامة مائية "منخفضة" عن طريق تحديث جدول العلامة المائية.
  3. نبدأ SELECT للكتلة التالية ونحفظ في الذاكرة النتيجة المفهرسة بواسطة المفتاح الأساسي.
  4. “” (high) , .
  5. . .
  6. , .
  7. , , .
  8. , 1.

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

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

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

يوضح الشكلان 2 أ و 2 ب خوارزمية اختيار الكتلة. كمثال ، نعطي جدولاً بالمفاتيح الأساسية من k1 إلى k6. يمثل كل إدخال في سجل التغيير حدث إنشاء أو تحديث أو حذف للمفتاح الأساسي. يوضح الشكل 2 أ توليد العلامة المائية واختيار الكتلة (الخطوات من 1 إلى 4). يؤدي تحديث جدول العلامة المائية في الخطوتين 2 و 4 إلى إنشاء حدثين للتغيير (أرجواني) ، يتم تلقيهما في النهاية من خلال السجل. في الشكل 2 ب ، نركز على خطوط الكتلة الحالية التي تمت إزالتها من مجموعة النتائج باستخدام المفاتيح الأساسية التي تظهر بين العلامات المائية (الخطوات من 5 إلى 7).


الشكل 2 أ - خوارزمية العلامة المائية لاختيار الكتلة (الخطوات 1-4).


الشكل 2 ب - خوارزمية العلامة المائية لاختيار الكتل (الخطوات 5-7).

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

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

يوضح الشكل 2 ج ترتيب التسجيل للكتلة بأكملها باستخدام نفس المثال كما في الشكلين 2 أ و 2 ب. يتم تسجيل الأحداث في السجل التي تظهر قبل العلامة المائية العليا أولاً. ثم الخطوط المتبقية من نتيجة الكتلة (أرجواني). وأخيرًا ، يتم تسجيل الأحداث التي تحدث بعد العلامة المائية العلوية.


الشكل 2 ج - ترتيب تسجيل الإخراج. قطاع بالتناوب مع تفريغ.

قواعد البيانات المدعومة


لاستخدام DBLog ، يجب أن توفر قاعدة البيانات سجل تغيير كمحفوظات خطية للتغييرات الملتزمة بقراءات غير قديمة. يتم استيفاء هذه الشروط من خلال أنظمة مثل MySQL و PostgreSQL و MariaDB ، إلخ ، وبالتالي ، يمكن استخدام إطار العمل بنفس الطريقة مع قواعد البيانات هذه.
حتى الآن ، أضفنا دعمًا لـ MySQL و PostgreSQL. تستخدم كل قاعدة بيانات مكتباتها الخاصة لتلقي أحداث السجل ، حيث تستخدم كل منها بروتوكولًا خاصًا. بالنسبة لـ MySQL ، نستخدم موصل shyiko / mysql-binlog الذي ينفذ بروتوكول النسخ المتماثل binlog. بالنسبة لـ PostgreSQL ، توجد فتحات للنسخ المتماثل مع البرنامج المساعد wal2json . يتم قبول التغييرات من خلال بروتوكول النسخ المتماثل للدفق ، والذي يتم تنفيذه بواسطة برنامج تشغيل jdbcPostgreSQL يختلف تعريف المخطط لكل تغيير تم التقاطه في MySQL و PostgreSQL. في PostgreSQL ، تحتوي wal2json على أسماء وأنواع أعمدة وقيم. بالنسبة إلى MySQL ، يجب تتبع تغييرات المخطط كأحداث binlog.

تم تنفيذ معالجة التفريغ باستخدام SQL و JDBC ، مما يتطلب فقط تنفيذ اختيار الكتلة وتحديث العلامة المائية. بالنسبة إلى MySQL و PostgreSQL ، يتم استخدام نفس الرمز ، والذي يمكن استخدامه لقواعد بيانات أخرى مماثلة. لا تعتمد معالجة التفريغ نفسها على SQL أو JDBC وتسمح لك باستخدام قواعد البيانات التي تلبي متطلبات DBLog ، حتى إذا كانت تستخدم معايير مختلفة.


الشكل 3 - معمارية DBLog عالية المستوى.

توافر عالية


يستخدم DBLog بنية السلبي النشط عقدة واحدة. مثال واحد نشط (يؤدي) ، بينما البعض الآخر سلبي (وضع الاستعداد). لتحديد المضيف ، نستخدم Zookeeper. يتم استخدام عقد الإيجار للعقدة الرئيسية ، والتي يجب تحديثها بشكل دوري حتى تظل الرئيسية. في حالة إنهاء تجديد الإيجار ، يتم نقل وظائف القائد إلى عقدة أخرى. حاليًا ، ننشر نسخة واحدة لكل AZ (منطقة التوافر ، وعادة ما يكون لدينا 3 AZ) ، لذلك إذا سقط AZ واحد ، فيمكن للنسخة في AZ أخرى متابعة المعالجة مع الحد الأدنى لإجمالي التوقف. يمكن وضع مثيلات النسخ الاحتياطي في مناطق مختلفة ، على الرغم من أنه يوصى بالعمل في نفس المنطقة مثل مضيف قاعدة البيانات لضمان وقت استجابة منخفض لالتقاط التغييرات.

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


DBLog هو أساس موصلات MySQL و PostgreSQL المستخدمة في دلتا . منذ عام 2018 ، تم استخدام Delta في الإنتاج لمزامنة مستودعات البيانات ومعالجة الأحداث في تطبيقات استوديو Netflix. تستخدم موصلات دلتا مُسلسِل الحدث الخاص بها. تُستخدم تيارات Netflix الخاصة مثل Keystone كمخرجات .


الشكل 4 - موصل دلتا.

بالإضافة إلى Delta ، يتم استخدام DBLog أيضًا في Netflix لإنشاء موصلات لمنصات حركة البيانات الأخرى التي لها تنسيقات بيانات خاصة بها.

ابقى معنا


يحتوي DBLog على ميزات إضافية لم يتم تناولها في هذه المقالة ، مثل:

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

نخطط لفتح شفرة مصدر DBLog في عام 2020 وتضمينها وثائق إضافية.

شكر وتقدير


ونود أن نشكر الشعب التالية للمساهمة في تطوير DBLog: جوش سنايدر ، راغورام Onti سرينيفاسان ، Tharanga Gamaethige و يون وانغ .

المراجع


[1] داس ، شيرشانكا وآخرون. "كل شيء على متن Databus!: منصة التقاط بيانات تغيير متسقة قابلة للتطوير من Linkedin." ندوة ACM الثالثة حول الحوسبة السحابية. ACM، 2012
[2] "حول تغيير التقاط البيانات (SQL Server)" ، مستندات Microsoft SQL ، 2019
[3] Kleppmann ، Martin ، "استخدام السجلات لبناء بنية تحتية قوية للبيانات (أو: لماذا تعد عمليات الكتابة المزدوجة فكرة سيئة)" ، كونفلوانت ، 2015
[4] كليبمان ، مارتن ، أليستر ر. بيريسفورد ، بورج سفينجين. "معالجة الأحداث عبر الإنترنت." اتصالات ACM 62.5 (2019): 43–49
[5] https://debezium.io/documentation/reference/0.10/connectors/mysql.html#snapshots


تعرف على المزيد حول الدورة التدريبية.

More articles:


All Articles