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

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

آموزش هوش تجاری

فهرست محتوایی

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

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

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

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

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

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

مشاهده و خرید کامل‌ترین دوره Power bi از نیک آموز

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

معماری انبار داده (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 به حجم زیادی از داده‌ها نیاز دارند که ذخیره آنها در انبار داده دشوار است.

اجرای پروژه هوش تجاری Enterprise تخصص ماست.

اولین دریاچه‌های داده ساخته‌ شده، شامل ذخیره داده‌ها در سیستم فایل توزیع‌ شده هادوپ (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” به‌ وجود آمد. نظر شما درباره آینده معماری داده چیست؟ برای دفاع از نظر خود چه گزاره‌هایی دارید؟ ما در تیم نیک‌ آموز مشتاق خواندن و اطلاع از دیدگاه ارزشمند شما هستیم؛ پس همین حالا آن را در بخش نظرات همین مقاله، با ما و سایر مخاطبان در میان بگذارید.