فصل ۱۶ — مش داده (Data Mesh)

تا اینجا دربارهٔ Modelهایی صحبت کردیم که برای ساخت سیستم‌های عملیاتی استفاده می‌شوند. سیستم‌های عملیاتی Transactionهای Real-Time را اجرا می‌کنند، دادهٔ سیستم را تغییر می‌دهند و Interactionهای روزمرهٔ آن را با محیط Orchestrate می‌کنند. این Modelها به دادهٔ پردازش تراکنشی برخط (Online Transaction Processing یا OLTP) مربوط‌اند. نوع دیگری از داده نیز نیازمند توجه و مدل‌سازی درست است: دادهٔ پردازش تحلیلی برخط (Online Analytical Processing یا OLAP).

در این فصل با معماری مدیریت دادهٔ تحلیلی موسوم به Data Mesh آشنا می‌شوید. خواهید دید Data Mesh چگونه کار می‌کند، چه تفاوتی با رویکردهای سنتی OLAP دارد و در نهایت، چگونه Domain-Driven Design و Data Mesh یکدیگر را تکمیل می‌کنند. اما نخست باید ببینیم Analytical Model چیست و چرا نمی‌توان Operational Model را مستقیماً برای Use Caseهای تحلیلی دوباره استفاده کرد.

مدل دادهٔ تحلیلی در برابر مدل تراکنشی

می‌گویند دانش قدرت است. Analytical Data همان دانشی است که به شرکت‌ها اجازه می‌دهد دادهٔ انباشته‌شده را برای به دست آوردن Insight دربارهٔ بهینه‌سازی کسب‌وکار، درک بهتر نیازهای مشتری و حتی تصمیم‌گیری خودکار با آموزش Machine Learning Modelها به کار بگیرند.

Analytical Modelهای OLAP و Operational Modelهای OLTP به Consumerهای متفاوت خدمت می‌کنند، Use Caseهای متفاوتی را ممکن می‌سازند و بنابراین بر اساس اصول طراحی متفاوت ساخته می‌شوند.

Operational Modelها حول Entityهای مختلف Business Domain ساخته می‌شوند، چرخهٔ عمر آن‌ها را پیاده می‌کنند و Interaction آن‌ها با یکدیگر را Orchestrate می‌کنند. این Modelها—مانند شکل ۱۶-۱—برای سیستم‌های عملیاتی‌اند و باید برای Business Transactionهای Real-Time بهینه شوند.

Analytical Modelها برای ارائهٔ Insight دربارهٔ عملکرد سیستم‌های عملیاتی طراحی می‌شوند. به‌جای اجرای Transactionهای Real-Time، هدف آن‌ها نشان دادن Performance فعالیت‌های کسب‌وکار و مهم‌تر از آن، یافتن راه‌هایی برای بهینه‌سازی عملیات و تولید ارزش بیشتر است.

از دید ساختار داده، OLAP Modelها Entityهای منفرد کسب‌وکار را در مرکز قرار نمی‌دهند؛ آن‌ها بر Business Activity تمرکز می‌کنند و آن را با Fact Table و Dimension Table مدل می‌کنند.

Fact Table

Factها فعالیت‌های کسب‌وکاری را نمایش می‌دهند که قبلاً اتفاق افتاده‌اند. از این جهت شبیه Domain Event هستند، چون هر دو چیزهایی را توصیف می‌کنند که در گذشته رخ داده است. با این حال، برخلاف Domain Event، الزام سبکی وجود ندارد که نام Fact حتماً به صورت فعل زمان گذشته باشد. مهم این است که Fact یک Business Process یا Activity را ثبت کند.

برای مثال، Fact Tableای با نام Fact_CustomerOnboardings برای هر Customer جدیدی که Onboard شده یک Record نگه می‌دارد و Fact_Sales برای هر Sale قطعی یک Record ثبت می‌کند. شکل ۱۶-۲ نمونه‌ای از Fact Table را نشان می‌دهد.

