ليس من قبيل الصدفة أن الزملاء الأكثر خبرة ، ورؤوسهم مليئة بالأخطاء ومن هذا الشعر الرمادي بالفعل ، يفكرون في النشر السريع بشكل لا يصدق لحزم "الحاويات" في "المكعبات" على عشرات الخوادم في "لغات عصرية" مع دعم مدمج للإدخال / الإخراج غير المتزامن غير المحظور - ابتسامة متواضعة ... ويستمرون بصمت في إعادة قراءة "man ps" ، والتعمق في الكود المصدري لـ "nginx" حتى ينزف الدم من أعينهم واختبارات وحدة الكتابة والكتابة والكتابة. يعرف الزملاء أن الأمر الأكثر إثارة سيكون في المستقبل ، عندما يصبح "كل هذا" ليلة واحدة على رأس المال في ليلة رأس السنة الجديدة. وفقط الفهم العميق لطبيعة نظام يونكس ، وجدول حالة TCP / IP المكتسب وخوارزميات البحث الفرز الأساسية سيساعدهم. لإعادة النظام إلى الحياة تحت الأجراس.
أوه نعم ، لقد كنت مشتتًا قليلاً ، لكني آمل أن أتمكن من نقل حالة الترقب.
أود اليوم أن أشارك تجربتنا في نشر مكدس مناسب وغير مكلف لـ DataLake ، والذي يحل معظم المهام التحليلية في شركة لأقسام هيكلية مختلفة تمامًا.
منذ بعض الوقت ، توصلنا إلى فهم أن الشركة تحتاج إلى المزيد والمزيد من ثمار كل من المنتج والتحليلات التقنية (ناهيك عن الكرز الموجود على الكعكة في شكل التعلم الآلي) وأنه من أجل فهم الاتجاهات والمخاطر ، يجب جمع المزيد والمزيد وتحليله. المزيد من المقاييس.
التحليلات الفنية الأساسية في Bitrix24
منذ عدة سنوات ، وبالتزامن مع إطلاق خدمة Bitrix24 ، استثمرنا الوقت والموارد بنشاط في إنشاء منصة تحليلية بسيطة وموثوقة من شأنها أن تساعدنا في رؤية مشاكل البنية التحتية بسرعة وتخطيط الخطوة التالية. بالطبع ، كان من المستحسن أن تأخذ الأدوات جاهزة وبسيطة ومفهومة قدر الإمكان. نتيجة لذلك ، تم اختيار nagios للمراقبة و munin للتحليلات والتصور. الآن لدينا آلاف الشيكات في ناجيوس ، ومئات المخططات في مونين والزملاء كل يوم ونستخدمها بنجاح. المقاييس واضحة ، والرسوم البيانية واضحة ، والنظام يعمل بشكل موثوق به لعدة سنوات ويتم إضافة اختبارات ورسوم بيانية جديدة إليه بانتظام: لقد قمنا بتشغيل خدمة جديدة - نضيف العديد من الاختبارات والرسوم البيانية. حظا سعيدا.
Hand on the Pulse - تحليلات تقنية متقدمة
أدت الرغبة في تلقي معلومات حول المشكلات "في أسرع وقت ممكن" إلى إجراء تجارب نشطة بأدوات بسيطة ومفهومة - pinba و xhprof.
أرسل لنا Pinba إحصائيات حزم UDP حول سرعة أجزاء من صفحات الويب في PHP وكان من الممكن أن نرى عبر الإنترنت في تخزين MySQL (يأتي pinba مع محرك MySQL الخاص به لتحليلات الأحداث السريعة) قائمة مختصرة بالمشكلات والرد عليها. و xhprof في الوضع التلقائي أتاح جمع الرسوم البيانية للتنفيذ لأبطأ صفحات PHP من العملاء وتحليل ما يمكن أن يؤدي إلى ذلك - بهدوء ، سكب الشاي أو شيء أقوى.
منذ بعض الوقت ، تم استكمال مجموعة الأدوات بمحرك آخر بسيط ومباشر إلى حد ما يعتمد على خوارزمية الفهرسة العكسية ، والتي تم تنفيذها بشكل مثالي في مكتبة Lucene الأسطورية - Elastic / Kibana. الفكرة البسيطة لكتابة المستندات متعددة الخيوط إلى فهرس Lucene المعكوس بناءً على الأحداث الموجودة في السجلات والبحث السريع خلالها باستخدام تقسيم الأوجه تبين أنها مفيدة حقًا.
على الرغم من نوع التصورات التقنية إلى حد ما في Kibana مع مفاهيم "التدفق لأعلى" منخفضة المستوى مثل "bucket" واللغة المبتكرة حديثًا للجبر العلائقي الذي لم يُنسى بعد ، بدأت الأداة في مساعدتنا جيدًا في المهام التالية:
- كم عدد أخطاء PHP التي واجهها عميل Bitrix24 على بوابة p1 في الساعة الماضية ، وأيها؟ فهم ، سامح وإصلاح بسرعة.
- - 24 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
هذا مثال ملموس. على الرغم من الاختبار الدقيق ومتعدد المستويات ، فقد تعرض العميل ، مع حالة غير قياسية للغاية وبيانات إدخال تالفة ، لخطأ مزعج وغير متوقع
، وصدرت صفارة الإنذار وبدأت عملية الإصلاح السريع: بالإضافة إلى ذلك ، يتيح لك kibana تنظيم الإخطار بالأحداث المحددة وفي وقت قصير أصبح استخدام عشرات الموظفين من مختلف الإدارات - من الدعم الفني والتطوير إلى ضمان الجودة.
أصبح نشاط أي قسم داخل الشركة مناسبًا للتتبع والقياس - فبدلاً من التحليل اليدوي للسجلات على الخوادم ، يكفي إعداد تحليل السجلات وإرسالها إلى الكتلة المرنة مرة واحدة للاستمتاع ، على سبيل المثال ، التفكير في لوحة معلومات kibana في عدد القطط المباعة ذات الرأسين المطبوعة على 3-d طابعة لآخر شهر قمري.
ذكاء الأعمال الأساسي
يعلم الجميع أن ذكاء الأعمال في الشركات غالبًا ما يبدأ باستخدام نشط للغاية ، نعم ، نعم ، Excel. لكن الشيء الرئيسي هو أنه لا ينتهي عند هذا الحد. تضيف Cloud 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. هناك أيضًا العديد من مسؤولي النظام ذوي الخبرة الذين نجوا من أكثر من كارثة واحدة لا تصدق على الإطلاق لا تتناسب مع قوانين الإحصاء (على سبيل المثال ، عندما يتم تدمير معظم الأقراص في raid-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 ، وبعد ذلك ، حاولنا حل المشكلات الموجودة بالفعل. EMR عبارة عن Apache Spark أعدته أمازون ببرنامج إضافي من النظام البيئي ، على غرار Cloudera / Hortonworks.
تخزين الملفات المطاطية للتحليلات - حاجة ملحة
لم تكن تجربة "الطبخ" Hadoop / Spark مع الحروق في أجزاء مختلفة من الجسم عبثًا. بدأت الحاجة إلى إنشاء تخزين ملف واحد وغير مكلف وموثوق به يكون مقاومًا لأعطال الأجهزة ويمكن فيه تخزين الملفات بتنسيقات مختلفة من أنظمة مختلفة والتي سيكون من الممكن فيها إجراء تحديدات فعالة وفي وقت معقول للتقارير في الظهور بشكل أكثر وضوحًا.
أردت أيضًا ألا يتحول تحديث البرنامج لهذه المنصة إلى كابوس رأس السنة الجديدة بقراءة آثار جافا المكونة من 20 صفحة وتحليل سجلات المجموعة التفصيلية بطول كيلومتر باستخدام Spark History Server وعدسة مكبرة بإضاءة خلفية. كنت أرغب في الحصول على أداة بسيطة وشفافة لا تتطلب الغوص المنتظم تحت الغطاء ، إذا توقف المطور عن تنفيذ طلب MapReduce قياسي عندما يخرج عامل تقليل البيانات من الذاكرة باستخدام خوارزمية التقسيم المختارة بشكل سيئ للبيانات الأولية.
Amazon S3 هل هو مرشح DataLake؟
علمت التجربة مع Hadoop / MapReduce أنك بحاجة إلى نظام ملفات قابل للتطوير وموثوق وعاملين قابلين للتطوير فوقه ، "يقتربون" من البيانات ، حتى لا تدفع البيانات عبر الشبكة. يجب أن يكون العمال قادرين على قراءة البيانات بتنسيقات مختلفة ، ولكن يفضل عدم قراءة المعلومات غير الضرورية وبالتالي يمكن تخزين البيانات مسبقًا بتنسيقات ملائمة للعاملين.
مرة أخرى ، الفكرة الرئيسية.ليست هناك رغبة في "تحميل" البيانات الضخمة في محرك تحليلي عنقودي واحد ، والذي سيغرق عاجلاً أم آجلاً وسيتعين أن يكون قبيحًا. أرغب في تخزين الملفات ، الملفات فقط ، بتنسيق مفهوم وإجراء استعلامات تحليلية فعالة عليها باستخدام أدوات مختلفة ولكنها مفهومة. وسيكون هناك المزيد والمزيد من الملفات بتنسيقات مختلفة. ومن الأفضل عدم تفكيك المحرك ، ولكن البيانات الأولية. نحن بحاجة إلى DataLake قابلة للتوسيع ومتعددة الاستخدامات ، قررنا ...
ماذا لو قمنا بتخزين الملفات في التخزين السحابي المألوف والمعروف القابل للتطوير Amazon S3 دون الحاجة إلى صنع القطع الخاصة بنا من Hadoop؟
من الواضح أن البيانات "أسفل" ، لكن البيانات الأخرى إذا أخرجتها و "دفعتها بفعالية"؟
النظام البيئي التحليلي العنقودي لخدمات الويب من أمازون - بكلمات بسيطة للغاية
انطلاقًا من تجربتنا مع AWS ، فقد تم استخدامه بنشاط هناك لفترة طويلة تحت أنواع مختلفة من صلصات Apache Hadoop / MapReduce ، على سبيل المثال ، في خدمة DataPipeline (أحسد زملائي ، لقد تعلموا كيفية طهيه بشكل صحيح). هنا قمنا بتكوين نسخ احتياطية من خدمات مختلفة من جداول DynamoDB:
وقد تم إجراؤها بانتظام على مجموعات Hadoop / MapReduce المدمجة مثل آلية الساعة لعدة سنوات. قم
بإعداده ونسيانه : يمكنك أيضًا الانخراط بشكل فعال في علم البيانات من خلال رفع أجهزة كمبيوتر Jupiter المحمولة للمحللين في السحابة واستخدام AWS SageMaker للتدريب ونشر نماذج الذكاء الاصطناعي في المعركة. إليك كيف يبدو معنا:
ونعم ، يمكنك اختيار كمبيوتر محمول في السحابة لنفسك أو التحليلات وإرفاقه بمجموعة Hadoop / Spark ، ثم حساب ثم "تثبيت" كل شيء:
مناسب حقًا للمشاريع التحليلية الفردية وبالنسبة للبعض ، فقد استخدمنا بنجاح خدمة السجلات الطبية الإلكترونية (EMR) لإجراء عمليات حسابية وتحليلات واسعة النطاق. ماذا عن حل نظام DataLake ، هل سيعمل؟ في تلك اللحظة كنا على وشك الأمل واليأس وواصلنا بحثنا.
AWS Glue - Apache Spark معبأ بدقة "على المنشطات"
اتضح أن AWS لديها نسختها الخاصة من Hive / Pig / Spark stack. دور الخلية ، أي يقوم فهرس الملفات وأنواعها في DataLake بتشغيل خدمة "كتالوج البيانات" ، والتي لا تخفي توافقها مع تنسيق Apache Hive. في هذه الخدمة ، تحتاج إلى إضافة معلومات حول مكان وجود ملفاتك وبأي تنسيق. يمكن أن تكون البيانات ليس فقط في s3 ، ولكن أيضًا في قاعدة البيانات ، ولكن هذا لا يتعلق بذلك في هذا المنشور. إليك كيفية تنظيم دليل البيانات DataLake هنا:
الملفات مسجلة ، عظيم. إذا تم تحديث الملفات ، فإننا نبدأ إما يدويًا أو وفقًا لجدول زمني بواسطة برامج الزحف ، والتي ستعمل على تحديث المعلومات عنها من البحيرة وحفظها. ثم يمكن معالجة البيانات من البحيرة ويمكن تفريغ النتائج في مكان ما. في أبسط الحالات ، نقوم بتحميله إلى s3 أيضًا. يمكن إجراء معالجة البيانات في أي مكان ، ولكن يُقترح إعداد المعالجة على مجموعة Apache Spark باستخدام إمكانات متقدمة من خلال AWS Glue API. في الواقع ، يمكنك أن تأخذ كود python القديم الجيد والمألوف باستخدام مكتبة pyspark وتهيئتها لتعمل على N عقد من مجموعة ذات بعض السعة مع المراقبة ، دون الحفر في أحشاء Hadoop وسحب حاويات عامل التحميل والتخلص من تعارضات التبعية.
مرة أخرى ، فكرة بسيطة.لا تحتاج إلى تكوين Apache Spark ، ما عليك سوى كتابة رمز Python لـ pyspark ، واختباره محليًا على سطح المكتب ثم تشغيله على مجموعة كبيرة في السحابة ، مما يشير إلى مكان بيانات المصدر ومكان وضع النتيجة. في بعض الأحيان يكون ذلك ضروريًا ومفيدًا ، وهذه هي طريقة تكوينه معنا:
وبالتالي ، إذا كنت بحاجة إلى حساب شيء ما في مجموعة Spark على البيانات في s3 - اكتب الكود في python / pyspark ، واختبره واستمتع برحلة جيدة إلى السحابة.
ماذا عن التناغم؟ ماذا لو سقطت المهمة واختفت؟ نعم ، يُقترح إنشاء خط أنابيب جميل بأسلوب Apache Pig وقد جربناها أيضًا ، لكننا قررنا استخدام تنسيقنا المخصص بعمق في PHP و JavaScript في الوقت الحالي (أفهم أن هناك تنافرًا معرفيًا ، ولكنه يعمل لسنوات وبدون أخطاء).
تنسيق ملف البحيرة هو مفتاح الأداء
من المهم جدًا فهم نقطتين أساسيتين أخريين. لكي يتم تنفيذ طلبات البيانات من الملفات الموجودة في البحيرة بأسرع ما يمكن ولا يتدهور الأداء عند إضافة معلومات جديدة ، فأنت بحاجة إلى:
- قم بتخزين أعمدة الملف بشكل منفصل (بحيث لا تحتاج إلى قراءة جميع الأسطر لفهم ما هو موجود في الأعمدة). لهذا اتخذنا تنسيق الباركيه مع الضغط
- من المهم جدًا أن يقوم الآباء بتجزئة الملفات بروح: اللغة ، السنة ، الشهر ، اليوم ، الأسبوع. ستنظر المحركات التي تفهم هذا النوع من التجزئة إلى الآباء المناسبين فقط ، دون دفع جميع البيانات عبر نفسها.
في الواقع ، بهذه الطريقة ، يمكنك وضع البيانات الأولية للمحركات التحليلية المعلقة في الأعلى بالشكل الأكثر فاعلية ، والتي يمكن أن تدخل بشكل انتقائي أبيات القطع وقراءة الأعمدة الضرورية فقط من الملفات. ليست هناك حاجة للذهاب إلى أي مكان ، فسوف يتحول إلى "ملء" البيانات (سوف ينفجر التخزين ببساطة) - فقط ضعها بشكل معقول في نظام الملفات بالتنسيق الصحيح على الفور. بالطبع ، يجب أن يكون واضحًا هنا أن تخزين ملف csv ضخم في DataLake ، والذي يجب قراءته أولاً بواسطة مجموعة سطر بسطر ، لاستخراج الأعمدة ، ليس مستحسنًا جدًا. فكر في النقطتين السابقتين مرة أخرى إذا لم يكن من الواضح بعد سبب كل هذا.
AWS Athena - "الجحيم" خارج صندوق السعوط
وبعد ذلك ، أثناء إنشاء البحيرة ، وجدنا بطريقة ما بالصدفة أمازون أثينا. فجأة اتضح أنه من خلال طي ملفات السجل الضخمة الخاصة بنا بدقة بواسطة شظايا الأب بالتنسيق الرأسي الصحيح (الباركيه) ، يمكنك إجراء تحديدات مفيدة للغاية عليها وإنشاء تقارير دون الحاجة إلى مجموعة Apache Spark / Glue.
يعتمد محرك البيانات s3 Athena على Presto الأسطوري ، وهو عضو في عائلة MPP (المعالجة المتوازية الضخمة) لأساليب معالجة البيانات ، مع أخذ البيانات حيث تكمن ، من s3 و Hadoop إلى Cassandra وملفات النص العادي. ما عليك سوى أن تطلب من أثينا تنفيذ استعلام SQL ، ثم كل شيء "يعمل بسرعة ومن تلقاء نفسه". من المهم أن نلاحظ أن أثينا "ذكية" ، وتذهب فقط إلى الآباء المبعوثين الضروريين وتقرأ فقط الأعمدة المطلوبة في الطلب.
الطلبات إلى أثينا تدفع أيضًا بشكل مثير للاهتمام. نحن ندفع مقابل كمية البيانات الممسوحة ضوئيًا . أولئك. ليس لعدد الآلات في الكتلة في الدقيقة ، ولكن ... للبيانات التي تم مسحها ضوئيًا بالفعل على 100-500 جهاز ، فقط البيانات اللازمة لتلبية الطلب.
ومن خلال طلب الأعمدة الضرورية فقط من الآباء المبعدين بشكل صحيح ، اتضح أن خدمة أثينا تكلفنا عشرات الدولارات شهريًا. حسنًا ، رائع ، مجاني تقريبًا ، مقارنةً بالتحليلات على المجموعات!
بالمناسبة ، هذه هي الطريقة التي نتبادل بها بياناتنا في s3:
نتيجة لذلك ، في وقت قصير ، بدأت الأقسام المختلفة تمامًا في الشركة ، من أمن المعلومات إلى التحليلات ، في تقديم الطلبات بنشاط إلى أثينا ، وبسرعة ، في ثوانٍ ، تتلقى إجابات مفيدة من "الكبار" بيانات لفترات طويلة نوعًا ما: شهور ، نصف عام ، إلخ.
لكننا ذهبنا إلى أبعد من ذلك وبدأنا في الذهاب إلى السحابة للحصول على إجابات عبر برنامج تشغيل ODBC : يكتب محلل استعلام SQL في وحدة تحكم مألوفة ، والتي ، على 100-500 آلة ، بيانات الصوف "مقابل فلس واحد" في s3 ويعيد الإجابة عادةً في بضع ثوانٍ. ملائم. و بسرعة. مازلت لا أستطيع أن أصدق ذالك.
نتيجة لذلك ، بعد أن اتخذنا قرارًا بتخزين البيانات في s3 ، بتنسيق عمودي فعال وبتقسيم معقول للبيانات من قبل الآباء ... حصلنا على DataLake ومحرك تحليلي سريع ورخيص - مجانًا. وأصبح يتمتع بشعبية كبيرة مع الشركة بسبب يفهم SQL ويقوم بتشغيل أوامر الحجم بشكل أسرع من بدء / إيقاف / تكوين المجموعات. "وإذا كانت النتيجة واحدة ، فلماذا تدفع أكثر؟"
يبدو الطلب إلى أثينا شيئًا كهذا. إذا رغبت ، بالطبع ، يمكنك تكوين ما يكفياستعلام SQL معقد ومتعدد الصفحات ، لكننا سنقتصر على التجميع البسيط. دعنا نرى رموز الاستجابة التي كان لدى العميل قبل بضعة أسابيع في سجلات خادم الويب والتأكد من عدم وجود أخطاء:
الاستنتاجات
بعد أن ذهبنا ، حتى لا نقول إنه مسار طويل ، ولكنه مؤلم ، ونقيم المخاطر باستمرار ومستوى التعقيد وتكلفة الدعم بشكل مناسب ، وجدنا حلاً لـ DataLake والتحليلات التي لا تتوقف أبدًا عن إرضائنا بالسرعة وتكلفة الملكية.
اتضح أنه حتى المطورين المتمرسين الذين لا يعملون أبدًا كمهندسين معماريين ولا يمكنهم رسم مربعات على مربعات بها أسهم والذين يعرفون 50 مصطلحًا من نظام Hadoop البيئي ، يمكنهم بناء DataLake فعال وسريع ورخيص لتلبية احتياجات أقسام مختلفة تمامًا من الشركة.
في بداية الرحلة ، كان رأسي ينفصل عن مجموعة أعنف حدائق الحيوان من البرامج المفتوحة والمغلقة وفهم عبء المسؤولية على الأحفاد. فقط ابدأ في بناء DataLake الخاص بك من أدوات بسيطة: nagios / munin -> مرن / kibana -> Hadoop / Spark / s3 ... ، وجمع التعليقات وفهم فيزياء العمليات الجارية بعمق. كل شيء معقد وموحل - أعطه لأعدائك ومنافسيك.
إذا كنت لا ترغب في الانتقال إلى السحابة وترغب في الحفاظ على مشروعات مفتوحة المصدر وتحديثها وتصحيحها ، فيمكنك إنشاء مخطط مشابه لمخططنا محليًا على أجهزة مكتبية منخفضة التكلفة مع Hadoop و Presto في الأعلى. الشيء الرئيسي هو عدم التوقف والمضي قدمًا ، والعد ، والبحث عن حلول بسيطة وواضحة ، وكل شيء سينجح بالتأكيد! حظ موفق للجميع ونراكم قريبا!