کلان داده ابری (Big Data as a Service) چیست؟

بیگ دیتا به عنوان سرویس
بیگ دیتا به عنوان سرویس

کلان داده (Big Data) چیست؟

در بیست سال گذشته افزایش داده در زمینه‌های مختلف با رشد سریعی همراه بوده است. بنا به گزارش IDC، در سال 2011 کل داده ساخته و یا کپی شده در جهان تقریباً برابر با 1.8 زتابایت بوده است که این مقدار نسبت به کل داده‌های تولید شده در پنج سالِ قبل از آن، نُه برابر شده است، ولی امروزه این میزان داده حداقل در هر دو سال دو برابر می‌شود.

با توجه به آنچه بیان شد، اهمیت تولید و به‌ کارگیری ابزارهایی مناسب برای مدیریت این حجم از داده­‎های عظیم بسیار ضروری به نظر می‌رسد. مدیریت کلان داده به مجموعه‌ای از متدها، ابزارها و چارچوب‌ها اطلاق می‌شود که مدیریت، کنترل و پردازش داده‌ها را در حالتی فراتر از توانایی ابزارهای پیشین انجام می‌دهند تا بتوانند ارزش‌هایی را که در مجموعه‌های بزرگ، وسیع، پیچیده و متنوع از داده‌ها هستند را آشکار سازند.

اصطلاح کلان داده (Big Data)، به مجموعه داده‌های بسیار بزرگ و پیچیده‌ای گفته می‌شود که ابزارهای سنتی نظیر پایگاه‌های داده‌ی رابطه‌ای نمی‌توانند آن‌ها را در چارچوب زمانی قابل‌قبول یا با هزینه‌های معقول، پردازش کنند. تأمین سخت‌افزار موردنیاز، جستجو، ذخیره و تجزیه‌وتحلیل داده، برخی از چالش‌های مدیریت کلان داده‌ با استفاده از ابزارهای سنتی می‌باشند؛ که با ابزارهای مدیریت توزیع‌شده، می‌توان بر این چالش‌ها فائق آمد. امروزه، یک مجموعه‌ی غنی از ابزارهای پردازشِ کلان داده (تهیه‌شده توسط بنیاد نرم‌افزار آپاچی) برای کمک به برآورده ساختن تمام نیازهای داده‌های کلان، قابل‌دسترس است.

کلان داده عمدتاً تحت سه واژه‌ی Volume، Velocity و Variety شناخته می‌شود. این سه واژه به‌اختصار 3V نامیده می‌شوند. توصیف این سه واژه به‌صورت زیر است:

الف-Volume: اندازه و حجم کلی مجموعه داده

ب-Velocity: نرخ تغییر داده و سرعت موردنیاز برای پردازش آن

ج-Variety: تنوع ساختاری داده‌ها ازلحاظ محتوا و مقدار، مانند داده‌های اصوات، تصاویر، سنسور، متن و …


ساختار بیگ دیتا
ساختار بیگ دیتا

در تعاریف دیگری از کلان داده، معیارهای دیگر یا به عبارتی Vهای دیگری مانند Value، Veracity نیز به مفهوم کلان داده اضافه شده است.

اکوسیستم هادوپ
برای مدیریت کلان داده نیازمند روش­‎های توزیع شده برای ذخیره‎­سازی داده و همچنین پردازش موازی داده­‎ها خواهیم بود و این همان چیزی است که مولفه‎­های اصلی Hadoop یعنی HDFS و MapReduce آن را فراهم می‎­سازند.

رویکرد کلان داده بر پردازش موازی استوار است. این موازی‌سازی مبتنی بر «تقسیم و غلبه» است. در این نظریه‌یِ ایده‌آل، داده‌ها به مجموعه‌های کوچک‌تر تقسیم شده و به‌صورت موازی، پردازش می‌شوند. برای پیاده‌سازی چنین محیطی ملزوماتی نیاز است. ازآنجایی‌که رشد داده منجر به اختلال در پردازش می‌شود، برای شروع، نیاز به یک پلتفرم ذخیره‌سازی قدرتمند که قابلیت توسعه‌پذیری با هزینه‌های معقول را داشته باشد، احساس می‌شود. درنهایت، در چنین سیستمی به‌جای بردن داده‌ها به سمت پردازش، بایستی پردازش را به سمت داده‌ها بُرد. اگر داده­‎ها به سمت پردازش بروند شبکه‌ها به‌سرعت دچار کمبود پهنای باند خواهند شد.