مشابه Domain Event، Recordهای Fact هرگز حذف یا ویرایش نمی‌شوند. Analytical Data از نوع Append-Only است: تنها راه بیان این‌که دادهٔ قبلی دیگر Current نیست، Append کردن Record جدید با State فعلی است. شکل ۱۶-۳ جدول Fact_CaseStatus را نشان می‌دهد که Status درخواست‌های پشتیبانی را در طول زمان ثبت می‌کند. در نام Fact فعل صریحی وجود ندارد، اما Business Process ثبت‌شده همان فرایند رسیدگی به Support Case است.

تفاوت مهم دیگر OLAP و OLTP در Granularity داده است. Operational System برای انجام Transaction به دقیق‌ترین دادهٔ ممکن نیاز دارد. در Analytical Model، Aggregated Data در بسیاری Use Caseها کارآمدتر است. برای مثال در Fact_CaseStatus شکل ۱۶-۳ Snapshot هر ۳۰ دقیقه گرفته می‌شود. Data Analystها تعیین می‌کنند چه Granularity برای نیازشان مناسب است. ساخت Fact Record برای هر تغییر کوچک داده در بعضی سناریوها Wasteful و در برخی حتی از نظر فنی ناممکن است.

Dimension Table

Building Block مهم دیگر Analytical Model، Dimension است. اگر Fact یک Business Process یا Action—یک «فعل»—را نشان دهد، Dimension آن Fact را توصیف می‌کند—مثل یک «صفت».

Dimensionها Attributeهای Fact را مدل می‌کنند و معمولاً Fact Table با Foreign Key به Dimension Table اشاره می‌کند. Attributeهایی که در Dimension قرار می‌گیرند Measurement یا داده‌هایی هستند که در Fact Recordهای متعدد تکرار می‌شوند و در یک Column منفرد به‌خوبی جا نمی‌گیرند. شکل ۱۶-۴ Fact مربوط به SolvedCases را با Dimensionهایش نشان می‌دهد.

یکی از دلایل Normalization بالای Dimensionها نیاز Analytical System به Query منعطف است. این هم تفاوت دیگری با Operational Model است. معمولاً می‌توان پیش‌بینی کرد Operational Model برای پشتیبانی Business Requirement چگونه Query خواهد شد. الگوهای Query در Analytical Model قابل پیش‌بینی نیستند. Data Analystها باید بتوانند داده را از زاویه‌های مختلف ببینند و دشوار است از قبل بدانیم در آینده چه Queryهایی اجرا می‌شوند. Normalization امکان Query، Filter و Group کردن Dynamic دادهٔ Fact بر اساس Dimensionهای مختلف را فراهم می‌کند.

Analytical Modelها

ساختار Table نشان‌داده‌شده در شکل ۱۶-۵ Star Schema نام دارد. این Schema بر رابطهٔ Many-to-One میان Fact و Dimension استوار است: هر Dimension Record توسط Factهای زیادی استفاده می‌شود و Foreign Key هر Fact به یک Dimension Record منفرد اشاره می‌کند.

مدل تحلیلی رایج دیگر Snowflake Schema است. Building Blockهای آن همان Fact و Dimension هستند، اما Dimensionها چندسطحی‌اند: هر Dimension به Dimensionهای ریزتر Normalize می‌شود؛ شکل ۱۶-۶ نمونه را نمایش می‌دهد.

Normalization بیشتر در Snowflake فضای ذخیره‌سازی Dimension Data را کاهش می‌دهد و Maintenance را آسان‌تر می‌کند، اما Query کردن Fact Data به Joinهای بیشتری نیاز دارد و در نتیجه Compute Resource بیشتری مصرف می‌کند.

Star Schema و Snowflake Schema هر دو به Data Analystها کمک می‌کنند Performance کسب‌وکار را بررسی کنند، Insight لازم برای بهینه‌سازی را به دست آورند و گزارش‌های Business Intelligence بسازند.

