امروزه با افزایش حسگرها، گسترش اینترنت ودستگاه‌هایی که داده‌ها را تولید و جمع‌آوری می‌کنند (مانند تلفن‌های همراه، رایانه‌ها، خودروهای هوشمند و ...) و استفاده از این داده‌ها برای الگوریتم های پردازش هوش مصنوعی و یادگیری ماشین، ضرورت داشتن یک معماری نرم‌افزار مناسب برای تولید داده‌ها، ذخیره‌سازی آن‌ها، انتقال، پیش پردازش و پردازش و تجزیه وتحلیل این حجم از داده به نحوی که در آینده باعث بروز مشکلات نشود بیش از پیش شده است.
معماریهای نرم‌افزار مختلفی از ابتدای زمان توسعه‌ی نرمافزارها وجود داشته و در حالی که نمی‌توان هیچ‌کدام را منقضی شده دانست اما همواره روش‌های جدید برای غلبه بر مشکلات جدید به وجود آمده تا کیفیت بالا را تضمین کنند. با توضیح مفهوم کلان داده و معماری‌نرم‌افزار و توضیح مفهوم کیفیت در این حوزه به سراغ ابزارها، روش‌ها و مراحل توسعه‌ی نرمافزارهای پردازش کلان‌داده خواهیم رفت و در انتها دو معماری معروف در این ضمینه را بررسی خواهیم نمود.
کلمات کلیدی: کلان‌داده، حجیم، پردازش، معماری نرم‌افزار
داده همیشه و همواره در حال تولید بوده است، اما ثبت داده را می‌توان از دوران لوح‌های سنگی و کتیبه‌ها دانست. با پیشرفت علم، این ثبت به صورت کاغذی، سپس نوارهای مغناطیسی و امروزه به صورت اسناد رایانه‌ای شامل متن‌ها، تصاویر، فیلم، صوت، جداول، بیت‌ها و ... درآمده و امکان تجزیه و تحلیل و پردازش آسان را برای انسان فراهم آورده است.
افزایش تعداد دستگاه‌های تولید داده مانند حسگرها، تلفن‌های همراه، خودروهای هوشمند، دستگاه‌های اینترنت اشیا، و به موازات آن گستردگی اینترنت و شبکه، سرعت تولید و ارسال داده‌ها را افزایش داده، همچنین پیشرفت سخت‌افزاری توان تولید و پردازش دادههای حجیم را فراهم آورده است. دادههایی که با سرعت و تنوع و حجم‌های مختلف تولید میشوند به دلایل مختلفی دسته بندی، تجزیه و تحلیل و و ارسال میشوند تا از قدرت و پتانسیل نهفته در آن‌ها استفاده شود. پردازش این حجم داده نیازمند روش‌هایی متفاوت است تا خللی در کار سخت‌افزار، نرم‌افزار، شبکه و دیگر المان‌ها ایجاد نگردد. در حالیکه توان پردازشی سخت‌افزارها و پهنای باند شبکه افزایش یافته، نرمافزارها نیز باید به گونه‌ای مناسب برای تعامل با این دو، داده‌ها و سایر نرم‌فزار‌ها تکامل یابند. این تکامل ها را به طور کلی در مفهومی به نام معماری نرم‌افزار پردازش دادههای حجیم تعریف میکنیم.اما ابتدا باید مفهوم دو واژه‌ی اصلی این حوزه یعنی معماری نرم‌افزار و کلان‌داده را بررسی کنیم.
۱.۱. معماری نرم‌افزار
معماری نرم‌افزار تعاریف مختلفی دارد که در اینجا به برخی از آن‌ها اشاره میکنیم:
معماری نرم‌افزار به تکنیک‌هایی اطلاق میشود که سعی در برآورده کردن نیازمندی‌های نرم‌افزار با بهترین کیفیت ممکن دارند[ ۱]. یا در تعریف دیگر معماری نرم‌افزار تصمیم‌هاییست که بهتر است در ابتدای توسعه‌ی نرم‌افزار گرفته شده یا معماری نرم‌افزار نحوه‌ی ارتباط و تعامل بین اجزای مختلف نرم‌افزار است [۲].
۱.۲. کلان داده
کلان‌داده، به مجموعه دادههای بسیار بزرگ و پیچیده اطلاق میشود [ ۳ ]که قابل ذخیره سازی، انتقال، پردازش و تحلیل با روش‌های سنتی و معمولی نبوده و به طور خاص دارای سه ویژگی حجم بالا، سرعت تولید زیاد و تنوع بالایی هستند[۴]. البته امروز تقریبا دو ویژگی دیگر ارزشمندی و صحت‌مندی نیز به عنوان ویژگی‌های کلان‌داده پذیرفته شده‌اند [۵].
این پنج ویژگی که به دلیل یکسان بودن حروف ابتدایی کلمات آن‌ها در زبان انگلیسی به 5V معورف هستند به شرح زیراند:
حجم (Volume):این مهم‌ترین ویژگی کلان‌داده که در خود این کلمه نیز وجود دارد به حجم بسیار بالای داده‌ها اشاره دارد.
تنوع (Variety): با توجه با گسترش ابزارهای تولید داده، انواع مختلفی از آن‌ها نیز توسط دوربین‌ها، حسگرها، ربات‌ها و ... تولید میشوند.
سرعت (Velocity): با توجه به گسترش سخت‌فزارها و اینترنت و راه‌های ارتباطی، این داده‌ها می‌توانند در لحظه‌ی به تعداد بالا تولید شده و انتقال یابند.
ارزش (Value): دادههایی ارزشمند هستند که بتوان از پردازش آن‌ها در مرحله‌ی اول اطلاعات و سپس دانش و خرد مناسبی به دست آورد.
صحت (Veracity): این ویژگی به کیفیت داده‌ها اشاره دارد، بدیهی است که تولید، ذخیره سازی و پردازش حجم بالای داده هزینه‌های گزافی خواهد داشت که در صورت غلط و غیرقابل اعتماد بودن داده‌ها، این هزینه‌ها اتلاف شده‌اند.
۱.۳. معماری نرم‌افزار کلان داده
معماری سرویس داده حجیم را می‌توان مدلی مقرون به صرفه دانست که داده را از منابع مختلف جمع‌آوری و استخراج کرده و متدهای مختلف و سفارشی پردازش ، تحلیل و بصری سازی داده را برای مصرف کنندگان فراهم می‌آورد[۶].
معماری سرویس کلان داده متشکل از سه لایه اصلی است، لایه‌ی جمع آوری و ذخیره سازی داده که در آن داده از منابع با تجیهزات مربوطه جمع آوری شده و پیش پردازشی روی داده به صورت توزیع شده (مانند Hadoop) انجام و ذخیره سازی میشود. در لایه‌ی پردازش چهارچوب‌های پردازش مختلفی بر اساس انواع مختلف داده (مانند Apache Spark) به کار گرفته میشوند. لایه‌ی آخر نیز تحلیل و ارائه است که در آن ابزارهای بصری ساز وجود دارند [۷].
این لایه‌ها به صورت سرویس‌های ابری (SaaS, PaaS, IaaS)نیز وجود دارند که در شکل زیر قابل مشاهده است:
۱.۴. اهمیت معماری کلان داده
همانگونه که پیش‌تر ذکر شدکلان داده‌ها با حجم، سرعت و تنوع بالا تولید شده و ارزش و صحت آن‌ها اهمیت بالایی دارد، پس نرم‌افزار هایی که در چرخه‌ی تولید، جمع آوری، ذخیره‌سازی، پردازش، تحلیل و ارائه‌ی آن‌ها قرار دارند نیز باید توانایی تعامل با کلان‌داده‌های با این ویژگی‌ها را داشته باشند، بدیهی است که کلان‌داده‌ای که به طور کامل، با سرعت و دقت انتقال نیابد، ذخیره سازی نشده و پردازش و تحلیل نگردد برای کسب و کار مخاطره ایجاد خواهد نمود. در پایین به برخی از ویژگی‌های مهم یک معماری نرم‌افزار کلان داده می‌پردازیم[۸]:
۱.۴.۱. دسترسی پذیری
احتمالا برای شما نیز پیش آمده است که وارد یک سایت ورزشی، خبری یا ... شده ولی با خطای http 503یا در دسترس نبودن مواجه شده‌اید. احتمالا چنین وضعیتی را در زمان انتخاب واحد دانشگاه نیز مشاهده کرده باشید، اما این خطا به چه معناست و چرا در صورت رفرش کردن صفحه ممکن است دیگر آن را ندیده و به راحتی به ادامه‌ی کار خود بپردازید؟
برنامه‌های تلفن‌همراه، وبسایت‌ها و ... روی رایانه‌های قدرتمندی که ممکن است در سراسر جهان در مراکز داده پخش شده باشند اجرا میشوند و از طریق شبکه مانند اینترنت با تلفن‌همراه و یا رایانه‌ی شخصی شما درخواست رد و بدل می‌کنند. به عبارتی اگر شما در زمان انتخاب واحد، درسی را انتخاب کنید، این درخواست شما از طریق اینترنت به یکی از آن رایانه‌های قدرتمند که اصطلاحا سرور نام دارد رسیده، سرور موارد لازم مانند مجاز بودن شما برای انتخاب این درس، ظرفیت کلاس و عدم تداخل با دیگر کلاس‌های شما را بررسی نموده و پاسخ (موفقیت یا عدم موفقیت در انتخاب آن درس) را دوباره از طریق اینترنت به رایانه و مرورگر شما اعلام میکند. در زمانی مانند انتخاب واحد، بعد از مسابقه فینال جام جهانی یا حمله نظامی به یک کشور، افراد زیاد به سایت دانشگاه، سایت ورزشی و سایت خبرگزاری هجوم می‌آورند تا انتخاب واحد کرده، نتیجه مسابقه فینال و گل‌ها را دیده و یا از صحت آن خبر نظامی-سیاسی مطمئن شوند. این وبسایت‌ها با توجه به میانگین تعداد کاربران و درخواست‌های ساعتی و روزانه‌ی خود، و بر اساس میزان قدرتی که سرورهایشان دارند (مانند قدرت پردازشی cpu و ram) برای پاسخ گویی به آن تعداد میانگین و معمول کاربر و درخواست تنظیم شده‌اند و در چنین زمان هایی که تعداد بسیار بیشتری از کاربران و درخواست‌ها به سمت آن‌ّا سرازیر میشوند این رایانه‌ها قدرت لازم برای پاسخ‌گویی به همه را نداشته و بر اساس تمهیدات قبلی، همه یا تعدادی از درخواست‌ها را پاسخ نمی‌دهند، در این زمان است که شما خطای ۵۰۳ را در مرورگر خود میبینید. همانطور که گفته شد برخی از این افزایش درخواست‌ها مانند زمان انتخاب واحد یا پس از یک فینال جام جهانی قابل پیشبینی است و می‌توان از قبل قدرت یا تعداد سرور‌ّا را بیشتر کرد اما در موردی مانند حمله نظامی احتمالا قابل پیشبینی نباشد.همچنین شما احتمالا چنین خطایی را در زمان بازکردن جیمیل خود یا جستجو در گوگل بسیار کم مشاهده کرده‌اید طبیعتا با داشتن میلیاردها کاربر جهانی از سراسر دنیا با فرهنگ، زبان و سلایق متفاوت و درخواست‌های آن‌ها گوگل شاید نتواند به راحتی زمان‌ّای افزایش درخواست و کاربران را پیشبینی کند، پس چگونه است که این غول فناوری اغلب سال در دسترس است؟ وجود سرور‌های بسیار بسیار زیاد و بسیار بسیار قدرتمند؟ قطعا بله، اما روشن و آماده به کار نگه داشتن این همه سرور هزینه‌های گزاف مدیریتی، برق و خنک سازی برای این شرکت به دنبال خواهد داشت. پس گوگل باید سرور‌های مختلف خود را به سرعت و در زمان لازم روشن و خاموش کند اما به گونه‌ای که کاربران دچار عدم دسترسی و خطای ۵۰۳ نشوند، چنین کاری مستلزم داشتن یک معماری نرم‌افزار فوق العاده است خصوصا زمانی که بدانیم گوگل خدمت‌های پردازش و تحلیل کلان دادهای را ارائه می‌دهد که گاها غیر رایگان و پولی بوده و مشتری انتظار دارد همواره این خدمات در دسترس باشند. البته جالب است بدانید که دسترسی پذیری ۱۰۰ درصدی نیز برای هیچ برنامه و وبسایتی ممکن نیست و گوگل بالاترین دسترسی پذیری دنیا را با بیش از 99.999% دسترسی پذیری در سال دارد.
۱.۴.۲.مقیاس پذیری
برای یک سامانه‌ی خاص، اگر فرض بر یکسان بودن انواع و حدود حجم داده داشته باشیم، بازهم سرعت تولید داده ممکن است در زمان‌های مختلف کاهش یا افزایش داشته باشد، برای مثال در دیجی کالا در زمان تخفیف‌هایی کانند حراج جمعه‌ی سیاده و یا حراج‌های یلدایی و آخرسال تعداد جستجو‌ها، مقایسه‌ها، ثبت سفارش‌ها و ... افزایش چشمگیری دارند. یا برای برنامه‌ای مانند تاکسی اینترنتی اسنپ طبیعتا تعداد درخواست‌ّها از ساعت ۶ صبح تا ۱۲ شب بسیار بیشتر از بازه‌ی ۱۲ شب تا ۶ صبح است. پس برای این سازمان‌ها و هرسازمان دیگری که چنین حالتی داشته باشد به صرفه نیست که تمام طول روز و سال تمامی سرور‌های قدرتمند خود را روشن و آماده به کار نگه دارد زیرا هزینه‌ی برق و سرمایش اتاق سرور‌ها حداقل هزینه‌ی تحمیلی به آن‌ها خواهد بود. یا برای شرکت‌های کوچکی که از سرور‌های ابری استفاده می کنند نیز بهتر است تا همیشه مطابق نیاز لحظه‌آی خود منابع داشته باشند تا هزینه کمتری بپردازند. در یک سامانه دارای معماری نرم‌افزار کلان داده‌ی مناسب، در صورتی که مثلا منابع به میزان ۱۰ درصد افزایش یابند، سامانه نیز باید قابلیت خدمت رسانی به حدود ۸ درصد درخواست بیشتر را داشته باشد و به همین نسبت مثلا اگر منابع ۲۰ درصد افزایش پیدا کنند، باید بتوان به حدود ۱۶ درصد درخواست بیشتر جواب داد. چنین سیستمی مقیاس پذیری مناسبی دارد. از دلایل اهمیت مقیاس پذیری در معماری نرم‌افزار کلان داده توزیع شده بودن منابع و مجازی سازی است که سامانه باید آن را به صورت مناسبی مدیریت کند.
۱.۴.۳.کارایی
زمانی که با کلان داده که دو ویژگی مهم حجم و سرعت تولید بالا دارد سروکار پاشته باشیم، سرعت انتقال (جستجتو، خواندن، نوشتن) و سرعت پردازش کاهش چشمگیری خواهند داشت و این مطلوب ما نیست. با افزایش منابع می‌توان سرعت را افزایش داد اما هنگامی که منابع توزیع شده باشند، معماری نرم‌افزاری که به صورت مناسب بتواند زمان‌پاسخ دهی ما را در حد مطلوب نگه دارد.
۱.۴.۴.سایر معیارها
مانند هر نرم‌افزار دیگری، معیارهای زیادی مانند قابلیت استفاده، امینت، تغییر پذیری، قابلیت نگه‌داری، تست پذیری، قابلیت تغییر، قابلیت انتقال و ... برای معماری نرمافزارهای پردازش کلان داده نیز وجود دارند، اما با توجه به تفاوت اساسی این نرمافزارها با نرم‌افزار پردازش کلان داده (تفاوت در حجم و سرعت داده‌ها)، موارد مقیاس پذیری و دسترسی پذیری و کارایی اهمیت بیشتری دارند.
۲.۱. لایه‌ی جمع‌آوری و ذخیره سازی
برای فرآیند ETL (Extract, Transfer, Load) که شامل جمع‌آوری، انتقال و بارگزاری در لایه‌ی اول است، دادههای حجیم با فرمت‌های حختلف از منابع گوناگون به صورت دسته‌ای و یا به صورت جریانی برخط و آنی رسیده و در صورت دسته‌ای بودن، داده در قالب‌های استاتیک ذخیره شده و در صورت برخط بودن ابتدا یک پردازش جزیی برای پاک سازی دادههای خراب و یا کثیف شده و سپس داده در یک انبار داده (Data warehouse)ذخیره میشود ابزارهایی مانند Kettle, Datastage, Informatica برای ETL استفاده میشوند .
فرآیند دیگر ELT(Extract, Load, Transfer) است که در آن که ابتدا تمام داده ها با تمام فرمت ها و ساختار ها در یک مکان به نام Data Lake بارگذاری می شوند. سپس هر موقع نیاز به پردازش و تخلیل داشتیم، باید داده های مورد نظر را از این دریاچه داده برداشته و پردازش و تحلیل را روی آن انجام می دهیم.پس تفاوت انبار داده و دریاچه داده در مرتب و تمیز بودن دادههای ذخیره شده در آنهاست[۹] .
ابزار Apache Hadoop ابزاری متن باز از این شرکت است که ببا استفاده از شبکه‌ای از رایانه‌های توزیع شده، برای کار با کلان‌داده‌ها توسعه داده شده است و از HDFS برای بخش ذخیره‌سازی به صورت گره‌های توزیع شده استفاده می کند. این ابزار نسبت به خرابی دیسک مقاوم بوده و با پشتیبانی از فرمت های مختلف ذخیره سازی، امکان پردازش سریع را فرآهم می‌اورد[۱۰-۱۱].
زمانی که جریانی از داده‌ها داریم، آنی بودن، تحمل خطا، پایداری و قابلیت اطمینان اهمیت بالایی دارند، Flume ابزاری است که برای چنین شرایطی توسعه داده شده و معمولا به همراه Hadoop استفاده شده و به عنوان ابزاری بین منبع ارسال و دریافت داده عمل میکند[۱۰و۱۲].
ابزار Kafka نیز ابزاری متن باز برای پیام رسانی است که کاربرد آن ساخت خطوط انتقال داده برای انتقال‌های به صورت جریان است و می‌توان به کمک آن و استفاده از صف سرعت پردازش جریان داده را بهینه نمود تا ناهمزمانی بین سرعت تولید و سرعت پردازش کنترل شود[۱۳و۱۰] .
ابزار Google File System (GFS) یک سیستم ذخیره‌سازی مقیاس بزرگ و توزیع شده‌ی توسعه داده شده توسط گوگل است که برای کار با دادههای حجیم توسعه داده شده است[۱۴]. HDFS نیز که بخشی از پروژه‌ی Apache Hadoop است بر اساس GFS توسعه داده شده و پراستفاده ترین ابزار این حوزه است.
امروزه که داده‌ها فرمت‌های مختلف و بدون ساختاری دارند، استفاده از پایگاه دادههای رابطه‌ای برای دادههای حجیم کمتر مرسوم بوده و از سیستم‌های NoSQL و NewSQL استفاده میشود. پایگاه دادههای NoSQL غیر رابطه‌ای هستند و شامل مدل‌های جفت کلید- مقدار (مانند Redis و Memcached)، گراف (مانند Neo4j و GraphDB)، مبتنی بر ستون (مانند Hbase و Cassandra) و مبتنی بر سند (مانند MongoDB و CouchDB) هستند.
پایگاه دادههای جفت کلید-مقدار دارای ساختار ساده، مقیاس پذیری بالا و بهره وری پایین برای پرسوجوهای به‌هنگام سازی ولی کارایی بالا برای خواندن و نوشتن داشته و برای کاربردهایی مانند اتصال اطلاعات کاربر به شناسه کاربری مناسب هستند .
پایگاه دادههای سند محور برای پردازش‌های مبتی بر سند مناسب بوده و از انواع داده مختلفی مانند JSON و XMLپشتبانی می‌کنند. این نوع پایگاه داده سرعت دسترسی بالا، بهره‌وری بالای پرسوجو و همزمانی را فراهم می‌سازند اما در حجم‌های بالا فضای زیادی را اشغال کرده و بهره‌وری پایین خواندن و نوشتن و نگه‌داری سخت دارند و به طور کلی برای ذخیره‌سازی فایل‌های لاگ و دادههای تحیلی به صورت بلادرنگ مناسب هستند.
پایگاه دادههای مبتنی بر ستون همبستگی زیاد در همان ستون را فراهم آورده و برای بارگزاری‌های سریع و ذخیره‌سازی دادههای بسیار حجیم مناسب هستند اما خواص ACID و پرسوجوهای دارای چندین شرط و همینطور زبان SQL را پشتیبانی نمی‌کنند. به طور کلی برای همزمانی بالا روی دادهای بزرگ و دسترسی بلادرنگ خواندن و نوشتن مناسب هستند.
در پایگاه دادههای مبتنی بر گراف، موجودیت‌ها راس‌ها بوده و همبستگی زیادی بین آن‌ها وجود دارد. کارایی پرسوجوها بهینه بوده و در عین پشتبانی از خواص ACID، الگوریتم‌های گرافی به خوبی روی آن‌ها اعمال میشوند اما پیچیدگی بالایی دارند. این نوع پایگاه های داده برای ذخیره سازی دادههای رابطه‌ای و موتورهای پیشنهاد دهنده و انجمن‌ها مناسب هستند.
پایگاه دادههای NewSQLرابطه‌ای بوده و از خواص ACID و زبان SQLپشتیبانی کرده و در عین حال مقیاس پذیری پایگاه دادههای NoSQL را نیز دارند [۱۵]مانند پایگاه‌داده‌های Spannerو MemSQL.
۲.۲. لایه‌ی پردازش
در ابتدای پردازش داده، داده‌ی خام باید تمیز، جداسازی و با دیگر داده‌ها یکپارچه شود تا کارایی مناسبی داشته باشد. به دلیل حجم بسیار زیاده داده، پردازش و تحلیل همه‌ی آن هزینه‌ی بالایی داشته و شاید در زمان مناسب امکان پذیر نباشد.چهار روش مختلف پردازش داده وجود دارد:
۲.۲.۱.پردازش دسته‌ای (Batch processing)
در زمان بسیار حجیم بودن دسته‌های داده و شبیه به هم بودن آن‌ها، از این روش غیربرخط استفاده میشود، سرعت پردازش این روش در حدود دقیقه بوده و برنامه نویسی آن ساده است. برای برقراری ارتباط از پروتکل RCP/HTTP و برای ذخیره سازی از HDFSاستفاده میشود. MapReduce نیز بر اساس این روش توسط گوگل توسعه داده شده و مدلی توزیع شده برای پردازش دادههای حجیم بدون نگرانی از همزمانی انجام پردازش‌ها، تحمل خطا، قابلیت اطمینان و دسترسی پذیریست. در MapReduce داده‌ها طی بخش Map به بخش‌های مستقلی تقسیم میشوند که به طور موازی طی بخش Reduce مورد پردازش قرار میگیرند و پاسخ بخش‌های مختلف به طور مناسب برای رسیدن به پاسخ کلی با هم ترکیب میشوند. مانند زمانی که بخواهیم تعداد تکرار هر کلمه را در متن بلندی پیدا کنیم، متن به بخش‌های کوچکتری تقسیم شده (Split). سپس در هر قسمت به صورت مجزا تعداد تکرار هر کلمه در متن کوچک شده را به صورت (key, value) که key خود کلمه و value تعداد تکرار آن است محاسبه می کنیم (Map). در گام بعدی نتایج را مرتب سازی می کنیم تا برای جمع زدن آماده بشوند (Shuffle). در نهایت نیز نتایجی که از هر قسمت به دست آمده بود با یکدیگر جمع می شوند تا نتیجه نهایی که تعداد تکرار هر کلمه در متن اصلی است به دست بیاید (Reduce).
۲.۲.۲.پردازش جریان (Stream processing)
این نوع پردزش مناسب زمانی است که نیاز به پاسخ درلحظه و تاخیرکم داریم.
ابزار Storm یک ابزار متن‌باز توسعه داده شده توسط Apache بر اساس این مدل پردازش و شبیه به Hadoop است که در لحظه کار میکند اما به دلیل عدم نیاز به زمانبندی پیچیده، تاخیر را کاهش می‌دهد. Storm دارای برنامه نویسی ساده، مقیاس پذیری بالا، قابلیت اطمینان بالا، تحمل پذیری خطاست.
ابزار Apache Samza نیز ابزار دیگری برای پردازش بهینه جریان دادههای کلان بوده و توسط لینکدین استفاده میشود. Samza معمولا همراه با Kafka استفاده میشود تا تحمیل پذیری خطا، بافر کردن داده و دیگر مزایا نیز به آن اضافه شود. (مانند ارتباط MapReduce و HDFS)
۲.۲.۳.پردازش دوگانه (Hybrid processing)
این نوع پردازش مناسب زمانیست که نیاز به هر دو پردازش دسته‌ای و جریانی داریم. Apache Sparkیک ابزار پردازش دسته‌ای داده است که قابلیت‌هایی برای پردازش جریان داده نیز فرآهم می‌اورد.Spark با قابلیت Resilient Distributed Dataset یا RDD توان انتقال پردازش به حافظه و افزایش سرعت مانند پردازش جریانی را داشته و تحمل پذیری خطا و متعادل سازی بارگزاری خوبی دارد. Spark نسبت به Hadoop کارایی بهتری در زمان محدودیت حافظه دارد.
ابزار Apache Flink ابزار متن بازی برای تحلیل دادههای دسته‌ای و جریانی بوده و همراه یک صف پیام مداوم مانند Kafkaاستفاده میشود.
۲.۲.۴.پردازش داده‌ی گرافی (Graph processing)
برخی داده‌ها را می‌توان به صورت یال و گره به یکدیگر ارتباط داد تا شبکه‌ای از داده‌ها ایجاد شود و زمانی که تعداد راس‌ها و یال‌ها ممکن است در حدود چندصد میلیون شود دیگر روش‌های سنتی پردازش جوابگو نخواند بود.
امروزه دو روش به طور کلی برای این نوع پردازش‌ها مرسوم است:
پایگاه داده‌ی گرافی که قابلیت پردازش لحظه‌ای داده را دارد مانند: Neo4j, OrientDB, DEX
روش دیگر موتورهای محاسباتی هستند که قابلیت پردازش موازی دسته‌های داده‌ها را دارند مانند: Hama, Giraph, Regel
ابزار Pregelنیز یک سامانه‌ی محاسباتی توسعه داده شده توسط گوگل است قادر به پردازش موازی و همزمان دسته‌ای است و برای پردازش گراف های تکرار شوند کارایی بالاتری نسبت به MapReduceداشته و برای مواردی چون یافتن کوتاه‌ترین مسیر، پیمایش، پیج رنک و دیگر الگوریتم‌های مورد نیاز در شبکه بسیار عالی عمل میکند.
برای پردازش دادههای دسته‌ای که حجم بالایی دارند، از روش‌های پردازش غیربرخط و توزیع شده که قابلیت پردازش همزمان دارند استفاده میشود. گوگل برای این مورد نیز ابزار MapReduce را توسعه داده که مدلی توزیع شده برای پردازش دسته‌های داده است و اجازه‌ی اجرای محاسبات سنگین بدون نگرانی در مورد ناهمزمانی، تحمل خطا، قابلیت اطمینان و دسترسی پذیری را می‌دهد.
۲.۳.تحلیل داده و بصری سازی
۲.۳.۱.یادگیری ماشین
مواردی مانند یادگیری ماشین برای کاوش در داده‌ها و استخراخ اطلاعات و دانش مفید و ارزشمند مانند شناسایی الگوها و پیشبینی استفاده میشود. این الگوریتم‌ها در ۴ دسته‌ی یادگیری نظارت شده، یادگیری نظارت نشده، یادگیری نیمه نظارت شده و یادگیری تقویتی قرار میگیرند.
۲.۳.۲.ابزارهای بصری ساز
ابزارهای بصری سازی داده‌ها در سه دسته‌ی زیر جای میگیرند:
ابزارهای ترسیم نمودار مانند: D3, RawGraphs, Google Charts
ابزارهای ترسیم کلاس نقشه مانند: Modest Maps, Openheatmap, ColorBrewer
ابزارهای ترسیم خط زمانی مانند: Cube, Timeflow, Dipity
رایانش ابری بستری برای فرآهم سازی دسترسی فراگیر و آسان به استخری از منابع قابل تنظیم مانند شبکه، قدرت پردازشی، حافظه‌های ذخیره سازی، خدمات و .. است که می‌تواند با کمترین تلاش مدیریتی به سرعت تهیه شده و آزاد گردد.[12]
قدرت این سامانه‌ها در توزیع شده بودن موتورهای پردازشی، پایگاه‌های داده و مجازی سازی آنهاست.
معماری سامانه های پردازش کلان داده ابری باید به گونه‌ای باشند تا هزینه، سرعت و مقیاس پذیری سیستم را مدیریت کنند. سه دسته کلی خدمت ابری برای حل این مشکلات وجود دارد:
نرم افزار به عنوان خدمت (SaaS)
در ساده ترین حالت بدین شکل، کاربر تنها دادههای خود را روی سرور ابری بارگزاری کرده و کلیه‌ی پردازش و تحلیل‌ها به صورت برخط انجام و سپس در صورت غیررایگان بودن تنها به میزان مصرف منابع هزینه پرداخت میشود. مانند Google Analytics
سکو به عنوان خدمت (PaaS)
برای فراهم سازی خدمت مقیاس پذیر، خطاپذیرو توزیع شده که کاربر نیازدارد تا تنظیمات رو خود انجام داده و شخصی سازی نماید و همه چیز مانند SaaS آماده در اختیارش نباشد مانند برخی پایگاه داده‌ها، Kubernetes، داکر، Google App Engine
زیرساخت به عنوان خدمت (IaaS)
مناسب برای زمانی که کاربر لازم دارد تا همه چیز را از صفر طبق نیاز خود فراهم سازد. مانند انتخاب میزان حافظه، توان پردازشی، سیستم عامل و .. در واقع شبیه داشتن یک رایانه‌ی کامل همیشه آماده به کار است که تنها باید از طریق شبکه به آن متصل شد.
از حاصل پردازش کلان‌داده‌ّا در حوزه‌های مختلفی استفاده میشود که برخی از آن‌ها عبارتند از:
سامانه‌های توصیه گر:
با افزایش انفجاری انواع داده در سال‌های اخیر، تصمیم گیری بر اساس داده سختتر شده(مشکلی که از آن به عنوان سربار اطلاعاتی یاد میشود) و سامانه‌های توصیه‌گر وظیفه‌ی استخراج اطلاعات مفید از کلان دادههای باارزش و کم ارزش و بی‌ارزش را دارند. ایده‌ی اصلی تحلیل تاریخچه رفتار کاربر و سپس توصیه‌ی خودکار محصولات به اوست.
شبکه هوشمند:
اطلاعات بسیار زیاد از طریق شبکه حسگرهای بیسیم برای تصمیم گیری خودکار استفاده در باره گذشته یا در لحظه میشود.
تحلیل احساسات:
تحلیل احساسات و نظرات مردم
۵.۱.معماری لامبدا
یک معماری نرم‌افزار پردازش داده‌ی حجیم معروف ارائه شده توسط Nathan Marz که متخصص علم داده‌ی شرکت توییتر(X) است، معماری لامبداست که قابلیت پردازش دسته‌ای و جریانی را داشته و تاخیر بسیارکم، تحمل پذیری خطا و مقیاس پذیری بالایی دارد[۱۶و۱۷].
در معماری لامبدا که در شرکت توییتر، نتفلیکس و یاهو استفاده میشود، با استفاده از سه لایه، توابع مختلف روی داده‌ی مشخص در لحظه اعمال میشود. این لایه‌ها عبارتند از:
۵.۱.۱.لایه‌ی دسته (Batch)
این لایه‌ی ذخیره سازی با استفاده از سیستم فایل توزیع شده HDFS است که مدیریت دسترسی داده را انجام داده و برای پردازش از Hadoop که مانند MapReduce است استفاده میکند. دادههای در معماری لامبدا در ساختاری به نام نمای دسته‌ای ذخیره شده و همه‌ی داده‌ها به نوعی یک کپی داشته و تغییرات در ابتدا فقط در یکی از این کپی‌ها انجام شده و دادههای اصلی که در این لایه هستند تغییر نمی‌کنند، پس بازیابی خطا بسیار آسان خواهد بود. این لایه را می‌توان شبیه یک دریاچه‌ی داده در نظر گرفت.
۵.۱.۲.لایه‌ی خدمت دهنده (Serving)
در این لایه بارگذاری و نمایش داده در مبنع داده انجام شده و پاسخ دهی به پرسوجوها در آن انجام میشوند. در این لایه به‌هنگام سازی دسته‌ای و خواندن تصادفی وچود دارد.
۵.۱.۳.لایه‌ی سرعت (Speed)
این لایه فقط مخصوص جبران تاخیر به‌هنگام سازی در لایه‌ی خدمت‌دهنده بوده و با استفاده از پردازش جریانی Stormدادههای جدید را برای محاسابت بلادرنگ استفاده می کند و پاسخ این محاسبات در این لایه تا زمان انتقال به لایه‌ی دیگر می‌ماند.
۵.۱.۴.مزایای معماری لامبدا
کاهش احتمال وقوع خطا به علت وجود لایه batch
فراهم سرعت بیشتر بدون کاهش ویژگی قابل اتکا بودن
مقاوم بودن در برابر وقوع خطا
۵.۱.۵.معایب معماری لامبدا
· پیچیدگی بالا به علت لایه‌های مختلفت و مدیریت آن‌ها
· محاسبات بیشتر برای آماده سازی داده در مرحله تحلیل
· دشواری استفاده و ترکیب با خدمات ابری و یا منبع‌باز
۵.۲.معماری کاپا
چالش‌های معماری لامبدا باعث تا معماری کاپا توسعه داده شود که همانند معماری لامبدا بستری برای پردازش جریان و دسته داده فراهم میکند ام در آن لایه‌ی دسته برای سادگی حذف شده است. در این معماری به طور کلی، داده دریافتی از جریان داده ورودی، ابتدا در یک message engine ( مثلا apache kafka ) ذخیره میشود و سپس توسط یک موتور پردازش جریان داده پردازش میشود و خروجی به صورت ساختاری مناسب برای تحلیل ذخیره میشود. با توجه به این که در این معماری، رویکردی نزدیک به رویکرد بلادرنگ استفاده میشود، (یعنی داده ورودی پس از دریافت سریعا برای تحلیل اماده میشود)، تحلیل داده های جدید به سرعت برای درخواست کاربران ذخیره میشوند[۱۸ و ۱۹].
بنابراین این معماری بیشتر برای کاربردهایی مناسب است که منطق سازمانی حاکم بر آن‌ها کاملا مشخص و بدون تغییر است. مثلا برای بررسی و پردازش خطا‌های نرم افزار، پایش شبکه‌های اجتماعی و همچنین پایش وضعیت سرو‌ها می‌توان از این معماری استفاده کرد چون غالب تصمیمات باید در لحظه گرفته شود و آمار مورد نیاز هم در همان حین دریافت اطلاعات قابل استخراج و ذخیره سازی است. در واقع این معماری محدودیت بیشتری دارد و شکل خلاصه شده‌ی معماری لامبدا است.
۵.۲.۱.مزایای معماری کاپا
پردازش بلادرنگ و بدون تاخیر داده
مقیاس پذیری بالا
معماری نرم‌افزار نسبتا ساده
قابلیت پردازش به دو صورت دسته‌ای و جریانی
قابلیت اطمینان بالا
قابلیل استفاده برای کاربردهای جدید
نیاز به منابع کمتر برای پردازش‌های یادگیری ماشین
۵.۲.۲.معایب معماری کاپا
افزایش احتمال خطا و کاهش ریکاوری به دلیل حذف لایه‌ی دسته‌ای
امروزه ما در دنیای انفجار اطلاعات زندگی میکنیم، افراد و کسب‌وکار‌هایی که به درستی از این داده‌ها استفاده کنند، همیشه پیشگویی در کنار خود خواهند داشت که آینده، روندها، الگوها و علایق را قبل از دیگران دانسته و یک قدم جلوتر خواهند بود. اما استخراج دانش درست از حجم بالای داده نیازمند رهیافت درستی است که کیفیت مراحل آن تضمین شده باشد، داده‌ها باید به سلامت از منابع تولید انتقال یافته، بدون از دست رفتن و خرابی در پایگاه ّهای داده ذخیره شده، دادههای نامربوط و کثیف پاکسازی شده و دادههای سالم به سرعت مورد پردازش و تجزیه تحلیل قرار گیرند بدون آنکه پردازنده‌ای معطل حافظه مانده و یا سامانه به دلیل خاموشی یک سرور با بار زیاد یا پر شدن یک حافظه دسترسی پذیری مناسب خود را از دست دهد، و همه‌ی این‌ها ممکن نیست به جز با داشتن یک معماری نرم‌افزار پردازش کلان داده‌ی مناسب که از ابتدا تا انتها برای آن سامانه تصمیمات مهندسی مناسب اتخاذ کرده باشد.
[1] Solms, F., 2012, October. What is software architecture?. In Proceedings of the south african institute for computer scientists and information technologists conference (pp. 363-373).
[2] Richards M, Ford N. Fundamentals of software architecture: an engineering approach. O'Reilly Media; 2020 Jan 28.
[3] Al-Mekhlal, M. and Khwaja, A.A., 2019, August. A synthesis of big data definition and characteristics. In 2019 IEEE International Conference on Computational Science and Engineering (CSE) and IEEE International Conference on Embedded and Ubiquitous Computing (EUC) (pp. 314-322). IEEE.
[4] Cappa, F., Oriani, R., Peruffo, E. and McCarthy, I., 2021. Big data for creating and capturing value in the digitalized environment: unpacking the effects of volume, variety, and veracity on firm performance. Journal of Product Innovation Management, 38(1), pp.49-67.
[5] Hariri, R.H., Fredericks, E.M. and Bowers, K.M., 2019. Uncertainty in big data analytics: survey, opportunities, and challenges. Journal of Big Data, 6(1), pp.1-16.
[6] Wang J, Yang Y, Wang T, Sherratt RS, Zhang J. Big data service architecture: a survey. Journal of Internet Technology. 2020 Mar 1;21(2):393-405
[7]P. Karunaratne, S. Karunasekera, A. Harwood, Distributed Stream Clustering Using Micro-clusters on Apache Storm, Journal of Parallel and Distributed Computing, Vol. 108, pp. 74-84, October, 2017.
[8] Barbacci M, Klein MH, Longstaff TA, Weinstock CB. Quality attributes. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Technical Report CMU/SEI-95-TR-021. 1995 Dec 1.
[9] Tayade DM. Comparative study of ETL and E-LT in data warehousing. Int. Res. J. Eng. Technol. 2019 Jun;6:2803-7.
[11] Borthakur D. The hadoop distributed file system: Architecture and design. Hadoop Project Website. 2007 Aug;11(2007):21.
[12] B. Shu, H. Chen, M. Sun, Dynamic Load Balancing and Channel Strategy for Apache Flume Collecting Real-Time Data Stream, IEEE International Symposium on Parallel and Distributed Processing with Applications (ISPA), Guangzhou, China, 2017, pp. 542-549.
[13] Thein KM. Apache kafka: Next generation distributed messaging system. International Journal of Scientific Engineering and Technology Research. 2014 Dec 1;3(47):9478-83.
[15] M. Wang, B. Li, Y. Zhao, G. Pu, Formalizing Google File System, IEEE 20th Pacific Rim International Symposium on Dependable Computing (PRDC), Singapore, Singapore, 2014, pp. 190-191.
[16] Kiran M, Murphy P, Monga I, Dugan J, Baveja SS. Lambda architecture for cost-effective batch and speed big data processing. In2015 IEEE international conference on big data (big data) 2015 Oct 29 (pp. 2785-2792). IEEE.
[17] Munshi AA, Mohamed YA. Data lake lambda architecture for smart grids big data analytics. IEEE Access. 2018 Jul 23;6:40463-71.
[18] Lin J. The lambda and the kappa. IEEE Internet Computing. 2017 Sep 1;21(05):60-6.
[19] Sanla A, Numnonda T. A comparative performance of real-time big data analytic architectures. In2019 IEEE 9th International Conference on Electronics Information and Emergency Communication (ICEIEC) 2019 Jul 12 (
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
