شعار زيفيرنت

لماذا تحتاج ETL إلى المصدر المفتوح لمعالجة الذيل الطويل من عمليات التكامل

التاريخ:

انقر لمعرفة المزيد حول المؤلف المشارك شريف ندا.

انقر لمعرفة المزيد حول المؤلف المشارك دافين شيا.

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

الوضع الحالي غير القابل للتطوير

كانت 80 مقابلة على الأقل من 200 مقابلة مع مستخدمي تقنية ETL الحالية ، مثل Fivetran و StitchData و Matillion. وجدنا أن كل واحد منهم كان يقوم أيضًا ببناء وصيانة الموصلات الخاصة به ، على الرغم من أنهم كانوا يستخدمون حل ETL (أو حل ELT - للبساطة ، سنستخدم مصطلح ETL فقط). لماذا ا؟ 

وجدنا سببين: 

  1. تغطية غير كاملة للموصلات
  2. احتكاك كبير حول نسخ قاعدة البيانات

عدم القدرة على تغطية جميع احتياجات الموصل

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

مثال للسياق: Fivetran موجود منذ ثماني سنوات ويدعم 150 وصلة. ومع ذلك ، يوجد في قطاعين فقط - martech و adtech - أكثر من 10,000 موصل محتمل. 

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

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

عدم القدرة على معالجة حالة استخدام النسخ المتماثل لقاعدة البيانات

تقوم معظم الشركات بتخزين البيانات في قواعد البيانات. كشفت المقابلات التي أجريناها عن مشكلتين مهمتين مع موصلات قاعدة البيانات التي توفرها ETL الحالية. 

  1. التسعير على أساس الحجم: قواعد البيانات ضخمة وتخدم كميات متزايدة من البيانات. تعد قاعدة البيانات التي تحتوي على ملايين الصفوف ، بهدف خدمة مئات الملايين من الصفوف ، مشهدًا مألوفًا. المشكلة مع حلول ETL الحالية هي تسعيرها على أساس الحجم. من السهل على الموظف نسخ قاعدة بيانات متعددة الملايين من الصفوف بنقرة واحدة. وهذه النقرة البسيطة قد تكلف بضعة آلاف من الدولارات! 
  2. خصوصية البيانات: مع مخاوف اليوم انتهت خصوصية والأمن ، تولي الشركات أهمية متزايدة للتحكم في بياناتها. غالبًا ما تنتهي بنية حلول ETL الحالية بسحب البيانات من السحابة الخاصة للشركة. تمنع عروض المصدر المغلق الشركات من الفحص الدقيق لكود / أنظمة ETL الأساسية. انخفاض الرؤية يعني ثقة أقل.

تشرح هاتان النقطتان سبب انتهاء الشركات ببناء خطوط أنابيب إضافية لنسخ قواعد البيانات الداخلية.

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

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

لماذا المصدر المفتوح هو السبيل الوحيد للمضي قدمًا

