هذا هو أول كتاب باللغة الروسية أصلاً يتم فيه فحص أسرار الحياة الواقعية لمعالجة البيانات الضخمة في السحاب بأمثلة حقيقية.
وينصب التركيز على حلول Microsoft Azure و AWS. يتم النظر في جميع مراحل العمل - الحصول على البيانات المعدة للمعالجة في السحابة ، باستخدام التخزين السحابي ، وأدوات تحليل البيانات السحابية. يتم إيلاء اهتمام خاص لخدمات SAAS ، ويتم توضيح مزايا التقنيات السحابية مقارنة بالحلول التي يتم نشرها على خوادم مخصصة أو أجهزة افتراضية.
تم تصميم الكتاب لجمهور عريض وسيكون بمثابة مورد ممتاز لتطوير Azure و Docker وغيرها من التقنيات التي لا غنى عنها ، والتي بدونها لا يمكن التفكير في المشاريع الحديثة.
ندعوك لقراءة فقرة "التحميل المباشر لبيانات التدفق"
10.1. العمارة العامة
في الفصل السابق ، قمنا بفحص الوضع عندما يتعين على العديد من تطبيقات العميل إرسال عدد كبير من الرسائل التي تحتاج إلى معالجة ديناميكية ، ووضعها في المستودع ثم معالجتها مرة أخرى فيه. في الوقت نفسه ، من الضروري أن تكون قادرًا على تغيير منطق معالجة البيانات وتدفق التخزين دون اللجوء إلى تغيير رمز العميل. وأخيرًا ، من وجهة نظر أسباب الأمان ، يجب أن يكون للعملاء الحق في القيام بشيء واحد فقط - إرسال الرسائل أو تلقيها ، ولكن لا يمكن قراءة البيانات أو حذف قواعد البيانات بأي حال من الأحوال ، ويجب ألا يكون لديهم حقوق مباشرة لكتابة هذه البيانات.
هذه المهام شائعة جدًا في الأنظمة التي تعمل مع أجهزة إنترنت الأشياء المتصلة عبر اتصال الإنترنت ، وكذلك في أنظمة تحليل السجلات عبر الإنترنت. بالإضافة إلى المتطلبات المذكورة أعلاه لخدمتنا المخصصة ، هناك متطلبان آخران يتعلقان بخصائص "إنترنت الأشياء" ولضمان معالجة رسالة موثوقة. بادئ ذي بدء ، يجب أن يكون بروتوكول التفاعل بين العميل ومستقبل الخدمة بسيطًا جدًا بحيث يمكن تنفيذه على جهاز ذي إمكانات حوسبة محدودة وذاكرة محدودة للغاية (على سبيل المثال ، Arduino و Intel Edison و STM32 Discovery وغيرها من الأنظمة الأساسية "غير الملائمة" ، مثل كما كان من قبل RaspberryPi). المتطلب التالي هو تسليم رسالة موثوقة بغض النظر عن الفشل المحتمل لخدمات المعالجة. هذا مطلب أقوى من متطلبات الموثوقية العالية. في الواقع ، لضمان الموثوقية الإجمالية للنظام بأكمله ، من الضروري أن تكون موثوقية جميع مكوناته عالية بما فيه الكفاية وأن إضافة مكون جديد لا يؤدي إلى زيادة ملحوظة في عدد الأعطال. بالإضافة إلى الفشل في البنية التحتية السحابية ، قد يحدث خطأ في الخدمة التي أنشأها المستخدم. وحتى ذلك الحين ، يجب معالجة الرسالة بمجرد استعادة خدمة المستخدم. للقيام بذلك ، يجب أن تقوم خدمة استقبال تدفق الرسائل بتخزين الرسالة بشكل موثوق حتى تتم معالجتها أو حتى انتهاء مدة صلاحيتها (يعد ذلك ضروريًا لمنع تجاوز الذاكرة أثناء تدفق الرسائل المستمر). خدمة مع هذه الخصائص تسمى محور الأحداث. بالنسبة لأجهزة إنترنت الأشياء ، هناك محاور متخصصة (IoT Hub) ، والتي تحتوي على عدد من الخصائص الأخرى التي تعتبر مهمة جدًا للاستخدام مع أجهزة إنترنت الأشياء (على سبيل المثال ، الاتصال ثنائي الاتجاه من نقطة واحدة ، وتوجيه الرسائل المضمنة ، و "مضاعفات رقمية" للجهاز وعدد من آخرون). ومع ذلك ، لا تزال هذه الخدمات متخصصة ، ولن نأخذها بعين الاعتبار بالتفصيل.
قبل الانتقال إلى مفهوم تركيز الرسالة ، دعونا ننتقل إلى الأفكار التي تقوم عليها.
لنفترض أن لدينا مصدر رسالة (على سبيل المثال ، طلبات من عميل) وخدمة يجب أن تتعامل معها. تستغرق معالجة طلب واحد وقتًا وتتطلب موارد حسابية (وحدة المعالجة المركزية ، والذاكرة ، و IOPS). علاوة على ذلك ، أثناء معالجة طلب واحد ، لا يمكن معالجة الطلبات المتبقية. حتى لا تتجمد تطبيقات العميل أثناء انتظار إصدار الخدمة ، من الضروري فصلها بمساعدة خدمة إضافية تكون مسؤولة عن تخزين الرسائل أثناء انتظار المعالجة أثناء وجودها في قائمة الانتظار. هذا الفصل ضروري أيضًا لزيادة الموثوقية الإجمالية للنظام. في الواقع ، يرسل العميل رسالة إلى النظام ، ولكن قد "تسقط" خدمة المعالجة ، ولكن لا يجب أن تفقد الرسالة ، يجب تخزينها في خدمة أكثر موثوقية من خدمة المعالجة. أبسط نسخة من هذه الخدمة تسمى قائمة الانتظار (الشكل 10.1).
تعمل خدمة قائمة الانتظار على النحو التالي: يعرف العميل عنوان URL لقائمة الانتظار ولديه مفاتيح وصول إليه. باستخدام SDK أو API لقائمة الانتظار ، يضع العميل رسالة تحتوي على الطابع الزمني والمعرف ونص الرسالة مع حمولة بتنسيق JSON أو XML أو تنسيق ثنائي.
يتضمن رمز برنامج الخدمة دورة "تستمع" إلى قائمة الانتظار ، وتسترد الرسالة التالية في كل خطوة ، وإذا كانت هناك رسالة في قائمة الانتظار ، يتم استخراجها ومعالجتها. إذا نجحت الخدمة في معالجة الرسالة ، فستتم إزالتها من قائمة الانتظار. في حالة حدوث خطأ أثناء المعالجة ، لا يتم حذفه ويمكن معالجته مرة أخرى عند تشغيل إصدار جديد من الخدمة ، مع الرمز الذي تم تصحيحه. تم تصميم قائمة الانتظار لمزامنة عميل واحد (أو مجموعة من العملاء المتشابهين) وخدمة معالجة واحدة بالضبط (على الرغم من أنه يمكن تحديد موقع الأخير في مجموعة خوادم أو في مزرعة خوادم). تتضمن خدمات السحابة في قائمة انتظار Azure Storage Queue و Azure Service Bus Queue و AWS SQS. تتضمن الخدمات المستضافة على الأجهزة الافتراضية RabbitMQ و ZeroMQ و MSMQ و IBM MQ ، إلخ.
تضمن خدمات الانتظار المختلفة أنواعاً مختلفة من تسليم الرسائل:
- تسليم رسالة مرة واحدة على الأقل
- التسليم لمرة واحدة بدقة ؛
- تسليم الرسائل مع الحفاظ على النظام ؛
- تسليم الرسائل دون الحفاظ على النظام.
توفر قائمة الانتظار تسليمًا موثوقًا به للرسائل من مصدر واحد إلى خدمة معالجة واحدة ، أي التفاعل بين شخصين. ولكن ماذا لو كان من الضروري توفير توصيل الرسائل لعدة خدمات؟ في هذه الحالة ، تحتاج إلى استخدام خدمة تسمى "الموضوع" (الموضوع) (الشكل 10.2).
عنصر مهم في هذه العمارة هو "الاشتراكات". هذا هو المسار المسجل في القسم الذي يتم إرسال الرسالة من خلاله. يتم نشر الرسائل في الموضوع من قبل العميل وتحويلها إلى أحد الاشتراكات ، والتي يتم استخراجها منها بواسطة إحدى الخدمات ومعالجتها بواسطتها. توفر الموضوعات بنية تفاعل خدمة العملاء واحد لواحد. تتضمن أمثلة هذه الخدمات موضوع ناقل خدمة Azure و AWS SNS.
لنفترض الآن أن هناك عددًا كبيرًا من العملاء غير المتجانسين الذين يحتاجون إلى إرسال العديد من الرسائل إلى الخدمات المختلفة ، أي أننا بحاجة إلى بناء نظام تفاعل بين أطراف كثيرة. بالطبع ، يمكن بناء مثل هذه البنية باستخدام عدة أقسام ، ولكن هذا البناء غير قابل للتطوير ويتطلب جهدًا للإدارة والمراقبة. ومع ذلك ، هناك خدمات منفصلة - مركزات الرسائل (الشكل 10.3).
يقبل المحور الرسائل الواردة من العديد من العملاء. يمكن لجميع العملاء إرسال رسائل إلى نقطة نهاية خدمة مشتركة واحدة أو الاتصال بشكل منفصل بنقاط نهاية مختلفة من خلال مفاتيح خاصة. تسمح لك هذه المفاتيح بإدارة العملاء بمرونة: قم بفصل بعضها ، وتوصيل عملاء جدد ، وما إلى ذلك. داخل المحور توجد أيضًا أقسام. ولكن في هذه الحالة ، يمكن توزيعها بين جميع العملاء من أجل زيادة الإنتاجية (جولة روبن - "مع الإضافة الدورية") أو يمكن للعميل نشر الرسائل في أحد الأقسام. من ناحية أخرى ، يتم دمج خدمات المعالجة في مجموعات المستهلكين. يمكن توصيل خدمة أو عدة خدمات بمجموعة واحدة. وبالتالي ، فإن مكثف الرسائل هو الخدمة الأكثر مرونة التي يمكن تكوينها كقائمة انتظار أو قسم أو مجموعة من قوائم الانتظار أو مجموعة من الأقسام. بشكل عام ، يوفر مُركِّز الرسائل علاقة كثير إلى كثير بين العملاء والخدمات. تتضمن هذه المحاور Apache Kafka و Azure Event Hub و AWS Kinesis Stream.
قبل النظر في خدمات PaaS المستندة إلى السحابة ، سنولي اهتمامًا لخدمة قوية جدًا ومعروفة - Apache Kafka. في البيئات السحابية ، يمكن الوصول إليه كتوزيع يتم نشره مباشرةً إلى مجموعة آلة افتراضية أو باستخدام خدمة HDInsight. لذا ، فإن Apache Kafka هي خدمة توفر الميزات التالية:
- النشر والاشتراك في تدفق الرسائل
- تخزين موثوق للرسائل ؛
- تطبيق خدمات معالجة رسائل دفق الطرف الثالث.
جسديا ، يعمل كافكا في مجموعة من خادم واحد أو أكثر. يوفر Kafka واجهة برمجة تطبيقات للتفاعل مع العملاء الخارجيين (الشكل 10.4).
ضع في اعتبارك واجهات برمجة التطبيقات هذه بالترتيب.
- تسمح واجهات برمجة تطبيقات البائع لتطبيقات العميل بنشر تدفقات الرسائل في موضوع واحد أو أكثر من موضوعات Kafka.
- تمنح واجهات برمجة تطبيقات المستهلك لتطبيقات العميل القدرة على الاشتراك في موضوع واحد أو أكثر ومعالجة تدفقات الرسائل التي تقدمها الموضوعات للعملاء.
- تسمح واجهات برمجة تطبيقات معالج الدفق للتطبيقات بالتفاعل مع مجموعة Kafka كمعالج دفق. قد تكون مصادر معالج واحد موضوع واحد أو أكثر. في هذه الحالة ، يتم أيضًا وضع الرسائل التي تمت معالجتها في موضوع واحد أو أكثر.
- تساعد واجهات برمجة تطبيقات الموصل على ربط مصادر البيانات الخارجية (على سبيل المثال ، RDB) كمصادر للرسائل (على سبيل المثال ، من الممكن اعتراض أحداث تغيير البيانات في قاعدة البيانات) وكمستقبلات.
في كافكا ، يتم التفاعل بين العملاء والمجموعة عبر TCP ، والذي يتم تسهيله من خلال حزم SDK الحالية للعديد من لغات البرمجة ، بما في ذلك .Net. لكن لغات SDK الأساسية هي Java و Scala.
في الكتلة ، يحدث تخزين تدفقات الرسائل (في مصطلحات كافكا المشار إليها أيضًا باسم الإدخالات) منطقيًا في كائنات تسمى الموضوعات (الشكل 10.5). يتكون كل سجل من مفتاح وقيمة وطابع زمني. في الجوهر ، الموضوع هو سلسلة من السجلات (الرسائل) التي تم نشرها من قبل العملاء. تدعم مواضيع كافكا من 0 إلى عدة مشتركين. يتم تمثيل كل موضوع فعليًا كسجل مقسم. كل قسم عبارة عن تسلسل منظم من السجلات ، تضاف إليه باستمرار السجلات الجديدة التي تصل إلى مدخلات كافكا.
يتطابق كل إدخال في القسم مع رقم في التسلسل ، يسمى أيضًا الإزاحة ، والذي يحدد هذه الرسالة بشكل فريد في التسلسل. على عكس قائمة الانتظار ، يحذف Kafka الرسالة ليس بعد معالجة الخدمة ، ولكن بعد عمر الرسائل. هذه خاصية مهمة للغاية ، حيث توفر القدرة على القراءة من موضوع واحد إلى مستهلكين مختلفين. علاوة على ذلك ، يرتبط التحيز بكل مستهلك (الشكل 10.6). وكل فعل للقراءة يؤدي فقط إلى زيادة القيمة لكل عميل على حدة ويتم تحديده بدقة من قبل العميل.
في الحالة العادية ، يزداد هذا الإزاحة بمقدار واحد بعد قراءة رسالة واحدة من الموضوع بنجاح. ولكن إذا لزم الأمر ، يمكن للعميل تغيير هذا الإزاحة وتكرار عملية القراءة.
استخدام مفهوم الأقسام له الأهداف التالية.
أولاً ، توفر الأقسام القدرة على قياس المواضيع عندما لا يتناسب موضوع واحد مع نفس العقدة. في نفس الوقت ، يحتوي كل قسم على عقدة بادئة واحدة (لا تخلط بينها وبين عقدة الرأس للمجموعة بأكملها) وعُقدة صفر أو عدة عقد تابعة. العقدة الرئيسية مسؤولة عن معالجة عمليات القراءة / الكتابة ، في حين أن المتابعين هم نسخها السلبية. إذا فشلت العقدة الرئيسية ، فستصبح إحدى العقد اللاحقة هي العقدة الرئيسية تلقائيًا. كل عقدة عنقودية هي المقدمة لبعض الأقسام ومتابعة للبعض الآخر. ثانيًا ، يزيد هذا النسخ من أداء القراءة بسبب إمكانية عمليات القراءة المتوازية.
يمكن للمنتج وضع الرسالة في أي موضوع من اختياره بشكل صريح أو في وضع روبن مستدير ضمنيًا (أي ، مع تعبئة موحدة). يتحد المستهلكون في ما يسمى مجموعات المستهلكين ، ويتم تسليم كل رسالة منشورة في الموضوع إلى عميل واحد في كل مجموعة من المستهلكين. يمكن استضافة العملاء في هذه الحالة فعليًا على خادم واحد أو أكثر / خوادم افتراضية. بمزيد من التفصيل ، تسليم الرسالة كما يلي. لجميع العملاء الذين ينتمون إلى نفس مجموعة المستهلكين ، يمكن توزيع الرسائل بين العملاء من أجل تحسين الحمل. إذا كان العملاء ينتمون إلى مجموعات المستهلكين المختلفة ، فسيتم إرسال كل رسالة إلى كل مجموعة. يظهر فصل الرسائل من الأقسام حسب مجموعات المستهلكين المختلفة في الشكل. 10.7.
الآن سأصف بإيجاز المعلمات الرئيسية لتسليم الرسائل وتخزينها التي تضمنها كافكا.
- ستتم إضافة الرسائل المرسلة من قبل الشركة المصنعة إلى موضوع معين بدقة بالترتيب الذي تم إرسالها به.
- يرى العميل ترتيب الرسائل في الموضوع الذي تم استلامه عند حفظ الرسائل. ونتيجة لذلك ، يتم تسليم الرسائل من المنتج إلى المستهلك بدقة حسب الترتيب الذي تم استلامها به.
- النسخ المتماثل N- أضعاف للموضوع يضمن استقرار الموضوع لفشل عقد N - 1 دون فقدان الأداء.
لذلك ، يمكن استخدام خدمة Apache Kafka في الأوضاع التالية.
- الخدمة - وسيط الرسائل (قائمة الانتظار) أو خدمة النشر - الاشتراك في الرسالة (الموضوع). في الواقع ، تستند كافكا على مجموعة من المواضيع التي يمكن تحويلها إلى قائمة انتظار بمشترك واحد. (يجب أن نتذكر: على عكس الخدمات المعتادة لوسطاء الرسائل ، المبنية على مبدأ قوائم الانتظار ، في رسائل كافكا يتم حذفها فقط بعد انتهاء مدة صلاحيتها ، بينما يقوم الوسطاء بتطبيق مبدأ Peek-Delete ، أي الاسترداد والحذف بعد المعالجة الناجحة. ) يلخص مبدأ مجموعات المستهلكين هذين المفهومين ، والقدرة على نشر الرسائل في جميع المواضيع مع توزيع روبن المستدير يجعل Kafka وسيط رسائل متعدد الأوضاع العالمي.
- خدمة تدفق تحليل الرسالة. هذا ممكن بفضل واجهة برمجة التطبيقات لمعالجات الدفق المضمنة في Kafka ، والتي تسمح لك ببناء أنظمة معقدة تم إنشاؤها وفقًا لمبدأ الحدث مدفوعًا بالخدمات التي تقوم بتصفية الرسائل أو الرد عليها ، بالإضافة إلى الخدمات التي تجمع الرسائل.
كل هذه الخصائص تجعل من الممكن استخدام Kafka كمكون رئيسي لمنصة تعمل مع تدفق البيانات ولديها قدرات كبيرة لبناء أنظمة معالجة الرسائل المعقدة. ولكن في نفس الوقت ، فإن كافكا معقدة للغاية من حيث نشر وتكوين مجموعة من العقد المتعددة ، الأمر الذي يتطلب جهدًا إداريًا كبيرًا. ولكن ، من ناحية أخرى ، نظرًا لأن الأفكار الكامنة في كافكا مناسبة تمامًا لأنظمة البناء ، وتدفق الرسائل وتلقي الرسائل ، فإن مزودي الخدمات السحابية يقدمون خدمات PaaS التي تنفذ هذه الأفكار وإخفاء جميع الصعوبات في بناء وإدارة مجموعة كافكا. ولكن نظرًا لأن هذه الخدمات لها عدد من القيود من حيث التخصيص والتوسع بما يتجاوز الحدود المحددة للخدمات ، فإن موفري السحابة يقدمون خدمات IaaS / PaaS خاصة للنشر الفعلي لكافكا في مجموعة آلة افتراضية. في هذه الحالة ، يتمتع المستخدم بحرية كاملة للتكوين والتوسيع. تتضمن هذه الخدمات Azure HDInsight. لقد سبق ذكره أعلاه. تم إنشاؤه من أجل تزويد المستخدم بالخدمات من النظام الإيكولوجي Hadoop من جانبه ، دون أغلفة خارجية ، ومن ناحية أخرى ، لتخفيف الصعوبات الناشئة عن التثبيت المباشر وإدارة وتكوين IaaS. استضافة Docker منفصلة قليلاً. نظرًا لأن هذا موضوع مهم للغاية ، سننظر فيه ، ولكن أولاً تعرف على خدمات PaaS التي يتم تنفيذها باستخدام المفاهيم الأساسية لـ Kafka.
10.2. محور حدث Azure
خذ بعين الاعتبار خدمة محور رسالة Azure Event Hub. إنها خدمة مبنية على نموذج PaaS. يمكن أن تعمل مجموعات العملاء المختلفة كمصادر رسالة لـ Azure Event Hub (الشكل 10.8). بادئ ذي بدء ، هذه مجموعة كبيرة جدًا من الخدمات السحابية التي يمكن تكوين مخرجاتها أو مشغلاتها لإرسال الرسائل مباشرة إلى Event Hub. يمكن أن تكون هذه هي Stream Stream Job و Event Grid ومجموعة كبيرة من الخدمات التي تعيد توجيه الأحداث - السجلات في Event Hub (تم إنشاؤها في المقام الأول باستخدام AppService: Api App و Web App و Mobile App و Function App).
يمكن التقاط الرسائل التي يتم تسليمها إلى المحور مباشرة وتخزينها في Blob Storage أو Data Lake Store.
المجموعة التالية من المصادر هي عملاء أو أجهزة برامج خارجية لا يوجد لها Azure Event Hub SDK ولا يمكن دمجها مباشرة مع خدمات Azure. يتضمن هؤلاء العملاء بشكل أساسي أجهزة إنترنت الأشياء. يمكنهم إرسال رسائل إلى Event Hub عبر HTTPS أو AMQP. يعتبر النظر في كيفية توصيل هذه الأجهزة خارج نطاق كتابنا.
أخيرًا ، عملاء البرامج الذين يقومون بإنشاء الرسائل وإرسالها إلى Event Hub باستخدام Azure Event Hub SDK. تتضمن هذه المجموعة Azure PowerShell و Azure CLI.
يمكن استخدام مستلمي الرسائل (المستهلكين - "المستهلكين") من Event Hub أو Stream Analytics Job أو خدمة Event Grid تكامل. بالإضافة إلى ذلك ، من الممكن تلقي رسائل من عملاء البرامج باستخدام Azure Event Hub SDK. يتصل المستهلكون بـ Event Hub باستخدام بروتوكول AMQP 1.0.
ضع في اعتبارك المفاهيم الأساسية لـ Azure Event Hub اللازمة لفهم كيفية استخدامه وتكوينه. يجب أن يستخدم أي مصدر (يسمى أيضًا الناشر في الوثائق) يرسل رسالة إلى لوحة الوصل بروتوكول HTTPS أو AMQP 1.0. يتم تحديد اختيار البروتوكول حسب نوع العميل وشبكة الاتصالات ومتطلبات معدل الرسائل. يتطلب AMQP اتصالاً دائمًا بين مقابس TCP ثنائية الاتجاه. وهي محمية باستخدام بروتوكول تشفير طبقة النقل TLS أو SSL / TLS. , , AMQP , HTTPS, . HTTPS.
, SAS (Shared Access Signature) tokens. SAS- SAS . SAS-, ( ).
256 . , .
, Event Hub. , , , -. EventHub (partitions). EventHub — , « — » (FIFO) (. 10.9).
— Event Hub. Event Hub 2 32 , Event Hub. , .
( ) , ( , — . ), (retention period), . . . , Azure Event Hub (offset). — , , , , . . Azure Event Hub SDK , , . -, .
, , , , . Azure Event Hub SDK , . , Storage Account. Azure, Event Hub, .
Event Hub (partition key), . — . , ( ) . , (round robin).
. , (consumer group) (. 10.11). . (view) ( ) , , . , . — 20, , .
. , . , (throughput unit). :
. , . . . كن حذرا! , , , Event Hub.
(namespace) (. 10.12).
»يمكن العثور على مزيد من المعلومات حول الكتاب على
موقع الناشر على الويب»
المحتويات»
مقتطفاتقسيمة خصم 20٪
للمتجولين -
BigData