آشنایی با معماری‌های داده در طراحی سامانه‌های جریان‌پرداز

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

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

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

قبل از بررسی پروژه­‌های متن‌­بازی که برای پردازش جریان طراحی شده‌­اند، باید معماری­‌های کلان پیشنهادی برای سامانه­‌های نوین اطلاعاتی را بررسی کنیم و در طراحی نهایی بر اساس اصول این معماری‌­ها حرکت کنیم.

منظور از معماری، مولفه‌­های اصلی تشکیل دهنده یک سامانه اطلاعاتی و نحوه ارتباط و کارکرد هریک از آنهاست.

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

معماری لامبدا

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

البته پردازش کاملاً بلادرنگ و بدون تأخیر در سامانه­‌های توزیع شده امروزی تقریباً غیرقابل دستیابی است و ما بیشتر به دنبال سیستم­هایی هستیم که با کمترین تأخیر ممکن، به پردازش داده‌­ها و استخراج اطلاعات مورد نیاز بپردازد.

معماری لامبدا دقیقاً با همین پیش­‌زمینه توسط Nathan Marz از متخصصین داده شرکت توئیتر پیشنهاد شد. شکل ۲ ساختار این معماری سه لایه را نشان می­دهد.

سه لایه اصلی پردازشی  تشکیل دهنده این معماری رایج عبارتند از :

• لایه پردازش زمان­مند(یا پردازش انبوه – Batch Layer) که بسته به نیاز کاربربه صورت موردی ویا در زمان های مشخص اقدام به پردازش انبوه داده­ های ذخیره شده کرده و نتایج مورد نظر کاربر را تولید می­کند. استخراج آمار روزانه خرید و فروش یا اجرای یک جستجوی خاص بر روی داده­ ها از جمله موارد کاربرد این لایه است.
• لایه پردازش سریع (Speed Layer) : تمام پردازش ­هایی که باید به صورت لحظه­ ای روی داده ­ها صورت بگیرند، در این لایه پیاده سازی می­شوند. محاسبه آمار لحظه ­ای یک سایت، پیشنهاد سریع یک مطلب جدید به کاربر بر اساس سابقه و سلایق او، بررسی خطاهای رخداده در سرورها و اتخاذ تصمیم مناسب از جمله مثال­هایی است که می­توان برای کاربردهای لایه پردازش سریع زد.
•  لایه کاربست و کاربرد (Serving Layer) :   این لایه، وظیفه سرویس دهی به کاربر، اجرای پرس و جوهای مختلف (کوئری) و آماده ­سازی داده در شکل­ های مورد نیاز او را برعهده دارد. داده ­هایی که در دولایه پردازش سریع و پردازش زمان­مند قبلاً ذخیره شده­ اند، توسط سرویس­هایی که در این لایه ایجاد می­شوند، در اختیار کاربران مختلف که هرکدام قالب و شکل خاصی از داده­ ها و گزارشات را نیاز دارند، قرار می­گیرد.

این سه لایه، حداقل نیازمندی هایی است که یک سامانه پردازش اطلاعات باید داشته باشد. در ادامه سایر مولفه هایی که می­تواند باعث بهبود این این چارچوب و تطبیق بیشتر آن با دنیای معاصر باشد را معرفی خواهیم کرد.

معماری کاپا

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

اگر در آینده و بخاطر تغییر در منطق سازمانی و قوانین، نیاز به پردازش جدیدی روی داده ­ها باشد، این کار به صورت جداگانه و موردی انجام خواهد شد.

برای نیل به این هدف، معماری Kappa بر چهار اصل استوار است  :

1. هرچیزی، یک جریان است: با این اصل، پردازش زمان­مند و انبوه هم جزئی از سامانه پردازش جریان قرار می­گیرد با این تفاوت که داده ­های زمان­مند و غیر لحظه­ ای، جریان ­های موردی تولید خواهند کرد که نیاز به پردازش دارد.
2. تمام داده ­ها به صورت پایدار ذخیره می­شوند: این اصل، تضمین می­کند که داده­ ای از دست نمی­رود و می توان در صورت نیاز، تمام محاسبات را از ابتدا بر روی داده­ ها انجام داد.
3. تنها یک چارچوب برای پردازش مورد نیاز است: با توجه به اصل ساده‌­سازی امور (KISS)، در این معماری تنها یک سامانه پردازشی خواهیم داشت که مدیریت و توسعه آن بسیار ساده تر است.
4. تکرارپذیری عملیات پردازش داده : محاسبات و نتایج می­تواند با ورود داده­‌های جدید و ترکیب آنها با داده‌های قبلی، به‌­روز شود.

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

توسعه معماری لامبدا

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

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

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

بخش مهم دیگری که در ساخت یک سامانه اطلاعاتی توزیع شده به آن نیازمندیم، لایه پیام رسانی است. (Messaging Layer).  برای ایجاد یک خط تولید که بتواند به صورت توزیع شده در تمام شبکه به کار بپردازد و بتوان به راحتی سیستم را به صورت افقی گسترش داد، راه­‌حلی که سالهاست به یک استاندارد در توسعه سامانه‌­های توزیع­‌شده تبدیل شده است، سامانه‌­های پیام رسان مانند Kafka, RabbitMQ  و ZeroMQ هستند که وظیفه آنها دریافت یک رخداد و تحویل آن به یکی از پردازه‌های بیکار در شبکه برای پردازش است. به این سامانه­‌های پیام­‌رسان، صف­های توزیع شده هم می­گوییم. آپاچی پولسار جزء جدیدترین پروژه های آپاچی در این حوزه است.

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

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

دریاچه داده : لایه نوین ذخیره سازی داده­‌ها

در تمامی معماری­های اطلاعاتی، یک لایه مهم و حیاتی وجود دارد با نام لایه ذخیره داده‌­ها که وظیفه ذخیره و بازیابی اطلاعات را برعهده دارد. اگر بخواهیم بسته به کاربرد، مدل داده­‌ای برای این لایه پیشنهاد کنیم معمولاً یا به قالب­‌های رایج ذخیره اطلاعات در کلان‌­داده مانند HDFS, Parquet, ORC, Carbon Data و Kudu و یا به بانک­های اطلاعاتی NewSQL‌ و NoSQL‌ مانند کاساندرا، الاستیک سرچ، مانگو دی بی، پستگرس، اس کیو ال سرور و اوراکل می­رسیم.

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

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

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

می توانیم طبق تعریف دائره المعارف تخصصی techopedia دریاچه داده را اینگونه تعریف کنیم :

«یک مخزن متمرکز، قابل دسترسی سریع و حجیم  شامل تمامی داده­‌های ساخیافته و بدون ساختار یک سازمان»

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

البته نکته مهمی که درباره دریاچه داده مطرح است عدم تبدیل آن به یک باتلاق داده است (ر. ک. مقاله دریاچه داده: فرصتی برای کشف بینش و خلق ارزش) یعنی به قدری در ذخیره خام داده­‌های یک سازمان تاکید کنیم که استفاده از آن تحت الشعاع قرار گیرد و درگیر مسائلی مانند فضای ذخیره سازی و مدیریت فراداده‌­ها شویم بدون اینکه استفاده خاصی از خود داده­‌ها به عمل آوریم .