ما المقصود بسجل المخططات؟

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

في Kafka، غالبًا ما يتم ترميز الأحداث باستخدام تنسيقات مثل Apache Avro وJSON Schema وProtocol Buffers، التي يتم اختصار اسمها غالبًا إلى protobuf. يخزّن سجل المخططات تعريفات هذه التنسيقات ويعيّن لكل مخطط معرِّفًا فريدًا. ويُعرَف هذا باسم معرِّف المخطط.

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

يُعَد سجل المخططات مهمًا في الأنظمة القائمة على الأحداث لأنه يساعد على ضمان توافق التطبيقات المنتجة والمستهلكة على هيكل البيانات المتبادلة. ويُسهم ذلك في الحفاظ على جودة البيانات وسلامتها.

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

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

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

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

يسهِّل هذا النهج على فِرق التطوير ما يلي:

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

في منصات البيانات الحديثة، يمكن لسجل المخططات أيضًا تمكين عقود البيانات بين التطبيقات المنتِجة للبيانات في Kafka والتطبيقات المستهلِكة للبيانات في Kafka. لا تحدِّد هذه العقود هيكل البيانات فحسب، بل تحدِّد أيضًا التوقعات بشأن كيفية تطوُّر هذه البيانات بمرور الوقت.

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

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

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

تساعد هذه الأساليب التطبيقات على تبادل البيانات مع تغيُّر الأنظمة والمتطلبات.

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

تخيَّل بائع تجزئة كبيرًا عبر الإنترنت لديه أنظمة متعددة تُنشئ البيانات وتستهلكها، منها موقع للتجارة الإلكترونية وتطبيق للأجهزة المحمولة ومحرك للتوصيات ونظام لإدارة المخزون ومنصة للشحن ومنصة لتحليلات العملاء. يتواصل كل نظام من هذه الأنظمة من خلال نشر الأحداث واستهلاكها عبر مجموعات Apache Kafka باستخدام Confluent Cloud، كما ينقل تدفقات هذه الأحداث إلى مستودع بيانات باستخدام Kafka Connect ضمن مسار البيانات الخاص به.

يؤدي كل إجراء على الموقع الإلكتروني إلى إنشاء عدة أحداث عبر أنظمة بائع التجزئة. عندما يقدِّم أحد العملاء طلبًا، ينشر الموقع الإلكتروني حدث OrderCreated في أحد موضوعات Kafka.

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

في البداية، يحتوي حدث OrderCreated على حقول مثل order_id وcustomer_id وproduct_id وquantity وtotal_price . تم تصميم جميع التطبيقات المستهلكة للبيانات لتتوقع هذا الهيكل.

لنفترض الآن أنه بعد مرور عدة أشهر، قررت الشركة دعم المبيعات الدولية. يحدِّث المطورون الموقع الإلكتروني بحيث يتضمن كل طلب الآن حقلين جديدين: currency وexchange_rate .

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

فكيف يمكن أن يبدو السيناريو نفسه عند استخدام Confluent Schema Registry للمساعدة على إدارة المخططات؟

قبل نشر المنتج المحدَّث، يسجِّل فريق التطوير إصدارًا جديدًا من مخطط OrderCreated. يُنشئ ذلك معرِّفًا جديدًا للمخطط مرتبطًا بالمخطط. يتحقق سجل المخططات من التغييرات المقترحة مقابل إعدادات التوافق المعتمدة في المؤسسة.

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

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

تزداد أهمية فوائد سجل المخططات مع نمو الشركة. مئات التطبيقات التي تطورها العشرات من فِرق الهندسة قد تتبادل البيانات من خلال الآلاف من الأنواع المختلفة من الأحداث.

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

مع وجود سجل للمخططات، تصبح مخططات الأحداث أصولًا مُدارة مركزيًا. يمكن للتطبيقات المنتِجة نشر البيانات وفقًا للمخططات المسجَّلة، ويمكن للتطبيقات المستهلِكة استخدام تعريفات هذه المخططات لتفسير الأحداث الواردة، كما يمكن لعمليات التحقق من التوافق تحديد التغييرات غير المتوافقة في المخططات.

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

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

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

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

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

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

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

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

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

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

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

يمكن لسجل المخططات دعم جهود الامتثال للوائح خصوصية البيانات، مثل اللائحة العامة لحماية البيانات (GDPR) وقانون خصوصية المستهلك في كاليفورنيا (CCPA).

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

تتمثل إحدى الفوائد الرئيسية في تحسين الرؤية بشأن البيانات التي تتم معالجتها.

يتم تخزين كل مخطط للأحداث في مستودع مركزي يوثِّق الحقول التي يمثِّلها المخطط. ويوفر ذلك مصدرًا للمعلومات حول البيانات الموجودة وما تمثِّله الحقول المحددة وكيفية تنظيم التطبيقات للبيانات التي تنتجها أو تستهلكها.

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

يمكن لسجل المخططات أيضًا دعم تقليل البيانات، وهو أحد مبادئ اللائحة العامة لحماية البيانات (GDPR).

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

يمكن أن يساعد التحقق من صحة المخططات أيضًا على منع التغييرات غير المصرَّح بها أو غير المقصودة التي تؤدي إلى إدخال بيانات حساسة جديدة إلى أنظمة الإنتاج.

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

