كيفية استهلاك البيانات في مقياس على AWS

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

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

صورة من https://www.thethingsnetwork.org

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

جار استقبال البيانات

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

اعتمادًا على كمية البيانات التي ستستهلكها ، ستحتاج إلى ضمان توفير ما يكفي من القطع. يمكن لكل قشرة تستهلك ما يصل إلى 1MB / ثانية ، 1000 السجلات / ثانية وتنبعث ما يصل إلى 2MB / ثانية. تحتوي أدوات التوفير داخل Kinesis على آلة حاسبة للمساعدة في تحديد عدد القطع المطلوبة - على الرغم من أنك قد ترغب في إعداد منبهات CloudWatch وتشغيل الأحداث للمساعدة في توسيع نطاق القطع المتوفرة لأعلى ولأسفل في بيئة الإنتاج.

لنقم بإنشاء Kinesis Stream. هناك عدة أنواع من تدفقات Kinesis المتاحة - دفق البيانات ، دفق التسليم ، تطبيق التحليلات أو دفق الفيديو. لقد اخترت Kinesis Data Stream وسأقدم لصفتي اسمًا وقم بتعيينه لحبة واحدة.

الآن - يعد استخدام Kinesis جيدًا وجيدًا ، لكن في حالة بائعي الأجهزة الخارجين عن المألوف ، لا يوجد لدى معظمهم مكتبة Kinesis Producer Library ، مما يمثل مشكلة (جيد بالنسبة لنا على أي حال). هذا أمر مفهوم لأن Kinesis ليس معيارًا حقًا. لحسن الحظ ، يمكن استخدام ميزة أقل شهرة في API Gateway لحل هذه المشكلة ، وكلاء الخدمة ، والتي تسمح لنا بتحميل البيانات إلى خدمات AWS الأخرى عبر API Gateway ويمكن استخدامها للعمل كمنتج ل Kinesis. تدعم واجهة برمجة التطبيقات (API Gateway) REST عبر HTTP ، وهو معيار معتمد من قبل العديد من بائعي الأجهزة ، لذلك سنستخدم ذلك.

قبل أن أخوض في التفاصيل ، أوضح كيف يعمل هذا وكيف يتم إنشاء خط الأنابيب ، اسمحوا لي أن أجيب على سؤال طرحته كل مرة تقريبًا ؛ "لماذا لا تضع Lambda خلف API Gateway ومعالجة البيانات بهذه الطريقة بدلاً من ذلك". هناك عدة أسباب وجيهة:

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

تحذير واحد آخر - إذا كنت بحاجة إلى إرجاع استجابة ذات معنى إلى منتج بياناتك ، فهذا الحل ليس لك.

العودة إلى بوابة API - حسنًا ، تقريبًا! أولاً ، سأقوم بإنشاء دور IAM له إذن بوضع البيانات في Kinesis Stream. سيكون النوع هو خدمة AWS والخدمة التي يتم تحديدها هي بوابة API (حيث ستستخدم الدور). تخطو إلى المعالج ، ثم أعطه اسمًا ثم أكمل العملية (لا تقلق بشأن الأذونات في الوقت الحالي).

بمجرد إنشاء دور IAM ، قم بتحرير الدور واختر خيار إنشاء سياسة مضمنة. ستكون السياسة التي أقوم بإنشائها لـ Kinesis ، مع أذونات PutRecord و PutRecords وسأقيدها الدفق الذي قمت بإنشائه من قبل من خلال توفير ARN. بمجرد إنشاء سياسة الدور ، يرجى ملاحظة ARN.

حسنًا - نحن الآن على استعداد بالفعل للعودة إلى بوابة API. في واجهة API Gateway ، سأقوم بإنشاء بوابة جديدة:

ضمن هذه البوابة ، سأقوم بإنشاء طريقة POST جديدة تحت مورد الجذر وملء حقول التكوين كما يلي:

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

بمجرد حفظ قالب التعيين ، لننشر التغييرات:

والآن لدي عنوان URL لواجهة برمجة التطبيقات:

باستخدام Postman مع عنوان URL الذي تم إنشاؤه ، يمكنك ملء بعض بيانات الاختبار وإرسالها إلى واجهة برمجة التطبيقات. نجاح! أرسل Kinesis ردًا مرة أخرى لتأكيد قبول البيانات.

بالنظر إلى علامة تبويب المراقبة الخاصة بي Kinesis Stream أستطيع أن أرى البيانات قد وردت هنا أيضًا.

معالجة البيانات

بعد تلقي Kinesis للبيانات ، تحتاج إلى القيام بشيء ما - يتطلب ذلك من المستهلكين قراءة البيانات من Kinesis. تقليديًا ، تم ذلك مع مثيلات EC2 كما في المخطط من AWS أدناه:

صورة من https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html

EC2 رائع ، لكن لدينا الآن القدرة على استهلاك هذه البيانات بعدة طرق مختلفة:

  • باستخدام لامدا
  • الاندماج المباشر مع Kinesis Firehose لوضع البيانات مباشرة في خدمات أخرى مثل S3 أو Redshift أو Elasticsearch أو Splunk

في هذا السيناريو ، سأستخدم Lambda. وبهذه الطريقة ، يمكننا معالجة البيانات وإخراجها في أي خدمة نريدها مثل DynamoDB أو RDS ، وحتى معالجة البيانات بالتوازي باستخدام وظائف الخطوة.

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

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

قبل أن نصل إلى أبعد الحدود ، سأقوم بتعيين سياسة مضمنة جديدة لدور IAM الذي تم إنشاؤه لوظيفة Lambda الخاصة بي. على مستوى عالٍ ، أحتاج إلى السماح بوظيفة Lambda بسرد جميع التدفقات ، ثم أذونات الحصول على البيانات من الدفق المحدد.

{
    "الإصدار": "2012-10-17" ،
    "بيان": [
        {
            "Sid": "VisualEditor0" ،
            "التأثير": "السماح" ،
            "عمل": [
                "الحركية: GetShardIterator"
                "الحركية: GetRecords"
                "الحركية: DescribeStream"
            ]،
            "Resource": "arn: aws: kinesis: ap-south-2: 881539945095: stream / TestStream"
        }،
        {
            "Sid": "VisualEditor1" ،
            "التأثير": "السماح" ،
            "العمل": "kinesis: ListStreams" ،
            "المورد": "*"
        }
    ]
}

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

يجب أن يؤكد اختبار التشغيل لوظيفة Lambda النجاح:

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

خاتمة

من الناحية المثالية ، سيتم إنشاء خط الأنابيب الخاص بك كرمز لعمليات النشر القابلة للتكرار أو التحديثات التي تتم باستخدام أداة مثل CloudFormation.

يعد استخدام Kinesis مقترنًا بواجهة برمجة التطبيقات (API) عبارة عن قوة فائقة. لا يقتصر الأمر على تطبيقات التليماتية فقط ، بل يمكنك استخدامه لاستيعاب أي نوع من البيانات لإعداد التقارير التحليلية. بالإضافة إلى خدمات AWS الأخرى مثل S3 و Athena أو Redshift ، يمكنك بسهولة إنشاء بحيرة بيانات منخفضة التكلفة.