پلتفرم‌های مدیریت دادهٔ تحلیلی

اکنون از مدل‌سازی تحلیلی به Architecture مدیریت داده‌ای می‌رویم که تولید و ارائهٔ Analytical Data را ممکن می‌کند. دو معماری رایج را بررسی خواهیم کرد: Data Warehouse و Data Lake. اصول کار، تفاوت‌ها و Challengeهای هرکدام پایهٔ لازم برای بحث اصلی فصل—Data Mesh و ارتباط آن با DDD—را فراهم می‌کند.

Data Warehouse

معماری Data Warehouse یا DWH نسبتاً سرراست است: داده را از تمام Operational Systemهای سازمان Extract کنید، Source Data را به Analytical Model Transform کنید و دادهٔ حاصل را در Database مخصوص تحلیل Load کنید. این Database همان Data Warehouse است.

این Architecture عمدتاً بر Scriptهای Extract-Transform-Load یا ETL متکی است. داده می‌تواند از Sourceهای مختلف بیاید: Operational Database، Event Stream، Log و موارد دیگر. Transformation علاوه بر تبدیل داده به Model مبتنی بر Fact/Dimension می‌تواند عملیات دیگری نیز انجام دهد: حذف Sensitive Data، Deduplicate کردن Recordها، مرتب کردن Eventهای Out-of-Order، Aggregate کردن Eventهای ریزدانه و موارد دیگر. گاهی Transformation برای دادهٔ ورودی به Temporary Storage نیاز دارد که Staging Area نامیده می‌شود.

Data Warehouse حاصل—شکل ۱۶-۷—Analytical Data مربوط به همهٔ Business Processهای Enterprise را نگه می‌دارد. داده از طریق SQL یا Dialect آن در اختیار Data Analystها و BI Engineerها قرار می‌گیرد.

خوانندهٔ دقیق متوجه می‌شود Data Warehouse بعضی از Challengeهایی را دارد که در فصل‌های ۲ و ۳ دربارهٔ Model بزرگ و واحد دیدیم.

در قلب DWH هدف ساخت Enterprise-Wide Model قرار دارد: مدلی که دادهٔ همهٔ سیستم‌های Enterprise را توصیف و همهٔ Use Caseهای Analytical Data را پاسخ دهد—بهینه‌سازی Business، کاهش Operational Cost، تصمیم‌گیری هوشمند، Reporting و حتی Training مدل‌های ML.

همان‌طور که در فصل ۳ دیدیم، چنین Model فراگیری جز برای کوچک‌ترین سازمان‌ها غیرعملی است. ساخت Model برای Task مشخص—مثلاً Report یا ML Training—روش مؤثرتر و Scalableتری است.

Challenge Model فراگیر را می‌توان تا حدی با Data Mart کاهش داد. Data Mart Databaseای است که فقط دادهٔ مرتبط با نیاز تحلیلی مشخص، مثلاً یک Department، را نگه می‌دارد. شکل ۱۶-۸ دو Mart را نشان می‌دهد: یکی مستقیماً با ETL از Operational System تغذیه می‌شود و دیگری داده را از Data Warehouse می‌گیرد.

اگر Data Mart از Enterprise Data Warehouse تغذیه شود، همچنان باید Enterprise-Wide Model در DWH تعریف شود. اگر Mart مستقیماً از Operational System داده بگیرد، Query کردن داده میان Martهای مختلف دشوار می‌شود، چون نیاز به Cross-Database Query دارد و Performance را به‌طور جدی تحت تأثیر قرار می‌دهد.

