هادوپ آپاچی برای کلان‌داده‌ها

آپاچی هادوپ (Apache Hadoop) در سال 2005 توسط داگلاس کاتینگ و مایک کافارل و در ابتدا به منظور پشتیبانی از قابلیت توزیع‌پذیری در پروژه موتور جستجوی Nutch ایجاد شد.

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

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

ماژول‌های تشکیل‌دهنده چارچوب آپاچی هادوپ

چارچوب آپاچی هادوپ از ماژول‌های زیر تشکیل شده است:

Hadoop Common

شامل توابع کتابخانه‌ای و برنامه‌های کاربردی که مورد نیاز سایر ماژول‌های هادوپ است.

HDFS یا Hadoop Distributed File System

یک فایل سیستم توزیع شده که داده‌ها را روی ماشین‌ها ذخیره کرده و مسیر انتقال داده پیوسته گسترده‌ای برای انتقال داده در کلاستر فراهم می‌کند.

Hadoop Yarn

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

Hadoop MapReduce

یک مدل برنامه‌نویسی برای پردازش داده‌ها با حجم زیاد.

تمامی ماژول‌ها با این فرضیه اساسی طراحی شده‌اند که خرابی سخت‌افزاری (یک ماشین خاص یا مجموعه‌ای از ماشین‌ها) یک پدیده رایج بوده، بنابراین در چارچوب در نظر گرفته شده، باید به صورت خودکار توسط نرم‌افزار مدیریت شود. همچنین در طراحی مولفه‌های Hadoop MapReduce و HDFS از روش‌های اشاره شده در مقالات گوگل استفاده شده است.

گذشته از HDFS، YARN و MapReduce بستر آپاچی هادوپ از مجموعه دیگر پروژه‌های مرتبط مانند Apache Pig، Apache Hive، Apache HBase نیز تشکیل شده است.

Apache Hadoop Ecosystem

چارچوب هادوپ بیش‌تر به زبان جاوا نوشته شده، برخی کدهای محلیNative Code  آن به زبان C و در برنامه‌های خط فرمان آن نیز از Shell-Script استفاده شده است.

HDFS و MapReduce

این دو به عنوان دو مولفه اصلی در هسته آپاچی هادوپ 1.X وجود دارند و همان‌طور که اشاره شد برگرفته از فناوری‌های داخلی گوگل هستند.

فایل سیستم توزیع شده هادوپ (HDFS)

همان‌طور که گفته شد این فایل سیستم به زبان جاوا نوشته شده است. در ساختار هادوپ هر گره (Node) معمولا یک Name node دارد و دسته‌ای (Cluster) از داده‌گره‌ها (Data node) یک HDFS Cluster را تشکیل می‌دهد. (البته الزامی در داشتن Data node وجود ندارد). هر Data node به بلاک‌های داده‌های آن شبکه با استفاده از یک Block Protocol خاص HDFS سرویس‌دهی می‌کند. فایل سیستم از لایه TCP/IP برای ارتباط و کلاینت‌ها نیز برای ارتباط میان خودشان از RPC یا Remote Procedure Call استفاده می‌کنند.

HDFS، فایل‌های بزرگ (در حد گیگابایت تا ترابایت) را روی چندین ماشین نگهداری می‌کند. به‌وسیله (replicate) داده‌ها روی چندین میزبان (Host)، قابلیت اطمینان (Reliability) حاصل می‌شود و در نتیجه نیازی به ابزارهای ذخیره‌سازی RAID نیست. با مقدار پیش‌فرض در نظر گرفته شده برای replication )عدد ۳)، داده‌ها روی ۳ گره ذخیره م‌یشود که دو تا روی یک rack و دیگری در یک rack متفاوت واقع شده‌اند.

به منظور حفظ حالت توازن داده‌ها، جابه‌جایی نسخه‌های کپی بین یکدیگر و نگهداری replication داده‌های مختلف داده گره‌ها با یکدیگر صحبت می‌کنند. از سوی دیگر HDFS با فایل سیستم POSIX سازگاری صد در صد ندارد، چرا که الزامات فایل سیستم POSIX با اهداف نهایی پروژه هادوپ تفاوت‌هایی دارد. به هر حال انتخاب یک فایل سیستم با این میزان از سازگاری با POSIX، از طرفی میزان کارایی در داده‌های انتقالی را افزایش می‌دهد و از طرف دیگر قابلیت پشتیبانی از مواردی مانند Append که Non-POSIX است نیز فراهم می‌کند.

با افزودن امکاناتی از جمله Secondary Name Nodee، قابلیت High-Avail-ability هادوپ در نسخه HDFS 2.X ارتقا پیدا کرد. چیزی که ممکن است باعث اشتباه برخی افراد شود این است که تصور می‌کنند وقتی Primary Name Node غیرفعال می‌شود Secondary Name node به حالت فعال درمی‌آید در حالی که در حقیقت Name Node ثانویه معمولا همیشه با Name Node اولیه در ارتباط بوده و از اطلاعات دایرکتوری آن تصاویری (Snap- shots) برای ذخیره در مکان‌های دیگر، تهیه می‌کنند. با داشتن این تصاویر، بدون نیاز به این‌که تمام اقدامات فایل سیستم مجددا اجرا شود، می‌توان یک Name Node اولیه که دچار نقص شده است، راه‌اندازی مجدد کرد. چون Name Node تنها نقطه ذخیره و مدیریت فراداده است، برای پشتیبانی از تعداد فايل‌های بسیار زیاد، به‌ویژه وقتی

