معماری دیتا مش Data Mesh Architecture

دیتا مش از دیدگاه مهندسی

اهمیت کاربرد دیتا مش

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

• آیا ارائه ارسال رایگان در بلک فرایدی ایده خوبی است؟
• آیا مشتریان زمان‌های حمل و نقل طولانی‌تر اما مطمئن‌تر را می‌پذیرند؟
• تغییر صفحه محصول چگونه بر نرخ پرداخت و بازگشت تأثیر می‌گذارد؟

تیم داده تمایل دارد به همه آن سؤالات کسب‌وکار سریع پاسخ دهد، اما در عمل با مشکل مواجه هستند زیرا باید زمان زیادی را صرف نگهداری و به‌روزکردن خطوط لوله داده و ETL ها، پس از تغییرات در پایگاه داده عملیاتی کنند. در زمان کمی که دارند، تیم داده باید داده‌های دامنه لازم را کشف و درک کند. برای هر سؤالی، آنها باید دانش دامنه را بیاموزند تا بینش معناداری ارائه دهند. به دست آوردن تخصص مورد نیاز دامنه یک کار دلهره آور و زمانبر است.

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

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

دیتا مش چیست؟

اصطلاح دیتا مش توسط ژامک دهقانی در سال ۲۰۱۹ ابداع شد و بر چهار اصل اساسی استوار است که مفاهیم شناخته شده را در بر می گیرد:

اصل مالکیت دامنه[۱]، تیم‌های دامنه را موظف می‌کند مسئولیت داده‌های خود را بر عهده بگیرند. بر اساس این اصل، داده‌های تحلیلی باید در اطراف دامنه‌ها، شبیه به مرزهای تیمی که با زمینه محدود سیستم همسو هستند، تشکیل شود. به دنبال معماری توزیع‌شده مبتنی بر دامنه، مالکیت داده‌های تحلیلی و عملیاتی به تیم‌های دامنه، دور از تیم داده مرکزی منتقل می‌شود.

اصل داده به عنوان محصول[۲]، اصل فلسفه تفکر محصول‌محور روی داده‌های تحلیلی مطرح می‌شود. این اصل به این معنی است که مصرف کنندگانی برای داده‌های فراتر از دامنه وجود دارند. تیم دامنه با ارائه داده‌های باکیفیت پاسخگوی نیازهای دامنه‌های دیگر است. اساساً، داده‌های دامنه باید مانند هر API عمومی دیگری در نظر گرفته شود.

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

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

روش طراحی دیتا مش

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

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

محصول داده[۵]

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

محصولات داده به منابعی مانند سامانه‌های عملیاتی یا سایر محصولات داده‌محور متصل می‌شوند و توانایی تغییر و تحول داده را دارد. محصولات داده مجموعه‌های داده را در یک یا چند پورت خروجی ارائه می‌کنند. پورت‌های خروجی معمولاً مجموعه داده‌های ساختاری هستند که توسط یک متاداد داده تعریف می‌شوند. چند نمونه:

• یک مجموعه داده BigQuery با چندین جدول مرتبط
• فایل‌های Parquet  در باکت‌های AWS S3
• فایل‌های دلتا در Azure Data Lake Storage Gen2
• پیام‌ها در تاپیک کافکا

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

برای طراحی محصولات داده، توصیه می کنیم از Data Product Canvas استفاده کنید.

برای مدیریت محصولات داده و پیگیری هزینه ها و انطباق، استفاده از Data Mesh Manager را در نظر بگیرید.

قرارداد داده[۶]

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

• ارائه دهنده محصول داده، شامل مالک و پورت خروجی برای دسترسی
• شرایط و ضوابط استفاده از داده
• طرحواره معناشناسی و ویژگی‌های داده ارائه شده
• ویژگی‌های کیفیت، مانند تازگی و تعداد ردیف‌ها
• اهداف در سطح خدمات، مانند زمان در دسترس بودن و پشتیبانی
• جزئیات صورتحساب برای استفاده از داده‌ها

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

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

مشخصات قرارداد داده یک قالب YAML[7] را برای توصیف شرایط استفاده و ویژگی های مجموعه داده های ارائه شده تعریف می کند.

حاکمیت فدرال[۸]

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