يوفر هذا النهج نقطة تحقق إضافية للحوكمة إلى جانب الاختبارات المعتادة للتطبيقات.

توفِّر إدارة الإصدارات وسجل المخططات قدرات التدقيق.

يتم تسجيل كل تغيير يطرأ على المخطط، ما يُتيح للمؤسسات معرفة وقت إضافة الحقول أو تعديلها أو حذفها.

أثناء تدقيق الامتثال، يمكن أن يساعد هذا السجل على إثبات أن هياكل البيانات تُدار بطريقة خاضعة للرقابة وقابلة للتتبُّع.

يمكن لسجل المخططات أيضًا تحسين الاتساق عبر الأنظمة المتعددة.

نظرًا إلى اعتماد التطبيقات المنتِجة والمستهلِكة على تعريفات المخططات المشتركة، يمكن للتطبيقات تفسير الحقول وفقًا لتعريفات هيكلية موحَّدة.

ويمكن أن يقلل ذلك من التباين في طريقة التعامل مع البيانات بين التطبيقات.

يستخدم العديد من المؤسسات سجل المخططات كجزء من تطبيق عقود البيانات.

لا تحدِّد هذه العقود هيكل الحدث فحسب، بل تحدِّد أيضًا البيانات الوصفية المتعلقة بالبيانات التي يحتوي عليها.

• قد يحدِّد عقد البيانات ما يلي:
• الحقول التي تحتوي على معلومات تعريف شخصية (PII).
• ما إذا كانت هناك متطلبات أمنية محددة لبعض الحقول.
• الجهات المصرَّح لها باستهلاك بيانات محددة.
• المدة التي ينبغي الاحتفاظ بالبيانات خلالها.

بعد ذلك، يمكن استخدام التحقق المؤتمت للتأكد من استمرار إصدارات المخططات الجديدة في استيفاء المتطلبات المحددة.

يمكن أيضًا دمج سجلات المخططات مع أدوات أوسع نطاقًا لحوكمة البيانات والأمان.

يمكن للأنظمة التالية استخدام البيانات الوصفية المخزَّنة إلى جانب المخططات:

• كتالوجات البيانات
• أنظمة التحكم في الوصول
• أدوات تتبُّع دورة حياة البيانات
• منصات الامتثال

وبالتالي، يمكن أن يشكِّل سجل المخططات أحد عناصر بنية الحوكمة الأوسع نطاقًا.

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

توفِّر عدة منصات إمكانات سجل المخططات لـ Kafka وأنظمة البيانات ذات الصلة.

يُعَد Confluent Schema Registry سجل مخططات مخصصًا لـ Kafka ويُستخدم على نطاق واسع.

وهو جزء من منظومة Confluent، ويتوفر كعنصر تتم إدارته ذاتيًا ضمن Confluent Platform، وكذلك كخدمة مُدارة في Confluent Cloud.

يدعم Avro وProtobuf وJSON Schema، ويوفر إدارة إصدارات المخططات وقواعد التوافق والتحقق من صحتها والتكامل مع تطبيقات Kafka المنتِجة والمستهلِكة.

توفِّر Amazon Web Services سجل AWS Glue Schema Registry.

وهو سجل مخططات مُدار يتكامل مع Apache Kafka وAmazon Managed Streaming for Apache Kafka (MSK) وAmazon Kinesis وAmazon Managed Service for Apache Flink وAWS Lambda.

ويدعم Avro وJSON Schema وProtobuf.

يُعَد Apicurio Registry سجلًا مفتوح المصدر للمخططات وعناصر واجهات برمجة التطبيقات (APIs)، ويمكن استخدامه مع Kafka.

يدعم تنسيقات تشمل Avro وJSON Schema وProtobuf، ويمكن نشره في بيئات مثل Kubernetes.

يوفر Apicurio أيضًا توافقًا مع واجهة برمجة التطبيقات (API) الخاصة بـ Confluent Schema Registry، ما قد يجعل من السهل استخدامه مع تطبيقات Kafka المصممة للعمل مع واجهات سجل المخططات من Confluent.

يتضمن Redpanda أيضًا خدمة متوافقة مع Schema Registry كجزء من منصة تدفق البيانات المتوافقة مع Kafka.

وقد يكون هذا النهج مفيدًا عندما تستخدم المؤسسة Redpanda بدلًا من Apache Kafka مباشرةً، إذ يمكن توفير إدارة المخططات كجزء من منصة تدفق البيانات نفسها.

ويكون سجل Redpanda أكثر تكاملًا مع منصة بديلة لتدفق البيانات متوافقة مع Kafka.

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

معرِّف المخطط هو معرِّف لتعريف مخطط محدد. يشير إصدار المخطط إلى موضع هذا المخطط ضمن تسلسل الإصدارات المُدارة لمخطط أو موضوع محدد. ويختلف التطبيق الفعلي لهذه الآلية باختلاف سجل المخططات. في Confluent Schema Registry، على سبيل المثال، يعمل معرِّف المخطط على تحديد المخطط بشكل فريد داخل السجل، بينما يرتبط الإصدار بموضوع محدد. وبالتالي، يمكن أن يكون للمخطط نفسه معرِّف المخطط نفسه، مع ارتباطه بإصدارات مختلفة ضمن موضوعات مختلفة.

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

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

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

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

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