Challenge مهم دیگر DWH این است که ETL Coupling شدیدی میان Analytical Systemهای OLAP و Operational Systemهای OLTP ایجاد می‌کند. داده‌ای که ETL مصرف می‌کند لزوماً از Public Interface سیستم نمی‌آید؛ اغلب DWH مستقیماً همهٔ دادهٔ داخل Operational Database را Fetch می‌کند. Database Schema یک Public Interface نیست، بلکه Implementation Detail داخلی است. در نتیجه حتی تغییر کوچک Schema می‌تواند ETL Script را بشکند.

از آن‌جا که Operational و Analytical System معمولاً توسط واحدهای سازمانی نسبتاً دور از هم ساخته و نگه‌داری می‌شوند، ارتباط بین Teamها دشوار و پر اصطکاک می‌شود. شکل ۱۶-۹ این الگوی ارتباطی را نشان می‌دهد.

Data Lake تلاش می‌کند بعضی محدودیت‌های Data Warehouse را برطرف کند.

Data Lake

Data Lake مانند Data Warehouse بر دریافت دادهٔ Operational System و تبدیل آن به Analytical Model تکیه دارد، اما تفاوت مفهومی مهمی دارد.

سیستم Data Lake دادهٔ Operational System را Ingest می‌کند، ولی به‌جای Transform فوری به Analytical Model، داده را به شکل Raw و در همان Operational Model اصلی ذخیره می‌کند.

Raw Data به‌تنهایی نیاز Data Analyst را برآورده نمی‌کند. بنابراین Data Engineer و BI Engineer باید بعداً دادهٔ موجود در Lake را تفسیر کنند، ETL Scriptهای لازم را بسازند، Analytical Model تولید کنند و آن را به Data Warehouse یا Storage تحلیلی منتقل کنند. شکل ۱۶-۱۰ معماری Data Lake را نشان می‌دهد.

چون Operational Data به شکل خام ذخیره می‌شود و Transformation به بعد موکول شده، Data Lake امکان ساخت چند Analytical Model مخصوص Task را می‌دهد: یک Model برای Reporting، دیگری برای ML Training و غیره. همچنین در آینده می‌توان Model جدید اضافه کرد و آن را با Raw Data موجود Initialization کرد.

اما تأخیر در تولید Analytical Model، Complexity کل System را افزایش می‌دهد. غیرعادی نیست Data Engineerها چند Version از یک ETL Script را نگه‌داری کنند تا Versionهای مختلف Operational Model را پشتیبانی کنند؛ شکل ۱۶-۱۱ این مشکل را نشان می‌دهد.

علاوه بر این، Data Lakeها Schema-Less هستند—هیچ Schema اجباری روی Incoming Data وجود ندارد—و معمولاً کنترل قوی روی Quality دادهٔ ورودی ندارند. در Scale بالا، Data Lake می‌تواند آشفته شود. Ingest داده آسان است اما استفاده از آن بسیار دشوارتر؛ به همین دلیل اصطلاح Data Swamp رایج شده است. Data Scientist برای درک این آشفتگی و استخراج Analytical Data مفید باید چند برابر تلاش کند.

Challengeهای Data Warehouse و Data Lake

هر دو Architecture بر این فرض بنا شده‌اند که هرچه دادهٔ بیشتری برای Analytics Ingest شود، Insight بیشتری به دست می‌آید. اما هر دو در زیر وزن Big Data تمایل به شکست دارند. در Scale بالا، تبدیل Operational Model به Analytical Model به هزاران ETL Script موردی و نگه‌داری‌ناپذیر تبدیل می‌شود.

از دید Modeling، هر دو Architecture از Boundary Operational System عبور و به Implementation Detail آن وابستگی ایجاد می‌کنند. Coupling به Implementation Model باعث اصطکاک میان Teamهای Operational و Analytical می‌شود؛ گاهی تا حدی که Team عملیاتی فقط برای جلوگیری از شکستن ETL Jobهای سیستم تحلیلی، از تغییر Model خودداری می‌کند.

