تصميم البيانات الضخمة للتعامل مع استيعاب ومعالجة وتحليل البيانات الضخمة جداً أو المعقدة لأنظمة قواعد البيانات التقليدية. يختلف الحد الذي تدخل فيه المؤسسات في مجال البيانات الضخمة، اعتمادا على قدرات المستخدمين وأدواتهم. بالنسبة للبعض، قد يعني المئات من الجيجابايت من البيانات، بينما بالنسبة للبعض الآخر يعني المئات من التيرابايت. مع تقدم أدوات العمل مع مجموعات البيانات الضخمة، كذلك معنى البيانات الضخمة. يرتبط هذا المصطلح أكثر بالقيمة التي يمكنك استخراجها من مجموعات البيانات الخاصة بك من خلال التحليلات المتقدمة، بدلا من حجم البيانات بدقة، على الرغم من أنها في هذه الحالات تميل إلى أن تكون كبيرة جدا.
تَغَيَر مشهد البيانات على مر السنين. ما يمكنك القيام به، أو المتوقع أن تفعله، مع تغيير البيانات. انخفضت تكلفة التخزين بشكل كبير، بينما تستمر الوسائل التي يتم من خلالها جمع البيانات في النمو. تصل بعض البيانات بوتيرة سريعة، تتطلب جمعها ومراقبتها باستمرار. تصل البيانات الأخرى ببطء أكبر ولكن في مجموعات كبيرة جدا، غالبا في شكل عقود من البيانات التاريخية. قد تواجه مشكلة تحليلات متقدمة، أو مشكلة تتطلب التعلم الآلي. هذه هي التحديات التي تسعى بنيات البيانات الضخمة إلى حلها.
تتضمن حلول البيانات الضخمة عادةً نوعاً واحداً أو أكثر من أنواع حِمل العمل التالية:
- معالجة دفعة من ملفات مصادر البيانات الضخمة الثابتة.
- معالجة في الوقت الحقيقي للبيانات الضخمة أثناء الحركة.
- الاستكشاف التفاعلي للبيانات الضخمة.
- التحليلات التنبؤية والتعلم الآلي.
ضع في اعتبارك بنيات البيانات الضخمة عندما تحتاج إلى:
- تخزين البيانات ومعالجتها بكميات كبيرة جداً بالنسبة لقاعدة البيانات التقليدية.
- تحويل البيانات غير المهيكلة للتحليل وإعداد التقارير.
- يمكنك تسجيل ومعالجة وتحليل تدفقات البيانات غير المحدودة في الوقت الحقيقي أو بزمن انتقال منخفض.
مكونات بنية البيانات الضخمة
يوضح الرسم التخطيطي التالي المكونات المنطقية التي تتلاءم مع بنية البيانات الضخمة. قد لا تحتوي الحلول الفردية على كل عنصر في هذا الرسم التخطيطي.
تشتمل معظم هياكل البيانات الضخمة على بعض أو كل المكونات التالية:
مصادر البيانات. تبدأ جميع حلول البيانات الضخمة بمصدر واحد أو أكثر من مصادر البيانات. تتضمن الأمثلة ما يلي:
- مخازن بيانات التطبيق، مثل قواعد البيانات العلائقية.
- الملفات الثابتة التي تنتجها التطبيقات، مثل ملفات سجل خادم الويب.
- مصادر البيانات في الوقت الحقيقي، مثل أجهزة إنترنت الأشياء.
تخزين البيانات. عادةً ما يتم تخزين البيانات لعمليات المعالجة المجمعة في مخزن ملفات موزع يمكن أن يحتوي على كميات كبيرة من الملفات الكبيرة بتنسيقات مختلفة. غالباً ما يُطلق على هذا النوع من المخازن مستودع البيانات. تتضمن خيارات تنفيذ Azure Storage Data Lake Store هذا أو حاويات البيانات الثنائية الكبيرة في Azure Storage.
معالجة دفعة من الملفات. نظراً لأن مجموعات البيانات كبيرة جداً، يجب على حل البيانات الضخمة غالباً معالجة ملفات البيانات باستخدام وظائف مجمعة طويلة الأمد لتصفية البيانات وتجميعها وإعدادها للتحليل. عادةً ما تتضمن هذه الوظائف قراءة ملفات المصدر ومعالجتها وكتابة الإخراج إلى ملفات جديدة. تتضمن الخيارات تشغيل وظائف U-SQL في Azure Data Lake Analytics، باستخدام Apache Hive أو Pig أو وظائف Map/Reduce المخصصة في مجموعة HDInsight Hadoop، أو استخدام برامج Java أو Scala أو Python في مجموعة HDInsight Spark.
استيعاب الرسائل في الوقت الحقيقي. إذا كان الحل يتضمن مصادر في الوقت الحقيقي، فيجب أن تتضمن البنية طريقة لتسجيل الرسائل في الوقت الحقيقي وتخزينها لمعالجة البث. قد يكون هذا مخزناً بسيطاً للبيانات، حيث يتم إسقاط الرسائل الواردة في مجلد للمعالجة. ومع ذلك، يحتاج العديد من الحلول إلى مخزن استيعاب رسائل للعمل كمخزن مؤقت للرسائل، ولدعم معالجة التوسع، والتسليم الموثوق، ودلالات انتظار الرسائل الأخرى. غالبا ما يشار إلى هذا الجزء من بنية الدفق باسم التخزين المؤقت للبث. تتضمن الخيارات مراكز أحداث Azure وAzure IoT Hub وKafka.
معالجة دفق البيانات. بعد تسجيل الرسائل في الوقت الحقيقي، يجب أن يعالجها الحل عن طريق التصفية والتجميع وإعداد البيانات للتحليل. ثم تتم كتابة بيانات التدفق المُعالجة إلى متلقي إخراج. يوفر Azure Stream Analytics خدمة معالجة دفق مُدارة تستند إلى استعلامات SQL التي تعمل بشكل دائم على تدفقات غير محدودة. يمكنك أيضا استخدام مصدر مفتوح تقنيات دفق Apache مثل Spark Streaming في مجموعة HDInsight.
التعلم الآلي. قراءة البيانات المعدة للتحليل (من معالجة الدفعات أو الدفق)، يمكن استخدام خوارزميات التعلم الآلي لإنشاء نماذج يمكنها التنبؤ بالنتائج أو تصنيف البيانات. يمكن تدريب هذه النماذج على مجموعات البيانات الكبيرة، ويمكن استخدام النماذج الناتجة لتحليل البيانات الجديدة وإجراء التنبؤات. يمكن القيام بذلك باستخدام Azure التعلم الآلي
مخزن البيانات التحليلية. تقوم العديد من حلول البيانات الضخمة بإعداد البيانات للتحليل ثم تخدم البيانات المعالجة بتنسيق منظم يمكن الاستعلام عنه باستخدام أدوات تحليلية. يمكن أن يكون مخزن البيانات التحليلية المستخدم لخدمة هذه الاستعلامات عبارة عن مستودع بيانات علاقي على غرار Kimball، كما هو موضح في معظم حلول ذكاء الأعمال التقليدية (BI). بدلاً من ذلك، يمكن تقديم البيانات من خلال تقنية NoSQL ذات زمن انتقال منخفض مثل HBase، أو قاعدة بيانات Apache Hive تفاعلية توفر تجريداً بيانات التعريف الوصفية على ملفات البيانات في مخزن البيانات الموزع. يوفر Azure Synapse Analytics خدمة مُدارة لتخزين البيانات واسعة النطاق ومستندة إلى السحابة. يدعم HDInsight Interactive Apache Hive وHBase وSpark SQL، والتي يمكن استخدامها أيضاً لخدمة البيانات للتحليل.
التحليل وإعداد التقارير. يتمثل الهدف من معظم حلول البيانات الضخمة في توفير رؤى حول البيانات من خلال التحليل وإعداد التقارير. لتمكين المستخدمين من تحليل البيانات، قد تتضمن البنية طبقة نمذجة بيانات، مثل مكعب OLAP متعدد الأبعاد أو نموذج بيانات جدولي في Azure Analysis Services. قد يدعم أيضاً ذكاء الأعمال ذاتية الخدمة، باستخدام تقنيات النمذجة والتمثيل في Microsoft Power BI أو Microsoft Excel. يمكن أن يأخذ التحليل وإعداد التقارير أيضاً شكل استكشاف البيانات التفاعلي بواسطة علماء البيانات أو محللي البيانات. بالنسبة لهذه السيناريوهات، تدعم العديد من خدمات Azure مفكرات الملاحظات التحليلية، مثل Jupyter، ما يمكّن هؤلاء المستخدمين من الاستفادة من مهاراتهم الحالية مع Python أو R. لاستكشاف البيانات على نطاق واسع، يمكنك استخدام Microsoft R Server، إما مستقل أو مع Spark.
التنسيق. تتكون معظم حلول البيانات الضخمة من عمليات معالجة البيانات المتكررة، المغلفة في تدفقات العمل، والتي تحول بيانات المصدر، وتنقل البيانات بين مصادر ومتلقيين متعددين، وتحميل البيانات التي تمت معالجتها في مخزن بيانات تحليلي، أو تدفع بالنتائج مباشرة إلى تقرير أو لوحة تحكم. للتنفيذ التلقائي فيما يخص عمليات سير العمل هذه، يمكنك استخدام تقنية التزامن مثل Azure Data Factory أو Apache Oozie وSqoop.
بنية Lambda
عند العمل مع مجموعات البيانات الضخمة للغاية، قد يستغرق وقتًا طويلًا لتشغيل نوع الاستعلامات التي يحتاجها العملاء. لا يمكن تنفيذ هذه الاستعلامات في الوقت الحقيقي، وغالبًا ما تتطلب خوارزميات مثل MapReduce التي تعمل بالتوازي عبر مجموعة البيانات بأكملها. ثم تُخزَّن النتائج تخزينًا منفصلًا عن البيانات الأولية وتُستخدم للاستعلام.
أحد عيوب هذا الأسلوب هو أنه يقدم زمن انتقال أي إذا استغرقت المعالجة بضع ساعات، فقد يرجع الاستعلام نتائج عمرها ساعات كثيرة. من الناحية المثالية، ترغب في الحصول على بعض النتائج في الوقت الحقيقي (ربما مع قليل من عدم الدقة)، وجمع هذه النتائج بالنتائج الواردة من تحليلات الدُفعة.
تعالج بنية lambda، التي اقترحها ناثان مارز أولا، هذه المشكلة عن طريق إنشاء مسارين لتدفق البيانات. تمر جميع البيانات الواردة إلى النظام عبر هذين المسارين:
تقوم طبقة الدفعة (المسار البارد) بتخزين جميع البيانات الواردة في شكلها الخام وإجراء معالجة الدفعات على البيانات. يتم تخزين نتيجة هذه المعالجة كعرض دفعي.
تحلل طبقة السرعة (المسار الساخن) البيانات في الوقت الحقيقي. تم تصميم هذه الطبقة لزمن انتقال منخفض، على حساب الدقة.
تُغذى طبقة الدفعة في طبقة خدمة تقوم بفهرسة طريقة عرض الدفعة للاستعلام الفعال. تعمل طبقة السرعة على تحديث طبقة العرض بتحديثات تزايدية استناداً إلى أحدث البيانات.
البيانات التي تتدفق إلى المسار الساخن مقيدة بمتطلبات زمن الانتقال التي تفرضها طبقة السرعة، بحيث يمكن معالجتها في أسرع وقت ممكن. غالبا ما يتطلب هذا مقايضة مستوى معين من الدقة لصالح البيانات الجاهزة في أسرع وقت ممكن. على سبيل المثال، ضع في اعتبارك سيناريو IoT حيث يرسل عدد كبير من أجهزة استشعار درجة الحرارة بيانات القياس عن بعد. يمكن استخدام طبقة السرعة لمعالجة نافذة زمنية منزلقة للبيانات الواردة.
من ناحية أخرى، لا تخضع البيانات المتدفقة إلى المسار البارد لنفس متطلبات زمن الانتقال المنخفض. يسمح هذا بالحساب عالي الدقة عبر مجموعات البيانات الكبيرة، والتي يمكن أن تكون مكثفة الوقت جدا.
في النهاية، تتقارب المسارات الساخنة والباردة في تطبيق عميل التحليلات. إذا كان العميل بحاجة إلى عرض البيانات في الوقت المناسب، ومع ذلك من المحتمل أن تكون أقل دقة في الوقت الحقيقي، فإنه سيحصل على نتيجته من المسار السريع. وإلا، فإنه سيتم تحديد النتائج من المسار البارد لعرض بيانات أقل في الوقت المناسب ولكن أكثر دقة. بمعنى آخر، يحتوي المسار الساخن على بيانات لنافذة صغيرة نسبيا من الوقت، وبعد ذلك يمكن تحديث النتائج ببيانات أكثر دقة من المسار البارد.
البيانات الأولية المخزنة في طبقة الدفعة غير قابلة للتغيير. يتم دائما إلحاق البيانات الواردة بالبيانات الموجودة، ولا تتم الكتابة فوق البيانات السابقة أبدا. يتم تخزين أي تغييرات على قيمة مرجع إسناد معين كسجل حدث طابع زمني جديد. يسمح هذا بإعادة الحساب في أي وقت عبر محفوظات البيانات التي تم جمعها. تعد القدرة على إعادة حساب طريقة عرض الدفعة من البيانات الأولية الأصلية مهمة، لأنها تسمح بإنشاء طرق عرض جديدة مع تطور النظام.
بنية Kappa
العيب في بنية lambda هو تعقيدها. يظهر منطق المعالجة في مكانين مختلفين - المسارات الباردة والساخنة - باستخدام أطر عمل مختلفة. يؤدي هذا إلى تكرار منطق الحساب وتعقيد إدارة البنية لكلا المسارين.
تم اقتراح بنية kappa من قبل Jay Kreps كبديل لبنية lambda. لديها نفس الأهداف الأساسية مثل بنية lambda، ولكن مع تمييز مهم: تتدفق جميع البيانات من خلال مسار واحد، باستخدام نظام معالجة الدفق.
هناك بعض أوجه التشابه مع طبقة الدفعة في بنية lambda، من حيث أن بيانات الحدث غير قابلة للتغيير ويتم جمعها كلها، بدلا من مجموعة فرعية. يتم استيعاب البيانات كتدفق من الأحداث في سجل موحد موزع ومتسامح مع الأخطاء. يتم ترتيب هذه الأحداث، ويتم تغيير الحالة الحالية للحدث فقط بواسطة حدث جديد يتم إلحاقه. على غرار طبقة سرعة بنية lambda، يتم تنفيذ جميع معالجة الأحداث على دفق الإدخال وتستمر كعرض في الوقت الحقيقي.
إذا كنت بحاجة إلى إعادة حساب مجموعة البيانات بأكملها (ما يعادل ما تفعله طبقة الدفعة في lambda)، يمكنك ببساطة إعادة تشغيل البث، وعادة ما تستخدم التوازي لإكمال الحساب في الوقت المناسب.
إنترنت الأشياء (IoT)
من وجهة نظر عملية، يمثل إنترنت الأشياء (IoT) أي جهاز متصل بالإنترنت. ويشمل ذلك جهاز الكمبيوتر الخاص بك، والهاتف المحمول، والساعة الذكية، والحرارة الذكية، والثلاجة الذكية، والسيارات المتصلة، وزرع مراقبة القلب، وأي شيء آخر يتصل بالإنترنت ويرسل البيانات أو يتلقىها. يزداد عدد الأجهزة المتصلة كل يوم، وكذلك كمية البيانات التي يتم جمعها منها. غالبا ما يتم جمع هذه البيانات في بيئات مقيدة للغاية، وأحيانا ذات زمن انتقال عال. في حالات أخرى، يتم إرسال البيانات من بيئات زمن الانتقال المنخفض بواسطة آلاف أو ملايين الأجهزة، ما يتطلب القدرة على استيعاب البيانات ومعالجتها بسرعة وفقا لذلك. لذلك، مطلوب التخطيط السليم للتعامل مع هذه القيود والمتطلبات الفريدة.
تعتبر البنيات المستندة إلى الأحداث أساسية لحلول IoT. يوضح الرسم البياني التالي بنية منطقية محتملة لإنترنت الأشياء. يؤكد الرسم التخطيطي على مكونات تدفق الأحداث في البنية.
تستوعب البوابة السحابية أحداث الجهاز على حدود السحابة، باستخدام نظام مراسلة موثوق به وذي زمن انتقال منخفض.
قد ترسل الأجهزة الأحداث مباشرةً إلى البوابة السحابية، أو عبر بوابة حقل. بوابة الحقل هي جهاز أو برنامج متخصص عادة ما يكون مجمعا مع الأجهزة، يتلقى الأحداث ويعاد توجيهها إلى بوابة السحابة. قد تقوم بوابة المجال أيضاً بمعالجة أحداث الجهاز الأولية، وتنفيذ وظائف مثل التصفية أو التجميع أو تحويل البروتوكول.
بعد الاستيعاب، تمر الأحداث عبر واحد أو أكثر من معالجات التدفق التي يمكنها توجيه البيانات (على سبيل المثال، إلى التخزين) أو إجراء التحليلات والمعالجة الأخرى.
فيما يلي بعض أنواع المعالجة الشائعة. (هذه القائمة ليست شاملة بالتأكيد.)
كتابة بيانات الحدث في التخزين البارد، للأرشفة أو لتحليلات الدُفعات.
تحليلات المسار السريع، وتحليل تدفق الأحداث في الوقت الحقيقي (القريب)، لاكتشاف الحالات الشاذة، أو التعرف على الأنماط عبر النوافذ الزمنية المتغيرة، أو تشغيل التنبيهات عند حدوث حالة معينة في الدفق.
معالجة أنواع خاصة من الرسائل غير المميزة من الأجهزة، مثل الإعلامات والتنبيهات.
التعلّم الآلي.
تعرض المربعات المظللة باللون الرمادي مكونات نظام إنترنت الأشياء التي لا ترتبط مباشرة بتدفق الأحداث، ولكنها مضمنة هنا للتأكد من اكتمالها.
يعد سجل الجهاز قاعدة بيانات للأجهزة المتوفرة، بما في ذلك معرفات الجهاز وبيانات التعريف للجهاز عادةً، مثل الموقع.
تعد واجهة برمجة التطبيقات (API) الاحتياطية واجهة خارجية شائعة لتوفير الأجهزة الجديدة وتسجيلها.
تسمح بعض حلول إنترنت الأشياء بإرسال رسائل الأوامر والتحكم إلى الأجهزة.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- زوينر تيجادا | المدير التنفيذي والمهندس المعماري
الخطوات التالية
راجع خدمات Azure ذات الصلة التالية: