ویژگی های کلودرا و نحوه طبخ آن چیست

بازار محاسبات توزیع شده و کلان داده، با توجه به آمار، 18-19 درصد در سال رشد می کند. این بدان معنی است که موضوع انتخاب نرم افزار برای این اهداف همچنان مرتبط است. در این پست به این موضوع می پردازیم که چرا به محاسبات توزیع شده نیاز داریم، با جزئیات بیشتری در مورد انتخاب نرم افزار صحبت خواهیم کرد، در مورد استفاده از Hadoop با Cloudera صحبت خواهیم کرد و در نهایت در مورد انتخاب سخت افزار و تأثیر آن بر عملکرد صحبت خواهیم کرد. به روش های مختلف

چرا در تجارت معمولی به محاسبات توزیع شده نیاز داریم؟ همه چیز ساده و در عین حال پیچیده است. ساده - زیرا در اکثر موارد ما محاسبات نسبتاً ساده ای را در واحد اطلاعات انجام می دهیم. دشوار است - زیرا چنین اطلاعاتی زیادی وجود دارد. خیلی زیاد. در نتیجه، مجبور است ترابایت داده را در 1000 رشته پردازش کنید. بنابراین، موارد استفاده کاملاً جهانی هستند: محاسبات را می توان در هر جایی که لازم باشد برای در نظر گرفتن تعداد زیادی از معیارها در یک آرایه داده حتی بزرگتر اعمال کرد.

یک مثال اخیر: پیتزا دودو مشخص بر اساس تجزیه و تحلیل پایگاه سفارش مشتری، که هنگام انتخاب یک پیتزا با رویه های دلخواه، کاربران معمولا تنها با شش مجموعه اصلی از مواد تشکیل دهنده به اضافه چند مورد تصادفی کار می کنند. بر این اساس، پیتزا فروشی خرید را تنظیم کرد. علاوه بر این، توانست محصولات اضافی ارائه شده در مرحله سفارش را بهتر به کاربران توصیه کند که باعث افزایش سود شد.

یک مثال دیگر: تجزیه و تحلیل کالا به H&M اجازه داد تا مجموعه فروشگاه‌های فردی را تا 40 درصد کاهش دهد و در عین حال سطح فروش را حفظ کند. این امر با حذف موقعیت های فروش ضعیف به دست آمد و فصلی بودن در محاسبات در نظر گرفته شد.

انتخاب ابزار

استاندارد صنعتی برای این نوع محاسبات Hadoop است. چرا؟ زیرا Hadoop یک چارچوب عالی و مستند است (همان Habr مقالات مفصل زیادی در مورد این موضوع ارائه می دهد) که با مجموعه کاملی از ابزارها و کتابخانه ها همراه است. شما می توانید مجموعه های عظیمی از داده های ساختاریافته و بدون ساختار را به عنوان ورودی ارسال کنید و خود سیستم آنها را بین قدرت محاسباتی توزیع می کند. علاوه بر این، همین ظرفیت ها را می توان در هر زمان افزایش یا غیرفعال کرد - همان مقیاس پذیری افقی در عمل.

در سال 2017، شرکت مشاوره با نفوذ گارتنر نتیجه گیریکه هادوپ به زودی منسوخ خواهد شد. دلیل آن بسیار پیش پا افتاده است: تحلیلگران بر این باورند که شرکت ها به طور گسترده به فضای ابری مهاجرت می کنند، زیرا در آنجا می توانند بر اساس استفاده از قدرت محاسباتی پرداخت کنند. دومین عامل مهمی که ظاهراً قادر به "دفن کردن" هادوپ است، سرعت کار است. زیرا گزینه هایی مانند Apache Spark یا Google Cloud DataFlow سریعتر از MapReduce زیرین Hadoop هستند.