مشکل بدتر این است که Data Analyst و Data Engineer در واحد سازمانی جداگانه قرار دارند و اغلب دانش عمیق Business Domain را که Development Team سیستم عملیاتی دارد در اختیار ندارند. تخصص آن‌ها عمدتاً Big Data Tooling است، نه منطق Business Domain.

Coupling به Implementation Model در پروژه‌های مبتنی بر DDD شدیدتر است، چون DDD بر تکامل و بهبود مستمر Model دامنه تأکید دارد. تغییر Operational Model ممکن است پیامدهای پیش‌بینی‌نشده‌ای در Analytical Model ایجاد کند. چنین تغییرهایی در DDD Frequent هستند و میان R&D و Data Team اصطکاک ایجاد می‌کنند.

این محدودیت‌ها الهام‌بخش معماری جدید مدیریت Analytical Data شدند: Data Mesh.

Data Mesh

Data Mesh از یک منظر، Domain-Driven Design برای Analytical Data است. همان‌طور که Patternهای DDD Boundary تعریف و از محتوای آن محافظت می‌کنند، Data Mesh نیز Boundaryهای Model و Ownership را برای Analytical Data تعریف و محافظت می‌کند.

Data Mesh بر چهار اصل اصلی استوار است:

1. داده را پیرامون Domainها تجزیه کنید (Decompose Data Around Domains).
2. داده را به‌عنوان Product در نظر بگیرید (Data as a Product).
3. Autonomy را ممکن کنید (Enable Autonomy).
4. Ecosystem بسازید (Build an Ecosystem).

۱. تجزیهٔ داده پیرامون Domainها

Data Warehouse و Data Lake هر دو تلاش می‌کنند همهٔ Enterprise Data را در یک Model بزرگ Unified کنند. Analytical Model حاصل به همان دلایلی ناکارآمد است که Enterprise-Wide Operational Model ناکارآمد است. علاوه بر آن، جمع کردن دادهٔ همهٔ Systemها در یک مکان، Ownership Boundary عناصر داده را مبهم می‌کند.

به‌جای ساخت یک Analytical Model یکپارچه، Data Mesh همان راه‌حلی را پیشنهاد می‌کند که فصل ۳ برای Operational Data مطرح کرد: از چند Analytical Model استفاده کنید و آن‌ها را با Origin داده هم‌راستا کنید. این کار Ownership Boundary مدل تحلیلی را به‌طور طبیعی با Boundary Bounded Context منطبق می‌کند؛ شکل ۱۶-۱۲.

وقتی Analytical Model بر اساس Bounded Contextهای System تجزیه شود، تولید Analytical Data به مسئولیت Product Team متناظر تبدیل می‌شود. هر Bounded Context اکنون مالک هر دو Model است: Operational یا OLTP و Analytical یا OLAP. در نتیجه همان Teamی که Operational Model را مالک است، مسئول Transform کردن آن به Analytical Model نیز می‌شود.

۲. داده به‌عنوان Product

Architectureهای کلاسیک مدیریت Data، کشف، درک و دریافت Analytical Data باکیفیت را دشوار می‌کنند، مخصوصاً در Data Lake.

اصل Data as a Product می‌گوید Analytical Data باید First-Class Citizen باشد. به‌جای این‌که سیستم تحلیلی دادهٔ Operational را از Sourceهای مشکوک مانند Internal Database یا Logfile جمع کند، در Data Mesh هر Bounded Context دادهٔ تحلیلی خود را از طریق Output Portهای تعریف‌شده ارائه می‌کند؛ شکل ۱۶-۱۳.

Analytical Data باید مانند هر Public API دیگری رفتار شود:

• Endpointهای لازم—Data Output Portها—باید به‌راحتی قابل کشف باشند.
• Analytical Endpoint باید Schema مشخصی برای Data و Format آن داشته باشد.
• Analytical Data باید قابل اعتماد باشد و مانند API دارای Service-Level Agreement یا SLA تعریف‌شده و Monitorشده باشد.
• Analytical Model باید مانند API Version شود و Breaking Changeهای Integration به‌درستی مدیریت شوند.

