دليل كامل حول كيفية كسر كتلة البيانات.

كيفية التعامل مع الهدف الكبير الجديد في عالم البرمجيات.

كسر متآلف البيانات!

التحفيز

متآلف البيانات

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

لقد عملت في العديد من المشاريع (في شركات مختلفة) على مدار السنوات الماضية ، وقد رأيت أن المشكلات التي تسببها البيانات المتجانسة متشابهة:

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

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

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

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

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

كيفية كسر المونوليث

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

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

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

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

استراتيجية توزيع البيانات

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

البنية التحتية للبيانات كمنصة

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

في مقال شبكة البيانات من مدونة Martin Fowler (التي كتبها زميلي السابق في Thoughtworks Zhamak Dehghani) يكتبون بعض القدرات التي يجب أن تمتلكها هذه البنية التحتية ، بعضها: تخزين بيانات حفر متعدد اللغات قابلة للتحجيم ، وإصدار البيانات ، ومخطط البيانات ، ونسب البيانات ، ومراقبة البيانات / التنبيه / السجل ، مقاييس جودة منتج البيانات ، إدارة البيانات ، الأمان والحوسبة وموقع البيانات.

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

صورة من Metaflow

ويمكن أن تكون الصورة التالية (من منشور شبكة البيانات لمدونة Martin Fowler) حالة نهائية محتملة. في هذا المخطط ، يمكنك رؤية المجالات المختلفة مع خطوط الأنابيب الخاصة بها ومنصة البيانات المستعرضة.

مخطط شبكة البيانات من مدونة مارتن فاولر

حسنًا ، حسنًا ، حسنًا ... أفهم المفهوم وكل شيء آخر ، ولكن ... ماذا عن الاستراتيجية لتحقيقه؟

حسنًا ، أولاً وقبل كل شيء ، نحن نحب الكود ، ولسنوات ونحن نقوم بتحسين أفضل الممارسات في الكود وأفضل المنهجيات وجميع التقنيات التي يحتويها XP. لذا ، دعنا نستخدم الكود أيضًا في البيانات وجميع أفضل الممارسات التي نعرفها.

يمكننا استخدام الكثير من الأدوات والأطر لجعل خطوط البيانات الخاصة بنا مع التعليمات البرمجية. في فريق الهندسة في Packlink ، نحن نحب برنامج شركاء Google المعتمدون ، لذا في هذا المنشور سأشرح هذه الأشياء باستخدام Airflow لأن نظام Google الأساسي يحتوي على نقرة وتشغيل وإدارة تنسيق سير العمل المُدارة بالكامل والمضمنة في Airflow: Cloud Composer.

تذكر أن النقاط المهمة (مثلما هو الحال في الخدمات هي نفسها إذا كنت تستخدم CircleCI ، Jenkins ، إلخ) هي الأفكار ، فالأداة ليست سوى وسيلة لتحقيق أهدافنا. الأدوات / الأطر الجيدة الأخرى هي Metaflow ، Luigi ، محافظ ، Pinball. في هذه اللحظة ، تقوم كل شركة ببناء إطارها الخاص بها وكلها مختلفة ، ولكن الإصرار على أن الفكرة هي الفكرة وأن كل منها هو رمز. في الأقسام التالية سأمر:

  • نمط الخانق: كاستراتيجية لتحقيقه.
  • خط أنابيب البيانات: كيف يجب أن يكون خط الأنابيب هذا؟
  • الرمز: الرمز المختبر لكتابة خط الأنابيب.

نمط الخانق

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

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

هذا النمط جيد للاستخدام لأنه ؛ لدينا الكثير من الأشياء تسير بشكل جيد ونريد القيام بهذا العمل بعقلية مفيدة ورشيقة في هذه الخطوات الثلاث:

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

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

خط البيانات

