Open Source DataHub: منصة البحث عن البيانات الوصفية واكتشافها على LinkedIn

Open Source DataHub: منصة البحث عن البيانات الوصفية واكتشافها على LinkedIn

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

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

لقد أصبح WhereHows الآن DataHub!

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

نهج المصدر المفتوح

WhereHows، بوابة LinkedIn الأصلية للعثور على البيانات ومن أين تأتي، بدأت كمشروع داخلي؛ فتحه فريق البيانات الوصفية كود المصدر في عام 2016. منذ ذلك الحين، احتفظ الفريق دائمًا بقاعدتي تعليمات برمجية مختلفتين — واحدة للمصدر المفتوح والأخرى للاستخدام الداخلي لـ LinkedIn — حيث لم تكن جميع ميزات المنتج التي تم تطويرها لحالات استخدام LinkedIn قابلة للتطبيق بشكل عام على الجمهور الأوسع. بالإضافة إلى ذلك، لدى WhereHows بعض التبعيات الداخلية (البنية التحتية والمكتبات وما إلى ذلك) التي ليست مفتوحة المصدر. في السنوات التي تلت ذلك، مر برنامج WhereHows بالعديد من التكرارات ودورات التطوير، مما جعل الحفاظ على تزامن قاعدتي التعليمات البرمجية تحديًا كبيرًا. لقد جرب فريق البيانات الوصفية أساليب مختلفة على مر السنين لمحاولة الحفاظ على مزامنة التطوير الداخلي والمفتوح المصدر.

المحاولة الأولى: "المصدر المفتوح أولاً"

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

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

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

المحاولة الثانية: "الداخل أولاً"

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

للمرة الثالثة عملت!

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

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

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

أتمتة النشر مفتوح المصدر

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

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

سوف تتعمق الأقسام الفرعية التالية في الوظائف المذكورة أعلاه والتي لديها مشاكل مثيرة للاهتمام.

مزامنة كود المصدر

على عكس الإصدار مفتوح المصدر من DataHub، وهو مستودع GitHub واحد، فإن إصدار LinkedIn من DataHub عبارة عن مزيج من مستودعات متعددة (تسمى داخليًا منتجات متعددة). توجد واجهة DataHub ومكتبة نماذج البيانات التعريفية وخدمة الواجهة الخلفية لمستودع البيانات التعريفية ووظائف البث في مستودعات منفصلة على LinkedIn. ومع ذلك، لتسهيل الأمر على مستخدمي المصادر المفتوحة، لدينا مستودع واحد للإصدار مفتوح المصدر من DataHub.

الشكل 1: التزامن بين المستودعات لينكدين: داتاهب ومستودع واحد داتاهب المصدر المفتوح

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

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

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

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

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

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

إنشاء سجلات الالتزام

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

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

اختبار التبعية

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

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

الاختلافات بين DataHub مفتوح المصدر وإصدار الإنتاج الخاص بنا

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

ينبع أحد مصادر التناقض من حقيقة أن إصدار الإنتاج الخاص بنا يحتوي على تبعيات على تعليمات برمجية ليست مفتوحة المصدر بعد، مثل LinkedIn's Offspring (إطار عمل حقن التبعية الداخلي في LinkedIn). يُستخدم النسل على نطاق واسع في قواعد التعليمات البرمجية الداخلية لأنه الطريقة المفضلة لإدارة التكوين الديناميكي. لكنها ليست مفتوحة المصدر؛ لذلك كنا بحاجة إلى إيجاد بدائل مفتوحة المصدر لـ DataHub مفتوح المصدر.

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

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

مثال آخر على الاختلاف هو وجود GMS واحد (مخزن بيانات التعريف العامة) في تطبيق مفتوح المصدر بدلاً من GMSs المتعددة. GMA (هندسة بيانات التعريف العامة) هو اسم البنية الخلفية لـ DataHub، وGMS هو مخزن بيانات التعريف في سياق GMA. GMA عبارة عن بنية مرنة للغاية تسمح لك بتوزيع كل بنية بيانات (مثل مجموعات البيانات والمستخدمين وما إلى ذلك) في مخزن البيانات التعريفية الخاص بها، أو تخزين بنيات بيانات متعددة في مخزن بيانات تعريف واحد طالما أن السجل يحتوي على تعيين بنية البيانات في تم تحديث نظام GMS. لسهولة الاستخدام، اخترنا مثيل GMS واحدًا يقوم بتخزين جميع بنيات البيانات المختلفة في DataHub مفتوح المصدر.

وترد في الجدول أدناه قائمة كاملة بالاختلافات بين التطبيقين.

ميزات المنتج
لينكد إن داتا هاب
مركز بيانات مفتوح المصدر

بنيات البيانات المدعومة
1) مجموعات البيانات 2) المستخدمون 3) المقاييس 4) ميزات تعلم الآلة 5) الرسوم البيانية 6) لوحات المعلومات
1) مجموعات البيانات 2) المستخدمون

