کلان داده
آموزش‌های پیشرفته هوش مصنوعیداده کاوی و بیگ دیتا

منظور از کلان داده چیست؟

0
مروری بر تاریخچه کلان داده

برای رسیدن به موقعیت کنونی چه مسیری را طی کرده‌ایم؟ در این مسیر به چه قابلیت‌هایی دست پیدا کرده‌ایم؟ و چه پیشرفت‌هایی در انتظار ما است؟ برای پاسخ به این سؤالات باید تاریخچه داده‌ را مطالعه کنیم.

گلن بک Glen Beck و بتی اسنایدر Betty Snyder – طرح انیاک ENIAC، آزمایشگاه پژوهش‌های بالستیک واقع در ساختمان ۳۲۸  ( تصاویر ارتش ایالات متحده، کالیفرنیا. ۱۹۵۵ – ۱۹۴۷). تصاویر ارتش ایالات متحده. این تصویر در تملک عمومی قرار دارد.

آغاز راه ( دهه ۴۰ میلادی)

سال‌ها پیش در ماه دسامبر سال ۱۹۴۵، اولین کامپیوتر الکترونیکی- دیجیتالی همه منظوره Electronic general-purpose digital computer ساخته شد. این کامپیوتر انیاک ( محاسبه‌گر و یکپارچه‌ساز عددی الکترونیک ) نامیده می‌شد. تا پیش از فرا رسیدن این دوره برای انجام هر کاری  به صورت سفارشی یک کامپیوتر مجزا ساخته می‌شد.

اگر بخواهیم انیاک را با تازه‌ترین پیشرفت‌هایی که در حوزه فن‌آوری حاصل شده مقایسه کنیم باید بگوییم که بیشینه کلاک Max clock انیاک تک هسته‌ای حدود ۵ کیلوهرتز بوده، در حالی‌که سرعت ساعت جدیدترین تراشه ۶ هسته‌ای تعبیه شده در آیفون (Apple A13) برابر با ۲.۶۶ گیگاهرتز است. به عبارت دیگر سیکل واحد پردازنده در هر ثانیه بیش از چهار میلیون برابر افزایش یافته و علاوه بر آن تعداد دستورالعمل‌هایی که واحد پردازنده می‌تواند در هر یک از این سیکل‌ها انجام دهد افزایش یافته است.

در طول تاریخ پیشرفت‌های بی‌شماری در حوزه سخت‌افزار حاصل شده و انسان‌ها با اتکاء به این پیشرفت‌ها توانسته‌اند به قابلیت‌های جدیدی در زمینه مهندسی نرم‌افزار دست پیدا کنند. در نتیجه انعطاف‌پذیری نرم‌افزارها افزایش پیدا کرده و در همان حال لازم است مهندسان مسئولیت‌پذیری بیشتری داشته باشند. مسلماً مهندسین آرزو دارند بتوانند نرم‌افزارهایی با همان میزان انعطاف‌پذیری عرضه کنند و در همان حال فشار و زحمت کمتری در این مسیر متحمل شوند.

سیر تکاملی داده‌ها (دهه ۶۰ میلادی دهه ۹۰ میلادی)

در آغاز هزینه استفاده و نگهداری از سرورها زیاد بود و در عین حال فضای حافظه کمکی و حافظه‌ اصلی و هم‌چنین توان محاسباتی آن‌ها محدود بود و به همین دلیل برنامه‌نویس‌ها ،از جمله مدیریت حافظه، برای حل مسائل متحمل زحمت زیادی می‌شدند. در مقابل، امروزه برای انجام این قبیل از کارها ، زبان‌های برنامه‌نویسی‌ با قابلیت زباله‌روبی خودکار در اختیار داریم. به همین دلیل زبان‌های C، C++ و FORTRAN به طور گسترده مورد استفاده قرار می‌گرفتند و کماکان از آن‌ها در حوزه‌های مهم استفاده می‌شود؛ در این‌گونه حوزه‌ها تلاش ما بر این است که حداکثر استفاده را از کارایی و ارزش یک سیستم داشته باشیم. امروزه نیز اکثر چارچوب‌های یادگیری ماشین و تحلیل داده Data analytics
به زبان پایتون برای اطمینان از کیفیت عملکرد، از زبان C استفاده می‌کنند و برنامه‌نویس‌ها فقط از یک API استفاده می‌کنند.

شرکت‌هایی از جمله IBM برای استفاده حداکثری از سیستم‌هایی که داده‌ها را سازمان‌دهی می‌کنند و هم‌چنین به منظور ذخیره‌ کردن، بازیابی و کار کردن با داده‌ها سرمایه‌گذاری‌های کلانی بر روی برخی مدل‌ها انجام داده‌اند. در مقابل مدل سلسله‌ مراتبی از داده‌ها ارائه شده که در طول دوران بزرگ‌رایانه Mainframe بسیار رایج و متدوال بوده است. شرکت‌ها با ایجاد یک مدل استاندارد میزان فعالیت ذهنی لازم برای شروع یک پروژه را کاهش دادند و دانشی را که می‌توان در پروژه‌های مختلف به کار بست، افزایش دادند.

کلان داده