حجم فای‌لها کم باشد، بدل به یک گلوگاه (Bottleneck) می‌شود که در ویرایش جدید، امکان HDFS Federation به منظور حل این مشکل، با امکان تعریف چندین Name-Space که توسط Name Node های جداگانه سرویس‌دهی می‌شوند، در نظر گرفته شده است.

یک مزیت استفاده از HDFS افزایش هشیاری داده‌ای (Data awareness) بین Job Tracker و Task Tracker است. Job Tracker با اطلاع از محل داده وظایف Task Tracker را کم‌تر می‌کند. به‌عنوان مثال اگر گره A شامل داده (x, y, z) و گره B شامل داده (a, b, c) باشند، Job Tracker با هدف کاهش وظایف روی (a, b, c) گره B را زمان‌بندی و با هدف کاهش وظایف روی (x, y, z) گره A را زمان‌بندی می‌کند که این مساله باعث کاهش حجم ترافیک ارسالی و جلوگیری از انتقال داده غیرضروری می‌شود. البته وقتی هادوپ با سایر فایل سیستم‌ها استفاده می‌شود این مزیت همواره در دسترس نیست که به نوبه خود می‌تواند اثر کاملا ملموسی در زمان کامل شدن Job هایی که درگیر داده هستند داشته باشد.

HDFS برای فایل‌هایی طراحی شده که تغییرات چندانی ندارند و از این رو ممکن است برای سیستم‌هایی که نیاز به چندین عملیات Write همزمان دارند مناسب نباشد. عدم امکان Mount شدن با سیستم‌عامل موجود نیز یکی دیگر از محدودیت‌های HDFS است. از این رو ورود یا استخراج داده‌ها از یک فایل سیستم HDFS  عملی که معمولا قبل و بعد از اجرای یک Job نیاز است – می‌تواند کار دشواری به حساب آید که البته لااقل برای سیستم‌عامل لینوکس و سایر سیستم‌های یونیکسی با در نظر گرفتن فایل سیستمی در دسته فایل سیستم‌های مجازی (Virtual) با نام FUSE این مساله حل شده است.

موتور MapReduce روی لایه فایل سیستم که شامل یک Job Tracker برای ایجاد امکان Submit کردن Job ها توسط Client Application ها است- قرار دارد. Job Tracker وظیفه رساندن کارها به گره‌های Task Tracker قابل دسترس در کلاستر مربوطه را بر عهده دارد، ضمن این‌که تلاش می‌کند تا کار مورد نظر در نزدیکترین فاصله از داده مورد نظر باشد.

با استفاده از یک فایل‌سیستم که از rack پشتیبانی می‌کند Job Tracker به خوبی از گره‌ای که شامل داد ه است و سایر ماشین‌های اطراف آن گره، آگاهی دارد. اگر کار روی گره‌ای که داده‌ها بر آن قرار دارد قابل host شدن نباشد اولویت به گره دیگری که در همان rack قرار دارد اختصاص می‌یابد، که این موضوع نیز باعث کاهش ترافیک روی Backbone شبکه اصلی می‌شود.

اگر Task Tracker دچار نقصی یا Timeout شود، آن بخش از Job مجددا زمان‌بندی خواهد شد. Task Tracker روی هر گره یک پردازه JVM مجزا همراه خود دارد تا چنان‌چه Job در حال اجرا باعث crash کردن JVM شود، خود Task Tracker از کار نیافتد. به منظور چک کردن وضعیتJob Tracker  هر چند دقیقه یک بار پالسی از سوی Task Tracker به آن ارسال می‌شود و وضعیت و اطلاعات این دو توسط Jetty ثبت شده و از طریق web Browser قابل مشاهده است.

در هادوپ نسخه 0.20 و پیش از آن، چنا نچه Job Tracker دچار مشکل می‌شد، تمام کارهای در صف انجام، از دست می‌رفتند. در نسخه 0.21 قابلیت‌هایی به این فرآیند اضافه شد تا امکان از سرگیری کارها از نقطه‌ای که خرابی اتفاق افتاده بود فراهم شود.

محدودیت‌های شناخته شده این رویکرد در هادوپ

اختصاص کار به Task Tracker ها عملی بسیار آسان است. هر Task Tracker تعدادی Slot در دسترس دارد که هرکدام از کارها با در نظر گرفتن نزدیکی به محل قرار گیری داده‌ها، به یکی از Slot ها، بدون در نظر گرفتن بار (Load) جاری سیستم اختصاص می‌یابد. اگر Task Tracker خیلی کند باشد، می‌تواند باعث به تاخیر افتادن کار MapReduce شود.

نسل بعدی MapReduce آپاچی هادوپ با نام YARN