علاوه بر این، چون Analytical Data یک Product است، باید نیاز Consumer را برآورده کند. Team مالک Bounded Context مسئول است مطمئن شود Model حاصل به نیاز Consumerها پاسخ می‌دهد. برخلاف Data Warehouse و Data Lake، در Data Mesh پاسخ‌گویی نسبت به Data Quality دغدغه‌ای سطح بالا است.

هدف Architecture مدیریت دادهٔ توزیع‌شده این است که Analytical Modelهای ریزدانه بتوانند برای پاسخ به نیازهای Data Analysis سازمان با هم ترکیب شوند. برای مثال اگر BI Report به دادهٔ چند Bounded Context نیاز دارد، باید بتواند Analytical Data همهٔ آن‌ها را به‌سادگی دریافت کند، Transformation محلی لازم را اعمال کند و Report را بسازد.

Consumerهای مختلف ممکن است داده را در Formatهای متفاوت بخواهند: بعضی SQL Query را ترجیح دهند و بعضی Object Storage. در نتیجه Data Productها باید Polyglot باشند و داده را در Format مناسب نیاز Consumer ارائه کنند.

برای اجرای Data as a Product، Product Team باید متخصصان Data-Oriented را به تیم اضافه کند؛ این همان قطعهٔ گم‌شدهٔ Cross-Functional Team است که به‌طور سنتی بیشتر متخصصان Operational System را در خود دارد.

۳. امکان Autonomy

Product Team باید هم بتواند Data Product خود را بسازد و هم Data Product Bounded Contextهای دیگر را مصرف کند. مانند Bounded Context، Data Productها باید Interoperable باشند.

اگر هر Team راه‌حل مستقل خود را برای ارائهٔ Analytical Data بسازد، نتیجه Wasteful، ناکارآمد و سخت برای Integration خواهد بود. برای جلوگیری از این وضعیت به Platformی نیاز است که Complexity ساخت، اجرا و نگه‌داری Data Productهای Interoperable را Abstract کند. طراحی و ساخت چنین Platformی کار بزرگی است و به Data Infrastructure Platform Team اختصاصی نیاز دارد.

این Team باید Blueprintهای Data Product، Unified Access Patternها، Access Control و Polyglot Storage را تعریف کند تا Product Teamها بتوانند از آن‌ها استفاده کنند. همچنین Monitor کردن Platform و اطمینان از رعایت SLA و Objectiveها نیز بر عهدهٔ همین Team است.

۴. ساخت Ecosystem

گام نهایی ساخت Data Mesh، تشکیل یک نهاد Governance فدرال است که Interoperability و Ecosystem Thinking را در حوزهٔ Analytical Data تضمین کند. معمولاً این گروه از Data Owner و Product Ownerهای Bounded Contextها و نمایندگان Data Infrastructure Platform Team تشکیل می‌شود؛ شکل ۱۶-۱۴.

Governance Group مسئول تعریف Ruleهایی است که سلامت و Interoperability Ecosystem را تضمین می‌کنند. این Ruleها باید روی همهٔ Data Productها و Interfaceهایشان اعمال شوند و گروه مسئول نظارت بر رعایت آن‌ها در سراسر Enterprise است.

ترکیب Data Mesh و Domain-Driven Design

این چهار اصل پایهٔ Data Mesh هستند. تأکید بر Boundary و Encapsulate کردن Implementation Detail پشت Output Portهای تعریف‌شده نشان می‌دهد Data Mesh از همان منطق DDD استفاده می‌کند. علاوه بر این، بعضی Patternهای DDD می‌توانند پیاده‌سازی Data Mesh را به‌طور مستقیم پشتیبانی کنند.