برای مدیریت کلان داده­‎ها علاوه بر مولفه­‎های اصلی Hadoop نیازمند مجموعه ابزارهایی هستیم که تمام ملزومات ایجاد یک سیستم جامع کلان داده را برآورده سازند. از واژه «اکوسیستم هادوپ» برای بیان تمام ابزارها، پروژه‌ها و تکنولوژی‌های مرتبط با کلان داده استفاده می­کنیم.

اکوسیستم هادوپ
اکوسیستم هادوپ

الزامات یک سیستم کلان داده

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

به‌طور خلاصه یک سیستم برای پردازش کلان داده نیازمند موارد زیر است:

  • روشی برای جمع‌آوری و طبقه‌بندی داده
  • روشی برای جابجایی داده در سیستم به‌صورت ایمن و بدون از بین رفتن داده‌ها
  • یک سیستم ذخیره‎­سازی که دارای مشخصات زیر است:
    بین تعداد زیادی از سِروِرها توزیع‌ شده باشد.
    قابل ارتقاء به هزاران سِرور باشد.
    قابلیت افزونگی داده و پشتیبان گیری داشته باشد.
    در موارد خرابی سخت‌افزاری، قابلیت بازیابی وجود داشته باشد.
    ازلحاظ هزینه مقرون‌ به‌ صرفه باشد.
  • مجموعه ابزار کارآمد و پشتیبانی از کاربران
  • روشی برای پیکربندی سیستم توزیع‌ شده
  • قابلیت پردازش موازی داده‌ها
  • ابزارهای مانیتورینگ سیستم
  • ابزارهای گزارش‌گیری
  • ابزارهای شبیه به ETL به‌منظور ساختن وظایفی که داده را پردازش کرده و پیشرفت اجرای آن‌ها را نمایش دهد
  • ابزارهای زمان‌بندی برای تعیین زمانِ اجرای وظایف و نمایشِ وضعیت آن‌ها
  • پردازش محلی درجایی که داده ذخیره می‌شود به‌منظور کاهشِ پهنای باند مورد استفاده‌ی شبکه


فهرست زیر نمونه‌ای از ابزارهای قابل‌دسترس در اکوسیستم هادوپ است که به بهترین شکل، نیازهای فوق را برآورده می­‎سازد:

الف-Ambari: مدیریت و مانیتورینگ هادوپ

ب-Avro: سیستم سریال سازی داده

پ-HDFS: مؤلفه ذخیره‌سازی توزیع‌شده‌ی هادوپ

ت-HBase: پایگاه داده غیر رابطه‌ای وNoSQL هادوپ

ث-Hive: انبار داده‌ی هادوپ

ج-Mahout: پلتفرم قابل ارتقای یادگیری ماشین

چ-MapReduce: چارچوب برنامه‌نویسی توزیع‌شده مورداستفاده در هادوپ

ح-Oozie: برنامه‌ریز گردش کار برای مدیریت کارهای هادوپ

خ-Pig: زبان سطح بالا برای تجزیه‌ و تحلیل داده

د-Solr: پلتفرم جستجو در متن

ذ-Sqoop: ابزار انتقال داده بین هادوپ و پایگاه داده‌های رابطه‌ای

ر-Storm: سیستم محاسبات بی‌درنگ توزیع‌ شده

ز-Yarn: فنّاوری مدیریت کلاستر و یکی از ویژگی‌های اصلی نسل دوم هادوپ

ژ-Zookeeper: یک سرویس متمرکز در هادوپ برای نگهداری اطلاعات پیکربندی، همگام‌سازی توزیع‌ شده و سرویس‌های گروهی