سیاست‌های قابلیت همکاری نقطه شروع هستند. آنها به سایر تیم‌های دامنه اجازه می‌دهند تا از محصولات داده به روشی روشن و ثابت استفاده کنند. برای مثال، سیاست‌های کلی می‌توانند روش استاندارد برای ارائه داده‌ها به صورت فایل CSV در AWS S3 متعلق به تیم دامنه مربوطه باشد.

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

یک راه یکسان برای دسترسی به محصول داده واقعی به روشی ایمن می تواند استفاده از دسترسی مبتنی بر نقش در AWS IAM باشد که توسط تیم دامنه مدیریت می شود.

سیاست‌های کلی مانند حفظ حریم خصوصی و انطباق نیز رایج هستند. به حفاظت از اطلاعات شناسایی شخصی (PII[9]) یا الزامات قانونی خاص صنعت فکر کنید.

بسیاری از سیاست‌های نمونه در وب‌سایت دیگر datamesh-governance.com موجود است که می‌توانید به راحتی در Data Mesh Manager، ابزار ما برای مدیریت شبکه داده، استفاده کنید.

تحولات داده[۱۰]

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

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

در عمل، ما اغلب داده‎های ورودی یا به صورت دستی را مشاهده می‌کنیم. به عنوان مثال، داده‌های پیش بینی ارسال شده از طریق ایمیل به عنوان فایل CSV یا توضیحات متنی برای کدهای کسب و کار. داده‌های سایر تیم‌ها به عنوان داده‌های خروجی ترکیب می‌شوند. هنگام استفاده از محصولات داده از تیم های دیگر که به خوبی اداره می شوند، این ادغام ممکن است به روشی بسیار سبک اجرا شود. در صورت وارد کردن داده ها از سیستم های قدیمی، منطقه خارجی به عنوان یک لایه ضد فساد عمل می کند.

تجمیع داده[۱۱]

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

استفاده از داده[۱۲]

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

رویدادهای دامنه[۱۳]

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

بسیاری از اشیاء تجاری به عنوان موجودیت‌ها و مجموعه‌ها در پایگاه‌های داده SQL یا NoSQL باقی می‌مانند. وضعیت آنها در طول زمان تغییر می‌کند و آخرین وضعیت فقط در پایگاه داده باقی می‌ماند. نامزدهای قوی برای نهادهای دارای وضعیت، مقالات، قیمت‌ها، داده‌های مشتری یا وضعیت ارسال هستند. برای موارد استفاده تحلیلی، اغلب لازم است که هم آخرین وضعیت و هم تاریخچه ایالت‌ها در طول زمان باشد. چندین رویکرد برای جذب موجودیت‌ها وجود دارد. یک راه این است که هر بار که یک موجودیت تغییر می کند، یک رویداد onCreate, onUpdate, onDelete با وضعیت فعلی تولید و منتشر کنید، به عنوان مثال. با افزودن یک جنبه یا EntityListeners. سپس می‌توان از انتقال جریانی برای استفاده داده‌ها همانطور که در بالا توضیح داده شد استفاده کرد. هنگامی که تغییر نرم افزار عملیاتی امکان پذیر نباشد،  با استفاده از CDC[14] ممکن است برای گوش دادن مستقیم به تغییرات پایگاه داده و پخش آنها در بستر داده استفاده شود.

نمونه هایی برای پخش CDC

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

پاک‌سازی داده‌ها[۱۵]

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

داده‌هایی که به پلتفرم داده وارد می‌شوند معمولاً در قالب اصلی خام و بدون ساختار وارد می‌شوند. هنگام استفاده از پایگاه داده ستونی، ممکن است این یک ردیف در هر رویداد باشد که حاوی یک فیلد CLOB برای بار رویداد است که ممکن است در قالب JSON باشد. برای تمیز کردن داده پردازش‌های زیر ضروری است:

• ساختاربندی Structuring: داده های بدون ساختار و نیمه ساختاریافته را به مدل داده های تحلیلی تبدیل کنید، به عنوان مثال، با استخراج فیلدهای JSON و بارگذاری در ستون‌ها.
• کاهش تغییرات ساختاری Mitigation of structural changes: هنگامی که ساختارهای داده تغییر کردند، آنها را تعدیل کنید، به عنوان مثال، با پر کردن مقادیر تهی با پیش فرض‌های معقول.
• Deduplication: از آنجایی که داده به اکثر سیستم‌های ذخیره سازی تحلیلی فقط اضافه می‌شود و موجودیت‌ها یا رویدادها را نمی‌توان به روز کرد، قبل استفاده از آن بایستی تمام ورودی‌های تکراری را حذف کرد.
• کامل بودن Completeness: اطمینان حاصل کنید که داده‌ها دارای دوره مورد توافق هستند، حتی زمانی که مشکلات فنی در حین انتقال وجود داشته باشد.
• رفع نقاط پرت Fix outliers: داده‌های نامعتبر که ممکن است از طریق اشکالات رخ دهد، شناسایی و اصلاح شوند.

از منظر پیاده سازی، این مراحل پیش پردازش را می توان به عنوان نماهای ساده SQL که داده‌های خام را نمایش می‌دهد، پیاده سازی کرد. پرس‌وجوها ممکن است از طریق عبارات جدول رایج[۱۶] سازماندهی شوند و ممکن است با توابع تعریف شده توسط کاربر[۱۷]، به عنوان مثال، برای پردازش JSON تقویت شوند. به عنوان یک جایگزین، مراحل تمیز کردن را می توان به عنوان توابع لامبدا که بر روی موضوعات عمل می کنند، پیاده سازی کرد. خطوط لوله پیچیده‌تری را می‌توان با چارچوب‌هایی مانند dbt یا Apache Beam ساخت که یک مدل برنامه‌نویسی پیشرفته را ارائه می‌کنند، اما مهارت‌های بیشتری نیز برای تسلط نیاز دارند.

تجزیه و تحلیل[۱۸]

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

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

برای بینش‌های پیشرفته‌تر، می‌توان از روش‌های علم داده[۱۹] و یادگیری ماشین[۲۰] استفاده کرد. این روش‌ها تجزیه‌وتحلیل‌های همبستگی، مدل‌های پیش‌بینی و سایر موارد استفاده پیشرفته را امکان پذیر می‌کنند. برای استفاده از آنها مهارت‌های روش شناختی، آماری و فن آوری ویژه مورد نیاز است. مثال‌هایی از یادگیری ماشین و علوم داده scikit-learn، PyTorch، TensorFlow هستند.

پلت فرم داده[۲۱]

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

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

یک پلت فرم داده پیشرفته‌تر برای دیتا مش‌ها همچنین قابلیت‌های محصول داده‌های مربوط به دامنه را برای ایجاد، نظارت، کشف و دسترسی به محصولات داده فراهم می‌کند. پلت فرم داده‌های خودسرویس باید از تیم‌های دامنه پشتیبانی کند تا بتوانند به سرعت یک محصول داده بسازند و همچنین آن را در تولید در منطقه ایزوله خود اجرا کنند. این پلت فرم باید از تیم دامنه در انتشار محصولات داده خود پشتیبانی کند تا سایر تیم‌ها بتوانند آنها را کشف کنند. این کشف به یک نقطه ورودی مرکزی برای همه محصولات داده غیرمتمرکز نیاز دارد. یک کاتالوگ داده را می‌توان به روش‌های مختلفی پیاده سازی کرد: به عنوان ویکی، مخزن git، یا حتی از قبل راه حل‌های فروشنده برای کاتالوگ داده های مبتنی بر ابر مانند Select Star، Google Data Catalog یا AWS Glue Data Catalog وجود دارد. با این حال، استفاده واقعی از محصولات داده، نیازمند یک تیم دامنه برای دسترسی، ادغام، و پرس و جو از محصولات داده سایر دامنه‌هاست. این پلت فرم باید دسترسی بین دامنه‌ای و استفاده از محصولات داده را پشتیبانی، نظارت و مستند کند.

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

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

فعال کردن تیم[۲۲]

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

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

در بین جلسات مشاوره، مواد آموزشی مانند اسکلت‌های راه رفتن، مثال ها، بهترین شیوه ها، آموزش ها یا حتی پادکست ها را به اشتراک می گذارند.

مش[۲۳]

