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

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