مصادر البيانات الوصفية المدعومة لمجموعات البيانات
1) أمبري 2) قاعدة الأريكة 3) داليدز 4) اسبريسو 5) HDFS 6) الخلية 7) كافكا 8) MongoDB 9) MySQL 10) Oracle 11) بينو 12) المعزوفة 12) البحار 13) Teradata 13) المتجهات 14) Venice
خلية كافكا RDBMS

حانة فرعية
ينكدين كافكا
كافكا المتكدسة

معالجة البث
Managed
مضمن (مستقل)

حقن التبعية والتكوين الديناميكي
ينكدين النسل
سبرينج

بناء الأدوات
Ligradle (مجمع Gradle الداخلي الخاص بـ LinkedIn)
غرادلو

CI / CD
CRT (CI/CD الداخلي لـ LinkedIn)
ترافيس سي و دوكر هاب

مخازن البيانات الوصفية
توزيع GMS متعدد: 1) GMS لمجموعة البيانات 2) GMS للمستخدم 3) GMS المتري 4) GMS المميز 5) GMS للمخطط/لوحة المعلومات
GMS واحد لـ: 1) مجموعات البيانات 2) المستخدمين

الخدمات المصغرة في حاويات Docker

عامل في حوض السفن يبسط نشر التطبيق وتوزيعه مع النقل بالحاويات. كل جزء من الخدمة في DataHub مفتوح المصدر، بما في ذلك مكونات البنية التحتية مثل Kafka، Elasticsearch, neo4j и MySQL، له صورة Docker الخاصة به. استخدمنا لتنسيق حاويات Docker دوكر يؤلف.

الشكل 2: الهندسة المعمارية داتاهب *مفتوحة المصدر**

يمكنك رؤية البنية عالية المستوى لـ DataHub في الصورة أعلاه. بالإضافة إلى مكونات البنية التحتية، فهو يحتوي على أربع حاويات Docker مختلفة:

datahub-gms: خدمة تخزين البيانات الوصفية

الواجهة الأمامية لمركز البيانات: التطبيق بلايستشن، يخدم واجهة DataHub.

datahub-mce-consumer: التطبيق كافكا تيارات، الذي يستخدم دفق حدث تغيير بيانات التعريف (MCE) ويقوم بتحديث مخزن بيانات التعريف.

datahub-mae-consumer: التطبيق كافكا تيارات، والذي يستخدم دفق حدث تدقيق البيانات الوصفية (MAE) ويقوم بإنشاء فهرس بحث وقاعدة بيانات رسم بياني.

وثائق المستودع مفتوح المصدر و منشور مدونة DataHub الأصلي تحتوي على معلومات أكثر تفصيلاً حول وظائف الخدمات المختلفة.

CI/CD الموجود على DataHub مفتوح المصدر

يستخدم مستودع DataHub مفتوح المصدر ترافيس سي للتكامل المستمر و دوكر هاب للنشر المستمر. يتمتع كلاهما بتكامل جيد مع GitHub ويسهل إعدادهما. بالنسبة لمعظم البنى التحتية مفتوحة المصدر التي طورها المجتمع أو الشركات الخاصة (مثل: تقاطع)، يتم إنشاء صور Docker ونشرها في Docker Hub لسهولة استخدامها من قبل المجتمع. يمكن استخدام أي صورة Docker موجودة في Docker Hub بسهولة من خلال أمر بسيط سحب عامل ميناء.

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

باستخدام داتا هاب

إعداد DataHub بسيط للغاية ويتكون من ثلاث خطوات بسيطة:

1. قم باستنساخ المستودع مفتوح المصدر وقم بتشغيل كافة حاويات Docker باستخدام docker-compose باستخدام البرنامج النصي docker-compose المتوفر للبدء السريع.
2. قم بتنزيل البيانات النموذجية المتوفرة في المستودع باستخدام أداة سطر الأوامر المتوفرة أيضًا.
3. تصفح DataHub في متصفحك.

تتبع بنشاط دردشة جيتر تم تكوينه أيضًا للأسئلة السريعة. يمكن للمستخدمين أيضًا إنشاء مشكلات مباشرةً في مستودع GitHub. والأهم من ذلك أننا نرحب ونقدر جميع التعليقات والاقتراحات!

خطط للمستقبل

حاليًا، يتم إنشاء كل بنية أساسية أو خدمة صغيرة لـ DataHub مفتوحة المصدر كحاوية Docker، ويتم تنسيق النظام بأكمله باستخدام عامل ميناء-يؤلف. نظرا لشعبيتها وانتشارها Kubernetes، نود أيضًا تقديم حل يستند إلى Kubernetes في المستقبل القريب.

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

أخيرًا وليس آخرًا، شكرًا لجميع مستخدمي DataHub الأوائل في مجتمع المصادر المفتوحة الذين قاموا بتقييم DataHub alphas وساعدونا في تحديد المشكلات وتحسين الوثائق.

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