رویکردها و ابزارهای نوین موثر در آینده پژوهی هوشمندی کسبوکار
اگر عضو یکی از شبکههای زیر هستید میتوانید این مطلب را به شبکهی خود ارسال کنید:
[30 Dec 2016]
[ فرشاد وحیدپور]
چکیده
آینده هوشمندی کسب و کار و آشنایی با ابعاد و مولفههای موثر بر آن همواره مورد توجه مدیران بوده است. بخصوص که امروزه در عصر داده زندگی میکنیم و با حجم داده بسیار زیادی مواجه هستیم. این داده حجیم میتواند تاثیرات بسیار مهمی بر سازمان داشته باشد. از طرفی تغییرات محیط کسبوکار، باعث پیچیدهتر شدن عملیات سازمانی شده است. این پیچیدگیها از طرفی منشاء فرصتها میباشند و از طرف دیگر، مشکلات و موانعی را برای کسبو کار ایجاد میکنند. علاوه براین، عوامل تأثیرگذار سازمانی و عواملی که بر محیط کسب و کار تأثیر دارند شامل بازارها، تقاضای مشتری، تکنولوژی و جامعه میباشند که شدت تأثیر این عوامل در طی زمان بیشتر و بیشتر میشوند و در نتیجه فشارهای محیطی و داخلی بیشتر، رقابت شدیدتر و همچنین مشکلات مدیریتی بیشتر میشوند. بنابراین، حجم وسیعی از دادهها و اطلاعات وارد سازمان شده و سازمانها را دچار مشکل میکنند. با توجه به محیط متغیر و حجم دادههای تولیدی ، مدیران باید فعالتر، منعطفتر، سریعتر باشند تا بتوانند به تحولات محیطی پاسخ مناسب بدهند. بنابراین موضوع مهم ، موضوع تصمیمگیری مدیران است زیرا تصمیمگیری مترادف با مدیریت میباشد و تصمیمگیری مترادف با پیدا کردن بهترین راهحلها در بین گزینههای مختلف میباشد که نیاز به اطلاعات مناسب دارد. بنابراین نیاز به راه حلی میباشد تا بتواند به حل مشکل بپردازد. از آنجایی که دانش در سازمانهای امروز به عنوان دارایی بسیار مهم تلقی میشود و دسترسی به دانش بسیار با اهمیت میباشد ، راهحل استفاده از هوشمندی کسبوکار است. در این حالت سازمانها به آینده چشم خواهند داشت. بدین صورت است که از دل تغییرات امروز در هوشمندی کسبوکار، واقعیت فردا تولد مییابد.
واژههای کلیدی : دادهحجیم ، هوشمندی کسبوکار ، انبار داده ، Hadoop ، Map-Reduce ، HDFS ، Hbase ، Hive ،Pig ، chukwa
مقدمه
داده حجیم به مجموعهای از دادههای بزرگ و پیچیده اطلاق می شود که نرمافزارهای سنتی پردازش اطلاعات امکان پردازش آنها را ندارند.چالش اصلی برخورد با داده حجیم شامل تجزیهوتحلیل، جمع آوری و جستجو در میان دادهها است. فرآیندهای دیگری مانند به اشتراک گذاری، انباشت، انتقال و حفظ امنیت دادهها در پردازش دادههای حجیم مطرح میشوند.
با دسترسی آحاد مردم به ابزارهای هوشمند قابلحمل )نظیر تلفنهمراه و تبلت( و گسترش استفاده از شبکه های اجتماعی، موتورهای جستجو و در حالت کلی با افزایش نفوذ اینترنت در زندگی روزمره مردم ، حجم این دادهها با سرعت رو به افزایش است. همچنین گسترش استفاده از ۱RFID ، دوربینهای مداربسته، خودپردازها ، کارتخوانها و نگهداری دادههای نرمافزارهای ERP در سازمانها منجر به تولید دادههای حجیم میشود.بنابراین تعریف داده حجیم متناسب با مکان و زمان متفاوت میباشد. طبیعی است که آنچه امروز به عنوان داده حجیم تعریف می شود در آینده مفهومی دیگر داشته باشد و داده حجیم شناخته نشود. همچنین مفهوم داده حجیم از یک سازمان به سازمان دیگر و از یک کسبوکار به کسب و کار دیگر در حال تغییر است. [۳] ویژگی های داده های حجیم
در سال ۲۰۰۱ میلادی داگ لنی۲ داده حجیم را به صورت سه V یعنی حجم۳ ، سرعت۴ و تنوع۵ تعریف نمود. امروزه داده حجیم با پنج ویژگی حجم ، تنوع ، سرعت ، تغییر۶ و پیچیدگی۷ شناخته می شود.
۱) حجم : کمیت دادههایی که جمعآوری می شود اهمیت زیادی دارند. اندازه داده مشخص می کند که آیا این دادهها می توانند به صورت بالقوه داده حجیم تلقی شوند؟
۲) تنوع: یکی دیگر از مشخصات داده های حجیم، تنوع دادهها است. بنابراین این مسئله که دادهها مربوط به چه کسبوکاری است و چه مفهومی را پشتیبانی میکند و درنتیجه به چه میزان نیاز به تجزیه و تحلیل دادهها وجود دارد ، در تعیین آنها به عنوان داده حجیم نقش دارد.
۳) سرعت : میزان داده تولید شده در یک بازه زمانی یا به بیان دیگر ، سرعت ایجاد دادههای جدید یکی دیگر از مشخصههای دادههای حجیم است.
۴) تغییر : تغییر دادههای ورودی، یکی از اصلیترین مشکلات مرتبط با دادههای حجیم است. این مفهوم به ناپایداری محیطهایی که داده در آن تولید می شود بر میگردد. هر چه ناپایداری در محیط بیشتر باشد، مدیریت و تحلیل دادهها دشوارتر خواهد شد.
۵) پیچیدگی : مدیریت دادهها فرآیند بسیار پیچیدهای است به خصوص هنگامی که حجم زیادی از دادههای پیچیده از منابع مختلفی تولید شود که نیاز به یکپارچهسازی و همگنسازی دارد.
هدف اصلی این نیست که مقدار زیادی داده بدست آید بلکه هدف این است که بدانیم با حجم انبوهی از داده چه باید کرد. بنابراین باید راهبردی اتخاذ شود تا سازمان ها قادر به دریافت داده از هر منبعی باشند ، دادههای مرتبط را تهیه و تحلیل کنند تا سوالاتی طرح شود که دستیابی به پاسخ آنها منجر به کاهش هزینهها ، کاهش زمان، توسعه محصولات جدید و پیشنهادات جدید و تصمیم گیری هوشمندانه تر در کسب وکار شود.[۴] در مسائل مرتبط با دادههايحجیم ، اندازه و حجم دادهها یک مفهوم نسبی است و بستگی به نقطه آغاز تحلیل و نحوهجمعآوری دادهها دارد. یکی از مهمترین مشکلات موجود رشد سریع تعداد کاربران و نیاز روزافزون به خدماترسانی همزمان به همه کاربران ، به صورت بدون وقفه و با کمترین هزینه ممکن است. یکی دیگر از مشکلات ، انجام تحلیلهاي مختلف و پردازشهاي مربوط به دادههای حجیم است که ميتواند حجم بسیار زیادی از دادههاي موقت تولید کند که مدیریت این نوع دادهها و نگهداری مناسب آنها جهت بهینه نمودن سرعت محاسبات متوالی و بسیار سنگین تحلیلی، امری بسیار چالشبرانگیز است. امروزه در مواجه با چنین مسائلی از روشی با نام MapReduce استفاده ميشود که برای نخستين بار توسط گوگل معرفی شده است و یک مدل برنامهنویسی برای تولید یا پردازش مجموعههاي بزرگ دادهاي بهصورت خودکار و موازی روی خوشهای از تعداد زیادی از سرورها است[۲]. در ادامه مقاله به بررسی MapReduce خواهیم پرداخت.
از طرفی با عنایت به تغییرات سریع در بازار سختافزار و نوآوریهای جدید در زمینه فضاهای ذخیرهسازی ، توان پردازشی و حافظه اصلی سرورها و معرفی سرورهای ارزان قیمت، تمایل سرویسدهندگان به استفاده از آنها در مراکز داده را افزایش داده است. تا چند سال گذشته که از پایگاههايدادهاي رابطهاي به عنوان راهحل ذخیرهسازی دادهها استفاده میشد ، در بحث دادههای حجیم ، معماری مناسب و ایدهآل برای سیستمهاي نرمافزاری و پایگاههاي دادهاي سنتي جهت بهرهبرداری مناسب از مجموعهاي از سختافزارها را نداشته و محدودیتهاي ساختاری، سیستمهای نرمافزاری را در مواجهه با ابعاد مختلف دادههاي حجیم نظیر حجم ، سرعت و تنوع و ناکارآمد ساخته بود. بر این اساس، در چند سال اخیر راهحلهایي برای مدیریت و تحلیل این دادههای حجیم تحت عنوان ۸NOSQL مطرح شده است که پرداختن به آن در این مقاله نمیگنجد.
ارزش افزوده پردازش صحیح و به موقع داده حجیم عبارتند از : [۴] ۱ – داده حجیم ميتواند دستیابی به ارزش بسیار بالای نهفته در دادههاي خام را با شفافسازی دادههاي جمعآوریشده و استفاده از آنها با تناوب بیشتر، فراهمسازد.
۲ – سازمانها ميتوانند ضمن ذخیرهسازی حجم بیشتری از دادهها ، از تنوع و دقت بیشتری نیز بهره ببرند و به تحلیلهاي صحیحتر و منعطفتری دست یابند.
۳ – استفاده از حجمهاي بیشتری از دادهها، این امکان را فراهم ميسازد تا کسبوکارهای مختلف بتوانند تقسيمبنديهاي دقیقتری روي مشتريان انجام داده و خدمات و محصولاتی مناسبتر با نیازهای آنها عرضه کنند.
۴ – سیستمهاي مبتنیبر دادههاي حجیم ، ميتوانند تحلیلهاي پیچیدهتری را ارائه نمایند که قدرت تأثیر مستقیم در تصمیمگیریهاي کلان را خواهند داشت.
۵ – مفهوم داده حجیم ميتواند در بهینهشدن و تصحیح محصولات تولیدکنندگان مختلف مؤثر باشد چراکه حسگرهای مختلف در ابزارهای امروزی، امکان تحلیل نیازها، خواست کاربران و نقاط ضعف و قوت محصولات حاضر را فراهم کرده و راهی برای بهبود محصولات را پيش پای تولیدکنندگان ميگذارد.
شرکتهایی نظیر نظیر آیبیام۹، مایکروسافت۱۰ و اسایپی۱۱ بیش از ۱۵ میلیارد دلار در زمینه داده حجیم سرمایهگذاری نمودهاند. صنعت دادههای حجیم ارزشی بالغ بر چند صد میلیارد دلار داشته و هر سال با در نظر گرفتن نرخ رشد ۱۰% ، با سرعتی دوبرابر کل تجارت نرمافزار در حال پیشرفت است.
هوشمندی کسبوکار۱۲
برخی اهداف مهم زیرساختی هوشمندی کسبوکار در سازمان ، مربوط به ایجاد یک بستر ،چارچوب و معماری با ثبات ، قابل گسترش ، تعاملپذیر و منعطف است که امکان بهکارگیری فنآوریهای نوین تجاری را در سازمان فراهم میکند. میتوان عنوان نمود که احساس نیاز به وجود یک سیستم هوشمندی کسبوکار در سازمان برای اولین بار در سطوح بالای مدیریتی احساس میشود و از بالای هرم ساختار سازمانی به بخشهای زیرین منتقل میگردد. مهمترین عملکرد یک مدیر ، تصمیمگیری است. فرآیند تصمیمگیری میتواند به سه بخش کلی تقسیم شود که عبارتنداز:
• دسترسی ، جمعآوری و پالایش دادهها و اطلاعات مورد نیاز٫
• پردازش ، تحلیل و نتیجهگیری بر اساس دانش.
• اعمال نتیجه و نظارت بر پیامدها یا جریان اطلاعات.
در هر یک از موارد فوق ، سازمانهای قدیمی که از هوشمندی کسبوکار استفاده نمیکنند ، دارای مشکلاتی هستند که اغلب به دلیل حجیم بودن دادهها ، پیچیدگی تحلیلها و ناتوانی در ردگیری پیامدهایی که در مورد آنها تصمیم گرفته شده ، به وجود میآیند. هوشمندی کسبوکار با کمک به حل مشکلات فوق ، به دلیل ساختاری که درسازمان اعمال میکند، فرصتهای جدیدی برای سازمان به وجود میآورد.[۱۱] سیستمهای کاربردی هوشمندی کسبوکار سازمانها را قادر میسازند تا با آگاهی بیشتری تصمیمگیری نموده و مزیت رقابتی را برای شرکت ایجاد مینمایند. به عنوان مثال یک شرکت با استفاده از این سیستمها، اطلاعات و شاخصهای محیطی ، پیرامون را مقایسه نموده و همچنین آینده پیشرفت و روند کارها را در زمینه فعالیت خود پیشبینی میکند.
سیستمهای کاربردی هوشمندی کسبوکار به شرکتها کمک میکنند تا روند تغییرات را در بازار سهام، تغییرات در رفتار مشتریان و الگوهای مصرف، اولویتهای مشتریان، تواناییهای شرکت و در نهایت وضعیت شرکت را تجزیه و تحلیل کنند. همچنین به تحلیلگران و مدیران برای تنظیم پاسخ به روند تغییرات نیز کمک مینماید و نیز به سازمانها کمک میکنند تا ثبات و پایداری بیشتری را ایجاد کنند و فرآیند تصمیمگیری مبتنی بر دادهها را که نتایج بهتری دارد جایگزین تصمیمگیری برمبنای حدس و گمان در فعالیتهای تجاری نمایند. به علاوه ارتباط بین واحدها را افزایش داده، فعالیتها را هماهنگ میکند و سازمانها را برای پاسخ سریعتر به تغییرات تجهیز مینماید.[۱۳] زمانی که سیستمهای هوشمندی کسبوکار به طور مناسب و صحیح طراحی و با فرآیندهای سازمان منطبق شده باشند و از سوی دیگر اطلاعات آن برای تصمیمسازی قابلیت استفاده داشته باشد، قادر خواهد بود تا عملکرد سازمان را بهبود دهد. دسترسی به اطلاعات صحیح و به موقع، سرمایه مهمی برای هر سازمان محسوب میشود، این موضوع سرعت تصمیمگیریها را افزایش داده و رضایت مشتریان را به همراه خواهد داشت.
ارائه خدمات به مشتریان به عنوان یک موضوع رقابتی، سازمانها را ملزم به داشتن اطلاعات به روز و دقیق در مورد اولویتها و نیاز های مشتریان میکند تا بتواند به سرعت، خودشان را با تغییر تقاضاها در بازار رقابتی وفق دهند.
هوشمندی کسبوکار ، سازمانها را قادر میسازد تا اطلاعاتی را در مورد روند فعالیتها در بازار جمعآوری کنند و تغییر در تولیدات یا خدمات مورد انتظار مشتریان را پیشبینی نمایند. همچنین این سیستمها به مدیران کمک میکنند تا از فعالیتهای شرکت رقیب مطلع شوند.
برای کارکرد موثر سیستمهای هوشمندی کسبوکار، سازمانها باید سیستمهای مکانیزه قابل اطمینانی داشته باشند تا بتوانند براساس سطوح مختلف سازمانی دسترسی به انبار دادهها را براساس سطح استفادهکنندگان یعنی کارمند، مدیر یا مدیر اجرایی تعیین کنند. به علاوه این سیستمها نیاز به ظرفیت کافی برای اطلاعات و برنامهای برای ذخیره و نگهداری دادهها دارند.نرمافزارهایی که توسط تحلیلگران هوشمندی کسبوکار تولید میشود امکان جمعآوری و تجزیه و تحلیل حجم زیادی از دادههای بدون ساختار را مانند معیارهای اندازهگیری تولید و تهیه گزارشهایی مانند آمارهای فروش، گزارش از خدمات ارائه شده و تعداد مشتریان انصراف داده، فراهم مینمایند. هر کدام از شرکتهای ارائه کننده خدمات هوشمندی کسبوکار به طورمعمول سیستمهای متفاوت و خاص خود را تولید میکند. هوشمندی کسبوکار بر پایه معماری انبار داده۱۳ یا مخزن داده عمل مینماید.
معماریهای انبار داده
امروزه معماری انبار داده بر اساس دو روش کلاسیک یا مدرن پیادهسازی میشود. در تصویر ۱ ، معماری کلاسیک انبار داده را مشاهده مینمائید. در چند سال اخیر معماری کلاسیک انبار داده دستخوش تغییر شده و مفاهیم جدیدی در معماری انبار داده وارد شده است. در تصویر ۲ معماری مدرن انبار داده را ملاحظه مینمائید. [۳] در معماری مدرن انبار داده تغییرات اساسی نسبت به معماری کلاسیک انبار داده مشاهده میشود. معماری مدرن انبار داده بر اساس مفاهیم دادهحجیم شکل داده شده است. جهت انتخاب بهترین راهبرد جهت استفاده از دادههای حجیم از Hadoop استفاده شده است. از طرفی دادهگاه/انبارک داده۱۴ در معماری کلاسیک تبدیل به انبارک تحلیلی۱۵ شده است. انبارک تحلیلی ورودی خود را از Hadoop دریافت می نماید. مشاهده میشود که مهمترین تغییر در معماری مدرن انبار داده ، استفاده از Hadoop میباشد. منشاء شکلگیری هادُپ به سیستم فایلی گوگل که در سال ۲۰۰۳ میلادی معرفی شد برمیگردد. [۳]
شرکت گوگل و ۱۶GFS
در سال ۲۰۰۳ میلادی در نوزدهمین کنفرانس ACM،مقاله سیستمفایلی گوگل توسط سانجای گِماوات۱۷ ، هوارد گوبیوف۱۸ و شانتاک لیونگ۱۹ مهندسین نرمافزار گوگل ارائه شد. [۱] جهت درک کاربرد و نتایج این پروژه ، فناوري و دانشي را در نظر بگيريد که در پشت زمينه صفحه اصلي موتور جستوجوي گوگل مورد استفاده قرار ميگيرد. در پشت الگوريتمها و ساير قابليتهايي که گوگل جهت جستجو بر مبناي متن وارد شده فراهم مينماید يک مرکز داده بزرگ نيز وجود دارد. در اين مرکز داده ، کپي متني و کاملي از هر آنچه در اينترنت وجود دارد ذخيره شده است. در همان زمان که کاربران در حال وارد کردن متن مورد نظر و جستجو اينترنتی هستند ، اين کپي عظيم از داده (داده حجیم) نيز به طور متناوب با دادههاي جديد بهروزرساني ميشود. به موازات همه اين فرآيندها ، دادههاي موجود توسط پردازندههای هزاران سرور مجزا در حال پردازش است. هر يک از اين پردازندهها ميتواند هر کاري، از انتخاب آگهي متناسب با متن مورد جستوجوي کاربر تا فرآيند مرتبسازي جهت تعيين ترتيب نمايش آنها را انجام دهند.
سيستم ذخيرهسازي استفاده شده در موتور جستوجوي گوگل بايد این قابلیت را داشته باشد که در هر روز به ميليونها درخواست خواندن و نوشتن اطلاعات پاسخ دهد. اين درخواستها توسط پردازشهايي ارسال ميشود که به صورت مستقل روي هزاران سرور مختلف ، در حال اجرا هستند. فرآيند پشتيبانگيري يا نگهداري از سيستم ، تحت هيچ شرايطي نبايد منجر به غيرفعال شدن اين سرويسها شوند. از طرف ديگر اين مجموعه دادهاي مجبور است به صورت بيوقفه در حال رشد و گسترش باشد. اين قابليت از آن جهت اهميت دارد که زيرساخت ذخيرهسازي بايد بتواند صفحات يافته شده توسط روباتهاي جستوجوگر اينترنت را که هر روز بر تعداد آنها افزوده ميشود، ذخيره کنند.
روباتهاي موتور جستوجوي گوگل روزانه بيش از بیست پِتابايت۲۰ داده را پردازش ميکنند. شرکت گوگل براي پاسخگويي به چنين نيازي نميتواند حتي به قويترين معماريهاي ذخيرهسازي که به صورت معمول در ساير پروژههاي بزرگ استفاده ميشوند تکيه کند. ساير غولهاي دنياي وب و ابَرشرکتهاي ارائه دهنده محيط پردازش ابري۲۱ و مراکز داده فوقالعاده بزرگ نيز با چالشهاي مشابهي روبهرو هستند. از جمله اين ابَر شرکتها ميتوان به یاهو۲۲ ، آمازون۲۳ ، والمارت۲۴ و شبکههای اجتماعی نظیر Face Book اشاره نمود.
بيشتر مراکز داده سعي دارند تا فرآيند مقياسپذيري فضاي ذخيرهسازي داده را از طريق افزودن به ظرفيتهاي ديسکها و تعداد سرورهاي پايگاهداده و سرورهاي متصل به رسانههاي ذخيرهسازي، به انجام برسانند. اما اين رويکرد معمولاً با شکست مواجه ميشود زيرا محدوديتها و الزامات موجود در محيط ابري جهت رسيدن به سطح کارآيي و عملکرد بالا، چالشي است که روش مذکور نميتواند پاسخگوي آن باشد. در محيط ابري ممکن است در هر زمان با هزاران کاربر فعال مواجه باشيم که بايد به دادهها دسترسي داشتهباشند و دادههايي که بايد در هر لحظه نوشته يا خوانده شوند، از چندين هزار ترابايت فراتر میرود.
بنابراین مسئلهای که مطرح میشود چيزي فراتر از سرعت خواندن و نوشتن ديسک است. وقتي جريان داده در سطح شبکه ذخيرهسازي به اين حد ميرسد، عملکرد و بازدهي شبکه ذخيرهسازي داده است که مشکلساز ميشود. حتي در صورت استفاده از بهترين سرورها و رسانههاي ذخيرهسازي، باز هم ممکن است تجهيزات ۲۵SAN مورد استفاده، تبديل به گلوگاهي در مسير دسترسي و پردازش داده، شوند. معمولاً در اين وضعيت، با مشکلات مرتبط با محدوديت در مقياسپذيري سيستم بوجود میآید .
با در نظر گرفتن سرعت افزايش ظرفيت مراکز داده در شرکتهاي بزرگ مبتني بر وب با استفاده از روشهاي معمولي که در مراکز داده کنوني براي ارتقاي ظرفيت به کار ميرود،هزينههاي نرمافزاري، سختافزاري و مديريتي اين فرآيند، بسيار زياد خواهد بود. سرعت افزایش ظرفیت به حدی است که امروزه در هر روز ظرفیتی برابر با ظرفیت سالانه سال ۲۰۰۱ میلادی به ظرفیت برخی مراکز داده اضافه میشود.
اين هزينهها هنگامیکه که پايگاههاي داده رابطهاي۲۶ به اين مجموعه افزوده شود، پيچيدهتر ميشود. ميزان اين پيچيدگي به نحوه توزيع داده و تهيه مرکز داده پشتيبان براي مرکز اصلي، وابسته است. نياز به چنين سطحي از مقياسپذيري و افزايش مداوم حجم مرکز داده و همچنين نياز به محيط ذخيرهسازي پایدار، این نیاز را برای شرکتهاي عظيم ارائهدهنده خدمات مبتني بر وب بوجود آورده است که سيستمهاي مديريت فايل توزيعشده۲۷ براساس رسانهذخيرهسازي مبتنی بر شیء۲۸ را انتخاب نمایند.
اين نوع سيستمها، حداقل تا حدودي از ساير سيستمهاي فايلي توزيع شده و خوشهاي نظير Global File System شرکت ردهت۲۹ و فناوري General Parallel Filesystem شرکت آیبیام الهام گرفته شدهاند. معماري سيستم فايلي در محيط شرکتهاي فراهمآورنده خدمات ابري، فراداده۳۰ را مستقل از خود داده ذخيرهشده در نظر ميگيرد. بنابراین امکان نوشتن و خواندن حجم عظيمي داده از روي کپيهاي متعدد داده فراهم شود و بدین ترتيب مفاهيم و مشکلاتي نظير قفل شدن فايل از بین ميرود.
تأثير سيستمهاي فايلي توزيعشده، فراتر از محدوده مراکز داده بسيار عظيمي است که از اين نوع سيستم فايلي استفاده ميکنند. اين نوع سيستمهاي فايلي تأثير مستقيمي بر نحوه توسعه و پيادهسازي برنامههايي داشتهاند که کاربران خدمات ابري همگاني نظير ۳۱EC2/S3 آمازون، App Engine گوگل يا Azure مايکروسافت۳۲ در حال استفاده از آنها هستند. همچنين این نوع سیستمهای فایلی برای دولتها ، دانشگاهها و سازمانها کاربرد بسیاری دارد تا بتوانند به سرعت دادههاي حجیم مورد نياز خود را ذخيره نموده و به آن دسترسی داشته باشند. [۹] شرکت گوگل، يکي از نخستين سازمانهایی بود که با مشکل مقياسپذيري رسانه ذخيرهسازي و مسائل مرتبط با آن روبرو شد و ايجاد يک سيستمفايلي توزيع شده، راهحلي بود که مهندسان نرمافزار گوگل در سال ۲۰۰۳ براي اين مشکل ارائه کردند.[۱] اين سيستمفایلی که Google File System يا GFS ناميده ميشود، به طور سفارشي و متناسب با راهبرد مورد استفاده در مراکز داده شرکت گوگل ايجاد و به کارگیری شده است. زيرساختار اصلي GFS براي تقريباً تمام سرويسهاي مبتني بر محيط ابري است که شرکت گوگل عرضه ميکند. اين سيستمفايلي نيازهاي متنوع مرتبط با ذخيرهسازي داده را مرتفع ميکند که از جمله آنها ميتوان به پايگاهداده BigTable و همچنين دادههاي AppEngine اشاره نمود.
گِماوات در مقاله سال ۲۰۰۳ مطرح نموده که سيستمفايلي GFS با در نظر گرفتن اولويتهاي خاصي طراحي شده است.[۱] مطابق اطلاعات ارائه شده در این مقاله هدف از طراحي GFS، تبديل تعداد زيادي از سرورها و دیسکهای سخت۳۳ ارزانقيمت، به مجموعهاي است که قابلیت ذخیره و مدیریت صدها ترابايت داده را داشته باشد و در صورت بروز خطا يا نقصهای سختافزاري ، امکان برطرف نمودن مشکل وجود داشته باشد. نحوه عملکرد GFS بسيار شبيه روش انجام فرآيند RAID5 است که در آن داده به صورت تکهتکه در سطح تمام ديسکهای RAIDشده ذخيره ميشود تا جلوي از بین رفتن داده گرفته شود. در GFS فايلها به صورت قطعاتی با اندازه ثابت در سطح خوشهاي۳۴ از سرورها کپي و توزيع ميشود. GFS به صورتی طراحي شده که بتواند بدون از دست دادن حجم قابل توجهي از داده براي اين گونه خطاها، راهکار ارائه دهد. در GFS ميتوان سرورهاي مورد بحث را در سطح شبکه توزيع کرد. بنابراین سرورها ميتوانند در يک يا چند مرکز داده توزيع شوند. در GFS موضوع مهم خواندن سريع داده است و شاخصهایی نظير سرعت دسترسي به يک قسمت خاص از فايل يا سرعت نوشتن داده در سيستمفايلي اهميت چنداني ندارد. هزينه دستيابي به سرعت بالا در سيستمفايلي GFS ، نوشتن و خواندن قطعهبندي شده روي چندين ديسک است. گِماوات در مقاله خود تاکید نموده «نوشتن قطعات کوچک داده در آدرسهاي متعدد و متفاوت توسط اين سيستمفايلي پشتيباني ميشود اما لزوماً کارآيي بالايي ندارد.»
ماهيت توزيع شده GFS و داده حجیمی که توسط اين سيستمفايلي مديريت ميشود به معني هزينهها و اثرات جانبي مشخصي است و اين اثرات جانبي باعث ميشود تا سيستمفايلي GFS براي نصب روي يک سرور مستقل و منفرد گزينه نامناسبي باشد. اين سيستمفايلي بايد جامعيت دادهها را تضمين نموده و سربار ناشي از فرآيند همزمانسازي را نيز به حداقل برساند تا از هر گونه کاهش کارآيي جلوگيري شود.
معماری سیستم فایلی GFS
سیستمفایلی GFS از سه لايه تشکيل میشود.يک کلاينت GFS که وظيفه آن پاسخگويي به درخواست داده از جانب برنامهها است؛ يک مرجع که با استفاده از يک انديس مقيم در حافظه به رديابي فايلهاي داده و مکان قطعات هر فايل داده در حافظه ميپردازد. عنصر بعدي اين معماري سرورهاي ارائه خدمات است که “chunk servers” نامیده میشود.در نگارش اولیه این سیستمفایلی به منظور حفظ سادگي اين روش ، GFS از يک مرجع به ازاي هر خوشه استفاده ميکرد. بدین ترتیب ترتيب وظيفه سيستم اين بود که تا حد ممکن ، بار کاري پردازش مرجع را در جهت تعيين روش دسترسي به داده، به حداقل برساند. اما در نگارشهای بعدی GFS ، گوگل يک سيستم مرجع توزيع شده فراهم نموده که ميتواند مديريت صدها مرجع را انجام دهد و هر يک از اين مرجعها نيز ميتواند حدود صد ميليون فايل را مديريت کنند. [۱] هنگامیکه که کلاينت فايل سيستم GFS ، درخواستي را به منظور دسترسي به يک فايل داده خاص دريافت ميکند درخواستي را براي سرور مرجع ارسال نموده تا آدرس فايل را به دست آورد. سرور مرجع ، آدرس يکي از کپيهاي داده مورد نظر را اعلام و کلاينت نيز به طور مستقيم با آن chunk server تعامل ميکند و بدین ترتيب فرآيند نوشتن و خواندن داده انجام ميشود. بنابراین سرور مرجع ديگر در اين فرآيند نقشي نخواهد داشت، مگر آنکه بخشي از اين فرآيند و عملکردها، با خطا مواجه شود. سيستمفايلي GFS براي تضمين بالاترين ميزان دسترسي به اين مجموعه داده ، بعضي از هزينهها را پذیرفته و برخی قابلیتها را قربانی میکند، نظير اصل ثبات و تشابه داده به ازاي کليه کپيهاي داده. همچنين GFS اصل تکهتکهکردن داده را تا حد ممکن اعمال ميکند. اگر يکي از فرآيندهاي نوشتن داده با خطا مواجه شود، در اين صورت فرآيند بازگرداندن فراداده به وضعيت قبلي انجام ميشود و يک کپي از داده قبلي را دوباره در اختيار درخواست مورد نظر قرار ميدهد. اما از طرفي ، عدم مشارکت سرور مرجع در فرآيندهاي نوشتن بدین معنا است که به موازات نوشته شدن داده در سيستم اين تغييرات به طور آني در ساير کپيهاي آن داده که در سطح هر خوشه وجود دارند، منعکس نميشود. سیستمفایلی GFS از فرآيندي بهره میبرد که گوگل آن را “relaxed consistency model” مينامد. استفاده از اين فرآيند، بدین معني است که GFS هيچ مشکلي با ارائه اطلاعات کهنه و قديمي ندارد. به بیان دیگر اگر در آن لحظه خاص ، داده جديد هنوز در سطح سيستم توزيع نشده باشد و کپيهاي در دسترس ، نسخههاي قديمي باشند، GFS همان دادههاي قديمي را به درخواست کننده تحويل خواهد داد. البته سرور مرجع تا حد امکان سعي میکند دادهها را به روز نگه دارد و براي اين کار به رديابي تغييرات ميپردازد و براي اين منظور به ازاء هر کپي، شماره نگارش قطعات داده را با هم مقايسه ميکند. به محض اینکه بعضي از کپيهاي داده از فرآيند بروزرساني عقب مانده باشند ، سرور مرجع GFS اين اطمينان را ايجاد مينماید که آدرس اين قطعات بروزرسانی نشده در اختيار کلاينتها قرار نميگيرد و اين محدوديت تا زماني اعمال ميشود که داده آن chunk بروزرساني شود. البته الزامی در رابطه با دادههایی که chunk آنها از قبل انجام شده شده است وجود ندارد. فراداده تغييرات تا زماني که سرور مرجع، تغييرات را بررسي نکرده و آنها را در فراداده منعکس نکردهباشد، اعمال نميشود. البته فراداده نيز در چندين مکان مختلف کپي شود تا در صورت بروز خطا در کپي اصلي، جايگزيني براي آن، وجود داشته باشد. اگر اين فرآيند انجام نشود، با از دست رفتن دادههای مرجع، کل اطلاعات مورد نياز جهت استفاده از اين سيستمفايلي، از دست ميرود. همچنين اگر در طول فرآيند نوشتن، سرور مرجع با خطا مواجه شود، تغييرات نیز به طور کامل از دست ميروند.
سيستمفايلي GFS براي پاسخگويي به برنامههايي تهيه شد که گوگل در سال ۲۰۰۳ میلادی به کاربران خود معرفي نموده بود، يعني زماني که گوگل هنوز با مشکلات مرتبط با مقياسپذيري سيستمها مواجه نشدهبود. در آن مقطع زمانی گوگل برای استفاده از سيستمفايلي GFS با مشکلاتي مواجه شد. بدین صورت که برنامههاي جديد گوگل در تعامل با اندازه فايل ۶۴مگابايتي عملکرد صحیحی نداشتند. براي برطرف نمودن اين مشکل، گوگل براي ذخيرهسازي داده به سراغ روش مبتني بر Bigtable رفت که بر روي زيرساخت و سيستمفايلي GFS قرار ميگيرد. ماهيت Bigtable نيز همانند سيستمفايلي GFS «فقط يکبار نوشتن» است. بنابراین کليه تغييرات در قالب افزوده شدن داده به جدولها ، بوجود می آیند. گوگل از اين راهکار در برنامههايي نظير Google Docs استفاده ميکند تا مسئله کنترل نگارش داده را مديريت کند.
محيط Google Cloud Storage، راهکاري را فراهم مينماید تا کاربران بتوانند آنچه را ميخواهند از طريق يک رابط تحت وب، در سطح سيستمفايلي GFS ، ذخيره و به آن دسترسي داشته باشند. با گذشت بیش از ۱۲ سال همچنان اطلاعات دقيقی در مورد رابطها و ابزارهاي اصلي براي دسترسي به سيستمفايلي GFS منتشر نشده اما وجود و ارائه مستنداتي که سيستمفايلي GFS را تشريح ميکنند ، منجر به ارائه يک سيستمفايلي توزيعشده ديگر به نام Hadoop Distributed File System شده است که در ادامه مقاله به بررسی آن خواهیم پرداخت.
هادوپ۳۵
هادوپ توسط داگلاس کاتینگ۳۶ طراح و نویسنده کتابخانه پُرکاربرد جستجوی متن Lucene و خزنده وب Nutch ، ایجاد شده است. ساخت موتور جستجوی وب از نقطه صفر هدفی بزرگ محسوب میشود چرا که از یک طرف نوشتن نرمافزاری که در وبسایتها خزیده و آنها را نمایهسازی۳۷ کند کاری پیچیده است و از سوی دیگر اجرای آن بدون یک تیم عملیاتی تماموقت اختصاصی چالشبرانگیز است. پروژه Nutch در سال ۲۰۰۲ میلادی آغاز و به سرعت یک خزنده وب و یک سامانه جستجو برای آن ساخته شد. تیم سازنده دریافتند که معماری آنها برای میلیاردها صفحه روی وب گسترشپذیر نیست. چاپ مقاله گِماوات در رابطه سیستمفایل گوگل در سال ۲۰۰۳ میلادی به آنها کمک کرد که این مشکل گسترش معماری خود را حل نمایند. بدین صورت که نیاز آنها به ذخیرهسازی فایلهای بسیار بزرگی که از خروجی فرآیند خزیدن در وب و نمایهسازی آن ساخته شده بود را حل میکرد. در سال ۲۰۰۴ میلادی آنها شروع به پیادهسازی نسخهای کُدباز از GFS نمودند و آن را سیستمفایل توزیع شده ناچ۳۸ نامیدند.
در سال ۲۰۰۴ جفری دین۳۹ و سانجای گماوات از شرکت گوگل مقالهی دیگری چاپ نمودند که در آن نگاشت-کاهش یا MapReduce را معرفی کردند. [۲] نگاشت-کاهش یک مدل برنامه نویسی برای پردازش مجموعه دادههای حجیم است. در چارچوب نگاشت-کاهش ، کاربر ، محاسبات را در قالب یک تابع نگاشت و یک تابع کاهش مینویسد و سیستم به صورت خودکار ، محاسبات را در بین خوشههای بزرگی از ماشینها به صورت موازی انجام میدهد و خرابیهای ماشین را مدیریت و ارتباطات بینماشینی را زمانبندی میکند تا استفاده از شبکه و منابع دیسکها سادهتر و سودمندتر گردد. بدین ترتیب برنامه نویس تنها بر روی نوشتن این دو تابع تمرکز کرده و موازی سازی محاسبات انبوه و بکار بردن سیستم و مدیریت خرابی ها برایش ساده میشود.
در هنگام انجام پردازش با MapReduce به صورت خودکار ، دادههای ورودی به چندین بلوک شکسته شده که هر بلوک توسط یک تابع map() پردازش میشود و سپس نتایج تمامی توابع map ، به عنوان ورودی به تابع reduce() ارجاع داده شده و توسط تابع reduce() ترکیب می شوند.
MapReduce روش برنامهنویسی است که امکان مقیاسپذیری گسترده در سطح صدها یا هزاران سرور در یک خوشه را میدهد. MapReduce دو وظیفه جداگانه و مجزا انجام میدهد. اولین وظیفه ، نگاشت (map) است که یک مجموعه داده را گرفته و آن را به مجموعه دیگری از داده تبدیل میکند، که در آن عناصر فردی به جفت کلید/مقدار۴۰ شکسته می شوند. مرحله کاهش (reduce) ، خروجی را از یک نگاشت میگیرد و جفتهای کلید/مقدار را به یک مجموعه جفت کلید/مقدار کوچکتر تبدیل میکند. مرحله کاهش همیشه بعد از مرحله نگاشت انجام می شود. [۵] کاتینگ و همکارانش در اوایل سال ۲۰۰۵ میلادی نسخهای از MapReduce را پیادهسازی نموده و در همان سال تمامی الگوریتمهای اصلی Nutch برای کار با MapReduce و NDFS تغییر دادند. نسخهی پیادهسازی شده از MapReduce و NDFS در Nutch برای کاربردهایی فراتر از جستجو نیز کاربرد داشت بنابراین در آغاز سال ۲۰۰۶ میلادی تجربیات و نتایج حاصله از Nutch جدا و مستقل شده و Hadoop پا به عرصه وجود گذاشت.
داگلاس کاتینگ نام فيل اسباببازي پسرش ، هادوپ را برای محصول جدید انتخاب نمود. در همان زمان داگلاس کاتینگ به یاهو پیوست که تیم و منابع اختصاصی را برای کار بر روی هادوپ فراهم کرده بود تا آن را به سیستمی برای کار در مقیاس وب تبدیل نماید.در سال ۲۰۰۸ میلادی یاهو اعلام نمود که نمایه جستجوی آن توسط خوشهای از هادوپ با ۱۰۰۰۰ هسته ساخته شده است. در همان سال هادوپ یک پروژه سطح بالای بنیاد آپاچی۴۱ شد که نشان دهنده موفقیت، مقبولیت و جامعه کاربری فعال آن است. سازمانهای دیگری نظیر فیسبوک و نیویورک تایمز از هادوپ استفاده کردهاند. نیویورک تایمز از سرویس ابری EC2 آمازون استفاده کرد تا ۴ ترابایت صفحه پویش شده را به PDF مناسب برای وب تبدیل نماید. عملیات پردازش با استفاده از ۱۰۰ سرور کمتر از ۲۴ ساعت زمان برد. در اواسط سال ۲۰۰۸ میلادی، هادوپ تیدیل به سریعترین سیستم مرتبسازی یک ترابایت داده شد. با اجرا روی خوشهای با ۹۱۰ گره ، هادوپ یک ترابایت را در ۲۰۹ ثانیه مرتب کرد. در همان سال گوگل اعلام نمود که پیادهسازی MapReduce یک ترابایت را در ۶۸ ثانیه مرتب کرده است. در سال ۲۰۰۹ میلادی یاهو اعلام کرد که توانسته یک ترابایت را با استفاده از هادوپ در ۶۲ ثانیه مرتب نماید.
از هادوپ برای ذخیره اطلاعات ساخت نیافته یا شِبهساختیافته در پایگاه داده های NoSQL نیز استفاده میشود.با توجه به این مسئله که پایگاه دادههای رابطهای کارآیی خود را برای پخش دادههای حجیم بر روی سرورهای مختلف از دست دادهاند حرکت به سوی پایگاه داده های NoSQL آغاز شد و امروزه هادوپ بستری برای NoSQL می باشد. [۶]
معماری سیستمفایلی هادوپ۴۲
معماری سيستمفايلی HDFS شبیه به GFS است و از ساختار سهلايهاي و تکمرجع آن پيروي ميکند. هر خوشه از هادوپ، يک سرور مرجع دارد که NameNode ناميده ميشود. اين سرور مرجع مسئول رديابي فراداده است و آدرس و وضعيت کپيهاي مربوط به هر يک از بلاکهاي ۶۴ مگابايتي داده را نگهداري ميکند. دادهها از طريق همين NameNode در محيط خوشه کپي ميشوند و سيستمهاي Data Node مسئوليت نوشتن و خواندن داده را بر عهده دارند. به طور پيشفرض هر بلاک داده، سه بار کپي ميشود اما ميتوان از طريق تغيير تنظيمات خوشهها ، تعداد کپيها را نيز تغيير داد.[۹] در HDFS همانند GFS ، سرور مرجع به سرعت از فرآيندهاي نوشتن و خواندن کنار گذاشته ميشود. اين کار مانع از ايجاد گلوگاه در عملکرد سيستم ميشود. زماني که درخواستي براي دسترسي به داده مطرح ميشود، سرور مرجع NameNode اطلاعات مکاني مربوط به DataNode را بازميگرداند. در اين فرآيند آدرس مربوط به يکي از کپيها برگردانده ميشود که کمترين فاصله را تا محل درخواست داده داشته باشد. همچنين سرور مرجع NameNode، مسئول بررسي و رديابي سلامت هر يک از DataNodeها میباشد. اين فرآيند از طريق پروتکلي به نام heartbeat انجام ميشود که مانع ارسال درخواست به DataNodeهايي که پاسخ نميدهند ميشود و آنها را با برچسب۴۳ «dead» علامتگذاري ميکند. بعد از اعلام آدرس، سرور مرجع NameNode براي تکميل فرآيند هيچ مسئوليت ديگري بر عهده ندارد. هرگونه تغيير در DataNodeها بعد از کاملشدن ، به سرور NameNode گزارش داده شده و در قالب يک فايل ثبت جزئيات عمليات۴۴ ذخيره ميشود. اين فايل در مرحله کپيبرداري از داده و به منظور اعمال تغييرات در سطح DataNodeها مورد استفاده قرار ميگيرد. اين فرآيند نيز همانند فرآيند معادل در محيط GFS، به کندي انجام ميشود. در اين فرآيند نيز به موازات هدايت درخواستها به سمت بهروزترين دادهها، پردازشهاي پسزمينهاي که در حال فعاليت هستند غالباً از همان دادههاي کهنه و قديمي استفاده ميکنند تا فرآيند به روزآوري به اتمام برسد.
از آنجا که دادهها و سرويسهاي محيط HDFS طوري طراحي شدهاند که دادهها فقط يکبار نوشته شود، شرايط فوق به ندرت رخ ميدهد. تغييرات دادهها در اين روش معمولاً در قالب افزوده شدن داده به دادههاي قبلي است، نه بازنويسي روي دادههاي جديد و در نتيجه حفظ ثُبات داده، آسانتر خواهد بود. از طرف ديگر به دليل ماهيت برنامههايي که از هادوپ استفاده ميکنند، دادهها معمولاً به صورت گروهي و در قالب قطعات بزرگ براي سيستمفايلي، ارسال میشوند. زماني که يک کلاينت، دادهاي را براي نوشتهشدن در محيط HDFS ارسال ميکند، اين داده در نخستين مرحله توسط برنامه کلاينت، در يک فايل موقت محلي ذخيره ميشود تا اندازه آن به ۶۴ مگابايت که اندازه پيشفرض بلاکها است، برسد. سپس کلاينت درخواستي را براي NameNode ارسال ميکند و نام يک DataNode را دريافت ميکند.
در مرحله بعدي، آدرس مذکور قفل شده و داده در آن ذخيره ميشود. اين فرآيند به طور متوالي و مجزا ، به ازاء هر بلاک از داده نهايي، انجام ميشود. با اين روش حجم ترافيک شبکه نيز کاهش مييابد و اما سرعت نوشتن داده نيز کندتر ميشود. ولی بايد در نظر داشت که HDFS بيشتر براي انجام فرآيندهاي خواندن داده طراحي شده و هدف اصلی آن فرآيندهاي نوشتن و ذخيره داده نمیباشد.[۱۷] يکي ديگر از ويژگيهاي HDFS که منجر به کاهش ترافيک نوشتن داده در سطح شبکه ميشود، به نحوه تهيه کپي از داده در اين سيستمفايلي باز ميگردد. با فعالکردن يکي از قابليتهاي HDFS با نام “rack awareness” امکان مديريت توزيعهاي مختلفي از داده فراهم ميشود. بدین ترتيب، مدير سيستم ميتواند به ازاي هر گره۴۵ ، يک rack ID تعيين کند. با اين کار و از طريق يک متغير در فايل متني تنظيمات، محل فيزيکي هر يک از دادهها مشخص میشود. به صورت پيشفرض، تمامی گرهها در يک rack قرار دارند، اما هنگامیکه پارامتر rack awareness فعال شود ، سيستمفايلي HDFS ، يک کپي از داده را در گره ديگري و در محل فيزيکي ديگری قرار ميدهد که در همان مرکز داده متناظر با آن rack قرار دارد و کپي ديگر را در rack ديگري قرار ميدهد.
اين کار ميزان ترافيک ناشي از نوشتن داده را در سطح شبکه، کاهش داده و بر اين منطق استوار است که احتمال بروز خطا در کل محيط rack در مقايسه با هر تکگره، بسيار ناچيز است. اين روش به صورت تئوري عملکرد نوشتن داده در سيستمفايلي HDFS را بهبود ميدهد بدون آنکه قابل اطمينان بودن آن را بامشکل روبهرو نماید. سرور مرجع NameNode در سيستمفايلي HDFS همانند نگارشهاي اوليه GFS، به صورت بالقوه به عنوان عامل شکست کل سيستمي به شمار ميآيد که قرار بود يک سيستم به شدت دردسترس و توزيعشده باشد. چراکه اگر فراداده ذخيره شده در NameNode از دست برود، کل سيستمفايلي HDFS مطلقا غيرقابل دسترس و استفاده خواهد بود. درست مانند ديسک سختي که جدول اختصاص دهي فضا به فايلهاي۴۶ آن خراب شده باشد.
سیستم فایلی HDFS داراي قابليت معرفي گره پشتيبان است. اين قابليت، يک کپي همزمان شده از فراداده NameNode را در حافظه نگهداري ميکند و کپيهايي از وضعيتهاي قبلي سيستم را نيز تهيه ميکند تا بتوان در صورت لزوم فرآيند بازگشت به عقب۴۷ را نيز از طريق آن انجام داد. [۹] این امکان وجود دارد که ، ميتوان کپيهایي از وضعيت قبلي را روي سيستمهايي جداگانه نگهداري کرد که در اين فرآيند check point node ناميده ميشوند. مطابق مستندات HDFS، اين سيستمفايلي فعلاً از فرآيند بازيابي خودکار داده سرور مرجع NameNode پشتيباني نميکند و گره پشتيبان نميتواند به صورت خودکار ، جايگزين گره اصلي شده و خدمات گره مرجع را ارائه دهد.
هر دو سيستمفايلي HDFS و GFS با توجه به نيازهاي برنامههايي نظير موتورهاي جستوجو طراحي شدهاند. اما در سرويسهاي محيط ابري که براي فرآيندهاي محاسباتي عموميتر طراحي شدهاند یا در سیستمهای هوشمندی کسبوکار که دارای داده حجیم هستند قابل استفاده میباشند. اساسا معماری نوین انبار داده بر روی همین ویژگی ها ارائه شده است. [۱۵] البته ناديده گرفتن بعضي نکات نظير رويکرد نوشتن فقط يک بار و تغييرات محدود در آن که براي تضمين عملکرد بهينه در پرسوجو از داده کاربرد دارد، نميتواند رويکرد مناسبي باشد. به همين دلیل شرکت آمازون سيستمفايلي توزيعشده مختص به خود را توسعه و معرفي نمود که با نام داينامو۴۸ شناخته ميشود.
نگاشت-کاهش (Map Reduce) در هادوپ
در قسمتهای قبلی مقاله مطرح شد که نگاشت-کاهش یک چارچوب نرمافزاری است که در سال ۲۰۰۴ توسط گوگل عرضه شد تا محاسبات توزیعشده روی مجموعه عظیمی از دادههای ذخیره شده روی خوشههای رایانهای را پشتیبانی نماید. [۲] برخی از بخشهای این چارچوب در برخی کشورها به صورت حق اختراع انحصاری۴۹ ثبت شدهاند. این چارچوب از توابع map و reduce که به صورت معمول در برنامهنویسی رویهای مورد استفاده قرار میگیرند، الهام گرفته است؛ اما عملکرد آنها در این چارچوب هیچ شباهتی به فرم اولیه ندارد. کتابخانههای Map Reduce به زبانهای مختلفی از جمله C++ ، C# ، Java، Perl، Phyton، PHP، F# ، R و سایر زبانها نوشته شده است. نگاشت-کاهش یک مدل برنامهنویسی برای پردازش مجموعه دادههای حجیم و بزرگ است. در چارچوب نگاشت-کاهش ، محاسبات در قالب یک تابع نگاشت و یک تابع کاهش نوشته شده و سیستم به صورت خودکار محاسبات را در بین خوشههای بزرگی از ماشینها به صورت موازی انجام میدهد و خرابیهای ماشینها را مدیریت و ارتباطات بینماشینی را زمانبندی میکند تا استفاده از شبکه و دیسکها سادهتر و سودمندتر گردد. بدین ترتیب برنامه نویس تنها بر روی نوشتن این دو تابع تمرکز کرده و موازی سازی محاسبات انبوه و بکار بردن سیستم و مدیریت خرابی ها برایش ساده میشود. [۹] در هنگام انجام پردازش با MapReduce ، به صورت خودکار، داده های ورودی به چندین بلوک شکسته می شوند که هر بلوک توسط یک تابع map() پردازش می شود و سپس نتایج تمامی توابع map، به عنوان ورودی به تابع reduce() ارجاع داده شده و توسط این تابع ترکیب می شوند. نگاشت-کاهش قلب تپنده هادوپ است. روش برنامهنویسی است که امکان مقیاسپذیری گسترده در سطح صدها یا هزاران سرور در یک خوشه هادوپ را می دهد. MapReduce در حقیقت به دو وظیفه جداگانه و مجزا که در برنامه های هادوپ انجام می شود، اشاره میکند. اولین کار، نگاشت است که یک مجموعه داده را می گیرد و آن را به مجموعه دیگری از داده تبدیل می کند، که در آن عناصر فردی به زوجهای مرتب دوتایی<کلید،مقدار>50 شکسته میشوند. مرحله کاهش خروجی را از یک نگاشت می گیرد و زوج مرتب دوتایی<کلید،مقدار> را به یک مجموعه کوچکتر ترکیب میکند. همانطور که ترتیب نام MapReduce اشاره دارد، مرحله کاهش همیشه بعد از مرحله نگاشت انجام می شود.
مزایای استفاده از نگاشت-کاهش عبارتند از : [۶] • مقیاسپذیری بالا
• پخش بار محاسباتی به صورت متعادل بر روی گرهها
• بهینهسازی انتقال اطلاعات بین منابع دیسک و شبکه
• اجرای موازی بدون تداخل
• مقاومت در برابر خطای بالا
اکنون به نحوه چگونگی انجام کار ۵۱ در نگاشت-کاهش میپردازیم. در MapReduce یک سرویس مرکزی به نام Job Tracker وجود دارد. این سرویس یک زمانبند ۵۲برای خوشه است و اشتراکاتی با زمانبندهای کارآمد متداول دارد. یک کار به این سرویس سپرده شده و Job Tracker از اجرای آن اطمینان حاصل میکند. برای اجرای یک کار ، Job Tracker کار را به وظیفههایی۵۳ تقسیم و اجرای وظیفهها را به Task Trackerها میسپرد.
یک خوشه معمولی را در نظر بگیرید.معمولاً در یک خوشه تعدادی رایانه خاص وجود دارند که به دقت از آنها مراقبت میشود و سایر رایانهها ، رایانه مخدوم۵۴ هستند. رایانههای مخدوم ، هم گرهِ داده که به آنها امکان نوشتن و استفاده از دیسک را میدهد و هم سرویس Task Tracker که به سیستم اجازهی زمانبندی محاسبات روی آن کامپیوتر میدهد را اجرا میکنند. نکته قبل توجه این است که Job Tracker میتواند محل دادهها را پیدا نموده و کار مربوط به آن را برای اجرا روی کامپیوتر محلی همان دادهها زمانبندی کند. به عنوان نمونه در نظر بگیرید که تعداد زیادی فایلهای بزرگ لاگ۵۵ وجود دارد. و بلاکهای این فایلها در سراسر سیستم پخش شدهاند. در نظر بگیرید که میخواهیم یک مجموعه محاسبات سادهی مربوط به رکوردهای ثبت شده در این فایلها انجام شود.میخواهیم برای انجام این کار از MapReduce استفاده کنیم. MapReduceمیتواند به صورتی برنامهریزی شود که رایانهای که این محاسبات را انجام میدهد رایانهای باشد که اطلاعات مورد نظر را به صورت محلی در اختیار دارد. این مسئله باعث میشود که پهنای باند بیشتری از شبکه برای انجام سایر کارها باقی بماند. [۴] اکنون این سوال پیش میآید که Job Tracker از چه منطقی برای زمانبندی استفاده میکند؟ پاسخ این است که در حقیقت بیش از یک نوع زمانبند وجود دارد که تا حدی قابل اتصال۵۶ به کُد هستند. برخی کارها میان تمامی زمانبندها مشترک هستند. اول اینکه آنها سعی میکنند میان توان عملیاتی کل سیستم و تأخیر۵۷ یک موازنه برقرار کنند. اتقافی که میافتد این است که گاهی اوقات کارهای کوچکی وجود دارند که تنها به مقدار کمی داده نیاز دارند. ترجیح این است که این کارها طی چند دقیقهی آینده انجام شوند نه اینکه یک هفته معطل شوند. بنابراین معطل نمودن چنین کارهای کوچک ، پشت کارهای بزرگ درون یک صف ، منطقی به نظر نمیرسد. از طرفی میدانیم که هر کار از تعدادی وظیفه تشکیل شده است. ممکن است رایانهای وجود داشته باشد که اطلاعات مورد نیاز یک وظیفه را به صورت محلی در اختیار داشته باشد. زمانبند تلاش میکند این مسئله را به صورت بهینه حل نماید. اجازه دهید مسئله سوم با مثالی مطرح شود.
فرض کنید که دو گروه در یک سازمان وجود دارند که هر کدام از آنها یک خوشه ۳۰ گرهای از Hadoop نیاز دارند و مدیر فناوری اطلاعات پیشنهاد خرید یک خوشه ۶۰ گرهای و به اشتراک گذاشتن آن میان دو گروه را میدهد. در نتیجه هر دو گروه زمانی که دیگری در حال استفاده از خوشه نباشند ، از امکانات بیشتری بهره خواهند برد و تنها یک مدیر۵۸ برای این خوشه لازم خواهد بود. پرسشی که ممکن است مطرح شود این است که اگر یک گروه در حال استفاده از خوشه باشد آیا کارهای گروه دیگر انجام نخواهد شد؟ به این مسئله زمانبندی عادلانه میگویند. یک زمانبند عادل تلاش میکند در شرایطی که خوشه بیکار است، بتوان از تمامی آن استفاده کرد و اگر رقابت برای دسترسی به منابع وجود دارد بتوان از یک پیکربندی۵۹ برای تقسیم منابع استفاده نمود. [۵] اکنون به نحوه ارتباط JobTracker و TaskTracker میپردازیم. JobTracker به صورت مداوم با استفاده از سیگنالهای سرویس Hearbeat که با نام پیامهای کنترلی۶۰ شناخته میشوند ، TaskTracker را نظارت و کنترل میکند. سیگنالهای Heartbeat از TaskTracker به JobTracker فرستاده شده و پس از دریافت این سیگنالها ، JobTracker پاسخی به همراه برخی دستورات (نظیر شروع ، پایان ، اجرای مجدد ) به TasKTracker ارسال میکند. اگر JobTracker در یک بازه زمانی مشخص ، پاسخی از TaskTracker دریافت ننماید ، درمییابد که وظیفه سپرده شده به TaskTracker با شکست مواجه شده است. هنگام وقوع چنین حالتی ، JobTracker نیاز دارد که برنامهریزی مجددی برای تمامی TaskTrackerها داشته باشد. [۸] اکنون بحث شکست۶۱ و رسیدگی به شکست مطرح میشود.
این سناریو را در نظر بگیرید که یک کار در حال اجرا باشد و یک نگاشتدهنده۶۲ هم وجود داشته باشد و به هر دلیل فرآیندی شکست بخورد. اولین اتفافی که میافتد این است که JobTracker از طریق اطلاع رسانی TaskTracker یا به این دلیل که مدتی است که از TaskTracker پاسخی دریافت نشده است متوجه شکست این فرآیند میشود و آن را دوباره اجرا میکند. فرآیند مجدداً روی همان رایانه اجرا میشود و ممکن است دوباره شکست بخورد. JobTracker تشخیص میدهد که ممکن است مشکل از رایانه باشد یا ممکن است همسایههای آن رایانه خراب باشند یا پیکربندی رایانه نادرست باشد یا خرابی دیگری وجود داشته باشد. در نتیجه کار را به رایانه دیگری میسپارد. در نهایت اگر مواجهه با خطا ادامه پیدا کند شکست عملیات گزارش میشود. بنا به خواست مدیر سیستم ممکن است گاهی اوقات در صورتی که درصدی از وظایف با موفقیت انجام شوند، شکست گزارش نشود. در صورتی که یکی از رایانهها خود به خود خراب شود JobTracker متوجه میشود که TaskTracker گزارش پیشرفت را نداده و آن را جای دیگری اجرا میکند. یک نکته مهم در این فرآیند این است که یک قرارداد صریح میان برنامهنویس و چارچوب موجود وجود دارد و آن این است که چارچوب میتواند تابع نگاشت را روی یک عنصر داده به تعداد دلخواه تکرار کند. بنابراین باید این اطمینان وجود داشته باشد که عملیات تکرارپذیر است. [۵]
معماری و اجزاء سیستم هادوپ
سیستم هادوپ با توجه شماره نگارش دارای اجزاء مختلفی است. با هسته اصلی هادوپ یعنی دو جزء بسیار مهم یعنی HDFS و MapReduce در بخشهای قبلی آشنا شدید. سایر زیرسیستمهای هادوپ شامل HBase ، Hive و Pig میباشند.[۹] Hbase : پایگاهداده هادوپ برای دسترسی خواندن و نوشتن تصادفی میباشد. HBase پایگاه داده توزیعشده، غیر رابطهای و کُدباز است که از روی BigTable گوگل مدلسازی و به زبان جاوا پیادهسازی شده است. این پایگاهداده به عنوان جزئی از پروژه هادوپ در بنیاد نرمافزار آپاچی توسعه داده شده است و روی HDFS اجرا میشود و قابلیتهایی همانند BigTable را دارا میباشد. به بیان دیگر با استفاده از HBase امکان ذخیرهسازی حجم عظیمی از دادههای پراکنده به روشی که تحمل خطا نیز وجود دارد فراهم میشود. پایگاه داده HBase قابلیتهای فشردهسازی، اجرای عملیات داخل حافظه۶۳ و فیلترهای ستون محور را فراهم میکند. جدولهای HBase میتوانند به عنوان ورودی و خروجی عملیات MapReduce که بر روی هادوپ در حال اجرا هستند به کار برده شوند. در تصویر ۱۰ معماری HBase را مشاهده می نمائید.
مدل داده در HBase به صورت زیر است :
• Hbase پایگاه دادهای مبتنی بر ستون است. به بیان دیگر جدولها از یکسری ردیف تشکیل شده است.
* Schema جدول فقط خانواده ستونها را تعیین میکند.
* هر خانواده از تعدادی ستون تشکیل شده است.
* هر ستون از تعدادی version تشکیل شده است.
* ستونها تنها در هنگام وارد کردن بوجود میآیند و بنابراین مقدار Null وجود ندارد.
* همهچیز بجز اسم جدولها ، byte[] هستند.
* هر مقدار در این پایگاه داده به صورت (Row, Family: Column,Timestamo) Value بیان میشود.
در پایگاه داده HBase چهار عمل اصلی Insert(Create) ، Read ، Update و Delete روی جداول بزرگ قابل انجام است، علاوه بر این برخی اعمال اتمیک۶۴ ، قفلگذاری مربوط به پایگاهداده و ایندکسگذاریها در آن لحاظ شده است. HBase از دو بخش Master و Slave تشکیل شده است که این بخشها HMaster و Region Server نامیده می شوند (تصویر ۱۰). در پایگاهدادهHBase از سیستمفایلیHDFS به عنوان مسئول ذخیره سازی داده استفاده میشود. این مسئله باعث می شود که پایگاهداده HBase از تمامی خصوصیات و ویژگیهای سیستمفایلی HDFS استفاده نماید (مانند Replication).مدیریت دادهها در پایگاه داده HBase در گرههای فرعی که توسط گره اصلی مدیریت می شود انجام میگیرد.
پایگاهداده HBase در موتورهای جستجو ، تحلیل دادههای حاصل از log و مدیریت جدولهای بسیار حجیم بدون استفاده از join کاربرد دارد. [۷] Hive : واسطکاربری برای هادوپ است که در Facebook توسعه داده میشود. این افزونه با ارائه HiveSQL، امکان نوشتن پرسوجو مبتنی بر SQL را بر بالای MapReduce ممکن میسازد. این افزونه با Hive tables خاص خود یا با Hbase سازگار است. کاری که Hive انجام میدهد ارائهی نوعی پوسته۶۵ نزدیک به SQL است. بنابراین این افزونه امکان نوشتن دستورالعملهایی را فراهم مینماید که شباهت زیادی به SQL دارند و Hive نگاشت میان Schema و فایلها را نگهداری میکند(۶۶HiveQL). اطلاعات فایلهای درون سیستمفایلی HDFS و اطلاعاتی در مورد محتوای آنها به Hive داده شده و Hive آنها را در ستونهایی مرتب میکند. سپس پرسوجوهایی نوشته میشود که به عنوان کارهای MapReduce اجرا میشوند. Hive دارای بهینهساز۶۷ است و قادر به اجرای کارهایی است که ممکن است شامل چندین کار MapReduce باشد.
هسته اصلی توزیع باینری Hive شامل سه قسمت میباشد. قسمت اصلی هسته Hive شامل فایلهای کد جاوا نظیر hive_exec*.jar و hive_metastore*.jar میباشد. این فایلها در مسیر $HIVE_HOME/lib قرار دارند. این مسیر حاوی اسکریپتهای اجرایی فراخوانی سرویسهای Hive و رابط خط فرمان۶۸ Hive است. Hive از سرویس Thrift برای دسترسی از راه دور از طریق دیگر processها و بهرهبرداری از JBDC و ODBC استفاده مینماید. Hive از سرویس metastor برای ذخیره شمای۶۹ جدول و فراداده بهرهبرداری میکند. Hive به عنوان یک زیرساخت برای انبارهای داده مبتنی بر هادوپ برای خلاصهسازی ، پرسوجو و انجام تحلیل دادهها استفاده میشود. یاهو از Hive در سرویس Amazon Elastic Map Reduce بهرهبرداری مینماید.Hive قابلیت تحلیل مجموعه دادههای حجیمی که بر روی سیستمهای فایلی سازگار با هادپ ذخیره شدهاند را دارا می باشد (نظیر S3 آمازون). [۴][۹] Pig : پیگ بستری سطح بالا برای ایجاد برنامههای MapReduce بر روی هادوپ است که در سال ۲۰۰۶ میلادی توسط یاهو گسترش داده شده است. زبان مورد استفاده در این بستر پیگلاتین۷۰ نامیده میشود. پیگلاتین برنامهنویس را از کدنویسی MapReduce براساس کَدهای جاوا بینیاز نموده و این قابلیتها را به صورت سیستم نگارشی سطح بالایی عرضه میکند که بسیار شبیه SQL در پایگاهداده رابطهای است. پیگلاتین را میتوان به کمک توابع تعریف شده توسط کاربر۷۱ گسترش داد به صورتی که کاربر میتواند این توابع را در جاوا پیادهسازی و بعدها مستقیماً از طریق پیگلاتین فراخوانی کند. پیگ کمک می تماید که برنامهنویسان امکان استفاده از روشی ساده برای ایجاد و اجرای عملیات MapReduce بر روی مجموعههای بسیار عظیم و حجیم داده در اختیار داشته باشند. پیگ امکان فراهم نمودن سناریوی ETL72 را نیز فراهم مینماید. از سال ۲۰۰۷ میلادی پروژه پیگ به بنیاد نرمافزاری آپاچی منتقل شده است. [۵][۹] Chukwa : چُکوا زیرسیستمی مبتنی بر عامل۷۳ جهت جمعآوری logهای سیستم است. به بیان دیگر این زیرسیستم جهت سرویس نظارت۷۴ استفاده میشود. بدین صورت که هدف چُکوا فراهم نمودن سرویس ETL برای خوشههای دادههای log است. در این حالت برای کاربر نهایی ، مسیری ساده برای دسترسی به رویدادهای مهم log فراهم میشود.
این زیر سیستم از فایلسیستم HDFS برای جمعآوری طیف وسیعی از اطلاعات و از MapReduce برای آنالیز اطلاعات جمعآوری شده استفاده مینماید. یکی از ا بزارهای مهم چُکوا ، HICC75 است که یک رابط مبتنی بر وب جهت نمایش کارآیی سیستم میباشد. قابلیت اطمینان در این زیرسیستم با استفاده از دو مدل end-to-end reliability و fast-path delivery جهت کاهش تاخیرات زمانی ، فراهم میشود. چُکوا در تعامل با فایل سیستم HDFS از پایگاه داده MySQL استفاده مینماید. مکانیزم چرخشی مورد استفاده چُکوا بدین صورت است که هر از پنج دقیقه فایلها گردآوری شده و در پایان هر ساعت ، فایلهای گردآوری شده تجمیع و در قالب دادهای ساعتی ذخیره میشوند. در پایان هر روز فایلهای ساعتی تجمیع شده و در قالب دادهای روزانه ذخیره میشوند. برای عملیات شرح داده شده از پروتکلی مشابه syslog استفاده میشود. [۶][۱۸]
نتیجهگیری
فناوریهای کسب و کار با سرعت بسیار زیادی به سمت هوشمند شدن در حال حرکت هستند. به بیان دیگر دوران شبکه سازی و شخصی سازی مدتها قبل به پایان رسیده و هوشمندی کسبوکار به عنوان یک مزیت در حال پیشرفت است. ما در عصری زندگی میکنیم که دارای دو ویژگی مهم سرعت تحولات و تغییر است. این دو ویژگی باعث هدایت بازارهای کسبوکار به سمت هوشمندی میشوند. وجود رویکردها و ابزار نوین در هوشمندی کسبوکار نظیر مدیریت دادههای حجیم ، هادُپ و زیرسیستمهای آن باعث میشود که آیندهای متفاوت در انتظار صنعت هوشمندی کسبوکار باشد.[۱۱] بازار نرمافزارها و راهکارهای مرتبط با هوشمندی کسبوکار با رشد مواجه هستند. مطابق گزارش فوربس بازار هوشمندی کسبوکار با رشد ۸% مواجه بوده است.[۱۰] هوشمندی کسبوکاردر سال ۲۰۱۲ میلادی هزینهای برابر با ۱۳٫۳ میلیارد دلار داشته در سال ۲۰۱۳ به ۱۴٫۴ میلیارد دلار افزایش یافته است. شرکت SAP به عنوان پیشرو در هوشمندی کسبوکارسهم ۳٫۱ میلیارد دلاری بازار را با افزایش ۵٫۳% به خود اختصاص داده است. در نمودار ۲ سهم بازار شرکتهای پیشرو در هوشمندی کسبوکاررا مشاهده مینمائید.بخش زیادی از این رشد موجود ، ناشی از افزایش گرایش عمومی به سیستمهای گزارشگیری و ابزارهای پرسوجو مربوط میشود و مابقی حاصل رونق سیستمهای دادهکاوی و تجزیه و تحلیل پیشرفته آمار است.
در همین فاصله آن دسته از نرمافزارها که مبتنی بر بانکهای اطلاعاتی متداول مانند SQL Server یا اوراکل بودهاند، تقریبا دو برابر میانگین رشد کل بازار رشد داشتهاند. بنابراین میتوان نتیجه گرفت که یکی از دلایل مهم این رشد شدید ، گرایش صنعت نرمافزار و برنامهنویسان بانکهای اطلاعاتی به سمت استفاده از راهکار هوشمندی کسبوکار بوده است.
امروزه شاهد هستیم که هوشمندی کسبوکاردر شاخههای هوشمندی کسبوکارسنتی ، هوشمندی کسبوکارمبتنی بر ابری ، هوشمندی کسبوکارمبتنی بر تلفن همراه و هوشمندی کسبوکاراجتماعی در حال گسترش است. مطابق گزارش موسسه گارتنر رشد شاخههای هوشمندی کسبوکار تا سال ۲۰۱۸ میلادی تا ۲۰ میلیارد دلار خواهد بود. [۱۰] بازار هوشمندی کسبوکاربه شدت درحال گسترش است و قابلیتهای راهکار هوشمندی کسبوکاربه گونهای است که به کار هر نوع کسبوکاری میآید. مثلا از این راهکار میتوان برای بررسی چرایی و چگونگی صفحات پربیننده یک سایت وب، استخراج گزارشهای مالی از فراز و نشیب شرکت یا سازمان، میزان استقبال مردم از یک برنامه ملی، نظرسنجی و افکارسنجی پیرامون یک موضوع خاص، تغییرات رشد جمعیت و گرایشهای آتی آن، برنامهریزی برای آینده صنعت کشاورزی با توجه به تغییرات آب و هوا، تغییرات میزان فروش یک محصول در بازار رایانه و پیشبینی وضعیت احتمالی بازار در آینده استفاده کرد.
دلیل این استقبال را میتوان در این مسئله جستجو کرد که استفاده از راهکارهای پیچیده و سیستمهای نرمافزاری گرانقیمت و اختصاصی این بازار، برای همه ممکن نیست و شرکتها و کسبوکارهای کوچک و متوسط ترجیح میدهند به جای سروکله زدن با این پیچیدگیها و هزینهها، به شرکتهای نرمافزاری محلی یا برنامهنویسان منفرد مراجعه کنند تا برایشان یک سیستم تجزیه و تحلیل سادهتر و کمهزینهتر بنویسند که متناسب با ساختار کسبوکارشان باشد. بدیهی است که اگر آنان سرمایهگذاری در این زمینه را قابل برگشت تشخیص دهند، پس از مدتی به استفاده از نرمافزارهای استاندارد بازار روی خواهند آورد.
منابع
[۱] Ghemawat ,Sanjay , Gobioff, Howard , Leung , Shun-Tak , (2003) , «The Google File System» , ۱۹th ACM Symposium on Operating Systems Principles, ACM, Bolton Landing, NY, pp. 20-43
[۲] Dean, Jeffrey , Ghemawat, Sanjay , (2008) , «MapReduce: Simplied Data Processing on Large Clusters» , Communications of the ACM – 50th anniversary issue: 1958 – ۲۰۰۸ , Volume 51 Issue 1 , pp. 107-113
[۳] Lopez, Karen , D›Antoni, Joseph , (2014) , «The Modern Data warehouse : How Big Data Impacts Analytics Architecture» , Business Intelligence Journal , volume 19 , number 3
[۴] Prajapati, Vignesh , (2013) ,»Big Data Analytics with R and Hadoop» , PACKET Publishing ,ISBN 978-1-78216-328-2
[۵] Turkington, Garry , (۲۰۱۳) ,»Hadoop Beginner›s Guide» , PACKET Publishing , ISBN 978-1-84951-7-300
[۶] White, Tom , (۲۰۱۲) ,»Hadoop: The Definitive Guide» , O›Reilly Publication , ISBN: 978-1-449-31152-0
[۷] Dimiduk, Nick , Khurana, Amandeep , (2013) , «HBase in Action» , Manning Publications Co. , ISBN:9781617290527
[۸] Cogorno, Matias , Rey, Javier, Nesmachnow, Sergio , (2013) , «Fault tolerance in Hadoop MapReduce implementation» , UdelaR PERMARE Team , HAL Id: hal-00863176
[۹] Karanth, Sandeep , (۲۰۱۴) , «Mastering Hadoop» , PACKET Publishing , ISBN 978-1-78398-364-3
[۱۰] Columbos , Louis , (۲۰۱۴) , « Roundup Of Analytics, Big Data & Business Intelligence Forecasts And Market Estimates» , www.forbes.com
[۱۱] Swoyer, Stephan , (2015) , «۲۰۱۴ in Review : The changing face of BI» ; The Data Warehousing Institute , volume 12
[۱۲] Mungal , Audrey , (2012) , « BI 2015: View of the Future of Intelligence in Firms» , Redwood ,
Redwood Analytics User Conference
[۱۳] Lang , Leah , Pirani, Judit A. , (2014) , «BI Reporting , Datawarehouse systems and beyond» , EDUCAUSE , Research Bulletin
[۱۴] Tribuzio, Jose , (2014) , «Leveraging BI for Improved Claims Performance and Results « , Systema Software
[۱۶] Carter , Keith B. , (2014) , «Actionable Intelligence» , John Wiley & Sons Publication , ISBN 978-1-118-92060-2
[۱۷] Murthy ,Arun C. , (2014) , «Apache Hadoop YARN : moving beyond MapReduce and batch processing with Apache Hadoop 2» , Addition-Wesly Piblication , ISBN 978-0-321-93450-5
[۱۸] Rabkin,Ariel , Katz ,Randy , (2010) , « Chukwa: A system for reliable large-scale log collection» , EECS Department , University of California, Berkeley , Technical Report No. UCB/EECS-2010-25
پاورقی
۱- Radio-frequency identification
۲- Doug Laney
۳- Volume
۴-Velocity
۵-Variety
۶-Change
۷-Complexity
۸-Not Only SQL
۹-IBM
۱۰-Microsoft
۱۱-SAP
۱۲-Business Intelligence
۱۳-Data Warehouse
۱۴-Data Mart
۱۵-Analytics Mart
۱۶-Google File System : GFS
۱۷-Sanjay Ghemawat
۱۸-Howard Gobioff
۱۹-Shun-Tak Leung
۲۰-Peta Byte = 1015 Byte
۲۱-Cloud Processing
۲۲-Yahoo
۲۳-Amazon
۲۴-Wal-Mart
۲۵-Storage Area Network (SAN)
۲۶-Relational Database
۲۷-Distribute File System Management
۲۸-Object Based
۲۹-RedHat
۳۰-Meta Data
۳۱-Elastic Compute Cloud
۳۲-Microsoft
۳۳-Hard Disks
۳۴-Cluster
۳۵-Hadoop
۳۶-Douglass Cutting
۳۷-Index
۳۸-Nutch Ditributed File Susyem (NDFS)
۳۹-Jeffrey Dean
۴۰-Tupples
۴۱-Apache
۴۲-Hadoop Disrtributed File System (HDFS)
۴۳-Tag
۴۴-log
۴۵-Node
۴۶-File Allocation Table (FAT)
۴۷-RollBack
۴۸-Daynamo
۴۹-Patent
۵۰-
۵۱-Job
۵۲-Scheduler
۵۳-Task
۵۴-Slave
۵۵-log
۵۶-Pluggable
۵۷-Latency
۵۸-Administrator
۵۹-Configuration
۶۰-Control Messages
۶۱-Fail
۶۲-Mapper
۶۳-In-Memory
۶۴-Atomic
۶۵-Shell
۶۶-Hive Query Language
۶۷-Optimizer
۶۸-Command-Line Interface (CLI)
۶۹-schema
۷۰-Pig Latin
۷۱-User Defined Functions (UDF)
۷۲-Extract , Transform , Load (ETL)
۷۳-Agent
۷۴-Monitoring Service
۷۵-Hadoop Infrastructure Care Center (HICC)
————————–
مطلبهای دیگر از همین نویسنده در سایت آیندهنگری:
|
بنیاد آیندهنگری ایران |
پنجشنبه ۳۰ فروردين ۱۴۰۳ - ۱۸ آوریل ۲۰۲۴
دانش نو
|
|