گذشته، حال و آینده معماری داده

معماری داده در تبدیل شدن به یک سازمان داده‌ محور نقش مهمی را ایفا می‌کند؛ به‌ طوریکه یکی از اهداف استراتژیک اصلی بسیاری از شرکت‌ها، پیاده‌سازی Data Architecture است. فرهنگ داده‌ محور به‌ معنای قرار دادن داده‌ ها در مرکز تمامی تصمیمات و فرآیند های سازمانی است؛ اما چگونه مطمئن باشیم که پیاده‌ سازی و اجرای معماری داده راهی امن و سود آور است؟ جواب این سوال در بررسی گذشته، حال و آینده معماری داده نهفته است که در این مقاله، به‌طور کامل به آنها می‌پردازیم.

چرا معماری داده مهم است؟

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

پلتفرم‌ های داده‌ای، بستری برای مستقر کردن Data Architecture است. به‌ عبارتی دیگر، پلتفرم داده مخزن و خانه پردازشی برای تمام داده‌ های سازمان است. جمع‌ آوری، پاک‌ سازی، تغییر شکل و کاربرد داده‌ها با این پلتفرم‌ ها به بینش‌ های تجاری تبدیل می‌شوند. 

هدف اصلی یک Data Architecture با طراحی خوب، کاهش سیلو های داده (Data Silos)، به‌حداقل رساندن تکراری بودن داده‌ ها و بهبود کارایی کلی فرآیند مدیریت آنها است.

گذشته معماری داده

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

» نسل اول: معماری انبار داده

معماری انبار داده (Data Warehouse Architecture) با حرکت داده‌ها از سیستم‌ های عملیاتی (SAP، Salesforce) و پایگاه‌ های داده شخص اول (My SQL، SQL Server) به سیستم‌ های هوش تجاری تعریف می‌شود. انبار داده نقطه مرکزی داده‌ها است که در آن یک طرح (Schema) تعریف می‌شود (اسکیمای دانه‌ های برف، اسکیمای ستاره‌ای). سپس در این انبار، داده‌ها در ابعاد و جداول Fact ذخیره می‌شوند. تا به کسب‌ و کارها اجازه ردیابی و دنبال کردن تغییرات در عملیات و تعاملات خود با مشتری را دهد. داده‌ها در این نسل عبارتند از:

• استخراج‌ شده از پایگاه‌‌ های داده‌‌ای عملیاتی و منابع زیاد.
• تبدیل به یک اسکیمای جهانی و قابل‌ نمایش در قالب جداول چند بعدی و متغیر زمانی.
• بارگیری از طریق فرآیند CDC (Change Data Capture) در جداول انبار.
• قابل‌ دسترسی از طریق کوئری‌های شبه SQL.
• عمده استفاده توسط تحلیل‌ گران داده با هدف گزارش‌ گیری و استفاده از مصور سازی تحلیلی.

در این سبک معماری، دیتا مارت‌ ها (Data Marts) وارد عمل می‌شوند. آنها یک لایه اضافی (متشکل از یک یا چند جدول) در بالای انبار داده هستند. تا به مشکلات تجاری بخش خاصی، با یک قالب خاص اسکیما پاسخ دهند. بدون داده‌ها، این دپارتمان‌ ها باید چند کوئری را در انبار کاوش و ایجاد کنند. تا داده‌ها را با محتوا و قالب مورد نیاز خود داشته باشند.

»» چالش‌های اصلی این رویکرد

• با گذشت زمان، هزاران شغل، جدول و گزارش ETL ساخته می‌شوند که فقط یک گروه از افراد متخصص می‌توانند آنها را بفهمند و حفظ کنند.
• شیوه‌ های مهندسی مدرن مانند CI/CD روی این نسل اعمال نمی‌شوند.
• مدل داده و طراحی اسکیما برای انبار های داده بسیار سفت‌ و سخت و خشک است؛ بنابراین نمی‌تواند حجم عظیمی از داده‌ های ساختار یافته و بدون ساختار را از منابع متعدد مدیریت کند. ضعف‌ های این نسل، ما را به نسل بعدی معماری داده، یعنی دریاچه داده هدایت کرد.

» نسل دوم: معماری دریاچه داده