نخست و مهم‌تر از همه، Ubiquitous Language و Domain Knowledge حاصل از آن برای طراحی Analytical Model ضروری‌اند. در بخش Data Warehouse و Data Lake دیدیم که نبود Domain Knowledge یکی از مشکلات Architectureهای سنتی است.

دوم، Expose کردن دادهٔ Bounded Context در Modelی متفاوت از Operational Model همان Open-Host Service است. در اینجا Analytical Model یک Published Language اضافه است.

Pattern CQRS تولید چند Model از یک Data را آسان می‌کند. می‌توان از آن برای Transform کردن Operational Model به Analytical Model استفاده کرد. توانایی CQRS در ساخت Projection از ابتدا همچنین اجازه می‌دهد چند Version از Analytical Model هم‌زمان تولید و ارائه شوند؛ شکل ۱۶-۱۵ دو Version Schema را نشان می‌دهد.

در نهایت، چون Data Mesh Modelهای Bounded Contextهای مختلف را برای Use Case تحلیلی ترکیب می‌کند، Patternهای Integration Bounded Context برای Operational Model به Analytical Model نیز قابل اعمال‌اند. دو Product Team می‌توانند Analytical Modelهای خود را در Partnership تکامل دهند؛ Team دیگر می‌تواند Anticorruption Layer بسازد تا از Model تحلیلی نامناسب محافظت شود؛ یا Teamها Separate Ways را انتخاب کنند و پیاده‌سازی Analytical Model را تکرار کنند.

جمع‌بندی

در این فصل جنبه‌های مختلف طراحی Software System با تمرکز بر تعریف و مدیریت Analytical Data را بررسی کردیم. Modelهای رایج Analytical Data—از جمله Star Schema و Snowflake Schema—و روش سنتی مدیریت داده در Data Warehouse و Data Lake را دیدیم.

Data Mesh تلاش می‌کند Challengeهای Architectureهای سنتی مدیریت Data را برطرف کند. در هستهٔ خود، همان اصول DDD را روی Analytical Data اعمال می‌کند: Analytical Model را به Unitهای قابل مدیریت تجزیه و اطمینان حاصل می‌کند داده از طریق Public Interface به‌صورت قابل اعتماد قابل دسترسی و استفاده باشد. در نهایت Patternهای CQRS و Bounded Context Integration می‌توانند پیاده‌سازی Data Mesh را پشتیبانی کنند.

تمرین‌ها

1. کدام عبارت یا عبارت‌ها دربارهٔ تفاوت Modelهای تراکنشی OLTP و تحلیلی OLAP درست‌اند؟
   1. OLAP باید Query Optionهای منعطف‌تری از OLTP ارائه کند.
   2. OLAP باید Updateهای بیشتری از OLTP تحمل کند و بنابراین برای Write بهینه شود.
   3. OLTP برای عملیات Real-Time بهینه است، در حالی که برای OLAP پاسخ چندثانیه‌ای یا حتی چنددقیقه‌ای ممکن است قابل قبول باشد.
   4. A و C درست‌اند.
2. کدام Pattern یکپارچه‌سازی Bounded Context برای پیاده‌سازی Data Mesh ضروری است؟
   1. Shared Kernel
   2. Open-Host Service
   3. Anticorruption Layer
   4. Partnership
3. کدام Architectural Pattern برای پیاده‌سازی Data Mesh ضروری است؟
   1. Layered Architecture
   2. Ports & Adapters
   3. CQRS
   4. Architectural Patternها نمی‌توانند از OLAP پشتیبانی کنند.
4. تعریف Data Mesh می‌گوید Data باید پیرامون «Domain»ها تجزیه شود. اصطلاح متناظر در DDD برای Domainهای Data Mesh چیست؟
   1. Bounded Contextها
   2. Business Domainها
   3. Subdomainها
   4. در DDD اصطلاح مترادفی وجود ندارد.

شکل‌ها و جدول‌های منبع

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