امروزه سیستمهای پردازش کلان داده در صنعتهای متنوعی و برای تامین مقاصد مختلفی استفاده میشود. هر یک از این سیستمها با وجودی که مقاصد مختلفی را دنبال میکنند به دلیل سر و کار داشتنن با کلان دادهها دارای بخشهای مشترکی در معماری نرمافزارشان هستند.در این مقاله ابتدا به بررسی اینکه مفهوم کلان داده چیست و چه نیازی به تحلیل کلان دادهها هست پرداختهایم.
سپس ضرورت وجود معماری برای سیستمهای پردازش کلان داده از این دید که هر کدام از این سیستمها داتا یک نرمافزار هستند بررسی کردیم.در بخش بعدی با توجه اشتراکاتی که این سیستمها در معماریشان با یکدیگر دارند ، به بررسی ویژگیهای کیفی که تمامی این معماریها به دنبال تامین آنها هستند، پرداختیم. در ادامه به بررسی معماری ۷ قسمتی که برای تمامی سیستمهای پردازش کلان داده وجود دارند و هر کدام با توجه به نیازمندیهایشان میتوانند شامل بخشهایی از این معماری باشند پرداختیم.
در بخش بعدی به بررسی ویژگیها و تفاوتهای معماریهای معروف حوزهی سیستمهای پردازش کلان داده شامل Lambda و Kappa پرداختیم و مزیتها و ضعفهای هریک را بررسی کردیم.در انتها با بررسی معماری Netflix که یکی ازمعماریهای برتر در حوزهی سیستمهای پردازش کلان داده است، نتایج این تحقیق را بیان کردیم.
کلید واژهها:Big Data,Big Data Architecture,Big Data Analytics,Quality Attribute,Big Data Tools
کلان داده به حجم عظیمی از دادهها اطلاق می شود که با ابزارهایی سنتی موجود در صنعت نرمافزار قابل ذخیره سازی، پردازش یا تحلیل نیست. امروزه میلیونها منبع داده وجود دارند که با نرخ سرعت بسیار بالا در حال تولید داده هستند.این منابع داده در سراسر جهان توزیع شدهاند.بعضی از بزرگترین منابع تولید داده را میتوان شبکههای اجتماعی، حسگرها، تلفن های هوشمند، رایانه ها، سیستم های موقعیت یاب جهانی، معاملات تجاری، بازی ها، شبکهها، فایلهای لاگ، اپلیکیشنهای تراکنشی و وب دانست. علاوه بر این دادهها در قالبهای مختلفی تولید می شوند:
۱- دادههای ساختارمند (Structured Data): این دادهها همان دادههای ذخیره شده در پایگاه دادههای رابطهای (ٍRDBMS) هستند.
۲- داده های نیمه ساختارمند (Semi-Structured Data): داده های نیمه ساختار مند میتوانند به شکل ساختارمند دیده شوند اما نمی توان آن ها را به صورت یک جدول رابطه ای در پایگاه داده در نظر بگیریم. مانند ایمیل، فایلهای XML و …
۳- داده های بدون ساختار (Unstructured Data): هر داده ای با فرمت و ساختار ناشناخته، به عنوان دادههایی بدون ساختار طبقه بندی میشود. نمونه بارز دادههای بدون ساختار، یک منبع داده ی ناهمگون است که شامل ترکیبی از تصاویر، ویدئوها و غیره است.
این حجم عظیم دادههای خام به خودی خود ارزشی ایجاد نمیکنند. در دنیای امروز ذخیره سازی کارآمد کلان داده و تجزیه و تحلیل موثر آن، یک عامل کلیدی برای موفقیت در بسیاری از حوزههای کسب و کار است. به طور معمول در طی فرآیند تحلیل دادهها، بینشهای معناداری از دادههای جمع آوری شده استخراج میشود؛این بینشها میتوانند الگوهای مخفی، ارتباطات ناشناخته، ترندهای مارکت و ترجیحات مشتریان باشد.تحلیل کلان دادهها مزیتهای فراوانی دارد؛برای مثال میتواند برای کمک به روند تصمیم گیری، پیشگیری از اقدامات کلاهبردارانه و … استفاده شود.
صنایع و کسب و کارها می توانند در حوزههای زیر از مزیتهای تحلیل کلان دادهها استفاده کنند. این حوزه ها عبارتند از:
۱- مدیریت ریسک: Banco de Oro یک شرکت فیلیپینی در حوزهی بانکی است.این شرکت از تحلیل کلان دادهها برای تشخیص فعالیتهای کلاهبردارانه و ایجاد لیستی محدود از مظنونین یا دلایل اصلی ایجاد مشکلات استفاده میکند.
۲-توسعهیمحصولات و نوآوریها: رولز رویس یکی از بزرگترین تولید کنندگان موتورهای جت و تجهیزات نظامی در جهان، از تحلیل کلاندادهها برای بررسی میزان کارایی طراحی موتورها و نیاز آن ها به بهبود استفاده میکند.
۳-تصمیم گیری سریعتر و بهتر درون سازمانی :استارباکس از تحلیل کلاندادهها برای تصمیمهای استراتژیک درون سازمانیاش استفاده میکند.به عنوان مثال برای تصمیم گیری دربارهی اینکه آیا مکانی که در نظر دارد برای شعبهی جدید مناسب است یا خیر.آنها برای این تصمیم گیری، فاکتورهای مختلفی مانند جمعیت، جمعیت شناسی، دسترسی مکان و … را تحلیل میکنند.
۴-بهبود تجربهی کاربر:Delta Air Lines از تحلیل کلاندادهها برای بهبود تجربهی مشتریانش استفاده میکند.آنها توییتها را بازبینی میکنند تا از تجربهی سفر مشتریانشان، تاخیرها و … مطلع شوند. هواپیمایی آنها توییتهای منفی را مشخص میکنند و پس از آن پیگیریهای لازم را جهت رفع مشکلات مطرح شده انجام میدهند. مطرح کردن مشکلات به شکل عمومی و راهحلهای پیشنهادی به این هواپیمایی کمک میکند تا رابطهی خوبی با مشتریانش داشته باشد.
با توجه به موارد مطرح شده لزوم وجود ساختاری برای معماری سیستم های پردازش کلان داده مشخص می شود.
در این مقاله ابتدا به اهمیت معماری نرم افزار در سیستم های پردازش کلان داده، ویژگی های کیفی مورد نیاز در سیستم های پردازش کلان داده ها، بررسی مولفه های مشترک در ساختار معماری کلان داده ها و معرفی معماری های مطرح در این حوزه می پردازیم.
اغلب سیستمهای پردازش کلان داده از بخشهای مختلفی مانند استخراج اطلاعات(Data Extraction)، پیش پردازش(Pre Processing)، پردازش(Processing)، دریافت و ادغام(Ingestion & Integration)، تجزیه و تحلیل داده(Data Analysis) و اجزای مربوط به گزارشگیری و مصورسازی(Visualization) تشکیل شدهاند.سیستمهای پردازش کلاندادهها با توجه به کاربردهای خاصی که دارند، نیازمندیهای متفاوتی نیز دارند؛ برای مثال ممکن است یک سیستم پردازش کلان داده به عنوان پلتفرمی برای گوش دادن موسیقی(Spotify) و یا به عنوان شبکهی اجتماعی(twitter)به کار رود. با توجه به این موضوع،معماریهای نرم افزار گوناگونی برای این سیستمها نیاز است.
هر یک از سیستمهای پردازش داده کلان یک نرمافزار در حوزهی کامپیوتر محسوب میشوند؛بنابراین تمام ویژگیهای ذاتی نرم افزار و دغدغههای مربوط به آن در این سیستمها نیز وجود دارند.
برخی از دلایل اهمیت معماری نرم افزار در سیستم های پردازش کلان داده عبارتند از:
۱- تعیین کنندهی ویژگیها کیفی سیستم به صورت کمی با توجه به نیازمندیها
این که سامانهی پردازش کلاندادهی مورد نظربا توجه به محدودیتهای تجاری حوزهی تعریفش ، کارکردهای مورد نظر ذینفعان و نیازمندیها مطرح شده، باید چه ویژگیهای کیفی داشته باشد و میزان اهمیت کمی هرکدام، توسط معماری نرم افزارتعیین می شود.
۲- بررسی دلایل ایجاد تغییر در سیستم و مدیریت تغییرها
با توجه به ذات تغییر پذیر نرمافزار و با توجه به آمار می توان گفت که ۸۰ درصد هزینههای نرم افزارمربوط به پس از استقرار اولیهی نرمافزار است چرا که باگهای موجود در آن شناسایی میشود و نیازمندی های کاربران تغییر می کند.بنابراین در سیستمها پردازش کلاندادهها که سیستم های بسیار بزرگی محسوب میشوند،این تغییرات با نرخ سرعت خیلی بیشتری به دست توسعه دهندگان میرسد، به همین دلیل این سیستمها نیازمند معماری نرمافزار دقیقی هستند که این تغییرات را مدیریت کند تا تیم توسعه تغییرات مورد نیاز را ایجاد کند و نظم و دیسیپلین تیمها در ارائهی تغییرات ایجاد شده حفظ شود و رضایت مندی مشتریان افزایش پیدا کند.مثلا وجود CI/CD ،تعیین تست کیسها ، نوع معماری که در کل سامانه به کار میرود (به طور معمول مایکروسرویس) … تعیین کننده ی نحوهی مدیریت تغییرات است.
۳-برقراری ارتباط بهتر میان ذینفعان
تمامی ذینفعان سیستمهای پردازش کلان داده افراد فنی نیستند و دانش فنی کافی برای درک تمامی موضوعات مرتبط با توسعه ندارند.برای ارتباط مناسب میان تمامی ذینفعان با هر سطحی از دانش،وجود معماری یک الزام است چرا که زبان مشترک میان ذینفعان است وبنابراین افراد به خوبی میتوانند دربارهی آیندهی سیستم پردازش کلان داده با توجه به معماری مطرح شده تصمیم گیری کنند.
۴-تصمیماتی که خیلی زود باید دربارهی نرم افزار گرفته شوند.
هنگامی که تصمیم به ساخت یک سیستم پردازش کلان داده گرفته میشود، تصمیماتی وجود دارند که باید پیش از شروع توسعهی سیستم گرفته شوند تا سیستم برمبنای آنها ساخته شود؛ هریک از این تصمیمات باعث ایجاد محدودیتهایی در ادامهی کار میشود، بنابراین تصمیمات مهمی برای آیندهی سیستم هستند. برای مثال وابستگی سامانه به یک سیستم عامل، سخت افزارو یا نرم افزار خاص و تعیین زبان برنامه نویسی مورد نظر برای پیاده سازی سیستم وابسته به یک می تواند از جمله ی این تصمیمات مهم باشد.
۵-تعریف محدودیتهای پیاده سازی
عناصر موجود در سیستم باید طبق روشی از پیش تعیین شده با یکدیگر تعامل داشته باشند. بنابرای محدودیتهایی برای توسعهدهنده در پیاده سازی ایجاد میشود تا روشهای مورد نظر معماری پیاده شوند.
علاوه برموارد گفته شده معماری نرمافزار از ابعاد دیگری نیز برای نرمافزارها حائز اهمیت است.نرمافزار هرچه بزرگتر باشد نیاز آن به معماری بسیار بیشتر میشود چرا که با بزرگ شدن نرمافزار دغدغههای کیفی جدیتر و پیچیدهتری مطرح میشوند که باید مدیریت شوند و درصورتی که معماری جدی گرفته نشود هزینههای هنگفتی به وجود میآید که احتمالا قابل جبران نیستند و میتوانند منجر به شکست کامل پروژه ی نرمافزاری شوند.
با بررسی سیستمهای پردازش دادهی کلان به طور کلی با چند ویژگی کیفی مشترک رو به رو میشویم که معماری تمامی این سیستمها به دنبال تامین آنها هستند:
Scalability
این ویژگی کیفی به این معناست که سیستمهای پردازش کلان داده باید قابلیت پشتیبانی از مجموعههای بزرگی از داده را چه الان و چه در آینده داشته باشند؛همچنین تمام مولفه های این سیستمها با افزایش پیچیدگی دادهها باید گسترش پیدا کنند.مقیاس پذیری در واقع به توانایی حفظ کیفیت سرویسها توسط سیستمهای پردازش کلانداده وقتی که کاربران وحجم دادههاس دریافتی افزایش می یابد، اشاره دارد.برای داشتن یک جریان مداوم از کلان داده، سیستمهای پردازش،سیستمهای ذخیرهسازی و…سیستمهای پردازش کلان داده باید دادهها را به نحوی مقیاس پذیر مدیریت کنند.
Performance
این ویژگی به کارایی سیستم پردازش کلان داده میپردازد مانند زمان پاسخ.کارایی در واقع توانایی سیستمهای پردازش کلان داده برای فراهم کردن به موقع سرویسهااست به خصوص در سه زمینهی میانگین زمان پاسخ، تعداد تراکنشها در هر واحد زمانی و توانایی حفظ پردازش با نرخ سرعت بالا.
به خاطر حجم بالای دادهها، کارایی یک موضوع کلیدی در سیستمهای پردازش کلان دادهها است.دلیل اصلی تمرکز بر کارایی در این سیستمها را میتوان مدیریت کردن حجم عظیمی از داده با میزان محدودی از منابع دانست. اگر بخواهیم دقیقتر باشیم، کارایی پردازش در سیستمهای پردازش کلان داده با وجود حجم عظیمی از داده را میتوان نقطهی موفقیت این سیستم ها در نظر گرفت.
Availability
این ویژگی میزان در دسترس بودن سیستم پردازش کلان داده را در صورتی که خطایی رخ دهد بررسی میکند.دسترس پذیری به معنای توانایی سیستمهای پردازش کلان داده برای اجرای یک Function تحت شرایط مشخصی است.رشد سریع دادهها، دسترس پذیری را به یک ویژگی کیفی واجب برای سیستمهای پردازش کلان داده مبدل کرده است چرا که باید جریان و حجم تاثیر گذاری از داده ها با تنوع بالا را مدیریت کنند؛بنابراین پردازش این عملیات ممکن است مشکلات فراوانی را به وجود بیاورد.
Reliability
این ویژگی میزان دوام سیستمهای پردازش کلان داده را زمانی که Functionality موردنظر در یک بازهی زمانی خاص و تحت شرایط خاصی اجرا میشود، اندازه میگیرد.قابلیت اطمینان در واقع به توانایی سیستمهای پردازش کلان داده برای اعمال Function های مشخص شده در شرایط مشخص شده و در مدت زمان مشخص شده اشاره دارد. مشکلات قابلیت اطمینان معمولا به خاطراستثناهای غیرمنتظره در طراحی و نقصهای موجود در کد که شناسایی نشدهاند؛ ایجاد میشوند.
Correctness
این ویژگی کیفی برای اندازهگیری میزان صحت سیستمهای پردازش کلان داده استفاده میشود.صحت، این احتمال را می سنجد که برنامه های کلان داده می توانند کارها را درست انجام دهند. در صورتی که سیستم پردازش کلان داده نتواند صحت را ضمانت کند، در آن صورت این سیستم فاقد ارزش است.برای مثال یک سیستم پیشبینی هوا که همیشه وضعیت آب و هوا را به اشتباه نشان میدهد قطعا به هیچ دردی نمیخورد. بنابراین میتوان گفت صحت اولین ویژگی کیفی است که باید در سیستمهای پردازش کلان داده در نظر گرفته شود.در صورتی که سیستم پردازش کلان داده به شکل نادرستی کار کنند، میتوانند باعث ناراحتی و یا حتی از دست رفتن کاربران شود.
تمامی معماریهای موجود برای نرمافزارهای پردازش داده حجیم با توجه به نیازهایی که برای آن طراحی شدهاند میتوانند شامل بخشهای زیر باشند:
۱- منابع داده:تمامی راهحلهای مرتبط با کلان داده شامل یک یا چندین منبع داده هستند؛مانند:منابع دادهی برنامههای کاربردی مثل پایگاه دادههای رابطهای،فایلهای استاتیک که توسط برنامههای کاربردی تولید میشوند مثل فایلهای لاگ و منابع داده بلادرنگ مثل دستگاههای IOT
۲- ذخیره سازی داده:دادهها برای عملیات پردازش دستهای در یک مخزن فایل توزیع شده که حجم بالایی از دادهها با هر فرمتی را میتواند ذخیره کند،ذخیره میشوند.
۳- پردازش دسته ای:از آنجایی که مجموعه ی دادهها حجیم هستند،هر راهحلی که برای کلان دادهها وجود دارد بخشی را برای پردازش فایلهای داده با استفاده از کارهای دستهای طولانی مدت (long-running batch jobs) درنظر میگیرند تا دادهها فیلتر،تجمیع و در نهایت برای تحلیل آماده شوند.معمولا این کارهای دستهای شامل خواندن فایل های منبع،پردازش آن ها و نوشتن خروجی در فایلهای جدید است.
۴- دریافت پیام بلادرنگ: درصورتی که منابع بلادرنگ دریافت داده داشته باشیم در این صورت معماری باید راهی برای دریافت و ذخیرهی پیامهای بلادرنگ جهت پردازش جریانی(Stream Processing) داشته باشد.ممکن است ازیک مخرن دادهی ساده استفاده کنیم تا پیامهای ورودی برای پردازش درون یک فولدر گذاشته شوند.البته ناگفته نماند که بسیاری از معماریها به یک مخزن دریافت پیام احتیاج دارند تا بتوانند از آن به عنوان بافر استفاده کنند.
۵- ذخیره سازی دادههای تحلیلی: بسیاری از معماریها،داده ها را برای تحلیل آماده میکنند و دادههای پردازش شده را در یک فرمت ساختارمند ارائه میکنند تا ابزارهای تحلیل بتوانند برای query از آنها استفاده کنند.
۶- تحلیل و گزارش: هدف اکثر نرمافزارهای کلان داده ایجاد کردن یک بینش از طریق تحلیل و گزارش دادههای دریافتی است.برای اینکه کاربر توانایی تحلیل دادهها را داشته باشد،معماری میتواند شامل یک لایهی مدلسازی داده مانند مکعب چند بعدی OLAP باشد.
۷- همنواسازی:مدیریت اعمال تکراری در پردازش و جریانهای کاری موجود و همنواسازی کانتینرهای موجود در سیستم پردازش کلان داده.
تولید انبوه داده ها در دنیای امروز و نیاز به پایش لحظه ای اطلاعات و ذخیره ی آن ها برای انجام تحلیل های بعدی، ما را به ساختاری هدایت می کند که بتواند این نیازمندی ها یعنی پردازش جریان های داده به صورت لحظه ای و بدون تاخیر و پردازش های انبوه و زمان مند را پاسخگو باشد. البته پردازش کاملا بلادرنگ و بدون تاخیر در سامانه های توزیع شده ی امروزی غیر قابل دستیابی است و هدف بیشتر این است که با کمترین تاخیر ممکن و نه لزوما بدون هیچ تاخیری به پردازش داده ها و استخراج اطلاعات مورد نیاز بپردازیم. در واقع یکی از مهمترین چالش هایی که کسب و کارهای داده محور با آن دست و پنجه نرم می کنند، عدم داشتن استراتژی صحیح به منظور پیاده سازی معماری فضای مدیریت داده در سازمان های مقیاس وسیع تلقی می شود. معماری لامبدا با همین پیش زمینه توسط Nathan Marz از متخصصین داده شرکت توییتر پیشنهاد شده است.
معماری Lambda از سه لایه مختلف تشکیل شده است:
لایه ی Batch: این لایه وظیفه ی مدیریت مجموعه داده اصلی را بر عهده دارد. داده ها در مجموعه ی داده ی اصلی خام و تغییر ناپذیر هستند. حتی اگر تمام مجموعه داده های لایه ی speed و serving از دست برود، می توانیم داده ها را از این مجموعه داده ی اصلی که در این لایه است، بازیابی کنیم. همچنین در این لایه مجموعه ی داده ها به شکل batch view نگهداری می شوند تا با سرعت بیشتری بتوان به پرس و جوها پاسخ داد.
همچنین از آنجایی که مجموعه ی داده ها دائما در حال رشد است، ما باید یک استراتژی برای مدیریت نماهای دسته ای (batch view) در هنگام اضافه شدن داده های جدید به سیستم داشته باشیم. این کار به دو صورت انجام می شود:
۱- الگوریتم های محاسبه مجدد (Re-Computation algorithms): حذف batch view های قدیمی و محاسبه ی مجدد توابع در کل مجموعه داده اصلی
۲- الگوریتم های افزایشی (Incremental algorithms):به روز رسانی مستقیم view ها هنگام ورود داده های جدید
به طور کلی می توان گفت در این لایه بسته به نیاز کاربر به صورت موردی و یا در زمان های مشخص اقدام به پردازش انبوه داده های ذخیره شده می شود و نتایج مورد نیاز کاربر تولید می شود. تکنولوژی هایی مثل Hadoop و Hive در این لایه مورد استفاده قرار می گیرند که قابلیت مقیاس پذیری افقی را نیز دارد مثل استخراج آمار روزانه خرید یک دوره آموزشی
لایه ی Speed: این لایه batch view ها را برای کوئری های موقت و سریع، ایندکس گذاری می کند. Real time view ها را ذخیره می کند و جریان داده های دریافتی را پردازش می کند تا این نماها را به روز کند. از آنجایی که تاخیری بین زمان ورود داده های جدید به سیستم و زمان لازم برای اینکه ممکن باشد روی آن ها کوئری بزنیم، وجود دارد (به دلیل زمان لازم برای ایجاد batch view از داده های جدید) این موضوع به لایه ی speed بستگی دارد که این gap را کوتاه کند. این لایه با داده های real time در ارتباط است و سربار محاسباتی کمتری دارد.
به طور کلی این لایه مجموعه پردازش های مبتنی بر یادگیری ماشین یا تحلیل های لحظه ای را پشتیبانی می کند. مثال: محاسبه ی آمار لحظه ای یک وب سایت، پیشنهاد در لحظه یک محتوای مرتبط با پست آموزشی به کاربر بر اساس سوابق مطالعاتی او
لایه ی Service: این لایه دسترسی به نتایج محاسبات انجام شده روی داده های اصلی را با تاخیر کم فراهم می کند. این لایه می تواند دیتاها را به منظور برطرف کردن اشکالات کد نویسی reindex کند. یا برای use case های مختلف، ایندکس های مختلف ایجاد کند. نیاز کلیدی در این لایه این است که پردازش به شکل گسترده ای موازی انجام شود تا زمان لازم برای ایندکس گذاری در مجموعه داده به حداقل برسد. همچنین این لایه با دو لایه ی قبلی در ارتباط است. ارتباط با ابزارهای هوش تجاری مانند Power BI در این لایه صورت می گیرد. داده هایی که در دو لایه Batch و Speed قبلا ذخیره شده اند، توسط سرویس هایی که در این لایه ایجاد می شوند، در اختیار کاربران مختلف که هرکدام قالب و شکل خاصی از داده ها و گزارشات را نیاز دارند قرار می گیرد.
مزایای استفاده از این معماری به شرح زیر است:
۱- تحمل خطا (Fault Tolerance): این معماری قابلیت تحمل خطای انسانی را فراهم می کند زیرا در صورت مرتکب شدن اشتباه، می توانیم الگوریتم ها را دوباره اجرا کرده و view ها را اصلاح کنیم.
۲- کوئری های ad hoc: لایه ی batch امکان پرس و جوهای ad hoc را فراهم می کند.
۳- مقیاس پذیری: همه ی لایه های batch، speed و service به راحتی مقیاس پذیر هستند.
۴- توسعه پذیری: افزودن view های جدید به مجموعه داده ها آسان است.
۵- سازگاری داده ها: یکی از ویژگی های اصلی معماری لامبدا این است که ریسک ناهماهنگی داده ها که در اغلب سیستم های توزیع شده وجود دارد را از بین می برد. در یک پایگاه داده توزیع شده احتمال خرابی داده ها و وجود دیتای ناسازگار وجود دارد. در واقع ممکن است یک کپی از داده ها به روز شده باشد اما کپی دیگر مقدار قبلی را داشته باشد. در معماری لامبدا از انجایی که داده ها به صورت متوالی پردازش می شوند، در فرایند indexing می توان مطمئن بود که آخرین وضعیت داده ها از لایه های batch و speed دریافت شده است.
همچنین استفاده از این معماری در سازمان منجر به چابکی کسب وکار به دلیل پاسخ در لحظه نسبت به سناریوهای سازمان می شود.
از چالش های این معماری می توان به موارد زیر اشاره کرد:
۱- به دلیل وجود لایه های مختلف و نیاز به مدیریت این لایه ها پیچیدگی داریم که همین موضوع خطایابی را دشوار می کند.
۲- نگهداری و پشتیبانی این معماری به دلیل وجود لایه های متمایز و توزیع شده ی batch و speed سخت تر است.
۳- استفاده از این معماری برای فناوری های متن باز می تواند دشوار باشد و اگر بخواهد در فضای ابری پیاده سازی شود، مشکل بیشتر می شود.
چالشهای معماری لامبدا باعث شد تا معماری دیگری به نام کاپا مطرح شود که در آن لایهی Batch عملا حذف میشود. در این معماری برای سادهترشدن مدیریت سامانه و عدم نیاز به دو بخش جداگانه پردازشی، تمام پردازشها در لایهی سریع انجام میگیرد و هر کاری که قرار است روی دادهی ورودی انجام شود، به صورت لحظهای و بلادرنگ صورت خواهد پذیرفت.
اگر در آینده و به خاطر تغییر در منطق سازمانی و قوانین، نیاز به پردازش جدیدی روی دادهها باشد، این کار به صورت جداگانه و موردی انجام خواهد شد. در این معماری دادهها در یک گذرگاه پیامرسانی (messaging bus) مانند کافکا ذخیره می شوند. یک موتور پردازش جریانی (stream processing engine) مانند Apache Spark، Apache Flink و غیره دادهها را از سیستم messaging میخواند و پردازشهای لازم مانند transformation را روی آنها انجام میدهد و سپس آنها را به سیستم پیامرسانی منتشرمیکند و برای تجزیه و تحلیل بلادرنگ (real time) در دسترس قرار میدهد.
معماری کاپا بر چهار اصل استوار است:
۱- هرچیزی، یک جریان است: با این اصل پردازش انبوه هم جزئی از سامانهی پردازش جریان قرار می گیرد با این تفاوت که دادههای غیر لحظهای جریانهای موردی تولید خواهند کرد که نیاز به پردازش دارد.
۲- تمام دادهها به صورت پایدار ذخیره میشوند: این اصل تضمین میکند که دادهای از دست نمیرود و میتوان در صورت نیاز، تمام محاسبات را از ابتدا روی دادهها انجام داد.
۳- تنها یک چارچوب برای پردازش مورد نیاز است: با توجه به اصل ساده سازی امور (Keep it Simple, Stupid)، در این معماری تنها یک سامانهی پردازشی خواهیم داشت که مدیریت و توسعهی آن بسیار سادهتر است.
۴- تکرار پذیری عملیات پردازش داده: محاسبات و نتایج می توانند با ورود دادههای جدید و ترکیب آنها با دادههای قبلی به روز شود.
بنابراین این معماری بیشتر برای کاربردهایی مناسب است که منطق سازمانی حاکم بر آنها کاملا مشخص و بدون تغییر است. مثلا برای بررسی و پردازش خطاهای نرم افزار، پایش شبکههای اجتماعی و همچنین پایش وضعیت سروها میتوان از این معماری استفاده کرد چون غالب تصمیمات باید در لحظه گرفته شود و آمار مورد نیاز هم در همان حین دریافت اطلاعات قابل استخراج و ذخیره سازی است. در واقع این معماری محدودیت بیشتری دارد و شکل خلاصه شدهی معماری لامبدا است.
این معماری چند مزیت دارد که عبارتند از :
۱- با استفاده از یک معماری واحد می توانیم هم پردازش جریانی (streaming) و هم دسته ای(batch) انجام دهیم.
۲- با تضمین درستی ترتیب دادهها کیفیت دادهها را بهبود میبخشد.
۳- برای موارد کاربرد جدید نیاز به معماری جدید نخواهیم داشت.
۴- برای انجام پردازشهای machine learning در این معماری نیاز به منابع کمتری داریم.
یکی از معایب این معماری این است که ممکن است در هنگام پردازش داده یا به روزرسانی پایگاه داده به دلیل عدم وجود لایهی batch خطا رخ دهد.
۱- گزارش دهی و داشبورد بلادرنگ (real time reporting and dashboarding): این نیاز عمدتا در تولید و به عنوان مثال صنعت نفت و گاز مشاهده میشود که در آن نیاز به روز رسانی وضعیت دستگاههای خط مونتاژ برای گزارش دهی بلادرنگ وجود دارد.
۲- پردازش قوانین و هشدار دهی بلادرنگ (real time rules processing and alerting): کاربرد این مورد در تجارت الکترونیک و مخابرات دیده میشود. در واقع در جاهایی که نیاز به اجرای قوانین پیچیده ی پردازش رویدادها در جریانهای دادههای سامانه های خرید آنلاین وجود دارد.
۳- عملیاتی کردن مدلهای بلادرنگ یادگیری ماشین: این امر در صنعت خدمات مالی استفاده میشود که در آن مدلهای ML برای شناسایی تقلب بر روی دادههای تراکنش و شناسایی تراکنشهای تقلبی و هشدار به مشتری به کار گرفته میشوند.
نتفلیکس سالهاست که یکی از بهترین سرویسهای پخش ویدئو مبتنی بر اشتراک آنلاین در جهان است و بیش از ۱۵ درصد از ظرفیت پهنای باند جهان را به خود اختصاص داده است. طبق آمارهای ارائه شده در سال ۲۰۱۹ نتفلیکس بیش از ۱۶۷ میلیون مشترک داشتهاست که در هر سه ماهه پنج میلیون مشترک جدید نیز اضافه می شده است. مشترکین نتفلیکس بیش از ۱۶۵ میلیون ساعت را صرف تماشای فیلم در روز میکنند. این آمار چشمگیر به ما نشان میدهد که که تیمهای فنی نتفلیکس چنین سیستم پخش ویدئویی شگفت انگیزی را با availabilty و scalability بالا طراحی کردهاند تا به مشتریان خود در سطح جهانی خدمات ارائه کنند.
معماری نتفلیکس به شرح زیر است:
نتفلیکس از AWS cloud برای نگه داری زیر ساختهای فناوی اطلاعات خود استفاده میکند. نتفلیکس با استفاده از این فضای ابری، مقیاس پذیری و در دسترس بودن خود را به طور قابل توجهی افزایش داده است. همچنین این شرکت برای پیاده سازی سیستم خود از الگوی Microservice بهره میبرد که این مساله باعث شده هر سرویسی قابل تغییر، استقرار سریع و ردیابی راحتتر مشکلات باشد.
از نظر معماری، نتفلیکس شامل سه بخش اصلی Client،Backend و Content Delivery Network است.
Client هر مرورگر پشتیبانی شده در لپ تاپ، گوشی هوشمند یا اپلیکیشن نتفلیکس در تلویزیونهای هوشمند است. اپلیکیشن مربوط به کلاینت دو نوع ارتباط با backend برقرار می کند. یک ارتباط مربوط به کشف محتوا و دیگری مربوط به موارد مربوط به امنیت است. همچنین در حین پخش ویدئها اپلیکیشن مربوط به کلاینت به طور هوشمند کیفیت را کاهش میدهد یا در صورت لزوم به سروهای دیگری سوییچ میکند.
Backend شامل سرویسهای داده، پایگاه داده و … است. Backend از بخشهایی مانند فضای ذخیرهسازی مقیاس پذیر (AWS S3)، میکروسرویسهای مربوط به منطق کسب و کار (Business logic)، پایگاه دادههای توزیع شدهی مقیاس پذیر( مانند AWS DynamoDB و Cassandra)، ابزارها و تکنولوژیهای مربوط به پردازش و تحلیل کلان دادهها (مانند AWS EMR Spark، Flink، Kafka، Hadoop و سایر ابزارهای ساخته شده توسط خود نتفلیکس برای این هدف) و پردازش و رمز گذاری ویدئوها اشاره کرد.
به طور خاصتر به بررسی مولفه های موجود در بکند می پردازیم:
۱- API Gateway Service: یکی از سرویسهایی که در backend وجود دارد، API Gateway است. این مولفه با AWS Load Balancer برای پاسخگویی به تمام درخواستهای کاربران ارتباط برقرار میکند.
۲- Application API: این مولفه نقش یک لایه همنواساز (orchestration) را برای میکروسرویسهای Netfliix ایفا می کند. Application API با عملکردهای اصلی کسب و کار Netflix در ارتباط است و باید مقیاس پذیر باشد و در حجم درخواست بسیار بالا در دسترس باشد. در حال حاضر، APIهای برنامه به سه دسته تقسیم می شود: Signup API برای درخواستهای مانند ثبت نام و تست رایگان و غیره، Discovery API برای جستجو و Play API برای پخش.
۳- میکرو سرویس: هر میکرو سرویس در این سامانه می تواند data store مخصوص به خود را داشته باشد و نتایج حاصل از اجرا را در کش ذخیره کند. EVCache یک انتخاب اصلی برای کش کردن نتایج میکرو سرویسها در نتفلیکس است.
۴- Data Stores: اگر بخواهیم به طور خاصتر در مورد ذخیرهسازی دیتا در نتفلیکس صحبت کنیم، نتفلیکس از هر دو نوع SQL و NoSQL برای اهداف مختلف استفاده کرده است. از MySQL برای ذخیرهی عناوین فیلمها و همچنین صورتحساب تراکنشهای مالی، از Hadoop برای پردازش کلان دادهها، از Elastic Search برای جستجوی عناوین فیلمها و از Cassandra که یک پایگاه دادهی توزیع شدهی NoSQL است، برای پاسخگویی به حجم زیاد درخواست ها استفاده می شود.
۵- Stream Processing Pipeline: این pipeline بخش اصلی این سیستم برای تجزیه و تحلیل کسب و کار را تشکیل می دهد. مسئولیت تولید، جمع آوری، پردازش، تجمیع و انتقال همهی رویدادهای میکروسرویسها را به پردازشگرهای داده در زمانی نزدیک به real time بر عهده دارد. پلتفرم Stream processing روزانه تریلیونها رویداد و چندین پتابایت داده را پردازش میکند. علاوه بر این با افزایش تعداد کاربران، این پلتفرم به طور خودکار scale می شود.
در این سیستم از Open Connect به عنوان CDN استفاده شده است که مسئول ذخیره و ارائه ی فیلم ها به مشترکان خود در سراسر جهان است. نتفلیکس Open Connect را به طور کارامدی با نزدیک کردن محتوایی که مردم می خواهند تماشا کنند به جایی که میخواهند تماشا کنند، ساخته و عملیاتی کرده است.
امروزه سیستمهای پردازش کلان داده بخش قابل توجهی از صنعت نرمافزار را تشکیل میدهند. این سیستمها سود قابل توجهی را میتوانند برای ذینفعانشان تولید کنند؛اما این سود به راحتی به دست نمیآید.نرمافزارخود ذاتا موجودیتی پیچیده است که مدیریت آن نیازمند دانش قابل توجهی است حال که با گذشت زمان ،این صنعت روز به روز بیشتر به سمت سیستمهای پردازش کلان داده میرود اهمیت معماری نیز برای تولید نرمافزاری با کارایی بالا که رضایتمندی مشتریان را به همراه داشته باشد، به شکل روز افزونی بیشتر میشود.در این مقاله دلایل اهمیت معماری را به طور کلی بررسی کردیم و معماریهای مشهوری که در این حوزه برای تامین ویژگیهای کیفی مورد نیاز وجود دارند، بررسی کردیم و در نهایت معماری به کار رفته در نتفلیکس را به عنوان یکی از معماریهای برتر حوزهی سیستمهای پردازش کلان داده شرح دادیم.
«این مطلب، بخشی از تمرینهای درس معماری نرمافزار در دانشگاه شهیدبهشتی است»
تهیه و تدوین این مطلب با همکاری دوست عزیز خانم زیبا امیدوار انجام شده است .
مراجع
[1] I. Samizadeh, "A brief introduction to two data processing architectures - Lambda and Kappa for Big Data", Towards Data Science, 2020. [Online]. Available: https://towardsdatascience.com/a-brief-introduction-to-two-data-processing-architectures-lambda-and-kappa-for-big-data-4f35c28005bbd. [Accessed: 20- Dec- 2021]. (1)
[2] C. Nguyen, "A Design Analysis of Cloud-based Microservices Architecture at Netflix", Medium, 2020. [Online]. Available: https://medium.com/swlh/a-design-analysis-of-cloud-based-microservices-architecture-at-netflix-98836b2da45f. [Accessed: 25- Dec- 2021]. (2)
[3] D. Vaz, "When and How to Leverage Lambda Architecture in Big Data - Cuelogic Technologies Pvt. Ltd.", Cuelogic Technologies Pvt. Ltd., 2020. [Online]. Available: https://www.cuelogic.com/blog/lambda-architecture-in-big-data. [Accessed: 11- Jan- 2022]. (3)
[4] V. BELUR, "Kappa Architecture – Easy Adoption with Informatica End-to-End Streaming Data Management Solution", Informatica, 2020. [Online]. Available: https://www.informatica.com/blogs/adopt-a-kappa-architecture-for-streaming-and-ingesting-data.html. [Accessed: 20- Dec- 2021]. (4)
[5] Feick M, Kleer N, Kohn M. Fundamentals of real-time data processing architectures lambda and kappa. SKILL 2018-Studierendenkonferenz Informatik. 2018. (5)
[6] Avci C, Tekinerdogan B, Athanasiadis IN. Software architectures for big data: a systematic literature review. Big Data Analytics. 2020. (6)
[7] Ji S, Li Q, Cao W, Zhang P, Muccini H. Quality Assurance Technologies of Big Data Applications: A Systematic Literature Review. Applied Sciences. 2020. (7)
[8] Zhang P, Zhou X, Li W, Gao J, editors. A survey on quality assurance techniques for big data applications. 2017 IEEE Third International Conference on Big Data Computing Service and Applications (BigDataService); 2017. (8)
[9] Folberth, J., Buck, A., Harvey, B. and Price, E., 2021. Big data architectures - Azure Architecture Center. [online] Docs.microsoft.com. Available at: https://docs.microsoft.com/en-us/azure/architecture/data-guide/big-data/<br/>[Accessed 30 December 2021].
[10]E. Price, A. Buck, D. Kshirsagar and T. Petersen, "Batch processing - Azure Architecture Center", Docs.microsoft.com, 2021. [Online]. Available at: https://docs.microsoft.com/en-us/azure/architecture/data-guide/big-data/batch-processing. [Accessed: 30- Dec- 2021].
[11]"What is Big Data Analytics and Why It is Important?", https://www.simplilearn.com/, 2022. [Online]. Available: https://www.simplilearn.com/what-is-big-data-analytics-article. [Accessed: 08- Jan- 2022].
[12]L. Bass, P. Clements and R. Kazman, Software Architecture in Practice, 4th ed. 2021.