المصدر المفتوح يعالج العديد من النقاط التي أثيرت أعلاه. هذا هو ما تعطينا المصدر المفتوح.

  • الحق في التخصيص: يعد الوصول إلى الكود والقدرة على تعديله وفقًا لاحتياجاتك امتيازًا يجلبه المصدر المفتوح. على سبيل المثال ، ماذا لو كان موصل Salesforce يفتقد بعض البيانات التي تحتاجها؟ مع المصدر المفتوح ، يكون هذا التغيير سهلاً مثل تقديم تغيير رمز. لا مزيد من الخيوط الطويلة على تذاكر الدعم!
  • معالجة الذيل الطويل للموصلات: لم تعد بحاجة إلى إقناع موفر ETL مملوك أن الموصل الذي تحتاجه يستحق البناء. إذا كنت بحاجة إلى موصل أسرع من تطوير النظام الأساسي له ، فيمكنك إنشاؤه بنفسك وصيانته بمساعدة مجتمع مستخدم كبير.
  • تكامل أوسع مع أدوات البيانات ومهام سير العمل: نظرًا لأن المنتج مفتوح المصدر يجب أن يدعم مجموعة متنوعة من التكديس وسير العمل للتنسيق والنشر والاستضافة وما إلى ذلك ، فمن المرجح أن تجد دعمًا خارج الصندوق لمكدس البيانات وسير العمل (قائم على واجهة المستخدم ، القائم على API ، المستند إلى CLI ، وما إلى ذلك) مع مجتمع مفتوح المصدر. يساهم المجتمع ببعض منهم ، مثل مشغل Airflow مفتوح المصدر في Airbyte. لكي نكون منصفين ، يمكنك نظريًا القيام بذلك باستخدام نهج مغلق المصدر ، ولكن من المحتمل أن تحتاج إلى بناء الكثير من الأدوات من البداية.
  • استقلالية التصحيح: إذا واجهت أي مشكلات في الموصل ، فلن تحتاج إلى انتظار فريق دعم العملاء ليعود إليك أو أن يكون الإصلاح الخاص بك على رأس أولويات شركة تابعة لجهة خارجية. يمكنك إصلاح المشكلة بنفسك.
  • الامتثال للأمان والخصوصية الجاهزين: إذا كان المشروع مفتوح المصدر مفتوحًا بدرجة كافية (MIT ، Apache 2.0 ، إلخ) ، يمكن لأي فريق أن يعالج احتياجات التكامل الخاصة بهم مباشرة عن طريق نشر الكود مفتوح المصدر في بنيتهم ​​التحتية.

ضرورة وجود مجموعة أدوات تطوير الموصل

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

ضع في اعتبارك ، على سبيل المثال ، برنامج نصي يسحب البيانات من واجهة برمجة تطبيقات REST. 

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

أولاً ، هناك مصادقة ، يمكن أن تكون بسيطة مثل اسم المستخدم / كلمة المرور أو معقدة مثل تنفيذ تدفق OAuth بالكامل (وتخزين بيانات الاعتماد هذه وإدارتها بشكل آمن). 

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

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

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

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

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

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

كيف تبدو مجموعة تطوير الموصل

دعنا نلقي نظرة مرة أخرى على العمل الذي ينطوي عليه بناء موصل ، ولكن من منظور مختلف.

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

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

التجريدات كطبقات البصل

يؤدي تعظيم العمل ذي الرافعة المالية العالية إلى بناء العمارة الخاصة بك بهيكل البصل:

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

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

بعد ذلك ، بالنسبة للمصادر ، لديك أنواع مختلفة مثل قواعد البيانات والموصلات القائمة على واجهة برمجة تطبيقات HTTP. يمكن تقسيم موصلات HTTP إلى REST و GraphQL و SOAP ، بينما قد تنقسم قواعد البيانات إلى قواعد بيانات علائقية و NoSQL ورسومات. قد تنقسم الوجهات إلى مستودعات وبحيرات بيانات وواجهات برمجة تطبيقات (لعكس ELT). 

CDK هو الإطار لتلك الأفكار التجريدية!

ما هو متاح بالفعل

لا يزال CDK لشركتنا في أيامه الأولى. اليوم ، يأتي إطار العمل بالميزات التالية: 

  1. إطار عمل Python لكتابة موصلات المصدر 
  2. تنفيذ عام لتطوير الموصلات بسرعة لواجهات برمجة تطبيقات HTTP
  3. مجموعة اختبار لاختبار التوافق مع بروتوكول Airbyte ومسارات الكود السعيدة 
  4. منشئ رمز لتطوير التمهيد وتعبئة الموصل الخاص بك

في النهاية ، يتيح CDK بناء موصلات قوية وكاملة الميزات في غضون ساعتين مقابل يومين سابقين. 

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

خاتمة - المستقبل أمامنا 

ألن يكون من الرائع تقليل الوقت اللازم لإنشاء موصل جديد إلى 10 دقائق ، والتوسع ليشمل المزيد والمزيد من مجموعات عمليات الدمج الممكنة؟ كيف هذا لطلقة على القمر! 

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

كوينسمارت. Beste Bitcoin-Börse في أوروبا
المصدر: https://www.dataversity.net/why-etl-needs-open-source-to-address-the-long-tail-of-integrations/

بقعة_صورة

أحدث المعلومات الاستخباراتية

بقعة_صورة