النقاط الأساسية التي يجب أن يحتوي عليها خط الأنابيب هذا هي:

  • معالجة البيانات. لا تتم مشاركة جميع البيانات التي تنتجها الخدمات ولا تتم جميع البيانات التي يتم إنتاجها بشكل خام. في بعض الأحيان نحتاج إلى إجراء بعض التحولات. سنفعل بالرمز ، وكما أقول دائمًا ، الرمز هو رمز ، لذا نحتاج إلى تطبيق أفضل الممارسات دائمًا.
  • فحص المخطط. إذا أردنا ضمان جودة بياناتنا ، فإننا بحاجة إلى استخدام مخطط عندما نقوم بمشاركته مع أجزاء أخرى من الشركة (الخدمات ، التحليلات ، إلخ). على سبيل المثال ، لدينا عمر الأشخاص الذين نريد التأكد من أن هذه القيمة هي عدد صحيح وأن القيمة القصوى هي ... 150؟ يمكنك استخدام أنظمة تسلسل البيانات المختلفة لتحقيق ذلك ، أوصي بمخازن بروتوكول أو Avro. مع ذلك ، يعرف كل من المنتج والمستهلك معنى كل نقطة بيانات.
  • تصدير مجموعات البيانات الثابتة كمنتجات. كل خدمة مسؤولة عن مشاركة المعلومات مع المنظمة. الخيار الأمثل هو مشاركة مجموعات البيانات الثابتة التي تم إصدارها عبر وسيط رسائل مثل Kafka أو pub / sub. يمكن قراءة منشور جيد يتحدث عن مشاركة البيانات في الأنظمة الموزعة هنا. يرجى ملاحظة ما يلي: يجب أن تكون البيانات ، كما تعلمنا أيضًا في البرمجة الوظيفية ، غير قابلة للتغيير كما أنها تسمح لنا بالحصول على السجل بأكمله وإجراء عمليات التجميع اللازمة لاحقًا دون حفظها.
  • إصدار البيانات / البيانات كرمز. كما وضعنا في التعليمات البرمجية ، نحن بحاجة إلى إصدار مجموعات البيانات الخاصة بنا ، وأكثر من ذلك ، نريد البيانات كرموز. لها بعض الفوائد: يمكننا إعادة إنتاج الأخطاء بسهولة ، واستخدام مجموعات البيانات في اختباراتنا وخطوط الأنابيب لدينا ، والعديد من الفوائد في التعلم الآلي (مزيد من المعلومات هنا) وبالتأكيد جميع الأشياء الجيدة التي تحتوي عليها الشفرة. DVC ، نظام التحكم في إصدار البيانات والنماذج القائم في git ، هو الحل ، بالنسبة لي ، أحد أفضل الأدوات في عالم البيانات.
الرسوم البيانية DVC حول البيانات والنماذج كرمز وتبادل البيانات
  • حوكمة البيانات والنسب. هذه واحدة من أهم النقاط بالنسبة لي في خط البيانات إذا أردنا كسر كتلة البيانات. بادئ ذي بدء ، نحتاج في منصة البيانات إلى أداة لحفظها. هناك بعض البدائل الجيدة ، ولكني سأوصي بثنين فقط: Lyft Ammundsen وإذا كنت تستخدم GCP ، كتالوج البيانات. كلاهما لديه اكتشاف تلقائي للبيانات. المهم هنا ليس الأداة ، بل هو المفهوم أيضًا. يجب أن نحفظ في خطوط الأنابيب لدينا وصف البيانات التي نشاركها والبيانات الوصفية عبر واجهة برمجة التطبيقات إلى أداتنا ، كما تفعل هذه المكتبة في كتالوج البيانات ووضع ما يلزم للحصول على نسب صحيح للبيانات. وبفضل ذلك ، سيعرف الجميع أين هي البيانات ، ومن هو المالك ، وكيف هي وماذا تعني كل قيمة.
إدارة البيانات مع Lyft Ammundsen
  • الملاحظة. نحن بحاجة إلى فهم كيفية عمل نظامنا ، وسنفعل ذلك بالعمل فوق ثلاثة أنواع من المستويات: مستوى البنية التحتية وأحداث مستوى الوظيفة ومستوى البيانات. قم بإنشاء لوحة معلومات بمعلومات واضحة ومفيدة. هذه هي النقطة الرئيسية. نحن نقوم بأنظمة معقدة لذا لا نحتاج إلى لوحة تحكم بها سوى المعلومات الأكثر أهمية لفهم بسهولة إذا كانت أنظمتنا تعمل بشكل صحيح. مع ذلك ، عندما تحدث السفينة ، وسوف تكون أول من يكتشفها. الخطأ النموذجي في البيانات هو نسيان الفشل الصامت. إذا توقف المصدر عن إنتاج بيانات جديدة ، فنحن بحاجة إلى أن نكون على دراية بذلك مبكرًا لأنه ربما تعتمد نماذجنا أو خدماتنا أو أعمالنا الأخرى على هذه البيانات بنسبة عالية. علاوة على ذلك ، بفضل خط بيانات جيد ، يمكننا تحقيق اكتشاف شاذ آليًا للأعطال ، على سبيل المثال ، عندما يكون هناك عدد أقل من الأحداث في فترة زمنية.
  • جودة البيانات. الاختبارات والاختبارات والمزيد من الاختبارات. نحن الاختبارات. بالإضافة إلى الاختبارات في التعليمات البرمجية ، نحتاج إلى بعض الاختبارات بالبيانات. على سبيل المثال ، ما رأيك في اختبار في خط الأنابيب هذا يقدم لنا المشورة إذا كنا نقدم طلبات أكثر من المنتجات؟ يبدو منطقيًا ومفيدًا ، أليس كذلك؟
  • احصل على تدريب على البيانات. إذا كنت تعمل أيضًا مع التعلم الآلي ولأننا نريد جعل حياة علماء البيانات لدينا ، فأنت بحاجة إلى الحصول على بيانات التدريب. هنا يوجد الكثير من النقاط الحاسمة: أخذ عينات لأهمية الوزن ، وقطع البيانات إلى شرائح أصغر ، وإخفاء هوية جميع البيانات الحساسة ... مزيد من المعلومات هنا.
  • نحن نعتني بعملائنا ، لذلك علينا الاهتمام ببياناتهم ، لذلك نحتاج إلى الكثير من الأمان في جزء البيانات هذا. من المهم إخفاء هوية جميع البيانات الحساسة إذا أردنا العمل معها.

