مطلب ۱۳ : فایل سیستم توزیع شده هدوپ، در دسترس بودن

هرچند در مطلب قبلی به منظور جلوگیری از Data Loss از راهکار ترکیب دو مکانیزم تکثیر فراداده (Metadata) مربوط به namenode روی چندین فایل سیستم و secondary namenode استفاده شد، اما مبحث "در دسترس بودن" (High-Availability) فایل سیستم بصورت کامل پوشش داده نشده است. namenode همچنان یک نقطه پر ریسک محسوب می شود، درصورتیکه این نود به هردلیلی از مدار خارج شود، تمامی client ها از جمله Job های MapReduce دیگر قادر به ادامه تعامل و پردازش نخواهند بود، زیرا namenode به عنوان اصلی ترین منبع فراداده و نگاشت بین بلاک و فایل می باشد. در این مواقع هدوپ دیگر قادر به ارائه سرویس نخواهد بود تا زمانیکه namenode جدید وارد کار شود.

مطلب ۱۲ : فایل سیستم توزیع شده هدوپ، نود

یک کلاستر HDFS دارای دو نوع نود می باشد که بر اساس یک الگوی master-worker طراحی شده اند: یک namenode  به عنوان master  و تعدادی datanode  به عنوان namenode .worker وظیفه مدیریت فضای عملیاتی فایل سیستم را برعهده دارد. این موجود از درخت فایل سیستم و فراداده (Metadata) تمامی فایل ها و پوشه های موجود روی درخت را نگهداری می نماید. اطلاعات همواره در قالب دو فایل روی دیسک محلی نگهداری می شود: namespace image و edit log. همچنین namenode تمامی datanode هایی که بلاک های مربوط به یک فایل روی آنها قرار گرفته را می شناسد، بنابراین نیازی به نگهداری موقعیت بلاک ها ندارد زیرا هنگام بارگذاری سیستم اطلاعات مورد نیاز در مورد آنها را از طریق datanode های مربوطه استخراج می نماید.

مطلب ۱۱ : فایل سیستم توزیع شده هدوپ، بلاک

کوچکترین واحد خواندن و یا نوشتن داده در دیسک را بلاک می نامند. فایل سیستم های معمول که با یک دیسک ارتباط دارند، داده را در تعدادی بلاک سطح بالا تقسیم بندی می نمایند. معمولا اندازه یک بلاک در فایل سیستم چند کیلو بایت است در حالیکه اندازه یک بلاک در دیسک  512 بایت می باشد. البته این نوع تقسیم بندی از دید کاربران پوشیده می باشد.

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

مطلب ۱۰ : فایل سیستم توزیع شده هدوپ، مقدمه

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

هدوپ دارای یک فایل سیستم توزیع شده با نام Hadoop Distributed File System) HDFS) می باشد. HDFS بهترین و مهمترین فایل سیستم هدوپ است.

مطلب ۹ : بهبود فرآیند انتقال داده در MapReduce

