هل Hadoop ميت؟ الجزء 2



تم إعداد ترجمة لهذه المقالة خصيصًا لطلاب دورة مهندس البيانات .


اقرأ الجزء الأول

لا أحد يحتاج البيانات الكبيرة


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

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

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

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

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

يمكن أن تعيش مجموعة البيانات هذه في ذاكرة الوصول العشوائي


سمعت أن الناس يقولون أن "مجموعة البيانات يمكن أن تنسجم مع الذاكرة." نمت كمية ذاكرة الوصول العشوائي ، حتى في السحابة ، بشكل ملحوظ في الآونة الأخيرة. هناك حالات EC2 مع 2 تيرابايت من ذاكرة الوصول العشوائي. عادة ، يمكن استخدام ذاكرة الوصول العشوائي في 12-25 غيغابايت / ثانية ، اعتمادا على بنية التثبيت. لن يؤدي استخدام ذاكرة الوصول العشوائي (RAM) وحدها إلى توفير الاسترداد من الأعطال في حالة حدوث انقطاع في الطاقة على الجهاز. بالإضافة إلى ذلك ، ستكون التكلفة لكل جيجابايت كبيرة مقارنة باستخدام محركات الأقراص.

الأقراص تزداد سرعة أيضًا. تم الإعلان مؤخرًا عن بطاقة SSD PCIe 4.0 NVMe 4 × 2 TB قادرة على القراءة والكتابة بسرعة 15 جيجابايت / ثانية. سيكون سعر محرك PCIe 4.0 NVMe منافسًا تمامًا مع ذاكرة الوصول العشوائي وسيوفر ذاكرة غير متقلبة. لا أستطيع الانتظار لرؤية مجموعة HDFS مع شبكة جيدة باستخدام محركات الأقراص هذه ، لأنه سيوضح شكل أرشيف البيانات في الذاكرة مع تخزين غير متغير مع أدوات النظام الإيكولوجي Hadoop الحالية الغنية.

مثقلة مع التجاوزات الهندسية


لا أرغب في إنفاق 6 أو 7 أرقام على تطوير نظام أساسي للبيانات وفريق لشركة لا يمكن أن يتجاوز النطاق ما يناسب على كمبيوتر محمول من مطور واحد.

من وجهة نظر سير العمل ، تتكون معظم أيامي من استخدام BASH و Python و SQL. العديد من الخريجين الجدد مؤهلين في ما سبق.

بيانات Petquet يمكن توزيع باركيه بسهولة عبر مليون ملف على S3. التخطيط المتعلق بما سبق ليس أكثر تعقيدًا من التفكير في كيفية تخزين 100000 ملف micropacket على S3. لمجرد أن الحل قابل للتطوير لا يعني أنه لا لزوم له.

مجرد استخدام PostgreSQL؟


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

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

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

إذا كنت بحاجة إلى مجموعة بيانات للمعاملات ، فمن الأفضل الاحتفاظ بعبء العمل المعزول هذا باستخدام مستودع بيانات للمعاملات. لهذا السبب أتوقع أن يستمر MySQL و PostgreSQL و Oracle و MSSQL لفترة طويلة جدًا.

ولكن هل ترغب في رؤية استراحة لمدة 4 ساعات في أوبر لأن أحد طلبات Presto الخاصة بهم تسبب في سلوك غير متوقع؟ هل ترغب في إطلاع شركتك على الحاجة إلى إعداد فواتير شهرية ، لماذا يتعين عليك إيقاف تشغيل موقع الويب الخاص بك لمدة أسبوع حتى تتوفر موارد كافية لهذه المهمة؟ لا ينبغي أن ترتبط أحمال العمل التحليلية بأعباء عمل المعاملات. يمكنك تقليل مخاطر التشغيل واختيار أنسب المعدات عن طريق تشغيلها في بنية أساسية منفصلة.

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

كيف يبدو المستقبل؟


سأستمر في تحليل وتوسيع مهارات البيانات الخاصة بي في المستقبل المنظور. على مدار الـ 12 شهرًا الماضية ، كنت أمارس العمل باستخدام Redshift و BigQuery و Presto بكميات متساوية تقريبًا. أحاول توزيع رهاناتي ، لأنني لم أجد كرة بلورية صالحة للتنبؤ.

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

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

قد يكون Cloudera و MapR في الأوقات الصعبة في الوقت الحالي ، لكنني لم أسمع شيئًا كهذا ليجعلني أعتقد أن AWS EMR و DataBricks و Qubole لديهم شيء للتنافس معه. حتى أوراكل تصدر عرضًا يحركه Spark . سيكون من الرائع أن ترى الصناعة في Hadoop شيئًا أكثر من مجرد عرض Cloudera ، وأدركت أن هذه الشركات ، وكذلك Facebook و Uber و Twitter قدمت مساهمة كبيرة في عالم Hadoop.

Hortonworks ، التي اندمجت مع Cloudera هذا العام ، هي المزود الأساسي لنظام Azure HDInsight ، الذي تديره Microsoft Hadoop. يوجد أشخاص في الشركة يمكنهم توفير منصة مناسبة لمزود خدمة سحابة تابع لجهة خارجية. آمل أن تركز أي مقترحات يعملون عليها على هذا النوع من العرض.

أظن أن عملاء Cloudera الأوائل كانوا من مستخدمي HBase و Oozie و Sqoop و Impala. سيكون من الجيد أن نرى أنهم لا ينافسون على مثل هذا الوقت الطويل من التطوير والإصدارات المستقبلية من منصاتهم التي ستشحن مع Airflow و Presto وأحدث إصدار من Spark خارج الصندوق.

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

Source: https://habr.com/ru/post/ar476908/


All Articles