معرفی هادوپ آپاچی برای داده‌های بزرگ

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

  • ۱. 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 Node، قابلیت High-Availability هادوپ در نسخه HDFS 2.X ارتقا پیدا کرد. چیزی که ممکن است باعث اشتباه برخی افراد شود این است که تصور می‌کنند وقتی Primary Name Node غیرفعال می‌شود Secondary Name node به حالت فعال درمی‌آید در حالی که در حقیقت Name Node ثانویه معمولا همیشه با Name Node اولیه در ارتباط بوده و از اطلاعات دایرکتوری آن تصاویری (Snapshots) برای ذخیره در مکان‌های دیگر، تهیه می‌کنند. با داشتن این تصاویر، بدون نیاز به این‌که تمام اقدامات فایل سیستم مجددا اجرا شود، می‌توان یک 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 قابل دسترس در کلاستر مربوطه را بر عهده دارد، ضمن این‌که تلاش می‌کند تا کار مورد نظر در نزدیک‌ترین فاصله از داده مورد نظر باشد.

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

با استفاده از یک فایل‌سیستم که از 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 قابلیت‌هایی به این فرآیند اضافه شد تا امکان از سرگیری کارها از نقطه‌ای که خرابی اتفاق افتاده بود فراهم شود.

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

نسل بعدی MapReduce آپاچی هادوپ با نام YARN:
MapReduce در هادوپ نسخه 0.23 تغییرات کلی یافت و آن‌چه که اکنون در دسترس ماست MRV2 یا MapReduce 2.0 یا 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 NodeManager
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 می‌توان چندین برنامه کاربردی را که همگی از یک مدیریت منابع مشترک استفاده می‌کنند در هادوپ اجرا کرد. رویه‌ای که اکنون در ساخت برنامه‌ای کاربردی توسط سازمان‌ها اتخاذ می‌شود نیز استفاده از YARN را مد نظر قرار دارد.

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 از لایه مدیریت منابع قابلیت چابکی به سرعت در حال تکامل و افزایش است.