Hadoop بر چندین ستون استوار است که قابل توجه ترین آنها فناوری MapReduce (سیستمی برای توزیع داده ها برای محاسبات بین سرورها) و سیستم فایل HDFS است. دومی به طور خاص برای ذخیره اطلاعات توزیع شده بین گره های خوشه ای طراحی شده است: هر بلوک با اندازه ثابت می تواند روی چندین گره قرار گیرد و به لطف تکرار، سیستم در برابر خرابی گره های جداگانه مقاوم است. به جای جدول فایل، از سرور خاصی به نام NameNode استفاده می شود.

تصویر زیر نحوه عملکرد MapReduce را نشان می دهد. در مرحله اول، داده ها بر اساس یک ویژگی خاص تقسیم می شوند، در مرحله دوم با قدرت محاسباتی توزیع می شوند، در مرحله سوم محاسبه انجام می شود.

MapReduce در ابتدا توسط گوگل برای نیازهای جستجوی خود ایجاد شد. سپس MapReduce وارد کد رایگان شد و آپاچی پروژه را در دست گرفت. خوب، گوگل به تدریج به راه حل های دیگر مهاجرت کرد. نکته جالب توجه: در حال حاضر، گوگل پروژه ای به نام Google Cloud Dataflow دارد که به عنوان گام بعدی بعد از Hadoop، جایگزین سریع آن است.

نگاه دقیق‌تر نشان می‌دهد که Google Cloud Dataflow مبتنی بر گونه‌ای از Apache Beam است، در حالی که Apache Beam شامل چارچوب مستند Apache Spark است که به ما امکان می‌دهد تقریباً در مورد همان سرعت اجرای راه حل صحبت کنیم. خوب، Apache Spark روی سیستم فایل HDFS به خوبی کار می کند، که به شما امکان می دهد آن را بر روی سرورهای Hadoop مستقر کنید.

در اینجا حجم اسناد و راه حل های آماده Hadoop و Spark در برابر Google Cloud Dataflow را اضافه کنید و انتخاب ابزار آشکار می شود. علاوه بر این، مهندسان می توانند خودشان تصمیم بگیرند که کدام کد - تحت Hadoop یا Spark - را با تمرکز بر کار، تجربه و صلاحیت ها اجرا کنند.

سرور ابری یا محلی

گرایش به سمت انتقال عمومی به فضای ابری حتی باعث ایجاد اصطلاح جالبی مانند Hadoop-as-a-service شده است. در چنین سناریویی، مدیریت سرورهای متصل بسیار مهم شده است. زیرا، متأسفانه، با وجود محبوبیت، Hadoop خالص یک ابزار نسبتاً دشوار برای پیکربندی است، زیرا شما باید کارهای زیادی را با دست انجام دهید. به عنوان مثال، می توانید سرورها را به صورت جداگانه پیکربندی کنید، عملکرد آنها را نظارت کنید و بسیاری از پارامترها را به خوبی تنظیم کنید. به طور کلی، برای یک آماتور کار کنید و شانس زیادی وجود دارد که جایی را خراب کنید یا چیزی را از دست بدهید.

بنابراین، توزیع های مختلف بسیار محبوب شده اند، که در ابتدا به ابزارهای مناسب استقرار و مدیریت مجهز شده اند. یکی از محبوب‌ترین توزیع‌هایی که از Spark پشتیبانی می‌کند و کارها را آسان می‌کند، Cloudera است. این دارای هر دو نسخه پولی و رایگان است - و در دومی، تمام قابلیت های اصلی در دسترس است و بدون محدودیت تعداد گره ها.

در طول راه اندازی، مدیر کلودرا از طریق SSH به سرورهای شما متصل می شود. یک نکته جالب: هنگام نصب بهتر است مشخص کنید که به اصطلاح توسط آن انجام شود بسته ها: بسته های ویژه ای که هر کدام شامل تمام اجزای لازم برای کار با یکدیگر هستند. در واقع، این یک نسخه بهبود یافته از مدیر بسته است.

پس از نصب، یک کنسول مدیریت خوشه دریافت می کنیم، که در آن می توانید تله متری را برای خوشه ها، سرویس های نصب شده مشاهده کنید، به علاوه می توانید منابع را اضافه یا حذف کنید و پیکربندی خوشه را ویرایش کنید.