شبکه زمانی پدیدار می‌شود که تیم‌ها از محصولات داده سایر دامنه‌ها استفاده می‌کنند. استفاده از داده‌های دامنه‌های بالادستی ارجاعات و جستجوی داده‌ها را ساده می‌کند (مانند دریافت قیمت یک محصول)، در حالی که داده‌های دامنه‌های پایین‌دستی، تجزیه و تحلیل اثرات را ممکن می‌سازد، به عنوان مثال. برای تست های A/B (مانند تغییرات در نرخ تبدیل). داده‌های چندین حوزه دیگر را می‌توان برای ایجاد گزارش‌های جامع و محصولات داده جدید جمع‌آوری کرد.

بیایید به یک مثال تجارت الکترونیک ساده نگاه کنیم:

دامنه ها را می توان بر اساس ویژگی های داده و استفاده از محصول داده طبقه بندی کرد. ما از طبقه بندی ژامک دهقانی استفاده می کنیم:

همسو با منبع  Source-aligned

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

تجمیع Aggregate

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

همسو با مصرف کننده  Consumer-aligned

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

پشته‌های فناوری Tech Stacks

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

راه‌کارهای مختلفی برای پیاده سازی معماری دیتا مش وجود دارد. در اینجا منتخبی از پشته های فناوری موجود را ذکر می‌کنیم:

• Google Cloud BigQuery
• AWS S3 و Athena
• Azure Synapse Analytics
• dbt و Snowflake
• Databricks
• MinIO و Trino
• SAP
• Kafka و RisingWave
• Starburst Enterprise (TBD)

سفر تیم دامنه

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

برای موفقیت آمیز بودن این سفر، تیم به سه چیز نیاز دارد:

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

پس بیایید سفر خود را شروع کنیم!

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

تجزیه و تحلیل داده ها فقط مرتبط نبود

سطح ۱ عملیات پرس و جوهای پایگاه داده

در حال تولید، احتمالاً باید یک حادثه را بررسی کنید و باید تجزیه و تحلیل کنید که چه تعداد مشتری تحت تأثیر قرار گرفته‌اند. همچنین، برخی از سهامداران ممکن است در رابطه با داده‌های شما سؤالاتی داشته باشند، مانند کدام مقالات موجود در انبار در شش ماه گذشته فروخته نشده است؟ یا زمان حمل و نقل در جمعه سیاه گذشته چقدر بود؟ برای پاسخ به همه این سؤالات، سؤالات تحلیلی را به پایگاه داده عملیاتی ارسال می‌کنید. با گذشت زمان، اولین تحلیل‌های اکتشافی را نیز انجام می‌دهید تا درک عمیق‌تری از رفتار سیستم خود داشته باشید.

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

سطح ۲ تجزیه و تحلیل داده های شخصی

با دردسرهای آهسته و پرس و جوهای تحلیلی سخت و ناخوانا، پلت فرم داده‎های سلف سرویس را که توسط تیم پلت فرم داده تبلیغ می‎شود امتحان کنید. برای مثال، اکنون به Google BigQuery دسترسی دارید. در این پلتفرم، تیم شما شروع به ساخت مدل داده‎های تحلیلی با دریافت پیام‎های کافکا می‎کند. این اولین محصول داده شماست. پلت فرم داده به شما این امکان را می دهد که داده‎های سیستم‎های خود را با پرس و جوهای قابل نگهداری و سریع تجزیه و تحلیل کنید، در حالی که طرحواره‎های پایگاه داده‎های عملیاتی خود را دست نخورده نگه دارید. شما یاد می‎گیرید که چگونه داده‎های تحلیلی را ساختار دهید، پیش پردازش کنید، تمیز کنید، تجزیه و تحلیل کنید، و تجسم کنید – این چیزهای زیادی برای یادگیری است، حتی اگر بیشتر SQL باشد، که قبلا با آن آشنا هستید.

از آنجایی که اکنون می توان به سؤالات مربوط به داده‎های خود به سرعت پاسخ داد، شما و صاحب محصول خود اکنون وارد چرخه تصمیم‎گیری‎های مبتنی بر داده می شوید: فرضیه ها را تعریف کنید و با داده ها تأیید کنید.

سطح ۳ تجزیه و تحلیل داده های متقابل دامنه

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

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

اگر شما اولین تیم هستید، ممکن است مجبور شوید فعلاً از این مرحله بگذرید و به سطح ۴ بروید و اولین نفری باشید که برای دیگران داده ارائه می دهد.

سطح ۴ قراردادهای انتشار داده

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

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

