شبكة البيانات: كيفية التعامل مع البيانات دون متراصة

مرحبا يا هبر! نحن في Dodo Pizza Engineering نحب البيانات حقًا (ومن لا يحبها الآن؟). الآن ستكون هناك قصة حول كيفية تجميع جميع بيانات عالم Dodo Pizza وإتاحة وصول أي موظف في الشركة بسهولة إلى مجموعة البيانات هذه. المهمة تحت العلامة النجمية: احتفظ بأعصاب فريق هندسة البيانات.

مثل Plyushkins الحقيقي ، نحن نحفظ جميع أنواع المعلومات حول عمل مطاعم البيتزا لدينا:

• تذكر جميع أوامر المستخدم ؛
• نحن نعرف كم من الوقت استغرق لصنع البيتزا الأولى في سيكتيفكار ؛
• نرى كم من الوقت تبرد البيتزا على الرف الحراري في فورونيج الآن ؛
• تخزين البيانات على شطب المنتجات ؛
• وأكثر من ذلك بكثير.

تتولى عدة فرق حاليًا مسؤولية العمل مع البيانات في Dodo Pizza ، أحدها هو فريق هندسة البيانات. الآن لديهم (أي ، نحن) مهمة: منح أي موظف في الشركة وصولاً سهلاً إلى مجموعة البيانات هذه.

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

ماذا نعني بـ "البيانات"

للبدء ، لنقرر ما نعنيه بالبيانات في Dodo Pizza Engineering:

• الأحداث التي ترسل الخدمات (لدينا حافلة مشتركة بنيت باستخدام RabbitMQ) ؛
• السجلات داخل قاعدة البيانات (بالنسبة لنا ، هذا هو MySQL و CosmosDB) ؛
• Clickstream من تطبيق الهاتف المحمول وموقع الويب.

حتى يتسنى لشركة Dodo Pizza استخدام هذه البيانات والاعتماد عليها ، من المهم تلبية الشروط التالية:

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

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

النهج التقليدي - بحيرة البيانات

لحل مشاكل التخزين الموثوق ومعالجة البيانات الضخمة ، هناك طريقة تقليدية تعتمدها العديد من الشركات التي تعمل مع تجمع المعلومات هذا - Data Lake. كجزء من هذا النهج ، يجمع مهندسو البيانات المعلومات من جميع مكونات النظام ويضعونها في مخزن كبير واحد (يمكن أن يكون هذا ، على سبيل المثال ، Hadoop ، Azure Kusto ، Apache Cassandra أو حتى نسخة متماثلة MySQL إذا اقتحمت البيانات ذلك).

مزيد من هؤلاء المهندسين نفس كتابة طلبات لمثل هذا التخزين. ينطوي تنفيذ هذا النهج في Dodo Pizza Engineering على أن فريق هندسة البيانات سوف يمتلك مخطط البيانات في المستودع التحليلي.

مع هذا السيناريو ، يصبح الفريق القطط المحزنة للغاية وهذا هو السبب:

• يجب عليها مراقبة التغيرات في جميع الخدمات داخل الشركة. وهناك الكثير منها وهناك الكثير من التغييرات (في المتوسط ​​ندمج ~ 100 طلب سحب أسبوعيًا ، في حين أن العديد من الخدمات لا تقوم بعمليات سحب على الإطلاق).
• عند تغيير نظام البيانات ، يجب على مدير المنتج والفريق الذي قام بتغيير نظام البيانات الانتظار حتى تكمل Data Engineering التعليمات البرمجية اللازمة لدعم التغييرات. علاوة على ذلك ، لقد برزنا منذ فترة طويلة والوضع الذي ينتظر فيه فريق ما فريق آخر نادر جدًا. ونحن لا نريد أن يصبح هذا جزءًا "عاديًا" من عملية التطوير.
• يجب أن تكون مغمورة في الأعمال التجارية للشركة بأكملها . سلسلة من البيتزا تبدو وكأنها عمل بسيط ، ولكن يبدو فقط. من الصعب للغاية جمع كفاءات كافية في فريق واحد لبناء نموذج بيانات مناسب للشركة بأكملها.
• إنها نقطة فشل واحدة. في كل مرة تحتاج فيها إلى تغيير البيانات التي تُرجعها الخدمة أو تكتب استعلامًا ، تقع جميع هذه المهام على عاتق فريق هندسة البيانات. نتيجة لذلك ، أصبح لدى الفريق تراكم زائد.

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

تتدفق من بحيرة البيانات إلى شبكة البيانات

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

اقترح Zhamak Dehghani ، مستشار ThoughtWorks ، اتباع نهج مماثل لحل مشكلة Data Data. عند مشاهدة Netflix و Spotify لحل مثل هذه المشكلات ، كتبت مقالة مذهلة حول كيفية الانتقال إلى ما وراء بحيرة بيانات متجانسة إلى شبكة بيانات موزعة (كان الرابط إليها في بداية المقال). الأفكار الرئيسية التي أخرجناها لأنفسنا:

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

وفي الوقت نفسه ، فإن فريق هندسة البيانات ...

إذا كنت تتخيل أن كل هذا يتحقق بنقرة إصبع ، فيجب عليك الإجابة عن سؤالين:

ماذا سيفعل فريق هندسة البيانات الآن؟ لدى Dodo Pizza Engineering بالفعل فريق منصة / SRE. وتتمثل مهمتها في توفير أدوات للمطورين لسهولة نشر الخدمات. سيقوم فريق هندسة البيانات بنفس الدور للبيانات فقط.

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

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

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

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

لدينا عدة طرق للقيام بذلك:

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

استهلاك البيانات

تحدثت الآن كثيرًا عن نشر البيانات. ولكن هناك أيضا الاستهلاك. ماذا عن هذه القضية؟

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

هذه هي الطريقة التي نرى بها العمل مع البيانات في Dodo Pizza Engineering. يسرنا أن نقرأ أفكارك حول هذا الموضوع في التعليقات.