بناء مستودع البيانات وبحيرة البيانات في AWS

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

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

• الأعمال المرتكزة على البيانات والبيانات.
• البيانات في أي مكان وفي أي وقت وعلى أي حال.

أهم الأصول

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

لن يكون كل المحتوى مفيدًا ، وبعض الأجزاء لن تكون حتى ولو لمرة واحدة. غالبًا ما شاهدت على الخط الأمامي كيف أن الشركات أنتجت كمية هائلة من البيانات لتصبح عديمة الفائدة بعد تحميل ناجح.

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

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

دعنا نلقي نظرة على ثلاث طرق أصلية حول كيفية تحقيق ذلك داخل AWS:

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

بحيرة البيانات بواسطة AWS Athena

المصدر: aws.amazon.com

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

AWS Athena عبارة عن قاعدة بيانات بها تخزين مباشرة على حاويات S3 وبدون مجموعات خوادم تعمل في الخلفية. هذا يعني أنها خدمة بحيرة بيانات رخيصة حقًا. تحافظ تنسيقات الملفات المهيكلة مثل ملفات باركيه أو ملفات قيم مفصولة بفاصلة (CSV) على تنظيم البيانات. يحتفظ دلو S3 بالملفات ، وتشير أثينا إليها كلما حددت العمليات البيانات من قاعدة البيانات.

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

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

إيجابيات وسلبيات

الفوائد التي يجب مراعاتها:

• حقيقة أن Athena رخيصة (تتكون فقط من حاويات S3 وتكاليف استخدام SQL لكل استخدام) هي الميزة الأكثر أهمية. إذا كنت ترغب في بناء بحيرة بيانات ميسورة التكلفة في AWS ، فهذه هي.
• كخدمة أصلية ، يمكن أن تتكامل Athena بسهولة مع خدمات AWS المفيدة الأخرى مثل Amazon QuickSight لتصور البيانات أو AWS Glue Data Catalog لإنشاء بيانات وصفية منظمة دائمة.
• الأفضل لتشغيل استعلامات مخصصة عبر كمية كبيرة من البيانات المنظمة أو غير المهيكلة دون الحفاظ على بنية أساسية كاملة حولها.

العيوب التي يجب مراعاتها:

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

الغرض وحالة الاستخدام في العالم الحقيقي

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

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

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

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

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

مستودع البيانات بواسطة AWS Redshift

المصدر: aws.amazon.com

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

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

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

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

إيجابيات وسلبيات

الفوائد التي يجب مراعاتها:

• خدمة مستودع بيانات سحابة AWS أصلية يسهل تكاملها مع الخدمات الأخرى.
• مكان مركزي لتخزين أنواع مختلفة من مصادر البيانات ومراقبتها واستيعابها من أنظمة مصادر مختلفة للغاية.
• إذا أردت يومًا ما أن يكون لديك مستودع بيانات بدون خادم بدون البنية التحتية لصيانته ، فيمكنك الآن ذلك.
• الأمثل لتحليل الأداء العالي وإعداد التقارير. على عكس حل بحيرة البيانات ، يوجد نموذج بيانات علاقي قوي لتخزين جميع البيانات الواردة.
• ينشأ محرك قاعدة البيانات Redshift في PostgreSQL ، مما يضمن توافقًا عاليًا مع أنظمة قواعد البيانات الأخرى.
• عبارات COPY و UNLOAD مفيدة جدًا لتحميل البيانات وتفريغها من حاويات S3 وإليها.

العيوب التي يجب مراعاتها:

• لا يدعم الانزياح الأحمر كمية كبيرة من الجلسات النشطة المتزامنة. سيتم تعليق الجلسات ومعالجتها بالتسلسل. على الرغم من أنها قد لا تكون مشكلة في معظم الحالات ، نظرًا لأن العمليات سريعة حقًا ، إلا أنها عامل مقيد في الأنظمة التي بها العديد من المستخدمين النشطين.
• على الرغم من أن Redshift يدعم الكثير من الوظائف المعروفة سابقًا من أنظمة Oracle الناضجة ، إلا أنها لا تزال على نفس المستوى. قد لا تكون بعض الميزات المتوقعة موجودة (مثل مشغلات قاعدة البيانات). أو أن الانزياح الأحمر يدعمها في شكل محدود للغاية (مثل الآراء المادية).
• كلما احتجت إلى مهمة معالجة بيانات مخصصة أكثر تقدمًا ، يجب عليك إنشاؤها من البداية. في معظم الأحيان ، استخدم لغة البرمجة Python أو Javascript. إنه ليس طبيعيًا مثل PL / SQL في حالة نظام Oracle ، حيث تستخدم حتى الوظيفة والإجراءات لغة مشابهة جدًا لاستعلامات SQL.

الغرض وحالة الاستخدام في العالم الحقيقي

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

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

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

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

تحقق من مقارنتنا بين Datalake و Datawarehouse.

Lakehouse بواسطة Databricks على AWS

المصدر: databricks.com

Lakehouse هو مصطلح مرتبط حقًا بخدمة Databricks. حتى إذا لم تكن خدمة AWS أصلية ، فهي تعيش وتعمل ضمن نظام AWS البيئي بشكل جيد للغاية وتوفر خيارات متنوعة لكيفية الاتصال والتكامل مع خدمات AWS الأخرى.

تهدف Databricks إلى الاتصال معًا (سابقًا) بمناطق مميزة جدًا:

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

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

لذلك تهدف Databricks إلى حل شامل ، في محاولة للجمع بين مزايا بحيرة البيانات ومستودع البيانات في حل واحد. علاوة على ذلك ، فإنه يوفر الأدوات اللازمة لاختبار نماذج التعلم الآلي وتشغيلها مباشرة عبر مخازن البيانات التي تم إنشاؤها بالفعل.

إيجابيات وسلبيات

الفوائد التي يجب مراعاتها:

• Databricks هي منصة بيانات قابلة للتطوير بدرجة كبيرة. إنه يتوسع بناءً على حجم عبء العمل ، ويقوم بذلك تلقائيًا.
• إنها بيئة تعاونية لعلماء البيانات ومهندسي البيانات ومحللي الأعمال. إن امتلاك إمكانية القيام بكل هذا في نفس المساحة معًا يعد فائدة عظيمة. ليس فقط من منظور تنظيمي ، ولكنه يساعد أيضًا في توفير تكلفة أخرى مطلوبة لبيئات منفصلة.
• تتكامل AWS Databricks بسلاسة مع خدمات AWS الأخرى ، مثل Amazon S3 و Amazon Redshift و Amazon EMR. يتيح ذلك للمستخدمين نقل البيانات بسهولة بين الخدمات والاستفادة من النطاق الكامل لخدمات AWS السحابية.

العيوب التي يجب مراعاتها:

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

الغرض وحالة الاستخدام في العالم الحقيقي

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

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

تتكامل Databricks أيضًا بسهولة مع أنظمة Informatica ETL. عندما يستخدم نظام المؤسسة بالفعل نظام Informatica البيئي على نطاق واسع ، تبدو Databricks إضافة جيدة متوافقة إلى النظام الأساسي.

الكلمات الأخيرة

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

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