معماری نرم افزار در سیستم های پردازش داده حجیم

مقدمهبا توجه به افزایش سرعت تولید داده در پلتفرم‌ های مختلف، بسیاری از نرم‌ افزار‌ ها در حوزه های مختلف با حجم زیادی از داده مواجه هستند. به همین جهت، حتی اگر ماهیت اصلی سیستم، تحلیل و پردازش داده نباشد، پردازش داده میتواند برای سازمان ارزش آفرین باشد.سیستم‌ های پردازش داده حجیم، عموما از بخش‌ های مشترکی تشکیل شده اند. این بخش‌ ها شامل بخش تولید داده، پیش‌پردازش و آماده‌ سازی اولیه، دریافت و یکپارچه سازی داده، تحلیل و اجرای پردازش برروی داده و نمایش نتایج میباشد. میدانیم هر سیستم مختلف، با داده‌ های مختلفی مواجه است و تبع آن، نیازمندی‌ های متفاوتی دارد و نیازمندی متفاوت، نیاز‌مند معماری متفاوت و مناسب برای پاسخ‌گویی به آن است. ایجاد معماری مناسب در چنین سیستم‌ هایی تاثیر بسیار مهمی در رسیدن به نیازمندی‌ ها با کارایی قابل قبول دارد.داده حجیم در این سیستم هاهمان طور که گفته شد، امروزه در حوزه‌ های مختلف، سیستم‌ های نرم‌ افزاری با حجم زیادی از داده مواجه هستند، و مدیریت این حجم بسیار زیاد، چالش‌ های زیادی خواهد داشت. به طور کلی، در مواجهه با داده حجیم، دو موضوع اهمیت زیادی دارد، اولا فراهم کردن امکان دریافت و ذخیره سازی داده، و ثانیا، فراهم کردن امکان پردازش داده ذخیره شده، مطابق با نیازمندی‌ ها.اصطلاح “داده حجیم” یا کلان داده، به داده‌ای اطلاق میشود که به علت حجم و اندازه بسیار زیاد آن، روش‌ ها و ابزار‌ های مرسوم که توسط نرم‌ افزار‌ های معمولی استفاده میشود، توانایی ذخیره‌ سازی و پردازش‌ آن را ندارند. به طور کلی داده حجیم با سه معیار ( Three Vs ) توصیف میشوند.حجم داد (Volume): معیاری برای توصیف حجم داده.سرعت (Velocity): معیاری برای توصیف سرعت تولید داده.تنوع (variety): معیاری برای توصیف میزان تفاوت در داده موجود.همان‌طور که گفته شد، امروزه سیستم‌ های نرم‌ افزاری در حوزه‌ های مختلف نیاز به پرداز داده حجیم دارند، بخصوص حوزه‌ هایی که با تعداد کاربر زیاد مواجه‌ هستند. بعنوان مثال، نرم‌ افزار‌ های شبکه‌ های اجتماعی، سیستم‌ های حوزه سلامت، حوزه‌ های صنعتی، حتی در زمینه‌ های خاص مانند سیستم‌ های هواشناسی و یا نظامی، همگی با توجه به حجم داده‌ای که در اختیار دارند، نیاز به تحلیل و پرداز دارند. به همین سبب وجود معماری و چارچوب مناسب در چنین سیستم‌ هایی بسیار اهمیت دارد.استفاده از کلان دادهمعمولا وجود این حجم زیاد داده، به خودی خود، ارزشی ندارد و تحلیل آن و استخراج دانش از آن است که سبب ارزش آفرینی میشود. در این فرایند لازم است تا داده حجیم که معمولا ساختار و فرمت مناسبی ندارد، ابتدا جمع آوری، ذخیره و پردازش شود تا بتوان اطلاعات مفید و سودمند از آن استخراج شود و در راستای تولید ارزش از آن استفاده شود.استفاده از این اطلاعات در زمینه‌ های مختلف مرسوم است. مثلا برای بهبود تجربه کاربر. در این رویکرد، میتوان با جمع آوری اطلاعات کاربران، و پردازش و تحلیل آن، محصول را در راستای افزایش رضایت کاربر بهبود بخشید. مثلا پلتفرم‌ های پخش فیلم، با جمع آوری تعامل کاربر با سیستم، و پردازش آن، پیشنهاد‌ هایی مطابق با سلیقه کاربر ارائه میدهند.همچنین میتوان با پردازش داده حجیم، امنیت را افزایش داد، مثلا در سیستم بانکی، با جمع اوری و تحلیل اطلاعاتی که مثلا از لاگ ‌ها بدست می آید، میتوان مخاطرات فرایند‌ های مختلف را شناسایی کرد و برای هر کدام راه حلی مناسب پیشنهاد داد.از دیگر استفاده‌ های سیستم پردازش داده حجیم، میتوان تصمیم گیری سریع را عنوان کرد، مثلا سیستم‌ های مسیر یاب، با تحلیل حجم زیادی از داده کاربران، میتوانند در لحظه حجم ترافیک در مسیر‌ های مختلف را محاسبه نمایند و بدین ترتیب در ارائه خدمات به کاربر، عملکرد بهتری داشته باشند.اهمیت انتخاب معماری مناسب در سیستم‌ های پردازش داده حجیمهمان طور که میدانیم، ایجاد معماری مناسب، و اتخاذ تصمیمات کلیدی برای فراهم کردن بستری مناسب برای توسعه محصول، در سیستم‌ های نرم افزاری امری ضروری است. همچنین میدانیم، هدف ایجاد معماری مناسب، رسیدن به ویژگی‌ های کیفی مناسب، با کمترین هزینه است.در سیستم‌ های پردازش داده حجیم، علاوه بر این موارد، چون با حجم زیادی از داده مواجه هستیم و سرعت تولید داده بسیار زیاد است، وجود ساختار و ظرفیت مناسب و پاسخگو برای مواجهه و مدیریت کلان داده بسیار اهمیت دارد. با توجه به این که سرعت تولید میتواند بسیار زیاد باشد، عدم وجود معماری مناسب در این شرایط، میتواند به سرعت سبب ایجاد چالش‌ های زیاد، با هزینه‌ های جبران‌ نا‌پذیر شود.قابل ذکر است که در این شرایط، اتخاذ تصمیم مناسب برای ایجاد معماری، بسیار حساس‌ تر و پیچیده‌ تر خواهد بود. در این شرایط معماری‌ پیشنهاد شده، باید توانایی پاسخ‌گویی به نیازمندی سیستم، با توجه به ویژگی‌های داده سیستم ( حجم، سرعت، تنوع) را داشته باشد.موضوع دیگری که در طراحی معماری اهمیت دارد، در نظر گرفتن احتمال ایجاد تغییرات در آینده است. معمولا در سیستم‌ های نرم‌ افزاری بخش زیادی از هزینه‌ مربوط به مراحل بعد از استقرار است. همواره در توسعه سیستم‌ های نرم‌ افزاری در مراحل اجرا با وقوع خطا‌ ها و باگ‌ ها مواجه خواهیم بود، که برای رفع آن نیاز به ایجاد تغییرات در ساختار سیستم‌ وجود دارد. همچنین ممکن است تا لازم باشد به علت تعریف نیازمندی جدید، ویژگی‌ هایی جدید به سیستم اضافه شود. پس بدین ترتیب لازم است معماری ایجاد شده، امکان ایجاد تغییر را داشته باشد.در سیستم‌ های پردازش داده حجیم، با توجه به این که معمولا این سیستم‌ ها بسیار بزرگ هستند، و حجم داده‌ای که با آن مواجه‌ اند نیز بسیار زیاد است معمولا با تغییرات بیشتر و پیچیده‌تری مواجه هستیم. به همین دلیل، وجود معماری‌ای منعطف و مناسب برای این موضوع، در سیستم‌ های پردازش داده حجیم، بسیار اهمیت دارد.اتخاذ تصمیم در مورد معماری در این سیستم‌ ها بسیار حساس‌تر است. با توجه به اندازه بزرگ سیستم، و نرخ بالای داده ورودی و تغییرات زیاد، اگر تصمیم گرفته شده، مناسب نباشد، تبعات آن بسیار سریع نمایان میشود، و میتواند سبب افزایش هزینه در مدت زمان بسیار کم شود.در طراحی معماری برای سیستم های پردازش داده حجیم لازم است تا نیاز مندی های سیستم به طور دقیق شناسایی شود و بر اساس آن ها تصمیمات لازم اتخاذ شود. اما به طور معمول، سیستم های پردازش داده حجیم در یکسری نیازمندی اشتراک دارند. هر سیستمی که لازم است در آن تحلیل داده صورت گیرد، نیازمند آن است که داده و منبع داده را شناسایی کند. برای پردازش و تحلیل داده نیاز است تا نسبت به منبع تولید کننده داده شناخت نسبی وجود داشته باشد. امکان ذخیره سازی داده حجیم ویژگی دیگری است که لازم است معماری برای آن رویکرد مناسب ارائه شود. ذخیره سازی داده حجیم به علت حجم بالا و نرخ تولید زیاد میتواند چالش بر انگیز باشد. هم چنین سرعت دسترسی به آن نیز بسیار مهم است، به همین دلیل در معماری این سیستم ها لازم است برای این امر نیز تصمیم مناسب اتخاذ شود.در بسیاری از سیستم های پردازش داده حجیم لازم است تا امکان پردازش داده به صورت بلادرنگ، پس از دریافت آن وجود داشته باشد. چون معمولا نرخ تولید داده بسیار زیاد است، وجود این ویژگی میتواند در کارایی و مقیاس پذیری سیستم تاثیر زیادی داشته باشد.ویژگی‌ های کیفی مهم در سیستم‌ های پردازش داده حجیمبه طور کلی، معماری در سیستم‌ های پردازش کلان داده، همانند دیگر سیستم‌ های نرم‌ افزاری، باید در راستای بهبود ویژگی‌ های کیفی طراحی شود. اما در سیستم‌ های کلان داده، به طور مشترک، برخی از این ویژگی‌ ها اهمیت بیشتری دارند. مقیاس‌ پذیریویژگی مقیاس‌پذیری را میتوان بعنوان مهم‌ترین ویژگی در بین ویژگی‌ های کیفی در چنین سیستم‌ هایی درنظر گرفت. این ویژگی بیان‌گر این است که معماری سیستم تا چه میزان توانایی و ظرفیت برای گسترش نرم‌ افزار برای پشتیبانی از کاربران و داده بیشتر را دارد. علت اهمیت این ویژگی در سیستم‌ های پردازش داده حجیم این است که، با بزرگ‌تر شدن چنین سیستم‌ هایی، تعداد کاربران و داده‌ های تولید شده به طور چشمگیر افزایش خواهد یافت. اگر در چنین شرایطی، معماری ظرفیت افزایش سریع پشتیبانی را نداشته باشد، با چالش‌ هایی مواجه خواهیم شد.دسترس‌ پذیرییکی دیگر از ویژگی‌ های مهم در این سیستم‌ ها، ویژگی دسترس پذیری است. با توجه به این که نرخ تولید داده در این سیستم‌ ها بسیار بالاست، دسترس پذیری پایین، میتواند سبب از بین رفتن حجم زیادی از داده شود. همچنین عدم مدیریت به موقع داده در زمان مشخص نیز میتواند هزینه بر باشد.کاراییمعیار کارایی بیانگر توانایی پاسخگویی سیستم، و هزینه لازم برای آن است. در چنین سیستم‌ هایی چون حجم داده بسیار زیاد است، توانایی سیستم در پاسخ‌گویی در کمترین زمان و منابع مورد نیاز برای پاسخگویی بسیار اهمیت دارد. هم چنین با توجه به این که نرخ تولید داده در این سیستم ها بسیار بالا است، پاسخگویی در کم ترین زمان ممکن بسیار اهمیت دارد. اگر این موارد در معماری به خوبی در نظر گرفته نشده باشد، با افزایش حجم داده و بزرگتر شدن سیستم، بدون شک با چالش مواجه خواهیم شد و با افزایش هزینه روبرو خواهیم بود.سازگاریممکن است سیستم مد نظر با حجم زیادی از داده و تنوع بالا مواجه باشد، به همین جهت لازم است تا معماری، علاوه بر توانایی مدیریت داده‌ های متنوع، بستری را فراهم کند تا یکپارچگی در سیستم حفظ شود.امنیتدر تمامی سیستم‌ های نرم‌ افزاری، ویژگی امنیت، موضوعی بسیار مهم و قابل توجه است. در سیستم‌ های پردازش داده حجیم، چون داده را میتوان بعنوان بخش مهمی از سیستم در نظر گرفت، حفظ امنیت ( بخصوص محرمانگی داده) اهمیت بیشتری دارد.مولفه‌ های مهم در معماری سیستم‌ های پردازش کلان دادهطبق بررسی‌ هایی انجام شده، معماری‌ هایی که در این زمینه معرفی شده اند، در یکسری مولفه، اشتراک دارند. این بخش‌ ها به شرح زیر میباشند.منابع دادهمنابعی که بعنوان منشا ورودی سیستم، داده تولید میکنند. منشا این داده‌ ها میتواند به طور مستقیم داده‌ ای باشد که کاربر وارد میکند. و یا داده‌ای باشد که سیستم از کاربران استخراج میکند، مثلا تعامل کاربر با سیستم، و یا ذخیره سازی رفتار کاربر. مثلا پلتفر‌ های بخش موسیقی و یا فیلم ( مثلا spotify ) رفتار‌ های کاربر در حین استفاده از پلتفرم، مانند پخش سبک خاصی از موسیقی در ساعات خاصی از روز، رد کردن موسیقی پیشنهادی، پخش کردن بخشی از موسیقی و دیگر تعاملات را برای پردازش ذخیره سازی میکنند. علاوه بر چنین اطلاعاتی، داده‌ های دیگری، مثلا لاگ ذخیره شده سیستم نیز میتواند بعنوان ورودی در نظر گرفته شود. بانک اطلاعاتیمولفه مشترک دیگر در این سیستم‌ ها، بخش مربوط به ذخیره سازی داده است. این مولفه رویکرد مربوط به ذخیره سازی را تعریف میکند. چون حجم داده زیاد است، نحوه نگه‌داری داده بسیار اهمیت دارد. در این بخش، تصمیمات مربوط به نگه‌داری داده، مانند تکنولوژی مورد استفاده، distribute بودن پایگاه‌داده، فرمت ذخیره سازی و چنین تصمیماتی گرفته میشود.مولفه پردازش دسته‌ ای دادهاین مولفه، داده‌ های جمع‌آوری شده را با پردازش اولیه برای تحلیل آماده میکند. علت استفاده از این بخش قبل از تحلیل داده، حجم زیاد داده است، و پردازش اولیه دسته‌ ای داده‌ ها میتواند هزینه لازم برای تحلیل و پردازش داده را کاهش دهد.دریافت داده بلادرنگپس از دریافت داده توسط ماژول قبلی، لازم است تا داده جمع‌آوری شده، برای تحلیل نهایی پردازش اولیه و آماده سازی شود. این امر توسط این مولفه انجام میشود. ابزار‌ هایی مانند Spark streaming و Azure stream analytics امکان پردازش جریان داده را فراهم میکنند.خزن داده ذخیره میشود. اما معمولا در این مولفه یکسری پردازش اولیه بر روی داده نیز انجام میشود. از ابزار‌ های موجود برای پیاده سازی و نگه‌داری این بخش، میتوان Azure events, kafka و Azure iot hub را نام برد.پردازش جریان دادهپس از دریافت داده توسط ماژول قبلی، لازم است تا داده جمع‌آوری شده، برای تحلیل نهایی پردازش اولیه و آماده سازی شود. این امر توسط این مولفه انجام میشود. ابزار‌هایی مانند Spark streaming و Azure stream analytics امکان پردازش جریان داده را فراهم میکنند.منبع ذخیره داده تحلیلیپس از پردازش داده، لازم است تا تحلیل داده فراهم شده با فرمت و ساختار متناسب با نیازمندی سیستم، ذخیره سازی شود. در این مولفه با انتخاب ابزار مناسب برای داده کلان، این امر فراهم میشود. مثلا ابزار Azure synapse یک سرویس مناسب برای داده با مقیاس بالا فراهم میکند.مولفه ارائه گزارش تحلیلیهمان طور که میدانیم، یکی از اصلی ترین اهداف سیستم‌ های پردازش داده حجیم، استخراج تحلیل و دانش از حجم زیاد داده است. برای فراهم کردن این امکان، معمولا در معماری سیستم‌ های پردازش داده حجیم، یک مولفه برای این امر در نظر گفته میشود که بعنوان لایه مدلسازی داده از آن یاد میشود.مولفه orchestration معمولا در این سیستم‌ ها فرایند پردازش داده به صورت تکراری و مداوم انجام میشود، این فرایند شامل دریافت داده، تبدیل آن به فرمت قابل پردازش، جابجایی بین لایه‌ ها و مولفه‌ های مختلف، و انتقال داده پردازش شده به مولفه مربوط به تحلیل است. برای استفاده از رویکرد‌ خودکار سازی این فرایند، میتوان از ابزار‌ های orchestration مانند Sqoop و یا Azure Oozie استفاده نمود.معماری‌ های ارائه شده برای سیستم‌ های پردازش کلان‌دادهمعماری لامبدایکی از معروف ترین معماری‌ هایی که در این حوزه استفاده میشود. این معماری بستری فراهم میکند تا بتوان داده با محم بسیار بالا را پردازش کرد. هم چنین رویکردی برای ایجاد مولفه پردازش دسته‌ ای و جریان داده را نیز ارائه میکند. این معماری که توسط Nathan Marz که یکی از متخصصین علم داده twitter است ارائه شده است و هدف آن ارائه چارچوبی مقیاس پذیر برای پردازش کلان داده است. اهداف اصلی این معماری، کاهش تاخیر سیستم، افزایش مقاومت در برابر خطا و بهبود مقیاس پذیری است.این معماری از سه لایه اصلی تشکیل شده است.لایه Batchوظیفه اصلی این لایه، مدیریت دسترسی به داده است. در این معماری، محموعه اصلی داده، تغییر ناپذیر است، و برای دسترسی به داده، باید از این لایه استفاده شود. بدین ترتیب، احتمال ایجاد تغییر به صورت اشتباه در مجموعه داده کاهش میابد. از این لایه بعنوان data lake نیز یاد میشود.در این لایه، داده ها با ساختاری مشخص به نام batch view ذخیره میشوند. مزیت این روش این است که نگه‌داری داده و مدیریت آن ساده تر میشود و هم چنین سرعت جست و جو و دسترسی به داده افزایش میابد.در معماری لامبدا، برای مدیریت نما‌ها دو رویکرد در نظر گرفته شده است. در روش اول با اضافه شدن نمای جدید، نما‌های قبلی حذف میشوند. اما در روش دیگر، با دریافت داده جدید، بجای حذف نما، نما‌های موجود بروز رسانی میشوند.در این لایه میتوان از ابزار‌ هایی مانند hadoob برای ذخیره‌سازی استفاده کرد.لایه Speedدر این لایه، مدیریت داده‌ های پردازش شده در لایه batch انجام میشود. هم‌چنین در این لایه از رویکرد‌ هایی برای افزایش سرعت دسترسی به داده استفاده میشود. مثلا در ای لایه، batch view ها برای جست و جوی سریع‌تر ایندکس میشوند. یا مثلا در این لایه، برای کاهش تاخیر در ایندکس کردن، از تکنیک پردازش جریان داده استفاده میشود، و داده‌ های ورودی، به صورت بلادرنگ پردازش میشوند.لایه Servingوظیفه این لایه، پاسخگویی به درخواست کاربر است. این لایه دسترسی به داده‌ های پردازش شده را با تاخیر کم فراهم میکند.با توجه به ویژگی و امکاناتی که این معماری فراهم میکند، در حوزه‌ هایی حجم داده با نرخ تولید بالا زیاد است، مانند ماشین لرنینگ، IOT ، مدیریت لاگ و غیره عملکرد خوبی خواهد داشت.استفاده از این معماری امکانات و ویژگی‌ هایی را برای سیستم فراهم میکند. میتوان گفت کاهش خطا یکی از مهم‌ ترین این ویژگی‌ هاست. چون در این معماری دسترسی به داده اصلی به صورت مدیریت شده توسط لایه batch انجام میشود، احتمالا وقوع خطا کاهش میابد. در این لایه از نما‌های مشترک و ساختار یافته استفاده میشود، به همین جهت ویژگی نگه‌ داری (maintainance) بهبود میابد. همچنین با توجه با ساختار لایه‌‌ های این چارچوب، این معماری از مقیاس‌ پذیری خوبی برخوردار خواهد بود.مزایای معماری لامبداکاهش احتمال وقوع خطا به علت وجود لایه batch فراهم سرعت بیشتر بدون کاهش ویژگی قابل اتکا بودنمقاوم بودن در برابر وقوع خطامعایبپیچیدگی بیشتر نسبت به دیگر معماری‌هامحاسبات بیشتر برای آماده سازی داده در مرحله تحلیلمعماری کاپامعماری کاپا همانند معماری لامبدا بستری برای پردازش جریان و دسته داده فراهم میکند. در این معماری به طور کلی، داده دریافتی از جریان داده ورودی، ابتدا در یک message engine ( مثلا apache kafka ) ذخیره میشود و سپس توسط یک موتور پردازش جریان داده پردازش میشود و خروجی به صورت ساختاری مناسب برای تحلیل ذخیره میشود. با توجه به این که در این معماری، رویکردی نزدیک به رویکرد بلادرنگ استفاده میشود، (یعنی داده ورودی پس از دریافت سریعا برای تحلیل اماده میشود)، تحلیل داده‌ های جدید به سرعت برای درخواست کاربران ذخیره میشوند.معماری کاپا بعنوان معماری ساده‌ تر جایگزین معماری لامبدا میشود. در این معماری با توجه به این که داده به صورت بلادرنگ اماده تحلیل میشود، عملا لایه batch حذف میشود.مزایای معماری کاپامعماری کاپا توانایی ایجاد بستری برای پردازش [تقریبا] بلادرنگ ( یا آنلاین ) داده را دارد.معماری ساده تر نسبت به لامبدا .مقیاس پذیری بالا.معایبعدم وجود لایه batch میتواند احتمال وقوع خطا را افزایش دهد.سخن پایانیامروزه در بسیاری از حوزه های مختلف، سیستم‌های نرم‌ افزاری با حجم زیادی از داده مواجه هستند. حتی اگر هدف اصلی سیستم نرم افزاری پردازش و تحلیل داده حجیم نباشد، جمع آوری و تحلیل این داده ها میتواند برای کسب و کار مفید و سود آور باشد. پس در حوزه های مختلف، مثل حوزه های مربوط به یادگیری ماشین، اینترنت اشیا، شبکه های اجتماعی و غیره، سیستم‌ های پردازش داده حجیم بسیار کاربرد دارند. با توجه به ویژگی این سیستم‌ ها، اندازه بزرگ آن ها، و حجم بسیار زیاد داده‌ ای که با آن مواجه هستند، وجود معماری مناسب و پاسخ گو امری ضروری است. با توجه به این که نرخ تولید داده در این این سیستم های نرم افزاری معمولا زیاد است، فراهم کردن یک معماری که ظرفیت مدیریت حجم زیاد داده را داشته باشد میتواند چالش بر انگیز باشد.به همین جهت بررسی کردیم تا ببینیم برای چنین سیستم هایی چگونه میتوان معماری مناسب ارائه کرد و در این معماری ها چه نکاتی اهمیت بیشتری دارند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»#معماری_نرم_افزار_بهشتیمنابع1.N. H. Madhavji, A. Miranskyy and K. Kontogiannis, "Big Picture of Big Data Software Engineering: With Example Research Challenges," 2015 IEEE/ACM 1st International Workshop on Big Data Software Engineering, Florence, Italy, 2015, pp. 11-14, doi: 10.1109/BIGDSE.2015.10.2.https://www.researchgate.net/publication/343666493_Software_architectures_for_big_data_a_systematic_literature_review3.https://www.sciencedirect.com/book/9780128054673/software-architecture-for-big-data-and-the-cloud4.https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/big-data5.https://hazelcast.com/glossary/kappa-architecture/6.https://hazelcast.com/glossary/lambda-architecture/7.https://data-flair.training/blogs/lambda-architecture/8.https://www.databricks.com/glossary/lambda-architecture