در گذشته از بزرگ‌رایانه‌ها برای حل مشکلات روز استفاده می‌شد اما این گونه‌ رایانه‌‍‌ها بسیار گران‌قیمت بودند، در نتیجه فقط مؤسسات بزرگ از جمله بانک‌ها توان مالی خرید چنین سیستم‌هایی را داشتند و می‌توانستند به نحوی کارآمد از مزایای آن‌ها بهره‌مند شوند. بزرگ‌رایانه‌ها در پیمایش ساختارهای درختی traversing tree-like structures بسیار کارآمد بودند، اما روابط یک به چند آن‌ها به حدی دقیق و پیچیده است که درک و استفاده از آن‌ها برای برنامه‌نویسان دشوار است.

مدتی بعد مدل‌های رابطه‌ای Relational model ساخته شدند که امروزه نیروی اکثر دیتابیس‌های ما را تأمین می‌کنند. در مدل‌های رابطه‌ای داده‌ها به صورت دسته‌های چندتایی (جدول‌ها) با روابط میان آن‌ها نشان داده می‌شوند. یک رابطه‌ معمولی کلیدی خارجی است که مشخص می‌کند داده‌های درون دو جدول باید با یکدیگر ارتباط داشته باشند. به بیانی ساده‌تر شما نمی‌توانید نمره‌‌هایی از یک آزمون درسی داشته باشید اما دانش‌آموزانی که در این آزمون شرکت کرده‌اند را نداشته باشید و نمی‌توانید کلاسی از دانش‌آموزان داشته باشید اما معلمی نباشد که به آن‌ها درس بدهد.

کلان داده

دیاگرام رابطه‌ای نشان می‌دهد جدول‌ها چگونه می‌توانند از طریق idها با یکدیگر ارتباط داشته باشند.

با توجه به ساختار داده‌ها می‌توانیم یک زبان استاندارد تعریف کنیم و از این طریق با داده‌هایی که ساختار مشابهی دارند کار کنیم.  سازنده اصلی مدل‌های رابطه‌ای، زبان پرسمان ساختاریافته (SQL) Structured Query Language (SQL) را هم ایجاد کرده که زبانی برای مدیرت داده‌ها است. دلیل آن هم این است که خواندن SQL بسیار آسان است و در همان حال بسیار توانمند است. چنانچه سیستم قابلیت اجرای تابع بازگشتی Recursion و تابع پنجره‌ را داشته باشد، SQL تورینگ کامل Turing complete خواهد بود. تورینگ کامل به این معناست که اگر زبان زمان کافی داشته باشد می‌تواند تمامی مشکلات محاسباتی را حل کند. توانایی حل تمامی مشکلات محاسباتی در زمان کافی یکی از ویژگی‌ها و قابلیت‌های ممتاز SQL است، اما به این معنی نیست که برای انجام هر کاری می‌توان از آن استفاده کرد. به همین دلیل از SQL برای بازیابی و دسترسی به داده‌ها و از پایتون و زبان‌های دیگر برای تحلیل پیشرفته داده‌ها استفاده می‌کنیم.

شرکت Oracle در سال ۱۹۷۹  اولین دیتابیس رابطه‌ای Relational database را عرضه کرد.  این سیستم‌ها سیستم‌های مدیریت دیتابیس رابطه‌ای (RDBMS) نامیده می‌شوند. از آن زمان به بعد RDBMSهای متن‌باز و تجاری زیادی عرضه شده است. تمامی این عوامل دست به دست یکدیگر دادند تا Apache Software Foundation به یکی از شرکت اصلی ارائه‌دهنده ابزارهای حوزه «کلان داده» تبدیل شود. با در اختیار داشتن پروانه‌های آسان‌گیر این شرکت می‌توان در زمان استفاده از کد منبع اصلی کتابخانه فعالیت‌های تجاری را انجام داد.

این‌گونه سیستم‌ها عملکرد بسیار خوبی در مدیریت و دسترسی به داده‌هایی با ساختارهای داده‌ای نرمال‌سازی‌شده Normalized data structures دارند. با وجود این، همزمان با افزایش حجم داده‌ها، عملکرد آن‌ها تحت تأثیر حجم کاری زیاد، کاهش پیدا می‌کند. تکنیک‌های بهینه‌سازی بسیاری از جمله شاخص‌‌گذاری و read-replicas و غیره داریم که می‌توانیم با استفاده از آن‌ها فشار و حجم کاری سیستم‌ها را کاهش دهیم.

جهان متصل و انواع گوناگون داده‌ها (دهه ۹۰ میلادی)

پیش از راه‌یابی کامپیوترها به خانه‌ها و پیش از این‌که هر فردی یک تلفن همراه شخصی داشته باشد، ارتباطات مردم با یکدیگر محدود و داده‌های مربوط به این ارتباطات به میزان قابل توجهی کم بود. تقریباً تمامی وب‌سایت‌هایی که به آن‌ها مراجعه می‌کنید پیگیری جریان اطلاعات را فعال کرده‌اند تا درک بهتری از تجارب کاربران به دست بیاورند و از این طریق نتایج شخصی‌سازی‌شده بیشتری به کاربران ارائه دهند.