پلتفرم‎­های Hortonworks و Cloudera

هنگامی‌که شما نیاز به ایجاد یک سیستم کلان داده دارید، بایستی بتوانید یک پشته‌ی (Stack) هادوپ ایجاد کنید، یعنی بسیاری از ابزارها و مؤلفه‌های پلتفرم هادوپ را با یکدیگر استفاده و یکپارچه کنید. موضوع مهمی که در اینجا مطرح است این است که شما بایستی به‌گونه‌ای ابزارها را در کنار هم قرار دهید که بتوانند بدون خطا در کنار یکدیگر کار کنند. به‌عنوان مثال اگر شما نیاز دارید که از ده ابزار در کنار یکدیگر استفاده کنید بررسیِ سازگاری نسخه‌های این ابزارها با یکدیگر به‌سرعت پیچیده خواهد شد.

خوشبختانه تعدادی پشته‌ی هادوپ در دسترس است که یک پکیج تست‌شده و آماده را برای استفاده‌کنندگان فراهم می‌نمایند. دو شرکت پیشرو در این زمینه Cloudera و Hortonworks می باشند.

مجموعه Hortonworks یک شرکت نرم افزار داده، واقع در کالیفرنیا است که به صورت نرم افزار متن باز (به طور اختصاصی در مورد هادوپ) توسعه و پشتیبانی می­‎شود. Hortonworks برای مدیریت کلان داده و پردازش‎­های دسته­ای طراحی شده است. پلتفرم Hortonworks شامل مجموعه­ای از پروژه­های نرم افزاری پایه است که تمرکز آنها روی ذخیره یا پردازش کلان داده می­باشد. داخل این مجموعه، سرویس­های زیر در دسترس هستند:

MapReduce, Hadoop Distributed File System (HDFS), Yet Another Resource Negotiator (YARN), Ambari, Falcon, Flume, HBase, Hive, Kafka, Knox, Oozie, Phoenix, Pig, Ranger, Slider, Spark, Sqoop, Storm, Tez, and ZooKeeper

معماری کلی پلتفرم Hortonworks به صورت زیر است (نسخه HDP 3.0.0):

معماری کلی پلتفرم Hortonworks
معماری کلی پلتفرم Hortonworks

در شکل بالا بخش­های اصلی مانند امنیت، پایگاه داده­‎های real time، ابزارهای یادگیری ماشین و یادگیری عمیق، پردازش‎های جریانی، ابرازهای ذخیره داده و غیره وجود دارند که ابزارهای حیاتی کار با کلان داده را فراهم می کنند.

نتیجه‎گیری:

بطور ساده Hortonworks پلتفرمی است که ابزارهای مختلف کلان داده را در کنار هم جمع­‎آوری کرده است که می­توان با آنها بصورت موثرتر و راحت­تر کار کرد.

شرکت Cloudera در زمینه توزیع هادوپ خیلی قبل­تر از Hortonworks شروع به کار کرده است. هم Hortonworks و هم Cloudera به صورت کامل هسته هادوپ را پیاده سازی کرده‎­اند و هر دوی آنها متن باز می‎باشند. در واقع هر دوی آنها سرویس‎­های پایه‎­ای موجود در هادوپ را پیاده ­سازی می‎­کنند و هر کدام برخی از امکانات جانبی دیگر را اضافه کرده‎­اند. مثلا Cloudera خصوصیات ابزاری مانند Cloudera Manager را برای نصب خودکار سرویس‎ها اضافه کرده است.

معماری کلی Cloudera در زیر قابل مشاهده می­باشد:

معماری کلی Cloudera
معماری کلی Cloudera

تشابهات Cloudera و Hortonworks:

  • هر دوی آنها بر اساس یک هسته مشابه ساخته شده‎اند.
  • هر دوی آنها از ساختار Master/Slave بهره می‎­برند.
  • هر دو آنها Map Reduce و Yarn را پشتیبانی می‎کنند.
  • هر دوی آنها دارای رابط­ه‎ای کاربرپسند و خطایابی راحت می‎­باشند.