با توجه به اینکه در اجرای یک Job در MapReduce به واسطه انتقال داده بین Map Task ها و Reduce Task ها پهنای باند موجود در سطح کلاستر مورد استفاده قرار می گیرد، لذا همواره Job ها با محدودیت انتقال داده و به حداقل رساندن آن به منظور استفاده هر چه بهینه تر از پهنای باند مواجه هستند. هدوپ به کاربران این امکان را می دهد تا آنها بتوانند یک (Combiner Function(CF تعریف نموده که روی خروجی Map اجرا می شود و در نهایت خروجی این نوع تابع به عنوان ورودی به تابع Reduce ارسال می گردد. از آنجایی که CF یک نوع بهینه سازی محسوب می شود، هدوپ هیچگونه تضمینی مبنی بر اینکه چندین بار آن را به ازای یک رکورد از خروجی Map فراخوانی خواهد کرد، نمی دهد. به عبارت دیگر، در صورتیکه تعداد فراخوانی CF صفر، یک، و یا چندین بار باشد، در نهایت می بایست شاهد تولید یک خروجی مشخص و ثابت از Reducer ها بود.

مطلب ۸ (قسمت دوم) :بررسی MapReduce در مقیاس گسترده با استفاده از هدوپ

با مطالعه و بررسی قسمت اول این مطلب، حال واضح است که چرا سایز مناسب یک Split بهتر است به اندازه سایز یک بلاک از HDFS باشد زیرا این اندازه بیشترین مقدار داده ورودی است که می توان مطمئن بود روی یک نود بصورت کامل ذخیره می شود. اگر یک Split بین دو Block پخش شود، احتمال اینکه که یک نود به تنهایی هر دو بلاک را در خود نگهداری نماید زیاد نخواهد بود، بنابراین در این حالت برخی از Split ها مجبوراند به منظور رسیدن به نودی که اجرای Map Task را برعهده دارد روی شبکه منتقل شوند، که البته روشن است کیفیت این نوع پردازش نسبت به حالتی که داده بصورت محلی وجود دارد متفاوت خواهد بود.

Map Task ها خروجی خود را بروی دیسک محلی ذخیره می نمایند، شاید این سوال مطرح شود که چرا از HDFS به منظور این کار استفاده نمی شود؟ خروجی Map به عنوان یک خروجی میانی شناخته می شود: این داده توسط Reduce Task ها مورد پردازش قرار می گیرد تا بر همین اساس خروجی نهایی به وجود آید، و هر گاه اجرای یک Job به اتمام برسد خروجی Map دیگر مورد استفاده قرار نمی گیرد. بنابراین ذخیره سازی آن بروی HDFS (با در نظر گرفتن مکانیزم تکثیر بلاک ها به منظور جلوگیری از Data Loss) یک کار بیهوده خواهد بود. اگر نود اجرا کننده یک Map Task قبل از اینکه بتواند خروجی خود را به یک Reduce Task برساند با شکست مواجه شود، هدوپ بصورت خودکار آن Map Task را بروی نود دیگری به منظور تولید مجدد خروجی Map دوباره به اجرا در خواهد آورد.

مطلب ۸ (قسمت اول) :بررسی MapReduce در مقیاس گسترده با استفاده از هدوپ

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

جریان داده

در آغاز، چند واژه جدید. یک Job  در MapRedcue به یک واحد کاری گفته می شود که به دستور client صورت می گیرد که متشکل است از داده ورودی، برنامه MapReduce، تنظیمات اولیه. هدوپ یک Job را به منظور اجرا به تعدادی Task تقسیم می نماید که خود دارای دو نوع است : Map Task , Reduce Task.

مطلب ۷ : آموزش نصب و راه اندازی هدوپ

نصب و اجرای هدوپ بروی یک ماشین به منظور تست و بررسی اولیه، کار بسیار ساده ای می باشد.

هدوپ به سه حالت نصب می شود:

•  Standalone

در این حالت هیچ یک از Server Role ها (Daemons) نصب نمی شوند (در قسمت های بعدی به آنها خواهیم پرداخت) و تنها یک JVM وظیفه اجرا را به عهده می گیرد. این حالت برای تست و بررسی اولیه برنامه های نوشته شده در MapReduce کاربرد دارد.

•  Pseudo-distributed

در این حالت تمامی Server Role ها (Daemons) بروی یک ماشین نصب می شوند، بنابراین امکان ایجاد یک کلاستر شبیه سازی شده در ابعاد کوچکتر را فراهم می سازد.

•  Fully distributed

در این حالت تمامی Server Role ها (Daemons)  بروی کلاستری از ماشین ها نصب می شوند. این حالت در محیط های عملیاتی مورد استفاده قرار می گیرد.

برای اجرای هدوپ در یکی از سه حالت ذکر شده می بایست به دو نکته دقت شود: Property های مورد نیاز هر حالت مقداردهی شوند، Server Role های (Daemons) هدوپ Start شوند. در حالت Standalone یا Local، فایل سیستم محلی و MapReduce محلی مورد استفاده قرار می گیرد، درمقابل برای دیگر حالت ها HDFS و Server Role های (Daemons) مربوط به MapReduce شروع به کار می کنند.

مطلب ۶ (قسمت سوم) : MapReduce

Java MapReduce

 بعد از آشنایی با چگونگی عملکرد MapReduce، نوبت به پیاده سازی مثال قسمت قبل (یافتن بیشترین درجه آب و هوا به ازای هر سال) در زبان برنامه نویسی Java رسیده است. ما به سه چیز نیاز داریم: تابع map، تابع reduce، تابع main. 

تابع map:

مطلب ۶ (قسمت دوم) : MapReduce

تحلیل داده توسط هدوپ

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

Map and Reduce

در MapReduce پردازش به دو فاز تقسیم می شود: فاز map و فاز reduce. هر فاز به عنوان ورودی و خروجی لیستی از زوجهای key-value دارد، که نوع آن توسط برنامه نویس تعیین می شود. همچنین برنامه نویس موظف است برای هر فاز بصورت جداگانه یک تابع بنویسد: تابع map و تابع reduce.

مثال: بیشترین درجه آب و هوا به ازای هر سال را مشخص نمایید.

در مجموعه داده هواشناسی، فایل های لاگ بصورت متنی و سطر به سطر طراحی شده اند، بنابراین در ورودی تابع map مقدار key بیانگر شماره سطر و مقدار value بیانگر محتوای سطر خواهد بود. البته در این مثال از مقدار key استفاده نمی شود. تابع map ساده می باشد. قرار است که دو فیلد سال و درجه از مقدار value استخراج شوند. توجه داشته باشید که به ازای هر سطر از ورودی یک بار تابع map فراخوانی می شود. در این مثال، تابع map تنها آماده سازی داده را انجام می دهد تا به واسطه آن ورودی تابع reduce فراهم شود.