نحن نعيش في وقت رائع حيث يمكنك بسرعة وسهولة توصيل العديد من الأدوات الجاهزة مفتوحة المصدر، وإعدادها مع "إيقاف وعيك" وفقًا لنصيحة Stackoverflow، دون الخوض في "الحروف المتعددة"، والتشغيل بها إلى التشغيل التجاري. وعندما تحتاج إلى التحديث/التوسيع أو يقوم شخص ما بإعادة تشغيل جهازين عن طريق الخطأ - فأنت تدرك أن نوعًا ما من الأحلام السيئة المهووسة قد بدأ، وأصبح كل شيء معقدًا بشكل كبير بحيث لا يمكن التعرف عليه، وليس هناك عودة إلى الوراء، والمستقبل غامض وأكثر أمانًا، بدلاً من البرمجة، قم بتربية النحل وصنع الجبن.
ليس من قبيل الصدفة أن يفكر الزملاء الأكثر خبرة، الذين تمتلئ رؤوسهم بالأخطاء وبالتالي رمادية بالفعل، في النشر السريع بشكل لا يصدق لحزم "الحاويات" في "مكعبات" على عشرات الخوادم "باللغات العصرية" مع دعم مدمج لـ الإدخال/الإخراج غير المتزامن وغير المحظور، ابتسم بتواضع. ويستمرون بصمت في إعادة قراءة "man ps"، والتعمق في كود مصدر "nginx" حتى تنزف أعينهم، ويكتبون، ويكتبون، ويكتبون اختبارات الوحدة. يعلم الزملاء أن الشيء الأكثر إثارة للاهتمام سيأتي عندما يصبح "كل هذا" يومًا ما معلقًا في ليلة رأس السنة الجديدة. ولن يساعدهم إلا الفهم العميق لطبيعة يونكس وجدول حالة TCP/IP المحفوظ وخوارزميات البحث والفرز الأساسية. لإعادة النظام إلى الحياة مع دقات الأجراس.
أوه نعم، لقد تشتت انتباهي قليلاً، لكن أتمنى أن أكون قد تمكنت من نقل حالة الترقب.
أريد اليوم أن أشارككم تجربتنا في نشر حزمة مريحة وغير مكلفة لـ DataLake، والتي تحل غالبية المهام التحليلية في الشركة للأقسام الهيكلية المختلفة تمامًا.
منذ بعض الوقت، توصلنا إلى إدراك أن الشركات تحتاج بشكل متزايد إلى ثمار تحليلات المنتج والتحليلات الفنية (ناهيك عن التزيين على الكعكة في شكل التعلم الآلي) وفهم الاتجاهات والمخاطر - نحن بحاجة إلى جمع وتحليل المزيد والمزيد من المقاييس.
التحليلات الفنية الأساسية في Bitrix24
منذ عدة سنوات، وبالتزامن مع إطلاق خدمة Bitrix24، استثمرنا الوقت والموارد بنشاط في إنشاء منصة تحليلية بسيطة وموثوقة من شأنها أن تساعد في رؤية المشاكل بسرعة في البنية التحتية والتخطيط للخطوة التالية. بالطبع، كان من المستحسن أن تأخذ أدوات جاهزة بسيطة ومفهومة قدر الإمكان. ونتيجة لذلك، تم اختيار nagios للمراقبة وmunin للتحليلات والتصور. لدينا الآن آلاف الشيكات في nagios، ومئات من المخططات في munin، ويستخدمها زملاؤنا بنجاح كل يوم. المقاييس واضحة، والرسوم البيانية واضحة، ويعمل النظام بشكل موثوق لعدة سنوات ويتم إضافة اختبارات ورسوم بيانية جديدة إليه بانتظام: عندما نبدأ تشغيل خدمة جديدة، نضيف العديد من الاختبارات والرسوم البيانية. حظ سعيد.
الإصبع على النبض - التحليلات الفنية المتقدمة
أدت الرغبة في تلقي معلومات حول المشكلات "في أسرع وقت ممكن" إلى إجراء تجارب نشطة باستخدام أدوات بسيطة ومفهومة - pinba وxhprof.
أرسل لنا Pinba إحصائيات في حزم UDP حول سرعة تشغيل أجزاء من صفحات الويب بلغة PHP، ويمكننا أن نرى عبر الإنترنت في مخزن MySQL (يأتي Pinba مع محرك MySQL الخاص به لتحليلات سريعة للأحداث) قائمة قصيرة من المشاكل والرد عليها هم. وقد سمح لنا xhprof تلقائيًا بجمع الرسوم البيانية لتنفيذ أبطأ صفحات PHP من العملاء وتحليل ما يمكن أن يؤدي إلى ذلك - صب الشاي بهدوء أو شيء أقوى.
منذ بعض الوقت، تم تجديد مجموعة الأدوات بمحرك آخر بسيط ومفهوم إلى حد ما يعتمد على خوارزمية الفهرسة العكسية، والتي تم تنفيذها بشكل مثالي في مكتبة Lucene الأسطورية - Elastic/Kibana. تبين أن الفكرة البسيطة المتمثلة في تسجيل المستندات متعددة الخيوط في فهرس لوسين معكوس استنادًا إلى الأحداث الموجودة في السجلات والبحث السريع من خلالها باستخدام تقسيم الجوانب، كانت مفيدة حقًا.
على الرغم من المظهر الفني إلى حد ما للتصورات في كيبانا مع مفاهيم منخفضة المستوى مثل "الدلو" "التدفق لأعلى" واللغة المعاد اختراعها للجبر العلائقي الذي لم ينس تمامًا بعد، بدأت الأداة في مساعدتنا جيدًا في المهام التالية:
- كم عدد أخطاء PHP التي ارتكبها عميل Bitrix24 على بوابة p1 في الساعة الماضية وأي منها؟ افهم واغفر وصحح بسرعة.
- ما هو عدد مكالمات الفيديو التي تم إجراؤها على البوابات الإلكترونية في ألمانيا خلال الـ 24 ساعة الماضية، وبأي جودة، وهل كانت هناك أي صعوبات في القناة/الشبكة؟
- ما مدى جودة عمل وظائف النظام (امتداد C الخاص بنا لـ PHP)، والتي تم تجميعها من المصدر في آخر تحديث للخدمة وتم طرحها للعملاء؟ هل هناك أخطاء منفصلة؟
- هل تتناسب بيانات العميل مع ذاكرة PHP؟ هل هناك أي أخطاء حول تجاوز الذاكرة المخصصة لعمليات: "نفاد الذاكرة"؟ البحث وتحييد.
وهنا مثال ملموس. على الرغم من الاختبارات الشاملة والمتعددة المستويات، تلقى العميل، الذي لديه حالة غير قياسية للغاية وبيانات إدخال تالفة، خطأً مزعجًا وغير متوقع، وانطلقت صفارة الإنذار وبدأت عملية إصلاحه بسرعة:
بالإضافة إلى ذلك، يتيح لك kibana تنظيم الإشعارات لأحداث محددة، وفي وقت قصير بدأ استخدام الأداة في الشركة من قبل عشرات الموظفين من أقسام مختلفة - بدءًا من الدعم الفني والتطوير وحتى ضمان الجودة.
أصبح نشاط أي قسم داخل الشركة ملائمًا للتتبع والقياس - فبدلاً من تحليل السجلات يدويًا على الخوادم، تحتاج فقط إلى إعداد سجلات التحليل مرة واحدة وإرسالها إلى المجموعة المرنة للاستمتاع بها، على سبيل المثال، التفكير في كيبانا لوحة القيادة عدد القطط ذات الرأسين المباعة المطبوعة على طابعة ثلاثية الأبعاد للشهر القمري الأخير.
تحليلات الأعمال الأساسية
يعلم الجميع أن تحليلات الأعمال في الشركات غالبًا ما تبدأ بالاستخدام النشط للغاية لبرنامج Excel، نعم. لكن الشيء الرئيسي هو أن الأمر لا ينتهي عند هذا الحد. تضيف Google Analytics المستندة إلى السحابة الزيت على النار أيضًا - حيث تبدأ سريعًا في التعود على الأشياء الجيدة.
في شركتنا التي تتطور بشكل متناغم، بدأ يظهر هنا وهناك "أنبياء" للعمل المكثف مع بيانات أكبر. بدأت الحاجة إلى تقارير أكثر تعمقا ومتعددة الأوجه تظهر بانتظام، ومن خلال جهود الرجال من مختلف الإدارات، تم منذ بعض الوقت تنظيم حل بسيط وعملي - مزيج من ClickHouse وPowerBI.
لفترة طويلة، ساعد هذا الحل المرن كثيرًا، ولكن بدأ الفهم تدريجيًا أن ClickHouse ليس مطاطًا ولا يمكن الاستهزاء به بهذه الطريقة.
من المهم هنا أن نفهم جيدًا أن ClickHouse، مثل Druid، مثل Vertica، مثل Amazon RedShift (الذي يعتمد على postgres)، هي محركات تحليلية مُحسّنة لإجراء تحليلات مريحة إلى حد ما (المبالغ والتجميعات والحد الأدنى الأقصى حسب العمود وعدد قليل من الصلات الممكنة )، لأن تم تنظيمها للتخزين الفعال لأعمدة الجداول العلائقية، على عكس MySQL وقواعد البيانات الأخرى (الموجهة نحو الصفوف) المعروفة لنا.
في جوهرها، ClickHouse هي مجرد "قاعدة بيانات" أكثر رحابة، مع إدراج غير مناسب للغاية بنقطة بنقطة (هذا هو المقصود، كل شيء على ما يرام)، ولكن تحليلات ممتعة ومجموعة من الوظائف القوية المثيرة للاهتمام للعمل مع البيانات. نعم، يمكنك حتى إنشاء مجموعة - لكنك تدرك أن طرق المسامير بالمجهر ليس صحيحًا تمامًا وبدأنا في البحث عن حلول أخرى.
الطلب على بايثون والمحللين
لدى شركتنا العديد من المطورين الذين يكتبون التعليمات البرمجية كل يوم تقريبًا لمدة 10-20 عامًا في PHP وJavaScript وC# وC/C++ وJava وGo وRust وPython وBash. هناك أيضًا العديد من مسؤولي النظام ذوي الخبرة الذين نجوا من أكثر من كارثة لا تصدق على الإطلاق ولا تتناسب مع قوانين الإحصاء (على سبيل المثال، عندما يتم تدمير غالبية الأقراص في غارة 10 بسبب ضربة صاعقة قوية). في مثل هذه الظروف، لفترة طويلة لم يكن من الواضح ما هو "محلل بايثون". Python مثل PHP، فقط الاسم أطول قليلاً وهناك آثار أقل قليلاً للمواد التي تغير العقل في الكود المصدري للمترجم. ومع ذلك، مع إنشاء المزيد والمزيد من التقارير التحليلية، بدأ المطورون ذوو الخبرة في فهم أهمية التخصص الضيق بشكل متزايد في أدوات مثل numpy وpandas وmatplotlib وseaborn.
من المرجح أن الدور الحاسم قد لعبه الإغماء المفاجئ للموظفين من مزيج عبارة "الانحدار اللوجستي" وإظهار التقارير الفعالة عن البيانات الكبيرة باستخدام نعم، نعم، pyspark.
Apache Spark، ونموذجها الوظيفي الذي يتناسب معه الجبر العلائقي بشكل مثالي، وقد تركت قدراتها انطباعًا كبيرًا على المطورين المعتادين على MySQL لدرجة أن الحاجة إلى تعزيز صفوف المحللين ذوي الخبرة أصبحت واضحة مثل اليوم.
محاولات أخرى لـ Apache Spark/Hadoop للانطلاق وما لم يسير وفقًا للنص
ومع ذلك، سرعان ما أصبح من الواضح أن شيئًا ما لم يكن صحيحًا تمامًا مع Spark، أو أنه كان من الضروري ببساطة غسل يديك بشكل أفضل. إذا تم إنشاء مكدس Hadoop/MapReduce/Lucene بواسطة مبرمجين ذوي خبرة إلى حد ما، وهو أمر واضح إذا نظرت عن كثب إلى الكود المصدري في Java أو أفكار Doug Cutting في Lucene، فإن Spark، فجأة، تمت كتابتها بلغة Scala الغريبة، والتي هي مثير للجدل للغاية من وجهة نظر التطبيق العملي ولا يتطور حاليًا. والانخفاض المنتظم في العمليات الحسابية على مجموعة Spark بسبب العمل غير المنطقي وغير الشفاف للغاية مع تخصيص الذاكرة لعمليات التخفيض (تصل العديد من المفاتيح في وقت واحد) قد خلق هالة حولها لشيء لديه مجال للنمو. بالإضافة إلى ذلك، تفاقم الوضع بسبب العدد الكبير من المنافذ المفتوحة الغريبة، والملفات المؤقتة التي تنمو في أكثر الأماكن غير المفهومة، وجحيم من تبعيات الجرة - مما جعل مسؤولي النظام لديهم شعور واحد معروف جيدًا منذ الطفولة: الكراهية الشرسة (أو ربما كانوا بحاجة إلى غسل أيديهم بالصابون).
ونتيجة لذلك، فقد نجحنا في "النجاة" من العديد من المشاريع التحليلية الداخلية التي تستخدم Apache Spark بشكل فعال (بما في ذلك Spark Streaming وSpark SQL) والنظام البيئي Hadoop (وما إلى ذلك وما إلى ذلك). على الرغم من حقيقة أننا تعلمنا مع مرور الوقت إعداد ومراقبة "ذلك" جيدًا، وتوقف "هو" عمليا عن الانهيار فجأة بسبب التغيرات في طبيعة البيانات وعدم توازن تجزئة RDD الموحدة، فإن الرغبة في أخذ شيء جاهز بالفعل ، وتحديثها وإدارتها في مكان ما في السحابة أصبحت أقوى وأقوى. في هذا الوقت حاولنا استخدام التجميع السحابي الجاهز لخدمات Amazon Web Services - وبعد ذلك حاول حل المشكلات باستخدامه. EMR هو Apache Spark الذي أعدته أمازون مع برامج إضافية من النظام البيئي، تمامًا مثل إنشاءات Cloudera/Hortonworks.
يعد تخزين الملفات المطاطية للتحليلات حاجة ملحة
تجربة "طبخ" Hadoop/Spark مع الحروق في أجزاء مختلفة من الجسم لم تذهب سدى. أصبحت الحاجة إلى إنشاء وحدة تخزين ملفات واحدة وغير مكلفة وموثوقة تكون مقاومة لفشل الأجهزة ويمكن فيها تخزين الملفات بتنسيقات مختلفة من أنظمة مختلفة وعمل عينات فعالة وموفرة للوقت للتقارير من هذه البيانات أمرًا متزايدًا واضح.
أردت أيضًا ألا يتحول تحديث برنامج هذا النظام الأساسي إلى كابوس رأس السنة الجديدة من خلال قراءة آثار Java المكونة من 20 صفحة وتحليل السجلات التفصيلية للمجموعة التي يبلغ طولها كيلومترًا واحدًا باستخدام Spark History Server وعدسة مكبرة بإضاءة خلفية. كنت أرغب في الحصول على أداة بسيطة وشفافة لا تتطلب الغوص المنتظم تحت الغطاء إذا توقف تنفيذ طلب MapReduce القياسي للمطور عندما سقط عامل تقليل البيانات من الذاكرة بسبب خوارزمية تقسيم بيانات المصدر التي لم يتم اختيارها جيدًا.
هل Amazon S3 مرشح لـ DataLake؟
علمتنا تجربة Hadoop/MapReduce أننا بحاجة إلى نظام ملفات موثوق وقابل للتطوير وعمال قابلين للتطوير فوقه، "يقتربون" من البيانات حتى لا يتم نقل البيانات عبر الشبكة. يجب أن يكون العمال قادرين على قراءة البيانات بتنسيقات مختلفة، ولكن يفضل عدم قراءة المعلومات غير الضرورية وأن يكونوا قادرين على تخزين البيانات مسبقًا بتنسيقات مناسبة للعاملين.
مرة أخرى، الفكرة الأساسية. ليست هناك رغبة في "صب" البيانات الضخمة في محرك تحليلي جماعي واحد، والذي سوف يختنق عاجلاً أم آجلاً وسيتعين عليك تحطيمه بشكل قبيح. أريد تخزين الملفات، الملفات فقط، بتنسيق مفهوم وإجراء استعلامات تحليلية فعالة عليها باستخدام أدوات مختلفة ولكن مفهومة. وسيكون هناك المزيد والمزيد من الملفات بتنسيقات مختلفة. ومن الأفضل عدم تقطيع المحرك، بل البيانات المصدر. نحن بحاجة إلى DataLake عالمية وقابلة للتوسيع، قررنا...
ماذا لو قمت بتخزين الملفات في وحدة التخزين السحابية المألوفة والمعروفة القابلة للتطوير Amazon S3، دون الحاجة إلى إعداد القطع الخاصة بك من Hadoop؟
من الواضح أن البيانات الشخصية "منخفضة"، ولكن ماذا عن البيانات الأخرى إذا أخذناها إلى هناك و"قمنا بها بفعالية"؟
النظام البيئي لتحليل البيانات الضخمة في Amazon Web Services - بكلمات بسيطة جدًا
انطلاقًا من تجربتنا مع AWS، تم استخدام Apache Hadoop/MapReduce بنشاط هناك لفترة طويلة تحت صلصات مختلفة، على سبيل المثال في خدمة DataPipeline (أنا أحسد زملائي، لقد تعلموا كيفية تحضيره بشكل صحيح). قمنا هنا بإعداد نسخ احتياطية من خدمات مختلفة من جداول DynamoDB:
وقد تم تشغيلها بانتظام على مجموعات Hadoop/MapReduce المضمنة كالساعة منذ عدة سنوات حتى الآن. "اضبطها واتركها":
يمكنك أيضًا الانخراط بشكل فعال في شيطانية البيانات من خلال إعداد أجهزة كمبيوتر Jupiter المحمولة في السحابة للمحللين واستخدام خدمة AWS SageMaker لتدريب نماذج الذكاء الاصطناعي ونشرها في المعركة. وهنا ما يبدو بالنسبة لنا:
ونعم، يمكنك التقاط جهاز كمبيوتر محمول لنفسك أو لمحلل في السحابة وإرفاقه بمجموعة Hadoop/Spark، وإجراء الحسابات ثم تثبيت كل شيء:
مناسب حقًا للمشاريع التحليلية الفردية وبالنسبة للبعض استخدمنا خدمة السجلات الطبية الإلكترونية (EMR) بنجاح لإجراء حسابات وتحليلات واسعة النطاق. ماذا عن حل نظام DataLake، هل سينجح؟ في هذه اللحظة كنا على حافة الأمل واليأس وواصلنا البحث.
AWS Glue - Apache Spark المعبأ بدقة على المنشطات
اتضح أن AWS لديها نسختها الخاصة من مكدس "Hive/Pig/Spark". دور الخلية، أي. يتم تنفيذ كتالوج الملفات وأنواعها في DataLake بواسطة خدمة "كتالوج البيانات"، والتي لا تخفي توافقها مع تنسيق Apache Hive. تحتاج إلى إضافة معلومات إلى هذه الخدمة حول مكان وجود ملفاتك وبأي تنسيق توجد. يمكن أن تكون البيانات ليس فقط في s3، ولكن أيضًا في قاعدة البيانات، ولكن هذا ليس موضوع هذا المنشور. إليك كيفية تنظيم دليل بيانات DataLake الخاص بنا:
تم تسجيل الملفات، عظيم. إذا تم تحديث الملفات، فإننا نقوم بتشغيل برامج الزحف إما يدويًا أو وفقًا لجدول زمني، مما سيؤدي إلى تحديث المعلومات المتعلقة بها من البحيرة وحفظها. ومن ثم يمكن معالجة البيانات من البحيرة وتحميل النتائج في مكان ما. في أبسط الحالات، نقوم أيضًا بالتحميل إلى s3. يمكن إجراء معالجة البيانات في أي مكان، ولكن يُقترح أن تقوم بتكوين المعالجة على مجموعة Apache Spark باستخدام الإمكانات المتقدمة من خلال AWS Glue API. في الواقع، يمكنك أخذ كود بايثون القديم والمألوف باستخدام مكتبة pyspark وتكوين تنفيذه على عقد N لمجموعة ذات سعة معينة مع المراقبة، دون البحث في أحشاء Hadoop وسحب حاويات docker-moker وإزالة تعارضات التبعية .
مرة أخرى، فكرة بسيطة. ليست هناك حاجة لتكوين Apache Spark، كل ما تحتاجه هو كتابة كود python لـ pyspark واختباره محليًا على سطح المكتب ثم تشغيله على مجموعة كبيرة في السحابة، مع تحديد مكان البيانات المصدر ومكان وضع النتيجة. في بعض الأحيان يكون هذا ضروريًا ومفيدًا، وإليك كيفية إعداده:
وبالتالي، إذا كنت بحاجة إلى حساب شيء ما على مجموعة Spark باستخدام البيانات الموجودة في s3، فسنكتب التعليمات البرمجية في python/pyspark، ونختبره، ونتمنى لك حظًا سعيدًا للسحابة.
ماذا عن التنسيق؟ ماذا لو سقطت المهمة واختفت؟ نعم، يُقترح إنشاء خط أنابيب جميل بأسلوب Apache Pig وقد جربناه، ولكن في الوقت الحالي قررنا استخدام تنسيقنا المخصص للغاية في PHP وJavaScript (أفهم أن هناك تنافرًا معرفيًا، لكنه يعمل، من أجل سنوات وبدون أخطاء).
تنسيق الملفات المخزنة في البحيرة هو مفتاح الأداء
من المهم جدًا أن نفهم نقطتين رئيسيتين أخريين. لكي يتم تنفيذ الاستعلامات المتعلقة ببيانات الملف في البحيرة في أسرع وقت ممكن وعدم انخفاض الأداء عند إضافة معلومات جديدة، فإنك تحتاج إلى:
- قم بتخزين أعمدة الملفات بشكل منفصل (حتى لا تضطر إلى قراءة جميع السطور لفهم ما هو موجود في الأعمدة). لهذا أخذنا تنسيق الباركيه مع الضغط
- من المهم جدًا تقسيم الملفات إلى مجلدات مثل: اللغة، السنة، الشهر، اليوم، الأسبوع. المحركات التي تفهم هذا النوع من التقسيم ستنظر فقط إلى المجلدات الضرورية، دون غربلة جميع البيانات المتتالية.
بشكل أساسي، بهذه الطريقة، يمكنك وضع البيانات المصدر في الشكل الأكثر كفاءة للمحركات التحليلية المعلقة في الأعلى، والتي حتى في المجلدات المقسمة يمكنها إدخال وقراءة الأعمدة الضرورية فقط من الملفات بشكل انتقائي. لا تحتاج إلى "ملء" البيانات في أي مكان (ستنفجر وحدة التخزين ببساطة) - ما عليك سوى وضعها بحكمة على الفور في نظام الملفات بالتنسيق الصحيح. بالطبع، يجب أن يكون واضحًا هنا أن تخزين ملف CSV ضخم في DataLake، والذي يجب أولاً قراءته سطرًا تلو الآخر بواسطة المجموعة من أجل استخراج الأعمدة، ليس أمرًا مستحسنًا للغاية. فكر في النقطتين المذكورتين أعلاه مرة أخرى إذا لم يكن من الواضح بعد سبب حدوث كل هذا.
AWS أثينا - الأداة المساعدة
وبعد ذلك، أثناء إنشاء بحيرة، صادفنا بطريقة ما أمازون أثينا. فجأة اتضح أنه من خلال ترتيب ملفات السجل الضخمة لدينا بعناية في أجزاء مجلدات بتنسيق العمود الصحيح (الباركيه)، يمكنك بسرعة إجراء تحديدات مفيدة للغاية منها وإنشاء تقارير بدونها، بدون مجموعة Apache Spark/Glue.
يعتمد محرك Athena المدعوم بالبيانات الموجودة في s3 على الأسطوري - ممثل لمجموعة أساليب MPP (المعالجة المتوازية الضخمة) لمعالجة البيانات، وأخذ البيانات أينما كانت، من s3 وHadoop إلى Cassandra والملفات النصية العادية. كل ما عليك فعله هو أن تطلب من Athena تنفيذ استعلام SQL، وبعد ذلك "يعمل كل شيء بسرعة وبشكل تلقائي". من المهم أن نلاحظ أن Athena هو برنامج "ذكي"، فهو يذهب فقط إلى المجلدات المجزأة الضرورية ويقرأ فقط الأعمدة المطلوبة في الطلب.
إن أسعار الطلبات المقدمة إلى أثينا مثيرة للاهتمام أيضًا. نحن ندفع ثمنها . أولئك. ليس لعدد الأجهزة في المجموعة في الدقيقة، ولكن... بالنسبة للبيانات التي تم مسحها فعليًا على 100-500 جهاز، فقط البيانات اللازمة لإكمال الطلب.
ومن خلال طلب الأعمدة الضرورية فقط من المجلدات المقسمة بشكل صحيح، اتضح أن خدمة Athena تكلفنا عشرات الدولارات شهريًا. حسنًا، رائع، مجاني تقريبًا، مقارنة بالتحليلات المتعلقة بالمجموعات!
بالمناسبة، إليك كيفية تقسيم بياناتنا في s3:
نتيجة لذلك، في وقت قصير، بدأت أقسام مختلفة تمامًا في الشركة، بدءًا من أمن المعلومات ووصولاً إلى التحليلات، في تقديم طلبات إلى أثينا وبسرعة، في ثوانٍ، تلقي إجابات مفيدة من البيانات "الكبيرة" على مدى فترات طويلة إلى حد ما: أشهر، نصف عام، الخ.ص.
لكننا ذهبنا أبعد من ذلك وبدأنا في الذهاب إلى السحابة للحصول على إجابات : يقوم المحلل بكتابة استعلام SQL في وحدة تحكم مألوفة، والتي ترسل البيانات إلى s100 على 500-3 جهاز "مقابل أجر زهيد" وتعيد الإجابة عادةً في بضع ثوانٍ. مريح. و بسرعة. لا أستطيع تصديق ذلك حتى الآن.
ونتيجة لذلك، بعد أن قررنا تخزين البيانات في s3، بتنسيق عمودي فعال ومع تقسيم البيانات بشكل معقول إلى مجلدات... تلقينا DataLake ومحرك تحليلي سريع ورخيص - مجانًا. وأصبح يتمتع بشعبية كبيرة في الشركة، لأنه... يفهم SQL ويعمل بأوامر كبيرة بشكل أسرع من خلال بدء/إيقاف/إعداد المجموعات. "وإذا كانت النتيجة هي نفسها، لماذا ندفع أكثر؟"
يبدو الطلب إلى أثينا شيئًا كهذا. إذا رغبت في ذلك، بالطبع، يمكنك تشكيل ما يكفي ، لكننا سنقتصر على التجميع البسيط. دعونا نرى ما هي رموز الاستجابة التي كان لدى العميل قبل بضعة أسابيع في سجلات خادم الويب والتأكد من عدم وجود أخطاء:
النتائج
بعد أن قطعنا طريقًا طويلًا ولكن مؤلمًا، وقمنا بتقييم المخاطر ومستوى التعقيد وتكلفة الدعم بشكل مناسب باستمرار، وجدنا حلاً لـ DataLake والتحليلات التي لا تتوقف أبدًا عن إرضائنا بسرعة وتكلفة الملكية.
اتضح أن بناء DataLake فعال وسريع ورخيص التشغيل لتلبية احتياجات أقسام الشركة المختلفة تمامًا هو ضمن قدرات المطورين ذوي الخبرة الذين لم يعملوا أبدًا كمهندسين معماريين ولا يعرفون كيفية رسم المربعات على المربعات الأسهم ومعرفة 50 مصطلحًا من نظام Hadoop البيئي.
في بداية الرحلة، كان رأسي ينفصل عن حدائق الحيوان البرية العديدة للبرمجيات المفتوحة والمغلقة وفهم عبء المسؤولية تجاه الأحفاد. ما عليك سوى البدء في إنشاء DataLake الخاص بك باستخدام أدوات بسيطة: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3...، وجمع التعليقات والفهم العميق لفيزياء العمليات التي تحدث. كل شيء معقد وغامض - أعطه للأعداء والمنافسين.
إذا كنت لا ترغب في الانتقال إلى السحابة وترغب في دعم المشاريع مفتوحة المصدر وتحديثها وتصحيحها، فيمكنك إنشاء مخطط مشابه لمخططنا محليًا، على أجهزة مكتبية غير مكلفة مع وجود Hadoop وPresto في الأعلى. الشيء الرئيسي هو عدم التوقف والمضي قدمًا، والعد، والبحث عن حلول بسيطة وواضحة، وكل شيء سينجح بالتأكيد! حظا سعيدا للجميع ونراكم مرة أخرى!
المصدر: www.habr.com