معماری و مولفه­‎های اصلی Hadoop

هادوپ یک پلتفرم متن‌باز است که توسط بنیاد نرم‌افزاری آپاچی برای حل مسائل کلان داده توسعه‌ یافته است. Hadoop از یک معماری Master/Slave برخوردار است و دارای دو مولفه اصلی می‎­باشد که عبارتند از:

  • HDFS Hadoop Distributed File System))
  • MapReduce

هادوپ دارای دو نسخه اصلی است که هر دوی آن‌ها از یک معماری Master/Slave برخوردار هستند. این دو نسخه را به ترتیب Hadoop V1 و Hadoop V2 می­‎نامند.


معماری Hadoop V1

شکل زیر معماری Hadoop V1 و دو مؤلفه اصلی آن را نمایش می‌دهد:

معماری Hadoop V1
معماری Hadoop V1

همان‌طور که از شکل فوق پیداست هادوپ، از یک گره (Node) یا کامپیوتر Master و چندین گره Slave تشکیل شده است. (مجموع این گره‌های متصل‌به‌هم را کلاستر هادوپ می‌نامیم) گره Master یک گره اصلی است که گره‌های Slave را مدیریت و مراقبت می‌کند. هم گره Master و هم گره­های Slave شامل دو مؤلفه اصلی هادوپ یعنی HDFS و MapReduce می‌باشند.

سیستم فایل توزیع‌شده هادوپ یا HDFS که دارای خواصی چون مقیاس‌پذیری و دسترس‌پذیری بالا می‌باشد، جهت ذخیره‌سازی و مدیریت داده‌ها استفاده می‌گردد. مؤلفه HDFS به‌گونه‌ای بهینه‌سازی شده است که به بهترین نحو ممکن عملیات خواندن و نوشتن فایل‌های بزرگ (چندین گیگابایت و بزرگ‌تر) را انجام دهد.


مؤلفه HDFS خود دارای دو زیرمولفه می‌باشد:

الف- NameNode

زیر مؤلفه NameNode که در گره Master قرار می‌گیرد برای ذخیره‌سازی MetaData های مربوط به DataNode ها استفاده می‌شود. برخی از MetaData هایی که ذخیره می‌شوند عبارت‌اند از: تعداد بلوک‌های ذخیره‌شده در DataNode ها، لیست DataNode های دارای داده، محل DataNode ها، جزئیات گره‌های Slave و غیره.

ب- DataNode

زیر مؤلفه DataNode که در گره‌های Slave قرار می‌گیرد به‌منظور ذخیره‌سازی داده‌های واقعی در HDFS استفاده می‌شوند و به‌صورت پیش‌فرض داده‌ها را در بلوک‌های 64 مگابایتی ذخیره می‌کنند.

فریم‏ورک MapReduce یک فریم‌ورک محاسباتی توزیع‌شده برای پردازش‌های دسته‌ای است که موازی‌سازی کارها را بر روی حجم عظیمی از داده‌ها امکان‌پذیر می‌سازد. اجرای چنین کارهایی که ممکن است با استفاده از تکنیک‌های برنامه‌نویسی سریال چندین روز طول بکشد، می‌تواند در عرض چند دقیقه با استفاده از MapReduce بر روی کلاستر هادوپ انجام شود.

مَپ رِدیوس هادوپ سیستمی برای پردازش موازی حجم بزرگی از داده‌ها بر روی کلاسترهای بسیار بزرگ است. این سیستم در برابر خطا مقاوم بوده و امکان می‌دهد داده‌ها به‌صورت توزیع‌شده بر روی نودهای کلاستر ذخیره گردند. در این مدل برنامه‌نویسی داده‌های ورودی به قطعات کوچک‌تری شکسته می‌شوند که ورودی‌های توابع مَپ (Map) را شکل می‌دهند. سپس توابع Map این قطعه‌های داده را روی DataNode های کلاستر هادوپ، فیلتر و دسته‌بندی می‌کنند. خروجی پردازش‌های مَپ به فرآیندهای رِدیوس (Reduce) تحویل داده شده که اطلاعات را برای تولید خروجی نهایی، درهم‌آمیخته و خلاصه می‌کند.

