هذه المقالة هي ترجمة لمقالتي على المتوسط - ، والتي تحولت إلى شعبية كبيرة، ربما بسبب بساطتها. لذلك، قررت أن أكتبها باللغة الروسية وأضيف القليل منها لأوضح لشخص عادي غير متخصص في البيانات ما هو مستودع البيانات (DW)، وما هي بحيرة البيانات (Data Lake)، وكيف يتم الحصول على جنبا إلى جنب معا .
لماذا أردت أن أكتب عن بحيرة البيانات؟ لقد عملت مع البيانات والتحليلات لأكثر من 10 سنوات، والآن أعمل بالتأكيد مع البيانات الضخمة في Amazon Alexa AI في كامبريدج، والتي تقع في بوسطن، على الرغم من أنني أعيش في فيكتوريا في جزيرة فانكوفر وكثيرًا ما أزور بوسطن وسياتل. وفي فانكوفر، وأحيانا حتى في موسكو، أتحدث في المؤتمرات. أنا أيضًا أكتب من وقت لآخر، لكني أكتب بشكل أساسي باللغة الإنجليزية، وقد كتبت بالفعل ، أحتاج أيضًا إلى مشاركة اتجاهات التحليلات من أمريكا الشمالية، وأكتب أحيانًا .
لقد عملت دائمًا مع مستودعات البيانات، ومنذ عام 2015 بدأت العمل بشكل وثيق مع Amazon Web Services، وتحولت بشكل عام إلى التحليلات السحابية (AWS، وAzure، وGCP). لقد لاحظت تطور حلول التحليلات منذ عام 2007، بل وعملت لدى شركة مستودعات البيانات Teradata وقمت بتنفيذها في Sberbank، وذلك عندما ظهرت Big Data with Hadoop. بدأ الجميع يقولون إن عصر التخزين قد ولى والآن أصبح كل شيء على Hadoop، ثم بدأوا يتحدثون عن Data Lake، مرة أخرى، لقد حان الآن بالتأكيد نهاية مستودع البيانات. لكن لحسن الحظ (ربما لسوء الحظ بالنسبة للبعض الذين كسبوا الكثير من المال من خلال إنشاء Hadoop)، لم يختف مستودع البيانات.
في هذه المقالة سوف نلقي نظرة على ماهية بحيرة البيانات. هذه المقالة مخصصة للأشخاص الذين لديهم خبرة قليلة أو ليس لديهم خبرة في مستودعات البيانات.
في الصورة بحيرة بليد، هذه إحدى البحيرات المفضلة لدي، رغم أنني كنت هناك مرة واحدة فقط، إلا أنني أتذكرها لبقية حياتي. لكننا سنتحدث عن نوع آخر من البحيرات - بحيرة البيانات. ربما سمع الكثير منكم عن هذا المصطلح أكثر من مرة، لكن تعريفًا آخر لن يضر أحداً.
في البداية، إليك التعريفات الأكثر شيوعًا لبحيرة البيانات:
"ملف تخزين لجميع أنواع البيانات الأولية المتاحة للتحليل من قبل أي شخص في المنظمة" - مارتن فاولر.
"إذا كنت تعتقد أن سوق البيانات عبارة عن زجاجة مياه - تمت تنقيتها وتعبئتها وتعبئتها للاستهلاك المريح، فإن بحيرة البيانات هي خزان ضخم للمياه في شكله الطبيعي. أيها المستخدمون، يمكنني جمع المياه لنفسي والغوص عميقًا والاستكشاف" - جيمس ديكسون.
الآن نحن نعلم على وجه اليقين أن بحيرة البيانات تتعلق بالتحليلات، فهي تسمح لنا بتخزين كميات كبيرة من البيانات في شكلها الأصلي ولدينا الوصول الضروري والمريح إلى البيانات.
غالبًا ما أحب تبسيط الأمور، فإذا تمكنت من شرح مصطلح معقد بكلمات بسيطة، فأنا أفهم بنفسي كيف يعمل وما هو المطلوب من أجله. في أحد الأيام، كنت أتجول في معرض صور iPhone، وخطر لي أن هذه بحيرة بيانات حقيقية، حتى أنني قمت بإعداد شريحة للمؤتمرات:
كل شيء بسيط جدا. نلتقط صورة على الهاتف، ويتم حفظ الصورة على الهاتف ويمكن حفظها في iCloud (تخزين الملفات السحابية). يقوم الهاتف أيضًا بجمع البيانات الوصفية للصور: ما هو معروض، والعلامة الجغرافية، والوقت. ونتيجة لذلك، يمكننا استخدام واجهة iPhone سهلة الاستخدام للعثور على صورتنا ونرى حتى المؤشرات، على سبيل المثال، عندما أبحث عن صور بها كلمة نار، أجد 3 صور بها صورة نار. بالنسبة لي، هذا يشبه أداة ذكاء الأعمال التي تعمل بسرعة كبيرة وبشكل واضح.
وبطبيعة الحال، يجب ألا ننسى الأمن (الترخيص والمصادقة)، وإلا فإن بياناتنا يمكن أن تنتهي بسهولة في المجال العام. هناك الكثير من الأخبار حول الشركات الكبيرة والشركات الناشئة التي أصبحت بياناتها متاحة للعامة بسبب إهمال المطورين وعدم اتباع القواعد البسيطة.
حتى هذه الصورة البسيطة تساعدنا على تخيل ماهية بحيرة البيانات، واختلافها عن مستودع البيانات التقليدي وعناصرها الرئيسية:
- تحميل البيانات (الابتلاع) هو مكون رئيسي في بحيرة البيانات. يمكن أن تدخل البيانات إلى مستودع البيانات بطريقتين - الدُفعة (التحميل على فترات) والتدفق (تدفق البيانات).
- ملف التخزين (التخزين) هو المكون الرئيسي لبحيرة البيانات. أردنا أن يكون التخزين قابلاً للتطوير بسهولة وموثوقًا للغاية ومنخفض التكلفة. على سبيل المثال، في AWS هو S3.
- الكتالوج والبحث (الكتالوج والبحث) - لكي نتجنب مستنقع البيانات (وهذا عندما نقوم بتفريغ جميع البيانات في كومة واحدة، ومن ثم يكون من المستحيل العمل معها)، نحتاج إلى إنشاء طبقة بيانات تعريفية لتصنيف البيانات حتى يتمكن المستخدمون من العثور بسهولة على البيانات التي يحتاجونها للتحليل. بالإضافة إلى ذلك، يمكنك استخدام حلول بحث إضافية مثل ElasticSearch. يساعد البحث المستخدم في العثور على البيانات المطلوبة من خلال واجهة سهلة الاستخدام.
- تحويل (العملية) - هذه الخطوة مسؤولة عن معالجة البيانات وتحويلها. يمكننا تحويل البيانات وتغيير بنيتها وتنظيفها وغير ذلك الكثير.
- أمن (الأمان) - من المهم قضاء بعض الوقت في التصميم الأمني للحل. على سبيل المثال، تشفير البيانات أثناء التخزين والمعالجة والتحميل. من المهم استخدام أساليب المصادقة والترخيص. وأخيرا، هناك حاجة إلى أداة التدقيق.
من الناحية العملية، يمكننا وصف بحيرة البيانات بثلاث سمات:
- جمع وتخزين أي شيء — تحتوي بحيرة البيانات على جميع البيانات، سواء البيانات الأولية غير المعالجة لأي فترة زمنية أو البيانات المعالجة/المنظفة.
- تفحص بعمق — تتيح بحيرة البيانات للمستخدمين استكشاف البيانات وتحليلها.
- وصول مرن - توفر بحيرة البيانات وصولاً مرنًا للبيانات المختلفة والسيناريوهات المختلفة.
الآن يمكننا أن نتحدث عن الفرق بين مستودع البيانات وبحيرة البيانات. عادة ما يسأل الناس:
- ماذا عن مستودع البيانات؟
- هل نستبدل مستودع البيانات ببحيرة بيانات أم نقوم بتوسيعها؟
- هل لا يزال من الممكن الاستغناء عن بحيرة البيانات؟
باختصار، ليس هناك إجابة واضحة. كل هذا يتوقف على الوضع المحدد ومهارات الفريق والميزانية. على سبيل المثال، ترحيل مستودع بيانات إلى Oracle إلى AWS وإنشاء بحيرة بيانات بواسطة شركة تابعة لشركة Amazon - Woot - .
من ناحية أخرى، يقول البائع Snowflake أنك لم تعد بحاجة إلى التفكير في بحيرة البيانات، نظرًا لأن منصة البيانات الخاصة بهم (حتى عام 2020 كانت مستودع بيانات) تتيح لك الجمع بين كل من بحيرة البيانات ومستودع البيانات. لم أعمل كثيرًا مع Snowflake، وهو حقًا منتج فريد يمكنه القيام بذلك. سعر القضية مسألة أخرى.
في الختام، رأيي الشخصي هو أننا ما زلنا بحاجة إلى مستودع بيانات باعتباره المصدر الرئيسي للبيانات لتقاريرنا، وأي شيء لا يناسبنا نقوم بتخزينه في بحيرة البيانات. يتمثل الدور الكامل للتحليلات في توفير وصول سهل للأعمال لاتخاذ القرارات. مهما كان القول، يعمل مستخدمو الأعمال بكفاءة أكبر مع مستودع البيانات مقارنةً ببحيرة البيانات، على سبيل المثال في Amazon - يوجد Redshift (مستودع البيانات التحليلية) ويوجد Redshift Spectrum/Athena (واجهة SQL لبحيرة البيانات في S3 استنادًا إلى خلية / المعزوفة). الأمر نفسه ينطبق على مستودعات البيانات التحليلية الحديثة الأخرى.
دعونا نلقي نظرة على بنية مستودع البيانات النموذجية:
هذا هو الحل الكلاسيكي. لدينا أنظمة مصدر، باستخدام ETL/ELT نقوم بنسخ البيانات إلى مستودع بيانات تحليلية وربطها بحل ذكاء الأعمال (المفضل لدي هو Tableau، فماذا عن حلك؟).
هذا الحل له العيوب التالية:
- تتطلب عمليات ETL/ELT الوقت والموارد.
- كقاعدة عامة، الذاكرة لتخزين البيانات في مستودع البيانات التحليلية ليست رخيصة (على سبيل المثال، Redshift، BigQuery، Teradata)، لأننا بحاجة إلى شراء مجموعة كاملة.
- يمكن لمستخدمي الأعمال الوصول إلى البيانات المنظفة والمجمعة في كثير من الأحيان ولا يمكنهم الوصول إلى البيانات الأولية.
وبطبيعة الحال، كل هذا يتوقف على حالتك. إذا لم تكن لديك مشاكل مع مستودع البيانات الخاص بك، فلن تحتاج إلى بحيرة بيانات على الإطلاق. ولكن عندما تنشأ مشاكل تتعلق بنقص المساحة أو الطاقة أو السعر الذي يلعب دورًا رئيسيًا، فيمكنك التفكير في خيار بحيرة البيانات. ولهذا السبب تحظى بحيرة البيانات بشعبية كبيرة. فيما يلي مثال على بنية بحيرة البيانات:
باستخدام نهج بحيرة البيانات، نقوم بتحميل البيانات الأولية إلى بحيرة البيانات الخاصة بنا (دفعة أو تدفق)، ثم نقوم بمعالجة البيانات حسب الحاجة. تسمح بحيرة البيانات لمستخدمي الأعمال بإنشاء تحويلات البيانات الخاصة بهم (ETL/ELT) أو تحليل البيانات في حلول ذكاء الأعمال (إذا كان برنامج التشغيل الضروري متاحًا).
الهدف من أي حل تحليلي هو خدمة مستخدمي الأعمال. لذلك، يجب علينا دائمًا العمل وفقًا لمتطلبات العمل. (يعد هذا أحد المبادئ في أمازون - العمل بشكل عكسي).
من خلال العمل مع كل من مستودع البيانات وبحيرة البيانات، يمكننا مقارنة كلا الحلين:
الاستنتاج الرئيسي الذي يمكن استخلاصه هو أن مستودع البيانات لا يتنافس مع بحيرة البيانات، بل يكملها. ولكن الأمر متروك لك لتقرر ما هو مناسب لحالتك. من المثير للاهتمام دائمًا تجربة ذلك بنفسك واستخلاص النتائج الصحيحة.
أود أيضًا أن أخبرك بإحدى الحالات التي بدأت فيها استخدام نهج بحيرة البيانات. كل شيء تافه تمامًا، لقد حاولت استخدام أداة ELT (كان لدينا Matillion ETL) وAmazon Redshift، وقد نجح الحل الخاص بي، لكنه لم يكن متوافقًا مع المتطلبات.
كنت بحاجة إلى أخذ سجلات الويب وتحويلها وتجميعها لتوفير بيانات لحالتين:
- أراد فريق التسويق تحليل نشاط الروبوت لتحسين محركات البحث
- أراد قسم تكنولوجيا المعلومات إلقاء نظرة على مقاييس أداء موقع الويب
سجلات بسيطة جدًا وبسيطة جدًا. هنا مثال:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"ملف واحد يزن 1-4 ميغابايت.
ولكن كانت هناك صعوبة واحدة. كان لدينا 7 نطاقات حول العالم، وتم إنشاء 7000 ألف ملف في يوم واحد. هذا ليس حجمًا أكبر بكثير، فقط 50 جيجا بايت. لكن حجم مجموعة الانزياح نحو الأحمر كان صغيرًا أيضًا (4 عقد). يستغرق تحميل ملف واحد بالطريقة التقليدية حوالي دقيقة. أي أن المشكلة لم يتم حلها بشكل مباشر. وكان هذا هو الحال عندما قررت استخدام نهج بحيرة البيانات. بدا الحل كالتالي:
الأمر بسيط للغاية (أريد أن أشير إلى أن ميزة العمل في السحابة هي البساطة). إستعملت:
- تقليل خريطة AWS المرنة (Hadoop) للطاقة الحاسوبية
- AWS S3 كمخزن للملفات مع القدرة على تشفير البيانات وتقييد الوصول إليها
- Spark كقوة حوسبة InMemory وPySpark لتحويل المنطق والبيانات
- الباركيه نتيجة الشرارة
- AWS Glue Crawler بمثابة جامع بيانات تعريفية حول البيانات والأقسام الجديدة
- Redshift Spectrum كواجهة SQL لمستودع البيانات لمستخدمي Redshift الحاليين
قامت أصغر مجموعة EMR+Spark بمعالجة مجموعة الملفات بالكامل في 30 دقيقة. هناك حالات أخرى لـ AWS، خاصة العديد منها المتعلقة بـ Alexa، حيث يوجد الكثير من البيانات.
علمت مؤخرًا أن أحد عيوب بحيرة البيانات هو القانون العام لحماية البيانات (GDPR). تكمن المشكلة في أنه عندما يطلب العميل حذفه وتكون البيانات موجودة في أحد الملفات، لا يمكننا استخدام لغة معالجة البيانات وعملية الحذف كما هو الحال في قاعدة البيانات.
آمل أن توضح هذه المقالة الفرق بين مستودع البيانات وبحيرة البيانات. إذا كنت مهتمًا، يمكنني ترجمة المزيد من مقالاتي أو مقالات المحترفين الذين قرأتهم. وأخبر أيضًا عن الحلول التي أعمل بها وبنيتها.
المصدر: www.habr.com