پیاده سازی داده مش: تسریع استخراج ارزش از سیستم های ERP/CRM

توسعه سریع داده ها از سیستم عامل های بزرگ را امکان پذیر می کند

برای یک مهندس داده تجزیه و تحلیل از سیستم‌های تراکنشی مانند ERP (برنامه‌ریزی منابع سازمانی) و CRM (مدیریت ارتباط با مشتری)، چالش اصلی پیمایش شکاف بین داده‌های عملیاتی خام و دانش دامنه است. سیستم های ERP و CRM برای انجام طیف وسیعی از فرآیندها و عملکردهای تجاری طراحی و ساخته شده اند. این تعمیم مدل های داده آنها را پیچیده و رمزآلود می کند و به تخصص دامنه نیاز دارد.

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

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

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

من برای درخواست داده های خام به نماها در پایگاه داده های تراکنش یا API های ارائه شده توسط سیستم عامل ها متصل می شدم.

عکس های فوری سفارش در منطقه توسعه شخصی من ذخیره می شود (تصویر توسط نویسنده)

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

هنگامی که داده‌های عملیاتی خام در دسترس بودند، مجبور شدم با چالش بعدی مقابله کنم: رمزگشایی تمام اشیاء و ویژگی‌های مرموز و برخورد با پیچ و خم ده‌ها اتصال بین آنها (یعنی داده‌های عمومی مواد در SAP مستند به https://leanx.eu /en/sap/table/mara.html)

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

پیاده‌سازی Data Mesh تجربه من را در جنبه‌های زیر بهبود بخشید:

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

طبق طبقه‌بندی Data Mesh، محصولات داده‌ای که بر اساس منابع عملیاتی ساخته می‌شوند، محصولات داده‌ای با منبع همسویی نامیده می‌شوند:

مجموعه داده‌های دامنه منبع دقیقاً داده‌های خام را در زمان ایجاد نشان می‌دهند و برای یک کاربر خاص برازش یا مدل‌سازی نشده‌اند. جامک دهگانی

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

مالکیت

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

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

پیاده سازی

به دنبال این رویکرد، دامنه فروش مسئول انتشار یک محصول داده “سفارش_فروش” و در دسترس قرار دادن آن در یک کاتالوگ داده مشترک است.

DP سفارشات فروش مجموعه داده sales_orders را نشان می دهد (تصویر توسط نویسنده)

خط لوله داده مسئول نگهداری محصول داده را می توان به صورت زیر تعریف کرد:

بازیابی دادهها

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

پاکسازی داده ها

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

-- Example of property standardisation in a sql query used to extract data
case
when lower(SalesDocumentCategory) = 'invoice' then 'Invoice'
when lower(SalesDocumentCategory) = 'invoicing' then 'Invoice'
else SalesDocumentCategory
end as SALES_DOCUMENT_CATEGORY

به روز رسانی داده ها

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

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

به روز رسانی متادیتا

محصولات داده باید باشد قابل درک. تولیدکنندگان باید متادیتای معنی‌داری درباره اشیا و ویژگی‌های موجود در آن بگنجانند. این ابرداده باید این جنبه‌ها را برای هر ویژگی پوشش دهد:

شرح کسب و کار: هر ملک چه چیزی را برای کسب و کار نشان می دهد. مثلا، “دسته کسب و کار برای سفارش فروش“.
سیستم منبع: یک نگاشت به ویژگی اصلی در منطقه عملیاتی ایجاد کنید. مثلا، “منبع اصلی: ERP | جدول MARA-MTART دارایی BIC/MARACAT“.
ویژگی های داده: ویژگی های داده های خاص، مانند شمارش ها و گزینه ها. مثلا، “این یک لیست با این گزینه ها است: فاکتور، پرداخت، شکایت“.

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

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

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

ورودی برای DP سفارشات فروش در مثال کاتالوگ داده (تصویر توسط نویسنده)

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

ما چندین مزیت را برای فعال کردن داده های عملیاتی از طریق محصولات داده آگاه از منبع شناسایی کرده ایم، به ویژه زمانی که متعلق به تولیدکنندگان داده باشد:

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

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

https://www.oreilly.com/library/view/data-mesh/9781492092384/

با تشکر از همکارانم در Thoughtworks، آرن (دو بار!)، پابلو، آیوش، و سامواردان که برای مرور نسخه های اولیه این مقاله وقت گذاشتند.

Source link