فریم‏ورک MapReduce کارهایی که از طرف کلاینت ارسال می‌گردد را به قطعات کوچک‌تری به نام Map Task و Reduce Task تجزیه کرده و آن‌ها را به‌منظور اجرا روی گره‌های Slave توزیع و مدیریت می‌کند.

فریم‏ورک MapReduce
فریم‏ورک MapReduce

نقش برنامه‌نویس در اینجا تنها تعریف توابع Map و Reduce بوده و از وارد شدن به جزئیات کار با سیستم‌های توزیعی (مانند توزیع کارها، مدیریت سخت‌افزار و نرم‌افزار و غیره) معاف است. خروجی تابع Map دوتایی‌های کلید/مقدار (Key/Value) است که این خروجی‌ها توسط تابع Reduce به‌منظور ایجاد خروجی نهایی پردازش می‌شوند.

مؤلفه MapReduce نیز همانند مؤلفه HDFS دارای دو زیرمولفه می‌باشد:

الف- Job Tracker

Job Tracker به‌منظور اختصاص کارها به Task Tracker ها و دریافت خروجی از آن‌ها استفاده می‌شود. در مواردی که یک Task Tracker به هر دلیلی از دسترس خارج شود، Job Tracker، کار اختصاص یافته به آن را به Task Tracker دیگری می‌دهد. بدین منظور Job Tracker همه وضعیت‌های Task Tracker ها مانند بالا بودن، در حال اجرا بودن، خراب بودن و بازیابی شده را نگهداری می‌کند.

ب- Task Tracker

برنامه های Task Tracker وظیفه اجرای کارهایی را دارند که توسط Job Tracker ها به آن‌ها اختصاص داده می‌شود. همچنین آن‌ها وضعیت کارهای اختصاصی خود را به Job Tracker ها ارسال می‌کنند. Task Tracker خود شامل دو جزء می‌باشد که این دو جزء عبارت‌اند از: (1) Map Task و (2) Reduce Task.

مسئولیت‌های چهار مؤلفه فوق و نحوه تعامل آن‌ها با یکدیگر برای اجرای کارهای برنامه کاربردی کلاینت به‌صورت زیر است:

  • کلاینت (کلاینت‌ها) کار (درخواست) خود را به سیستم هادوپ ارسال می‌کند.
  • سیستم هادوپ درخواست کلاینت را با استفاده از گره Master دریافت می‌کند.
  • مؤلفه Job Tracker در گره Master مسئول دریافت کار کلاینت و تقسیم آن به بخش‌های مستقل قابل مدیریت و اختصاص این بخش‌ها به Task Trackers‌ها می‌باشد.
  • برنامه Task Trackers ها کارهای دریافتی را با استفاده مؤلفه MapReduce اجرا می‌کنند.
  • هنگامی‌که همه Task Tracker ها کارهای خود را به اتمام رساندند، Job Tracker خروجی آن‌ها را گرفته و برای تولید خروجی نهایی آن‌ها را ترکیب می‌کند.
  • درنهایت سیستم هادوپ خروجی نهایی را برای کلاینت ارسال می‌کند.

در کل سیستم هادوپ دو نوع درخواست از کلاینت دریافت می‌کند: (1) درخواست ذخیره‌سازی؛ و (2) درخواست محاسبات

هنگامی‌که سیستم هادوپ درخواستی را برای ذخیره‌سازی یک فایل داده‌ای بزرگ در HDFS دریافت می‌کند، آن را به بلوک‌های قابل مدیریت و معنی‌دار تقسیم کرده و سپس این بلوک‌ها را بین گره‌های متفاوت (با سه کپی) توزیع می‌کند. (فاکتور تکرار پیش‌فرض در هادوپ 3 می‌باشد).