پس از ان‌که جمع‌آوری داده‌ها به صورت خودکار درآمد و کاربران مجبور بودند نظرات و بازخوردهای خود را در قالب پیمایش، تماس‌های تلفنی و غیره ارائه دهند، روند جمع‌آوری داده سیر صعودی در پیش گرفت. امروزه فعالیت‌های ما معرف ما هستند و اعمال و فعالیت‌های ما بیشتر از افکار و سخنان ما در معرفی ما نقش دارند. از مدت‌ها پیش نتفلیکس دیگر به شما اجازه نمی‌دهند به فیلم‌ها امتیاز دهید و یا آن‌ها را رتبه‌بندی کنید، چرا که متوجه شده‌اند این  اطلاعات به درک بهتر از این اکوسیستم کمکی نمی‌کند.

شاخص جست‌و‌جوی گوگل و نیاز به MapReduce (اوایل دهه اول قرن بیست و یک)

گوگل جز اولین‌ شرکت‌هایی است که از فن‌آوری‌های پیشرفته برای جمع‌آوری داده‌ها در حجم بالا استفاده کرد؛ هرچند امروزه شرگت گوگل به عنوان یکی از سودآورترین شرکت‌‌های دنیا شناخته می‌شود اما در اواخر دهه ۹۰ میلادی بودجه کلانی کنونی را در اختیار نداشت. مزیت رقابتی شرکت گوگل در حجم داده‌ای است که در اختیار دارد و علاوه بر این می‌تواند به بهترین نحو از این داده‌ها استفاده می‌کند.

در زمان آغاز به کار شرکت گوگل تیم مهندسی آن با مشکل پیچیده‌ای رو به رو شد و میباست آن را رفع کند، اما آن‌ها توان مالی خرید سخت‌افزار شرکتی را نداشتند؛ این سخت‌افزار بسیار گران بود و شرکت‌های قدیمی‌تر برای انجام امور خود به آن متکی بودند. هرچند در آن ‌زمان توان محاسباتی این شرکت بیشتر از شرکت‌های دیگر نبود اما با آن‌ها برابری می‌کرد. تقاضا برای خدمات شرکت گوگل و به طور کلی

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

در آن زمان جِف دین و سانجی قماوات مهندسان ارشد شرکت گوگل بودند. آن‌ها با جدیت تمام در حال بازنویسی کُدبیس Frankenstein system گوگل بودند تا مقاومت آن را در مقابل خرابی‌ها افزایش دهند. یکی از اصلی‌ترین مشکلاتی که با آن مواجه بودند این بود که این سخت‌افزار در حین اجرای برنامه‌ها متوقف می‌شد و می‌بایست آن را مجدداً راه‌اندازی کرد. این دو فرد در هنگام رفع مشکل کدبیس، متوجه یک الگوی ثابت شدند که می‌توانند چارچوب را بر مبنای آن بسازند. این الگو MapReduce نامیده می‌شد.

MapReduce یک مدل برنامه‌نویسی است و شامل دو مرحله است، مرحله نگاشت Map phase  و مرحله کاهش Reduce phase. منظور از نگاشت شکستن یک تسک بزرگ به تسک های کوچک تر است و منظور از کاهش جمع بندی تمام نتایج برای تولید نتیجه کار اولیه است. این چارچوب دارای یک رابط ساده است که با استفاده از آن می‌توان یک کار را در میان ورکِرهای مختلف یک خوشه به اجزای کوچک‌تر تقسیم کرد. اگر بتوانیم کاری را به قسمت‌های کوچک‌تر تقسیم کنیم، در صورت بروز هر گونه خطا می‌توانیم کار را بدون نیاز به اجرای مجدد آن،  بازیابی کنیم. علاوه بر این، تقسیم یک کار به قسمت‌های کوچک‌تر به این معناست که سیستم‌ مقیاس‌پذیرتر و قوی‌تر است. راه‌های زیادی برای ارتقای عملکرد سیستم MapReduce وجود دارد و همزمان با توضیح لایه‌های انتزاعی Abstraction layers آن‌ها را نیز بررسی می‌کنیم.

کلان داده

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

جف دین و سانجی قماوات کماکان در این شرکت فعالیت دارند و در بسیاری از پیشرفت‌هایی که در حوزه فن‌آوری حاصل شده و چشم‌انداز داده را شکل داده مشارکت داشته‌اند.

MapReduce به عنوان یک پیاده‌سازی متن باز- مقدمه‌ای بر Hadoop (اواسط دهه اول قرن بیست و یک)

شرکت گوگل ابزارهاِ گوناگون را برای استفاده در سیستم‌های داخلی و درون‌سازمانی خود طراحی و تولید می‌کند. اما این شرکت دانش خود را در قالب مقالات علمی در اختیار دیگران قرار می‌دهد. در مقاله MapReduce: پردازش آسان داده در خوشه‌های بزرگ مدل برنامه‌نویسی MapReduce به طور خلاصه توضیح داده شده است و در قسمت ضمیمه نمونه‌ای از پیاده‌سازی الگوریتم شمارش کلمات Word count algorithm قرار داده شده است. تعداد کدهایی که برای نوشتن یک کار MapReduce لازم است بیشتر از تعداد کدهای پایتون برای انجام همان کار است. کدهای پایتون فقط بر روی یک ریسه واحد اجرا می‌شود و توان عملیاتی Throughput آن محدود است، در مقابل MapReduce با هر تعداد سروری که برای انجام یک کار نیاز داریم، مقیاس‌بندی می‌شود.