معماری دریاچه داده (Data Lake Architecture) در سال ۲۰۱۰ در پاسخ به چالش‌ ها و ضعف‌ های معماری Data Warehouse ایجاد شد تا در برآورده کردن کاربرد های جدید داده‌ ها خوش بدرخشد. دسترسی به داده‌ها توسط دانشمندان داده (Data Scientists) در فرآیند آموزش مدل یادگیری ماشین، یکی از معروف‌ ترین سناریو های این معماری کامپیوتر است. دانشمندان داده برای فرآیند آموزش مدل یادگیری ماشین (ML)، به داده‌ها در شکل اصلی‌ شان نیاز دارند؛ همچنین مدل‌ های ML به حجم زیادی از داده‌ ها نیاز دارند که ذخیره آنها در انبار داده دشوار است.

اولین دریاچه‌ های داده ساخته‌ شده، شامل ذخیره داده‌ها در سیستم فایل توزیع‌ شده هادوپ (Hadoop Distributed File System (HDFS))، در مجموعه‌ای از گره‌ های محاسباتی خوشه‌ای بود. در این معماری، داده‌ها با استفاده از MapReduce، Spark و سایر فریمورک‌ های پردازش داده استخراج و پردازش می‌شوند. معماری دریاچه داده به‌ جای فرآیند ETL، تحت فرآیند ELT کار می‌کند؛ داده‌ها (E) از سیستم‌ های عملیاتی استخراج می‌شوند و (L) در یک مخزن ذخیره‌سازی مرکزی بارگذاری می‌شوند. با این‌ حال، برخلاف انبار داده، یک Data Lake، تغییر و مدل‌ سازی بسیار کمی از داده‌ها را به خود می‌بیند. 

هدف از به‌ کارگیری این معماری، نگه داشتن داده‌ها به شکل اصلی‌شان است؛ هنگامی‌که داده‌ها وارد دریاچه می‌شوند، معماری Data Lake با پایپ‌ لاین تبدیل داده (T)، برای مدل‌ سازی داده‌ های خام و ذخیره آن در انبار داده یا نگه‌دارنده‌ های Feature گسترش می‌یابد.

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

»» چالش‌ های اصلی این رویکرد

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

حال معماری داده

در زمان کنونی معماری داده، با نسل سوم، یعنی معماری دریاچه داده ابری مواجه هستیم. بزرگترین تغییرات از نسل دوم به نسل سوم معماری داده، مهاجرت به پلتفرم‌های ابری (Cloud Platforms) و آغاز Cloud Data Lake Architecture بود. این پلتفرم‌ ها در دسترس بودن داده‌ها به‌ شکل Real-time و همگرایی بین Data Warehouse و Data Lake را به‌ سادگی فراهم می‌کند. جزئیات این پلتفرم‌ ها بسیار جذاب است:

• با معماری‌ هایی مانند Kappa، از پخش استریم برای در دسترس بودن داده‌ها در زمان واقعی پشتیبانی می‌کند.
• سعی دارد تا پردازش دسته‌ای و استریمی را برای تبدیل داده‌ها با فریمورک‌ هایی مانند Apache Beam یکسان کند.
• به‌ طور کامل از خدمات مدیریت‌ شده مبتنی‌ بر ابر پشتیبانی می‌کند؛ همچنین امکان پیاده‌ سازی‌ های بومی داده‌ها را روی ابر های مدرن، با محاسبات و ذخیره‌ سازی مجزا فراهم می‌کند؛ در این حالت ذخیره‌ سازی داده‌ها بسیار ارزان‌ تر از دو نسل قبلی می‌شود.
• انبار و دریاچه داده را به یک فناوری هم‌ گرا تبدیل می‌کند؛ به‌همین‌ علت گسترش انبار داده و آموزش ML تعبیه‌ شده به‌ طور متناوب ممکن می‌شود. یکپارچگی انبار داده، قابلیت Transaction و سیستم‌ های جست‌ و جو هم در این نسل، به راه‌ حل‌ های دریاچه داده اضافه شدند. 

 برخی از چالش‌ ها همچنان در این معماری باقی مانده است:

• پیاده‌ سازی و اجرای Cloud Data Lake Architecture در معماری Data Lake، پیچیدگی زیادی را به فرآیند مدیریت داده‌ ها تحمیل می‌کند و به‌همین‌ علت هم روی کیفیت و قابلیت اطمینان داده‌ها تاثیر منفی می‌گذارد.
• طراحی معماری همچنان پر چالش است و به تیمی از مهندسان داده با تجربه و کار کشته نیاز دارد.
• زمان طولانی برای درک بینش توسط مخاطبان وجود دارد تا بتوانند کاربرد مجموعه داده‌ها را در تجزیه‌ و تحلیل و یادگیری ماشین بیابند.
• انبار های داده دیگر دنیای واقعی را از طریق داده‌ها تکرار نمی‌کنند؛ بنابراین بر تجربه مخاطبان مصورسازی داده ها در حین کاوش تاثیر منفی می‌گذارد.