هنگامی‌که هادوپ یک درخواست محاسبات دریافت می‌کند، ابتدا برای بازیابی بلوک‌های داده‌ای مرتبط با درخواست، با نزدیک‌ترین گره‌ها تماس حاصل می‌کند و سپس محاسبات را انجام می‌دهد. هنگام خواندن داده و یا انجام محاسبات، اگر یک یا چند گره از دسترس خارج شوند، سیستم هادوپ به‌صورت خودکار، کارها را به نزدیک‌ترین گره‌های در دسترس اختصاص می‌دهد. به‌این‌ترتیب سیستم هادوپ، دسترس‌پذیری و تحمل‌پذیری در مقابل خطا را مدیریت می‌کند.

معماری Hadoop V2

علیرغم ویژگی‌های خوب Hadoop V1، محدودیت‌ها و ضعف‌هایی وجود دارد که در نسخه Hadoop V2 رفع گردیده‌اند. در شکل زیر معماری سطح بالای Hadoop V2 قابل‌مشاهده می‌باشد.

معماری Hadoop V2
معماری Hadoop V2

همان‌گونه که در شکل فوق مشاهده می‌شود Hadoop V2 نسبت به نسخه قبلی دارای چندین تفاوت است. در این نسخه یک مؤلفه جدید با نام YARN اضافه شده که یک مدیر کلاستر (Cluster Manager) می‌باشد که به‌عنوان سیستم‌عامل هادوپ نیز شناخته می‌شود. همچنین مؤلفه‌های MapReduce و HDFS نیز با اضافه شدن چندین ویژگی جدید، آپدیت شده‌اند. باقی مؤلفه‌های اکوسیستم هادوپ بر روی این سه مؤلفه اصلی قرار می‌گیرند. به‌منظور بررسی دقیق‌تر، در شکل زیر معماری Hadoop V2 با جزئیات بیشتری نمایش داده شده است.

ایده بنیادی YARN در Hadoop V2 این است که وظایف اصلی Job Tracker یعنی مدیریت منابع و زمان‌بندی/ مانیتورینگ، به دو بخش جداگانه تقسیم شوند: یک ResourceManager مرکزی و یک ApplicationMaster به ازای هر برنامه کاربردی. همچنین مؤلفه Task Tracker با یک مؤلفه به نام NodeManager جایگزین شده است که منابع گره‌های Slave و کارهای اختصاصی به آن‌ها را مدیریت می‌کند. حاکمیت نهایی کلیه منابعی که در اختیار سیستم است بر عهده ResourceManager می‌باشد. مؤلفه NodeManager نیز عاملی است که به ازای هر گره Slave موجود در کلاستر وجود داشته و مسئول مانیتورینگ منابع مورداستفاده (CPU، RAM، DISK) برای اجرای کارها و گزارش آن‌ها به ResourceManager می‌باشد. مؤلفه ApplicationMaster نیز مسئول مدیریت چرخه عمر برنامه‌های کاربردی اختصاص داده شده، ارتباط و تعامل با ResourceManager برای به دست آوردن منابع موردنیاز، ارتباط با Node Manager به‌منظور اجرای کارهای اختصاص یافته و نظارت بر وضعیت کارهای مذکور می‌باشد. توابع MapReduce نیز با استفاده از ApplicationMaster کنترل می‌شوند.

مقایسه نسخه‌های هادوپ

الف- Hadoop V1 تنها یک مدل برنامه‌نویسی را پشتیبانی می‌کند که همان MR (MapReduce) است؛ اما Hadoop V2 به واسطه وجود Yarn، چندین مدل شامل MR، Spark، Storm، Streaming، Graph و … را پشتیبانی می‌کند.

ب- Hadoop V1 تنها برای پردازش دسته‌ای کاربرد دارد درحالی‌که Hadoop V2 برای پردازش‌های بی‌درنگ و کار با داده‌های جریانی نیز کاربرد دارد.

پ- در Hadoop V1، بسیاری از وظایف بر عهده JobTracker است و اگر این مؤلفه از دسترس خارج شود، مشکل ایجاد خواهد شد.