نعم خوان جميل جدا ، ولكن ...

البرمجة المتطرفة للإنقاذ

بادئ ذي بدء ، سنستمر في توجيه كل شيء كرمز ، لذلك خط أنابيب البيانات أيضًا.

مع نهج الخانق ، وفي التكرار الأول ، يعيد المنطقي إعادة استخدام جزء من المنطق الذي فعلناه من قبل ، وسنقوم بذلك مع TDD ، كما يقول XP وحسنا العام.

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

إذا كنت تعرف Airflow ، فأنت تعلم أن هناك عوامل تشغيل متعددة (python_operator و http_operator و bash_operator و mysql_operator وما إلى ذلك.) اعتمادًا على نوع الرمز الذي تريد وضعه في كل DAG. هؤلاء المشغلون لديهم بعض المشاكل. الأسوأ بالنسبة لي هو الطريقة المعقدة والقبيحة لاختبارها ، علاوة على ذلك ، إذا كنت تستخدم Python ، فستستمع إلى شيء حول فوضى التبعية. مع هؤلاء المشغلين تحتاج إلى تثبيت كل التبعيات في كل المشروع ، ولا تحتاج إلى إصدار مختلف منهم واستخدام نفس الإصدار من Python. علاوة على ذلك ، نحن شركة حديثة ونريد أن يكون لدينا نظام متعدد اللغات وتجربة لغات جديدة!

حل بلدي هو استخدام ، بينما نقوم بعمل نمط غريب ، مشغل عامل الميناء ، kubernetes_pod_operator. إذا كنت تستخدم Google Composer ، فيجب عليك استخدام Kubernetes واحدًا وعدم استخدام GKEContainerOperator أبدًا لأن ذلك قد يؤدي إلى منافسة الموارد. باستخدام هذه العوامل ، سيتم وضع الكود الذي سيتم تنفيذه في كل DAG في حاوية (يمكن أن يكون هناك كود بيثون ، سكالا ، جافا ، عمليات الشعاع ، عمليات سبارك ، تيارات كافكا ، تلخيص ، كل ما يمكنك تخيله ...) ، حتى تتمكن من استخدم TDD الخاص بك باللغة التي تريدها ويمكنك إعادة استخدام بعض التعليمات البرمجية القديمة الخاصة بك. يتم اختبار الوحدة واختبار التكامل ... تقريبًا!

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

لذا ، مثلما نفعل TDD ، تختبر الوحدة أولاً:

هذا هو رمز إنتاج خط الأنابيب الذي قمنا بإنشائه باستخدام TDD:

لكن اختبار الوحدة ليس كافيًا ، في Packlink Engineering تعرف أن الاختبارات هي أهم جزء من الشفرة. لذا ، دعنا نذهب مع المزيد من الاختبارات.

حان الوقت الآن لاختبارات التكامل في جزء تدفق الهواء (تحتوي الحاويات على وحدتها واختبارات التكامل). من خلال هذا النهج ، ترتبط اختبارات التكامل هنا بتكوين Airflow و XComs ، وهي باختصار الطريقة في تدفق الهواء التي يتعين علينا مشاركتها في المعلومات بين المهام في DAG. في مثالنا ، نحتاج إلى اختبار أن المعلومات المحفوظة في packlink_hello_task هي تلك التي التقطتها stream_data_task:

الجزء الأخير من اختبار الهرم هو اختبارات e2e. في الهرم ، تكون اختبارات e2e دائمًا على الجانب الأصغر لأنها باهظة الثمن. في تدفق الهواء ربما أكثر. يمكنك مشاهدة مثال جيد هنا: https://github.com/chandulal/airflow-testing. لم أستطع فعلها بشكل أفضل.

الاستنتاجات

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

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

الموارد والروابط