سفر تیم داده

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

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

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

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

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

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

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

سوالات متداول

بنابراین، واقعاً چه چیزی پشت این هیاهو وجود دارد؟

دیتا مش ها در درجه اول یک تغییر سازمانی است. مسئولیت داده به جریان ارزش کسب و کار نزدیک‌تر می‌شود. این امر تصمیم‌گیری‌های مبتنی بر داده را سریع‌تر می‌کند و موانع را برای نوآوری‌های داده محور کاهش می‌دهد.

چه کسی واقعاً یک دیتا مش را پیاده سازی کرده است؟

مجموعه‌ای جامع از داستان‌های سفر کاربر از جامعه Data Mesh Learning وجود دارد که نمونه‌های دیتا مش از بسیاری از صنایع مختلف را پوشش می‌دهد.

آیا دیتا مش برای شرکت من است؟

بستگی دارد و البته چند پیش نیاز وجود دارد که باید وجود داشته باشد: شما باید سیستم نرم افزاری خود را با رعایت اصول طراحی دامنه محور یا چیزی مشابه ماژولار کرده باشید. شما باید تعداد خوبی (۵+) از تیم‎های دامنه مستقل داشته باشید که سیستم‎های آنها در حال حاضر در حال تولید است. و در نهایت، باید به تیم‎های خود اعتماد کنید تا تصمیمات مبتنی بر داده را به تنهایی اتخاذ کنند.

چگونه شروع کنیم؟

از کوچک شروع کنید و روی تصویر بزرگ توافق کنید. دو تیم دامنه (که در حدود سطح ۲ هستند) را پیدا کنید که در آن یک تیم به داده‎های تیم دیگر نیاز دارد. اجازه دهید یک تیم یک محصول داده بسازد (سطح ۴) و تیم دیگری از آن محصول داده (سطح ۳) استفاده کند. شما هنوز به یک پلت فرم داده پیچیده نیاز ندارید. می‌توانید فایل‌ها را از طریق AWS S3، یک مخزن Git به اشتراک بگذارید یا از یک پایگاه داده مبتنی بر ابر مانند Google BigQuery استفاده کنید.

چه زمانی باید از دیتا مش اجتناب کنم؟

برخی از شاخص‌ها وجود دارد که ممکن است روش دیتا مش برای شما مناسب نباشد، از جمله:

• شما خیلی کوچک هستید و چندین تیم مهندسی مستقل ندارید.
• نیازهای داده با تأخیر کم دارید. دیتا مش یک شبکه داده است. اگر نیاز به بهینه سازی برای تاخیر کم دارید، در یک پلت فرم داده یکپارچه تر سرمایه گذاری کنید.
• شما از سیستم یکپارچه بسیار یکپارچه خود (مانند SAP) راضی هستید. ممکن است استفاده از پلتفرم تحلیلی آنها کارآمدتر باشد.

دیتا مش چه چیزی نیست؟

• دیتا مش یک گلوله نقره ای نیست.
• دیتا مش یک دین نیست.
• دیتا مش پلاگین و بازی نیست.
• دیتا مش محصولی نیست که فقط بتوانید بخرید.
• دیتا مش یک پلت فرم فقط داده نیست.
• دیتا مش نمی تواند توسط تیم داده به تنهایی پیاده سازی شود.
• دیتا مش مفهومی برای داده های عملیاتی نیست.
• دیتا مش مجازی سازی داده نیست.
• دیتا مش جانشین Data Warehouse یا Data Lake نیست.
• دیتا مش را نمی توان به سرعت به عنوان Big Bang پیاده سازی کرد.
• دیتا مش ها شبکه خدماتی برای داده ها نیست.
• دیتا مش مطلقاً ربطی به بلاک چین ندارد.

آیا دیتا مش یک راه حل عمومی برای معماری داده های توزیع شده است؟

خیر

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

محصول داده: چه داده هایی را باید در یک محصول داده گنجانده شود؟ آیا محصول داده باید شامل داده های دامنه های دیگر باشد؟

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

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

دامنه‌های انبوه و دامنه‌های همسو با مصرف‌کننده می‌توانند شامل همه داده‌های خارجی باشد که به موارد استفاده مصرف‌کنندگان مربوط است.

تفاوت بین دیتا مش و دیتا فابریک چیست؟