ت- Hadoop V1 حداکثر از 4000 گره در هر کلاستر پشتیبانی می‌کند اما Hadoop V2 بیشتر از 10000 گره در هر کلاستر را نیز پشتیبانی می‌کند.

ث- Hadoop V1 برخی محدودیت‌ها در رابطه با مقیاس‌پذیری دارد که در Hadoop V2 حل شده است.


نرم افزار Apache Spark

آپاچی اسپارک یک پلتفرم محاسبات توزیع‌شده‌ی همه‌منظوره و سریع می‌باشد که با زبان اسکالا نوشته شده است. پروژه اسپارک در سال 2009 در دانشگاه برکلی شروع شد و در مدت‌زمان کوتاهی به‌عنوان نسل بعدی موتورهای پردازشی کلان داده شناخته و به‌سرعت رشد یافت. اسپارک فریم‌ورک MR هادوپ را از چند جنبه توسعه و بهبود داده است که شامل این موارد است: سرعت پردازش بالاتر، استفاده راحت‌تر به‌واسطه وجود API های غنی، ایجاد پرس‌وجوهای تعاملی، کار با داده‌های جریانی، داشتن کتابخانه‌های قوی مانند MLlib برای یادگیری ماشین و GraphX برای پردازش گراف.

مزیت عمده اسپارک، سرعت پردازش بالای آن است که به‌واسطه انجام محاسبات در حافظه است؛ بااین‌حال همچنان اسپارک برای اجرای کاربردهای پیچیده روی دیسک نیز نسبت به MR کاراتر است.

اسپارک دارای API های ساده‌ای در پایتون، اسکالا، جاوا و SQL می‌باشد. همچنین اسپارک با بسیاری از ابزارهای کلان داده یکپارچه شده است. اسپارک می‌تواند روی کلاستر هادوپ اجرا شده و به هر سیستم ذخیره‌سازی داده (مانند HDFS، S3، HBase، Hive، Cassandra و …) که توسط هادوپ پشتیبانی می‌شود نیز قابلیت دسترسی دارد. پروژه اسپارک شامل چندین مؤلفه است که به‌خوبی با یکدیگر یکپارچه شده‌اند.