آینده معماری داده

آینده معماری داده به دست یک نسل نو ظهور و نه‌ چندان بالغ رقم خواهد خورد: نسل چهارم و معروف به معماری مش داده. معماری مش داده (Data Mesh Architecture)، تا حدودی یک رویکرد جدید در Data Architecture است که به‌دنبال رفع برخی از چالش‌ های شناسایی‌شده در سه نسل قبلی است. مش داده همان چیزی را که میکروسرویس‌ها برای کاربردهای یک‌ پارچه در نرم‌ افزار ها آورده‌اند، به معماری داده‌ ها هدیه می‌دهد.

در Data Mesh، داده‌ها غیر متمرکز هستند و مالکیت آنها بین دامنه‌ های مختلف توزیع می‌شود. هر دامنه مسئول داده‌ های موجود در محدوده (Scope) خود است. این محدوده شامل مدل‌ سازی داده، ذخیره‌سازی، حاکمیت و معماری است که باید مجموعه‌ای از اقدامات را ارائه دهد. در طول این فرآیند، هر دامنه می‌تواند داده‌های خود را به‌ طور مستقل مدیریت کند.

اجزای کلیدی معماری مش داده‌ها به شرح زیر است:

دامنه‌ها (Domains)

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

محصولات داده (Data Products)

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

زیرساخت داده (Data Infrastructure)

زیر ساخت داده شامل ابزار ها و فناوری‌ های مورد نیاز برای مدیریت داده‌ ها در یک دامنه است؛ چیزی شبیه‌ به یک میکروسرویس Container برای نرم‌ افزار؛ این بخش از معماری مش داده شامل ابزار های ذخیره‌سازی، پردازش و تجزیه‌ و تحلیل داده‌ها است.

حاکمیت داده (Data Governance)

حاکمیت داده توسط هر دامنه مدیریت می‌شود. این ویژگی معماری Data Mesh به مجموعه فرآیند هایی برای کنترل کیفیت داده‌ ها، حریم خصوصی و امنیت اشاره دارد.

Mesh API

درست مانند یک میکروسرویس که همه چیز را از API های HTTP REST در معرض دید قرار می‌دهد، یک دامنه مش داده هم تمام عناصر را از یک رابط تعریف‌ شده در معرض نمایش می‌گذارد تا توسط سایر دامنه‌ ها و محصولات داده مصرف شود.

می‌توانید مش داده‌ها را به‌عنوان یک تغییر پارادایم در نحوه طراحی معماری داده و سازمان‌ دهی تیم‌های Data و به‌شکل زیر تصور کنید:

• تیم‌های داده به تیم‌ هایی با عملکرد متقابل تبدیل می‌شوند که در یک یا چند حوزه تجاری (نه فناوری) متخصص هستند. درست مانند تیم‌ های محصولات نرم‌افزاری که بسیار خدمات‌ گرا تشکیل شده و پیش می‌روند.
• هر دامنه تجاری که از یک یا چند میکروسرویس تشکیل شده باشد، مفهوم پایگاه داده OLAP  و سیستم ذخیره فایل توزیع‌ شده خود را خواهد داشت؛ درست مانند هر قطعه‌ای از یک میکروسرویس که به‌طور مستقل کار می‌کند.
• محصول داده A توسط Data Product B مصرف می‌شود و هر دو بر بستر پخش استریم یا REST API، با سایر محصولات داده ارتباط برقرار می‌کنند. مصداق بارز آن هم میکروسرویس‌ های برنامه هستند که با یکدیگر ارتباط برقرار می‌کنند.
• API های محصول داده با مستندات REST API سنتی دنبال می‌شوند و محصولات داده را می‌توان از راه فهرست مش داده کشف کرد.

سخن پایانی

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

این تغییر درست زمانی رخ داد که نقش مدیر محصول یا “Product Manager” به‌ وجود آمد.  نظر شما درباره آینده معماری داده چیست؟ برای دفاع از نظر خود چه گزاره‌ هایی دارید؟ ما در تیم نیک‌ آموز مشتاق خواندن و اطلاع از دیدگاه ارزشمند شما هستیم؛ پس همین حالا آن را در بخش نظرات همین مقاله، با ما و سایر مخاطبان در میان بگذارید.