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

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

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

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

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

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

مطلب ۸ (قسمت دوم) :بررسی 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 دوباره به اجرا در خواهد آورد.

مطلب ۵ : هدوپ و اکوسیستم آن

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

در ادامه برخی از آنها به اختصار توضیح داده شده اند:

Common

مجموعه ای از مولفه ها و سرویس ها برای فایل سیستم های توزیع شده و مفاهیم عمومی I/O نظیر Serialization،

(Java Remote Procedure Call (RPC می باشد.

مطلب ۲ : نگهداری داده و تحلیل

از آنجایی که ظرفیت ذخیره سازی هارد دیسک ها در سال های اخیر بصورت قابل توجهی افزایش یافته، اما سرعت دسترسی (مدت زمانی که به جهت خواندن داده از روی هاردیسک صرف می شود) آنها به آن اندازه رشد نکرده است. 

یک هارد دیسک معمولی سال 1990 توانایی ذخیره سازی داده تا حدود 1,370 MB با سرعت دسترسی در حدود 4.4 MB/s را داشت. بنابراین تمامی داده آن در حدود پنج دقیقه واکشی می شد. با گذشت بیست سال، هاردیسک ها در حدود یک ترا بایت داده را با سرعت دسترسی در حدود 100 MB/s نگهداری می نمایند، که در این حالت کل داده در حدود دو ساعت و نیم واکشی می شود.

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

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