هسته اصلی اسپارک «موتور محاسباتی» آن است که مسئولیت زمان‌بندی کارها، مدیریت حافظه، توزیع‌شدگی، تعامل با سیستم‌های ذخیره‌سازی و … را بر عهده دارد. همچنین هسته اسپارک شامل API هایی است که (RDD (Resilient Distributed Dataset را تعریف می‌کند که درواقع انتزاع برنامه‌نویسی اسپارک به‌حساب می‌آیند. یک RDD یک مجموعه از اشیاء داده‌ای توزیع‌شده بر روی مجموعه‌ای از گره‌ها است. این مجموعه‌ها انعطاف‌پذیر (Resilient) هستند چراکه در صورت از دست رفتن بخشی از مجموعه داده، قابلیت بازسازی دوباره دارند.

آپاچی اسپارک
آپاچی اسپارک

پشته‌ی اسپارک

اسپارک می‌تواند روی چندین مدیر منبع متفاوت اجرا شود که عبارت‌اند از:Hadoop Yarn، Apache mesos و Standalone Scheduler که آخری مدیر منبع خود اسپارک است که برای ایجاد و تنظیم ساده یک کلاستر مناسب می‌باشد.

– نگاهی به الگوریتم واژه‌شمار

بهترین راه درک مدل برنامه‌نویسی مَپ رِدیوس، ارائه‌ی یک مثال است. یک الگوریتم واژه‌شمار مبتنی بر مپ ردیوس نه‌تنها ساده‌ترین و معمول‌ترین مثال مَپ رِدیوس است بلکه شامل تکنیک‌هایی است که می‌توانید برای طرح‌های پیچیده‌تر، از آن استفاده کنید. برای شروع، شکل زیر را در نظر بگیرید که فرآیند واژه‌شمار را به مراحلی تقسیم می‌کند.

فایل ورودی در سمت چپ شکل فوق، در گام اول به چندین Data chunk تقسیم می‌شود. اندازه‌ی این Chunkها در مَپ رِدیوس قابل‌کنترل است؛ بعلاوه تعداد این قسمت‌ها تحت تأثیر اندازه‌ی بلوک‌های داده‌ای است که در HDFS ذخیره می‌شوند. در گام بعد هر Chunk، یک فرآیند مَپ رِدیوس روی DataNode ها را آغاز می‌کند.

در مدل برنامه‌نویسی مپ ردیوس مفهومی به نام «کلید/مقدار» یا key/value وجود دارد که ساختاری برای محاسبات توزیع‌شده و موازی را ارائه می‌دهد. فرآیند مَپ یک مجموعه از جفت‌های کلید/مقدار را ایجاد می‌کند که در مثال واژه‌شمار، کلیدها، خود کلمات هستند، (برای مثال، «one») و مقادیر، تعداد دفعات تکرار آن کلمات می‌باشند. این مجموعه‌های کلید/مقدار بر اساس نوع کلید بُر (Shuffle) خورده و داخل لیست‌هایی مجزا قرار می‌گیرند. سپس این لیست‌ها در اختیار توابع رِدیوس قرار می‌گیرند که در آن مقادیر مربوط به هر لیست، به‌صورت جداگانه باهم جمع می‌شوند. خروجی رِدیوس، لیستی ساده از جفت‌های کلید/مقدارِ جمع شده است.

معرفی Apache Ambari

نرم افزار Ambari پروژه­ای است که تاکید و تمرکز آن بر ساخت و مدیریت ساده­تر کلاستر هادوپ جهت توسعه نرم­افزار و مانیتورینگ می­باشد. Ambari مدیریت سیستم را به سه صورت انجام می دهد:

  • فراهم کردن یک کلاستر هادوپ
  • مدیریت یک کلاستر هادوپ
  • مانیتورینگ یک کلاستر هادوپ

معماری کلی Ambari به صورت شکل زیر است:

معماری کلی Ambari
معماری کلی Ambari

به بیان ساده Ambari Server ابتدا داده­ها را در سراسر کلاستر جمع­آوری می­کند. هر ماشینی در کلاستر یک کپی از Ambari Agent دارد، این Agent اجازه کنترل کردن یک ماشین را به Ambari Server می­دهد. اساسا برای دسترسی به اطلاعات کلاستر و انجام دادن عملیات روی آن، Ambari Web ابتدا Ambari REST API را (که از Ambari Server قابل دسترسی است) فراخوانی می­کند. با استفاده از REST API ارتباط بین سرور و مرورگر بلافاصله انجام می­گیرد.

نرم افزار Ambari Server:

بطور کلی نقطه ورود برای مدیریت تمام فعالیت­های سرور Master از طریق Ambari Server انجام می­گیرد. یکscript shell، به نام ambari-server.py وجود دارد و تمام درخواست­ها به آن ارجاع داده می­شوند. نقاط ورودی (entry point) مختلفی برای عبور پارامترها بهAmbari Server وجود دارد:

الف- Management Daemon: مثلا با استفاده از دستور ambari-server start ما Ambari را start می­کنیم

  • ارتقای نرم­افزار (Software upgrade)
  • تنظیم نرم­افزار (Software setup)
  • مدیریت LDAP/PAM/Kerberos
  • پشتیبان­گیری و بازگرداندن Ambari
  • گزینه­های مختلف دیگر

ب- Ambari Agent:

روی تمام ماشین­هایی که می­خواهیم بوسیله Ambari مدیریت شوند، Ambari agent باید در حال اجرا باشد. اساسا، این برنامه به صورت دوره­ای ضربان قلب (heartbeats) را به گره master می­فرستد. Ambari server با استفاده از این agentها تعداد زیادی از taskها را روی سرورها اجرا می­کند.


https://www.XaaS.ir