تفاوت سیستم‌های اولیه با سیستم‌های امروزی در پیچیده‌ بودن و قابلیت مقیاس‌پذیری آن‌ها است و سیستم‌های اولیه‌ای که MapReduce را توانا می‎ساختند بسیار پیچیده بودند.

اواسط دهه اول قرن بیست و یک داک کاتینگ و مایک کافارلا مقاله گوگل حول موضوع MapReduce را مطالعه کردند و علاوه بر این مقاله دیگری حول موضوع سیستم فایل توزیع‌شده گوگل موسوم به سیستم فایل گوگل مطالعه کردند. در آن زمان این دو فرد بر روی یک خزنده وب توزیع شده موسوم به Nutch کار می‌کردند و متوجه شدند آن‌ها هم برای مقیاس‌­پذیر کردن سیستم‌ خود همین مشکل را دارند.  داگ به دنبال یک شغل تمام وقت بود و در نهایت به استخدام یاهو در آمد و از آن‌ جایی که در آن زمان یاهو از شرکت گوگل عقب مانده بود، ایده ساخت سیستم‌ متن باز برای توانا ساختن شاخص‌گذاری مقیاس بزرگ Large-scale indexing را از داگ خرید. شرکت یاهو کاتینگ را استخدام کرد و از او خواست به کار کردن بر روی پروژه Nutch که باعث بسط دادن سیستم فایل توزیع‌شده و چارچوب محاسباتی می‌شد ادامه دهد و این در حالی بود که سیستم فایل توزیع‌شده و هم‌چنین چارچوب محاسباتی از اجزای اصلی هدوپ Hadoop بودند. سیستم فایل توزیع‌شده و چارچوب محاسباتی سیستم فایل توزیع‌شده هدوپ و Hadoop MapReduce نامیده می‌شدند. هم‌زمان با این‌که  سیستم فایل توزیع‌شده و چارچوب محاسباتی در هدوپ خلاصه شدند، هدوپ وارد چرخه هایپ (محبوبیت) شد و به همین دلیل این نامگذاری کمی عجیب به نظر می‌رسد.

MapReduce برای مصون ماندن در مقابل خطاهایی که در کل پشته سخت‌افزار روی می‌دهد، از سیستم فایل توزیع‌شده استفاده می‌کند. جِف دین این مطلب را در ظهور سیستم‌های رایانش ابری توضیح داده و در بخشی از این مقاله عنوان می‌کند که « قابلیت اطمینان باید از جانب نرم‌افزارها تأمین شود» و در ادامه خطا‌هایی که در سال ۲۰۰۶ در یک خوشه معمولی گوگل  روی داده را شرح می‌دهد:

  • کابل‌کشی مجدد شبکه Network rewiring ( حدود ۵ درصد از ماشین‌ها به مدت دو روز خاموش می‌شوند)
  • خطای رَک Rack failure (۴۰ تا ۸۰ ماشین درون یک رک ناپدید شدند، بازگرداندن آن‌ها ۱ تا ۶ ساعت طول کشید)
  • رَک‌ها ضعیف شدند ( ۴۰ تا ۸۰ ماشین درون یک رک با ۵۰ درصد مشکل ارتباطی مواجه شدند)
  • نگهداری شبکه ( ممکن است به طور تصادفی باعث قعطی ۳۰ دقیقه‌ای در ارتباطات شود)
  • بارگذاری مجدد مسیر ( سرویس DNS و vipهای مجازی برای دقایقی از دسترس خارج شدند)
  • خطاهای مسیریاب ( ترافیک داده‌‌ها برای یک ساعت قطع می‌شود )
  • ده‌هاخطای کوچک سی ثانیه‌ای بر روی سرویس DNS، تقریباً ۱۰۰۰ ماشین خاموش شدند
  • خطا در دیسک حافظه موجب کندی، مشکل در حافظه، اشتباه در تنظیمات ماشین‌ها، ماشین‌های بی‌ثبات و غیره می‌شود

روش‌های زیادی برای ارتقای عملکرد پشته وجود دارد، برای مثال می‌توان داده‌ها را در حجم کم جا به جا کرد و از این طریق تأخیر در شبکه را به حداقل رساند. به منظور دست‌یابی به این هدف به جای این‌که حافظه کمکی را NFS و یا SAN نگهداری کنیم، با استفاده از دیسک‌های بزرگ محاسبه را در حافظه انجام می‌دهیم. در زمان انجام محاسبات در حافظه نمی‌خواهیم یک گره خاص در یک خوشه محاسبات بسیار زیادی انجام دهد چرا که حاوی داده است. علاوه بر این باید یک کپی از داده‌ها تهیه کنیم، در این صورت اگر گره‌ای از کار افتاد با مشکل مواجه نخواهیم شد و می‌توانیم کار را تقسیم کنیم. اگر به نمونه خطا‌هایی که گوگل توضیح داده نگاهی بیندازیم، متوجه می‌شویم که باید آمادگی لازم برای مقابله  با خطاهای گره‌ها و خطای رک را داشته باشیم . به عبارت دیگر باید با انواع خطاهای رک در حافظه آشنایی داشته باشیم و چندین کپی از داده‌ها داشته باشیم.