در هادوپ نسخه 0.23 تغییرات کلی یافت و آ نچه که اکنون در دسترس ماست MRV2 یا 2.0 MapReduce یا YARN نامیده می‌شود که در آن بین مدیریت منابع و مولفه‌های پردازشی، جداسازی صورت گرفته است. در حقیقت YARN در اثر نیاز به طیف وسیع‌تری از الگوهای تعاملی برای ذخیره داده‌ها، در HDFS مبتنی بر MapReduce متولد شده است. معماری مبتنی بر YARN از هادوپ نسخه 2.0 یک بستر پردازشی عمومی‌تر ساخته است که محدود به MapReduce نیست.

ایده اصلی MRV2 تفکیک دو کارکرد عمده Job Tracker  یعنی مدیریت منابع (Resource Management) و زمان‌بندی و پالایش Job ها (Job Scheduling/ Monitoring) از یکدیگر است، به گونه‌ای که موجودیت‌های زیر را داشته باشیم:

• a Global Resource Manager (RM)
• a Per-application Application Master (AM)
• a per-node slave Node Manager
• a Per-application container running on a Node Manager

RM یا ResourceManager به همراه NM یا NodeManager سیستم جدید و عمومی‌تری برای مدیریت برنامه‌های کاربردی با شیوه توزیع شده، ایجاد می‌کنند. به عبارت دیگر RM ضمن آن‌که مرجع نهایی برای چگونگی گردش منابع و تخصیص آن‌ها به برنامه‌های کاربردی سیستم به شمار می‌آيد به همراه NM چارچوب محاسبات داده‌ای را فراهم می‌آورد. به عبارتی RM یک برنامه زمانبندی‌کننده (Scheduler) دارد که وظیفه اختصاص منابع به برنامه‌های مختلف در حال اجرا با در نظر گرفتن شرایطی همچون ظرفیت صف (Queue Capacity) و محدودیت کاربران (User-limits) و … را بر عهده دارد. این برنامه زمان‌بندی‌کننده، وظیفه‌اش را بر مبنای الزامات منابع (Resource Requirements) برنامه‌های کاربردی انجام می‌دهد.

AM یک موجودیت مبتنی بر چارچوب است که با کمک RM و NM وظیفه اجرا و پایش وظایف مولفه‌ها را برعهده دارد. NM تابعی از هر ماشین (Per-Machine Slave) است که مسئولیت اجرا کردن حامل (Container) برنامه‌های کاربردی، پایش استفاده منابع (CPU, Memory, Disk, Network) و گزارش آن‌ها به RM را بر عهده دارد. از دیدگاه سیستمی Application Master به‌عنوان یک Container معمولی به‌شمار می‌آید که مسئولیت انتخاب درست Resource Container از برنامه زمان‌بندی‌کننده (scheduler)، پیگیری وضعیت و پایش پیشرفت آن را بر عهده دارد.

YARN به‌عنوان بخشی از هادوپ 2.0 قابلیت‌های مدیریت منابعی که در MapReduce وجود داشت برای engine جدید قابل استفاده می‌کند که در نتیجه آن‌چه که به‌عنوان هدف اصلی به شمار می‌آید، یعنی پردازش داده‌ها را تسهیل می‌کند. اکنون با استفاده از YARN می‌توان چندین برنامه کاربردی را که همگی از یک مدیریت منابع مشترک استفاده می‌کنند در هادوپ اجرا کرد. رویه‌ای که اکنون در ساخت برنامه‌ای کاربردی توسط سازمان‌ها اتخاذ می‌شود نیز استفاده از YARN را مد نظر قرار دارد. هنگامی که داده‌های یک سازمان در قالب HDFS موجود باشد، داشتن چندین راه برای پردازش آن حائز اهمیت است که استفاده از هادوپ 2.0 و YARN را موجه نشان می‌دهد.

آن چه که YARN انجام می‌دهد

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

سازگاری با MapReduce

برنامه‌های MapReduce موجود می‌توانند بدون اختلال در فرآیندهای جاری آن‌ها کماکان اجرا شوند.

استفاده بهبود یافته از کلاستر

RM یک برنامه زمان‌بندی‌کننده محض است که بر اساس شرایطی از قبیل Capacity Guarantees, Fairness و SLAs استفاده از کلاستر را بهینه‌سازی می‌کند. همچنین، بر خلاف گذشته، نبود Named map و کاهش تعداد Slot ها نیز به این بهبود کمک می‌کند.

پشتیبانی از Workload هایی به غیر از MapReduce

امکان پردازش داده‌هایی درباره مدل‌های برنامه‌نویسی مانند پردازش گراف و یا مدل‌های تکراری (Iterative modeling) وجود دارد که این امکان به سازمان‌ها اجازه می‌دهد درک بهتری از پردازش‌های بلادرنگ (real-time) داده‌ها باشند و بدین ترتیب سرمایه اختصاص داده شده به پروژه‌های هادوپ را توجیه‌پذیرتر می‌کند.

چابکی (Agility)

 با توجه به توابع کتابخانه‌ای بسیار و استقلال MapReduce از لایه مدیریت منابع قابلیت چابکی به سرعت در حال تکامل و افزایش است.