در ابتدا، مایکروسافت دیتا فابریک شبیه به دیتا مش به نظر می رسد زیرا یک پلت فرم داده سلف سرویس مشابه را ارائه می دهد. با نگاهی عمیق‌تر، معلوم می‌شود که بافت داده یک رویکرد مرکزی و دامنه آگنوستیک است، که در تضاد شدید با رویکرد دامنه محور و غیرمتمرکز شبکه داده است. اطلاعات بیشتر در این مقاله مقایسه

برای تیم هایی که سیستم های تجاری خارج از قفسه (COTS) را اداره می کنند، سفر چه می تواند باشد؟

بسیاری از سیستم های COTS (مانند Salesforce، SAP، Shopify، Odoo) قابلیت های تحلیلی بهینه شده دامنه را ارائه می دهند. بنابراین سفر تیم های دامنه مستقیماً از سطح ۲ شروع می شود.

چالش ادغام محصولات داده از سایر دامنه ها (سطح ۳، که در صورت عدم نیاز ممکن است نادیده گرفته شود) و انتشار محصولات داده برای سایر دامنه ها (سطح ۴) است. داده های سیستم باید به پلتفرم داده صادر شده و به عنوان محصولات داده مدیریت شوند، مطابق با سیاست های جهانی. همانطور که مدل های داده با به روز رسانی سیستم تکامل می یابند، یک لایه ضد فساد ضروری است، به عنوان مثال، به عنوان یک مرحله تمیز کردن.

چگونه ممکن است مجموعه داده های خارجی به دست آمده بخشی از یک شبکه داده باشند؟

مثال‌های معمولی: پایگاه‌های اطلاعات قیمت یا مطالعات پزشکی. یک تیم باید این مجموعه داده را داشته باشد و آن را در datamesh بیاورد. اگر این یک تیم خیلی فنی نیست، پلتفرم داده باید یک سلف سرویس آسان برای آپلود فایل ها و ارائه متا دیتا ارائه دهد. یک Excel API یا Google Sheets نیز ممکن است در اینجا گزینه ای باشد.

[۱] The domain ownership principle

[۲] The data as a product principle

[۳] The self-serve data infrastructure platform principle

[۴] The federated governance principle

[۵] Data Product

[۶] Data Contract

[۷] YAML یک زبان سریال سازی داده قابل خواندن توسط انسان است. معمولاً برای فایل‌های پیکربندی و در برنامه‌هایی که داده ذخیره یا منتقل می‌شوند استفاده می‌گردد. YAML بسیاری از برنامه‌های ارتباطی مشابه زبان نشانه‌گذاری توسعه‌یافته (XML) را هدف قرار می‌دهد، اما دارای یک نحو حداقلی است که عمداً با زبان نشانه‌گذاری تعمیم‌یافته استاندارد (SGML) متفاوت است. از تورفتگی به سبک پایتون برای نشان دادن تودرتو استفاده می‌کند و نیازی به نقل قول در اطراف بیشتر مقادیر رشته‌ای ندارد (همچنین از سبک JSON […] و {…} که در یک فایل ترکیب شده‌اند نیز پشتیبانی می‌کند).

[۸] Federated Governance

[۹] Personally Identifiable Information

[۱۰] Data Transformations

[۱۱] Data Aggregations

[۱۲] Data Ingesting

[۱۳] Domain events

[۱۴] Changing Data Capture

[۱۵] Clean Data

[۱۶] Common Table Expressions (CTEs)

[۱۷] User-Defined Functions (UDFs)

[۱۸] Analytics

[۱۹] Data Science

[۲۰] Machine Learning

[۲۱] Data Platform

[۲۲] Enabling Team

[۲۳] Mesh

 

تألیف و ترجمه: آقای مهندس رضا بهادری زاده در صورت تمایل. برای کسب اطلاعات بیشتر در زمینه مهندسی داده. و ارتباط با اینجانب، شماره تلفن مستقیم ۰۲۱۸۶۱۱۱۷۲۵ در اختیار شماست.

جهت استفاده از خدمت هوش تجاری نفیس. و همچنین گرفتن مشاوره. هوشمند سازی کسب‌وکار در سازمان خود، فرم زیر را تکمیل بفرمائید:

 

• 
• 
• 
• 
•