کلان داده

«مجموعه¬ای از تاخیرها که هر برنامه نویسی باید بداند» – پی. استارک

اولین مدل MapReduce به نام Hadoop MapReduce به دانش زیادی در زمینه فرایند MapReduce و مبانی بهینه‌سازی عملکرد در چارچوب نیاز داشت. یکی از اصلی‌ترین مشکلات MapReduce این بود که نمی‌توانستیم فرایندهای پیچیده‌ای بر روی آن تعریف کنیم. در آن زمان سیستمی  برای ایجاد منطق‌های پیچیده وجود نداشت. در عوض، Hadoop MapReduce بلوک‌های سطح پایین‌تر را برای انجام محاسبات مقیاس‌پذیر ارائه می‌داد  اما نمی‌توانست به نحوی کارآمد آن‌ها را هماهنگ کند. یکی دیگر از نقاط ضعف Hadoop MapReduce استفاده از دیسک بود و چیزی بر روی حافظه ذخیره نمی‌شد. در زمان عرضه MapReduce حافظه بسیار گران بود و اگر حافظه‌ پر می‌شد، در انجام کارها اختلال به وجود می‌آمد . همه مواردی که به آن‌ها اشاره کردیم نشان می‌دهند که Hadoop Reduce کند و نوشتن برای آن دشوار بوده، اما در همان حال ثابت و مقیاس‌پذیر بود.