در نتیجه برش آن موشک در مقابل شما ظاهر می شود که شما را به آینده درخشان BigData می برد. اما قبل از اینکه بگوییم «بریم»، بیایید زیر کاپوت به سرعت جلو برویم.

الزامات سخت افزاری

Cloudera در وب سایت خود به پیکربندی های مختلف ممکن اشاره می کند. اصول کلی ساخت آنها در تصویر نشان داده شده است:

MapReduce می تواند این تصویر خوش بینانه را تار کند. با نگاهی دوباره به نمودار در بخش قبل، مشخص می‌شود که تقریباً در همه موارد، یک کار MapReduce می‌تواند هنگام خواندن داده‌ها از دیسک یا شبکه به گلوگاه برخورد کند. این موضوع در وبلاگ Cloudera نیز ذکر شده است. در نتیجه، برای هر گونه محاسبات سریع، از جمله از طریق Spark، که اغلب برای محاسبات بلادرنگ استفاده می شود، سرعت I/O بسیار مهم است. بنابراین، هنگام استفاده از Hadoop، بسیار مهم است که ماشین‌های متعادل و سریع وارد خوشه شوند، که، به بیان ساده، همیشه در زیرساخت ابر ارائه نمی‌شود.

تعادل در توزیع بار از طریق استفاده از مجازی سازی Openstack بر روی سرورهایی با CPUهای چند هسته ای قدرتمند به دست می آید. گره های داده منابع پردازنده و دیسک های خاص خود را تخصیص می دهند. در راه حل ما موتور دریاچه داده کدکس Atos مجازی سازی گسترده به دست می آید، به همین دلیل است که هم از نظر عملکرد (تاثیر زیرساخت شبکه به حداقل می رسد) و هم از نظر TCO (سرورهای فیزیکی اضافی حذف می شوند) برنده می شویم.

در مورد استفاده از سرورهای BullSequana S200، بار بسیار یکنواخت و بدون برخی از تنگناها دریافت می کنیم. حداقل پیکربندی شامل 3 سرور BullSequana S200 است که هر کدام دارای دو JBOD هستند، به علاوه S200 های اضافی حاوی چهار گره داده به صورت اختیاری متصل می شوند. در اینجا یک بار نمونه در آزمایش TeraGen آمده است:

آزمایش‌هایی با حجم داده‌های مختلف و مقادیر تکرار نتایج یکسانی را از نظر توزیع بار در گره‌های خوشه نشان می‌دهند. در زیر نموداری از توزیع دسترسی به دیسک بر اساس تست های عملکرد ارائه شده است.

محاسبات بر اساس حداقل پیکربندی 3 سرور BullSequana S200 است. این شامل 9 گره داده و 3 گره اصلی و همچنین ماشین های مجازی رزرو شده در صورت استقرار حفاظت مبتنی بر مجازی سازی OpenStack است. نتیجه تست TeraSort: اندازه بلوک 512 مگابایتی ضریب تکرار سه با رمزگذاری 23,1 دقیقه است.

چگونه می توان سیستم را گسترش داد؟ انواع مختلفی از برنامه‌های افزودنی برای Data Lake Engine موجود است:

• گره های داده: برای هر 40 ترابایت فضای قابل استفاده
• گره های تحلیلی با قابلیت نصب GPU
• گزینه های دیگر بسته به نیازهای تجاری (به عنوان مثال، اگر به کافکا و موارد مشابه نیاز دارید)

مجموعه Atos Codex Data Lake Engine شامل خود سرورها و نرم افزارهای از پیش نصب شده، از جمله کیت Cloudera با مجوز است. خود Hadoop، OpenStack با ماشین‌های مجازی مبتنی بر هسته لینوکس RedHat Enterprise، سیستم‌های تکثیر داده و پشتیبان‌گیری (از جمله استفاده از یک گره پشتیبان و Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine اولین راه حل مجازی سازی است که گواهینامه دریافت کرده است Cloudera.

اگر به جزئیات علاقه مند هستید، خوشحال می شویم به سوالات خود در نظرات پاسخ دهید.

منبع: www.habr.com