به منظور حل این مشکلات چندین راهکار از جمله Pig (رونویسی، Hive ( زبان پرسمان ساختاریافته)، MRJob (پیکربندی) ارائه شد. تمامی این راهکارها موجب شدند MapReduce، الگوریتم‌های تکراری Iterative algorithms، بویلرپلیت Boilerplate کمتر، انتزاع‌ ( مخفی کردن نحوه پیاده‌سازی) بهتر کد را توانا سازد. وجود این‌گونه ابزارها به افرادی که تخصص کمتری در حوزه مهندسی نرم‌افزار دارند و تجربه کمتری در حوزه جاوا دارند کمک کرد از مزایای «کلان داده» بهره‌مند شوند.

کاهش مسئولیت‌پذیری و افزایش انعطاف‌پذیری با استفاده از انتزاع‌ها (اوایل دهه دوم قرن بیست و یکم)

همزمان با ظهور و افزایش میزان استفاده از فن‌آوری ابری با وب‌ سرویس‌های آمازون (AWS) در اوایل دهه دوم قرن بیست و یکم، این سؤال برای مردم پیش آمد که چگونه می‌توانند حجم کاری هدوپ را بر روی AWS اجرا کنند. AWS تمامی شرایط و ویژگی‌های لازم برای اجرای حجم‌های کاری تحلیلی را داشت، حجم‌های کاری تحلیلی برای مدت زمان کوتاهی اجرا می‌شدند و سرورها در مدت زمان باقی‌مانده در یک مرکز داده منتظر باقی می‌ماندند.

با وجود این در آن زمان Hadoop MapReduce تا حد زیادی به سیستم فایل HDFS متکی بود. در آن زمان استفاده از راهکارهای ذخیره‌سازی مقیاس‌پذیر غیر ممکن بود؛ این راهکارها که محصول فن‌آروی ابری بودند و می‌توانستند خوشه‌ها را از رده خارج کنند. چگونه می‌توانستیم این حجم‌کاری را به ابر منتقل کنیم و همزمان با مقیاس‌پذیر کردن حجم کاری خود هزینه‌ها را کاهش دهیم و از مزایای فضاهای ابری بهره‌مند شویم؟ اگر محدودیت‌ عدم استفاده از حافظه را برطرف می‌کردیم و شرایطی فراهم می‌کردیم تا داده‌ها را با مقدار تأخیر کمتری در حافظه نگهداری کنیم چه اتفاقی می‌افتاد؟ چگونه می‌توانیم فرایندهای تکرار‌پذیر همچون فرایندهای یادگیری ماشین را انجام دهیم؟

Spark  ابتدا در سال ۲۰۱۴ با هدف تحقق همین اهداف عرضه شد. مقاله اصلی در سال ۲۰۱۰ منتشر شد. نویسندگان این مقاله متوجه شدند اگر فقط کمی از حافظه استفاده شود عملکرد تا ۱۰ برابر افزایش پیدا می‌کند و علاوه بر این پیچیدگی‌های برنامه‌نویسی تا حد زیادی کاهش پیدا می‌کند.

Spark 1.x عملکرد بسیار خوبی در مقیاس‌بندی و کار کردن با داده‌ها نداشت. مدل برنامه‌نویسی Spark 1.x  کماکان پیچیده است و برای نوشتن کد به دانش زیادی لازم است. Spark انعطاف‌پذیری زیادی داشت و مجموعه‌ای از مسئولیت‌ها که وجود آن‌ها ضروری نبود را حذف کرد. Spark ابزار نسل دوم و فوق‌العاده ای بود و از آن زمان شهرت و محبوبیت آن افزایش چشمگیری داشته است. در ابتدا عملکرد آن نسبت به هدوپ بهتر بود و همزمان با شکل‌گیری نیازهای جدید، Spark نیز تکامل پیدا کرد.

کلان داده

مقایسه Spark و هدوپ توسط Google Trends

ارتقای تجارب (اواسط دهه دوم قرن بیست و یک)

تا سال ۲۰۱۶ ، Spark به اندازه کافی تکامل یافته بود و به همین دلیل مردم به استفاده از این مدل برنامه‌نویسی روی آوردند. از افرادی که در زمینه مهندسی نرم‌افزار تجربه نداشتند خواسته می‌شد از داده‌ها خلق ارزش کنند. به همین دلیل حوزه علم داده بر استخراج ارزش از داده‌ها به روشی علمی متمرکز بود و مسیر  پیشرفت و تکامل را در پیش گرفته بود.

Pandas به عنوان ابزاری معرفی شد که همه می‌توانند با بهره‌گیری از آن با داده‌ها کار کنند و به همین دلیل شهرت زیادی پیدا کرد. Pandas یک API ساده در اختیار کاربران قرار می‌داد. این ابزار را وِس مک‌کینی در Two Sigma ساخت؛ هدف از ساخت این ابزار آسان کردن زندگی برای پژوهش‌گران کمّی بود. این پژوهش‌گران برای تحلیل داده‌ها مجبور بودند یک کد را بارها ایجاد کنند. Two Sigma این کتاب‌خانه را به صورت متن‌باز در آورد و آن را به الگویی برای چگونگی برقراری ارتباط انسان‌ها با داده‌ها تبدیل کرد.

گروهی که بر روی Spark کار می‌کردند متوجه شدند که بسیاری از کاربران آن‌ها کارهای اولیه خود را در Pandas انجام می‌دهند و پس از آن‌که ایده‌های‌شان به اندازه کافی پرورش یافت از Spark  استفاده می‌کنند. استفاده جداگانه از این دو ابزار موجب شد بار کاری انسجام نداشته باشد و برای آن‌که کد مناسب مدل MapReduce در Spark  شود باید آن را دوباره می‌نوشتند. Spark به دلیل این‌که کاربران از Pandas استفاده می‌کردند DataFrame API را اضافه کرد که از Pandas API تقلید می‌کرد؛ به عبارت دیگر، کاربران Spark می‌توانستند از همان بارکاری استفاده کنند اما می‌بایست آن را در مقابل موتور MapReduce اسپارک اجرا کنند ، در این حالت امکان مقیاس‌بندی حتی در طول مرحله تحلیل نیز وجود داشت.

علاوه بر کاربرد برنامه‌ای Spark، تعدادی از کاربران آن‌ها تمایل داشتند از SQL برای دسترسی به داده‌ها استفاده کنند. همان‌گونه که پیش از این گفتیم، از SQL تقریباً به مدت پنجاه سال برای دسترسی به داده‌ها استفاده می‌شود. تیم Spark در آن زمان تصمیم فوق‌العاده‌ای گرفتند، آن‌ها تصمیم گرفتند Spark SQL را توانا سازند اما از همان موتور بهینه‌سازی که برای DataFrame API نوشته بودند، استفاده کند. استفاده از یک موتور بهینه‌سازی واحد موجب می‌شد  کدی که می‌نوشتند رابط SQL و هم‌چنین رابط برنامه‌ای آن‌ها را تحت تأثیر قرار دهد. این موتور بهینه­ساز Catalyst  نامیده می‌شد و همانند بهینه‌ساز برنامه پرسمان Query plan optimizer در یک RDBMS قدیمی کار می‌کرد. Spark 2.0 تمامی این قابلیت‌ها را داشت و به همین دلیل کارایی آن تا حد زیادی افزایش یافت.

کلان داده

بهینه¬سازCataliyst توسط Databricks

کاهش مسئولیت با همان میزان انعطاف‌پذیری (۲۰۲۰)

ماه ژوئن سال ۲۰۲۰ جدیدترین و پیشرفته‌ترین نسخه Spark یعنی Spark 3.0 عرضه شد، این نسخه از Spark قابلیت‌های جدیدی ندارد اما عملکرد، قابلیت اطمینان و قابلیت استفاده آن ارتقا پیدا کرده است.

به منظور ارتقای عملکرد، Spark  اجرای تطبیقی پرسمان Adaptive query execution
 و حذف پویای پارتیشن را اضافه کرده است، هر دوی مواردی که از آن‌ها نام برده شد حتی در حوزه RDBMS نیز پیشرفت‌های نسبتاً جدیدی به حساب می‌آیند. ارتقای عملکرد می‌تواند مزایای بسیاری به همراه داشته باشد. مطابق با معیارهای TPC-DS، حذف پویای پارتیشن از ۶۰ پرسمان از میان ۱۲۰ پرسمان بین ۲ برابر و ۱۸ برابر ارتقا پیدا می‌کند. به عبارت دیگر، اگر شرکت‌ها از Spark استفاده کنند، محاسبات کمتری باید انجام دهند و هزینه‌های آن‌ها در زمینه زیرساخت کاهش پیدا می‌کند و بیشتر بر روی نتایج تمرکز می‌کنند. کاربران به این قابلیت‌های جدید واقف هستند و نیازی به بازنویسی کدها وجود ندارد.

برای افزایش قابلیت اطمینان، تیم Spark تعداد قابل توجهی از باگ‌ها (۳.۴۰۰) را بین شاخه‌های ۲.x و ۳.۰ رفع‌ کردند و این امکان را برای کاربران فراهم کردند تا بهتر بتوانند خطاهای پایتون را کنترل کنند تا استفاده از API پایتون آسان‌تر شود. علاوه بر این، ارتقای عملکرد موجب می‌شود بدون نیاز به تغییر مدل مسئولیت Spark، انعطاف‌پذیری آن افزایش پیدا کند.

برای افزایش قابلیت استفاده، Spark یک UI جدید برای استفاده در موارد کاربرد جدید ارائه داده است که اطلاعات بیشتری راجع به آمارهای mini batch و به طور کلی وضعیت پایپ لاین ارائه می‌دهد. در بسیاری از موارد کاربرد، به سختی متوجه می‌شدیم که چه زمانی سیستم تأخیر دارد و چگونه می‌توانیم به نحوی کارامد به این تغییرات از جمله مقیاس‌بندی گره‌های جدید یا مقیاس‌بندی به منظور کاهش هزینه‌ها واکنش نشان دهیم.

Spark 3.0 بدون کاهش میزان انعطاف‌پذیری، مسئولیت کاربران نهایی را کاهش می‌دهد و کماکان به پیشرفت و ارتقای این حوزه کمک می‌کند. این قابلیت Spark به ما کمک می‌کند چالش‌های بیشتری را حل کنیم و تا حد زیادی عملیات‌های خود را ارتقا دهیم و و بر روی کارهای ارزش‌آفرین تمرکز کنیم.

کلان داده

تاریخچه عرضه ابزارهای مورد استفاده در حوزه «کلان داده». همان‌گونه که در تصویر فوق نشان داده‌ شده، تا چندی پیش هر دو سال یک بار در زمینه انتزاع (مخفی‌کردن نحوه پیاده‌سازی) پیشرفت‌هایی حاصل می‌شد. همزمان با تکامل MapReduce و دسترسی کاربران به پشته فن‌آوری، ترندهای اخیر افزایش میزان استفاده از فن‌آوری ابری را نشان می‌دهند.

چالش‌های امروز – آینده پیش رو

در این مقاله به بحث و گفت‌و‌گو راجع به هدوپ و Spark پرداختیم و سیر تکامل و پیشرفت این حوزه را در طول زمان بررسی کردیم. بیش از ۱۰۰ ابزار در حوزه «کلان داده» وجود دارد که هر کدام موارد کاربرد خاصی دارند و برای حل مشکلات و مسائل خاصی طراحی شده‌اند. اگر به رابط‌هایی مشابه SQL داده‌ها در چارچوب‌های توزیع‌شده نگاهی بیندازید، به Hive، Presto و Impala می‌رسید که هر کدام مسئول حل چالش‌های متفاوتی در این حوزه بوده‌اند. چنانچه به پیاپی‌سازی داده Data serialization از جمله CSV قدیمی و ناکارآمد علاقه‌مند هستید تا ذخیره‌سازی و مدت زمان محاسبه را کاهش دهید به Avro، Parquet، ORC و Arrow می‌رسید.

از زمان آغاز چرخه هایپ «کلان داده» در سال ۲۰۱۰، پیشرفت‌های زیادی در این حوزه حاصل شده است. در حال حاضر شرکت‌هایی از جمله آمازون، مایکروسافت و گوگل خدمات ابری ارائه می‌دهند و قابلیت‌هایی را ممکن می‌سازند که پیش از این داشتن آن‌ها در حد رویا بود. فن‌آوری ابری بر مقیاس‌پذیری بارکاری متمرکز است. در عوض شما مبلغی مازاد بر ارزش واقعی مرکز داده پرداخت می‌کنید و نیاز به حفظ و نگهداری جنبه‌های فنی، عملیاتی، نظارتی و  غیره زیرساخت مرکز داده را کاهش می‌دهید. اگر موارد کاربرد تحلیلی را بررسی کنیم متوجه می‌شویم که در همه آن‌ها از سخت‌افزار استفاده می‌شود و به همین دلیل می‌توانیم از فن‌آوری ابری در آن‌ها استفاده کنیم.

ارائه‌دهندگان خدمات ابری برای بار کاری «کلان داده» فرایند مقیاس‌بندی عمودی و افقی و کاهش مقیاس را بر روی راهکارهای خود انجام می‌دهند. برای نمونه می‌توان به EMR (آمازون)، Azure Databricks (مایکروسافت) و Dataproc (گوگل) اشاره کرد که هر کدام از این ارائه‌دهندگان از بار کاری موقتی بر ر روی فضای ابری پیشتیبانی می‌کنند. این ارائه‌دهندگان راهکارهایی از جمله ذخیره‌سازی اشیا S3، Azure Lake Storage و Google Cloud Storage برای ذخیره‌سازی ارائه دادند و انجام محاسبات را به فضای دیگری- به غیر از حافظه- منتقل کردند. اگر می‌خواهید تحلیلی انجام دهید، آن را در خوشه‌ای مجزا انجام می‌دهید بدون این‌که بر روی کارهای در حال اجرای دیگران تأثیر بگذارید. تنظیم دقیق خوشه چالش بسیار بزرگی بود چرا که بارهای کاری‌ مختلف چالش‌های عملکردی متفاوتی دارند. با رفع این چالش، متخصصین می‌توانند به جای تمرکز بر روی زیرساخت، توجه خود را به تحقق اهداف معطوف کنند.

افزون بر این، ما می‌خواهیم فشار بر روی کدها را هم کم کنیم. در دنیای امروزی موارد کاربرد لحظه‌ای و بی‌شماری داریم. پیش از این مجبور بودیم دو کد بیس جداگانه داشته باشیم تا بتوانیم عملکردی درخور هر یک از موارد کاربرد داشته باشیم. پس از مدتی متوجه شدیم که دسته فقط یک مورد خاص اجرا است، پس بهتر نیست روش استفاده از آن را به کار ببندیم؟ Flink، Spark و Beam به روش‌های متفاوتی در تلاش هستند تا این مشکل را حل کنند، چه به صورت first-class citizen (Beam)  یا با تغییر APIهای خود تا آن را برای کاربران نهایی آسان کنند (Flink\Spark).

در مرکز تمامی این پیشرفت ها نیاز به توانا سازی تحلیل‌های پیچیده دیتاست‌های حجم بالا احساس می‌شود. ما باید موارد کاربرد یادگیری ماشین و هوش مصنوعی را برای داده‌ها آسان کنیم. برای انجام این کار، فقط پردازش داده‌ها کافی نیست، باید بتوانیم این فرایند را بدون دخالت کاربر نهایی انجام دهیم. استفاده همگانی از ابزارهای هوش مصنوعی و یادگیری ماشین طی بیست سال گذشته با استفاده از scikit-learn، Keras ، Tensorflow، Pytorch، MXNet و تعداد زیادی دیگری از کتابخانه‌ها صورت گرفته است تا امکان مدل‌سازی آماری و هم‌چنین موارد کاربرد یادگیری عمیق را فراهم سازد. هدف از استفاده از این ابزارها در حوزه کلان داده درس گرفتن از این ابزارها و استفاده مستقیم از آن‌ها است.

منظور از کلان داده چیست؟

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

تعداد از شرکت ها مقیاس یک ماشین واحد را به صورت عمودی در می‌آورند و حافظه آن را افزایش می‌دهند. تعدادی از شرکت‌ها بار کاری SAP را بر روی ماشین‌های مجازی با حافظه ۲۴ ترابایتی اجرا می‌کنند؛ برخی دیگر فقط می‌توانند فرایند مقیاس‌بندی عمودی را تا ۱.۵ ترابایت انجام دهند. هرچند، این کار فقط امکان دسترسی سریع تر به داده‌ها را برای ما فراهم می‌کند. زمانی که بخواهیم محاسبات جزیی را بر روی داده‌های موارد کاربردی از جمله یادگیری ماشین و هوش مصنوعی انجام دهیم چه اتفاقی می‌افتد؟ در این حالت فقط می‌توانیم تعداد زیادی هسته بر روی یک ماشین نگهداری کنیم؛ برای مثال، موارد کاربرد ماشین مجازی با حافظه ۲۴ ترابایتی SAP، ۳۸۴ هسته دارد. اکثر خوشه‌های کلان داده بیش از ۱۰۰۰ واحد پردازش گرافیکی دارند و استفاده از آن‌ها بسیار به صرفه‌تر از خرید یک ماشین مجازی بزرگ است که برای این‌گونه موارد کاربرد SAP ساخته شده است.

اگر بیش از ۱۰۰ گیگابایت داده دارید، با یک سیستم از گره سر و کار دارید. احتمالا زمان زیادی و یا تلاش زیادی صرف بهینه‌سازی کدها، شاخص‌ها یا سایر قبلیت‌ها می‌کنید تا کارها را بر روی یک گره واحد اجرا کنید. بهتر از کار خود را با راهکارهای خوشه‌ای از جمله Spark یا Dask شروع کنید اما برای آن‌که به نحوی کارآمد بتوانید از آن‌ها استفاده کنید باید در زمینه زیرساخت سرمایه‌گذاری کنید. ارائه‌دهندگان خدمات ابری از جمله آمازون، مایکروسافت و گوگل همگی تلاش کردند قابلیت‌هایی برای مقیاس‌بندی این راهکارهای خوشه‌ای ارائه دهند و در همان حال میزان تلاش لازم برای مدیریت زیرساخت را برای مشتریان نهایی کاهش دهند.

همزمان با پیشرفت قابلیت‌های فن‌آوری، تفاوت های میان حجم کاری تک گره‌ای و حجم کاری خوشه‌ای از بین می‌رود. این قابلیت‌ها این امکان را برای ما فراهم می‌کنند تا در آینده کارایی بیشتری داشته باشیم و البته نباید فراموش کنیم کارایی که امروزه داریم در مقایسه با انیاک در سال ۱۹۴۵  بیشتر است.

استفاده از هوش مصنوعی در استارتاپ‌ها چه مزایایی دارد؟

مقاله قبلی

دوره‌های آنلاین رایگان هوش مصنوعی در دانشگاه هلسینکی

مقاله بعدی

شما همچنین ممکن است دوست داشته باشید

نظرات

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *