معماری Enterprise BI؛ Data Warehouse، Lakehouse و Semantic Model مشترک

کتاب جامع Power BI — آموزش پروژه‌محور، تصویری و کاربردی

مقدمه؛ Power BI کل معماری داده نیست

وقتی پروژه کوچک است، ممکن است Power BI مستقیم به Excel یا SQL وصل شود و همه‌چیز خوب پیش برود. اما در سازمان بزرگ ده‌ها سیستم منبع، میلیون‌ها رکورد و چندین تیم تحلیل داریم. اینجا باید Power BI را به عنوان بخشی از معماری کلان داده ببینیم، نه کل معماری.

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

۱۳.۱. تصویر کلان Enterprise BI

شکل ۱۳-۱ — نمای مفهومی معماری Enterprise BI

در یک معماری سازمانی معمولاً سیستم‌های منبع داده تولید می‌کنند، لایه Ingestion داده را جمع می‌کند، لایه تحلیلی آن را آماده می‌کند، Semantic Model منطق کسب‌وکار را ارائه می‌دهد و Power BI تجربه تحلیل را به کاربر می‌رساند.

۱۳.۲. سیستم عملیاتی با سیستم تحلیلی فرق دارد

ERP برای ثبت سفارش و عملیات روزانه ساخته شده، نه الزاماً برای اجرای ده‌ها Query تحلیلی سنگین. CRM هم برای مدیریت ارتباط با مشتری است، نه اینکه مستقیماً Data Warehouse باشد.

نکته: هر دیتابیسی که داده دارد، الزاماً بهترین منبع مستقیم برای گزارش سازمانی نیست.

۱۳.۳. OLTP و Analytics

هدف این جدول ساده‌سازی مفهوم است؛ معماری واقعی بسته به سیستم و زیرساخت می‌تواند متفاوت باشد.

۱۳.۴. Data Warehouse چیست؟

Data Warehouse یک مخزن تحلیلی ساختاریافته است که داده چند منبع را برای گزارش و تحلیل یکپارچه می‌کند.

ERP + CRM + Sales App
        ↓
Data Warehouse
        ↓
Power BI

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

۱۳.۵. چرا مستقیم به Production DB وصل نشویم؟

اتصال مستقیم همیشه اشتباه نیست، ولی در پروژه سازمانی باید اثر آن روی Performance، امنیت، تغییر Schema و پایداری بررسی شود.

اگر گزارش‌های متعدد Query سنگین به Database عملیاتی بزنند، ممکن است هم BI و هم سیستم اصلی آسیب ببینند.

۱۳.۶. ETL چیست؟

ETL یعنی Extract، Transform و Load؛ داده را از منبع می‌گیریم، تبدیل می‌کنیم و در مقصد تحلیلی بارگذاری می‌کنیم.

Extract → Transform → Load

۱۳.۷. ELT چیست؟

در ELT ابتدا داده وارد پلتفرم مقصد می‌شود و Transform بخش مهمی از پردازش در همان محیط انجام می‌شود.

Extract → Load → Transform

انتخاب ETL یا ELT به پلتفرم، حجم، معماری و ابزارهای سازمان بستگی دارد.

۱۳.۸. Data Lake

Data Lake برای نگهداری حجم زیادی از داده با شکل‌ها و ساختارهای مختلف کاربرد دارد؛ از فایل و Log تا داده خام سیستم‌ها.

اما وجود Data Lake به تنهایی به معنی آماده بودن داده برای مدیر نیست. داده خام هنوز نیاز به کیفیت، مدل و معنای کسب‌وکاری دارد.

۱۳.۹. Lakehouse

Lakehouse تلاش می‌کند مزایای Data Lake و قابلیت‌های تحلیلی ساختاریافته را در یک معماری نزدیک‌تر کند.

برای این کتاب مهم است بدانیم Lakehouse می‌تواند بخشی از لایه داده سازمان باشد و Power BI روی داده آماده‌شده آن تحلیل ارائه کند.

۱۳.۱۰. معماری Medallion

شکل ۱۳-۲ — مفهوم Bronze، Silver و Gold

در مدل مفهومی Medallion، Bronze معمولاً داده خام‌تر، Silver داده پاک‌سازی و همسان‌شده و Gold داده آماده مصرف کسب‌وکار است.

Bronze → Silver → Gold → Semantic Model → Report

۱۳.۱۱. Bronze؛ داده را از دست نده

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

۱۳.۱۲. Silver؛ تمیز و همسان

در Silver می‌توانیم Data Type، Duplicate، استاندارد کدها و همسان‌سازی منابع را مدیریت کنیم.

مثلاً کد مشتری ERP و CRM را به یک ساختار مشترک نزدیک کنیم.

۱۳.۱۳. Gold؛ زبان کسب‌وکار

Gold برای مصرف تحلیلی آماده‌تر است. Fact فروش، Dimension مشتری و Aggregateهای مورد نیاز می‌توانند در این لایه شکل بگیرند.

مرز دقیق لایه‌ها به معماری سازمان بستگی دارد؛ اصل مهم جدا کردن Raw Data از داده Business-ready است.

۱۳.۱۴. Semantic Model چیست؟

Semantic Model بین داده فنی و زبان کاربر کسب‌وکار قرار می‌گیرد. Relationshipها، Measureها، Hierarchyها و منطق تحلیلی در این لایه معنا پیدا می‌کنند.

Technical columns → Business measures
SalesAmount → Total Sales
CostAmount  → Profit
DateKey     → YTD / YoY

۱۳.۱۵. Semantic Model مشترک

شکل ۱۳-۳ — یک Semantic Model مرجع برای چند تجربه تحلیلی

به جای اینکه Executive، Finance و Branch هرکدام تعریف جداگانه‌ای از Total Sales بسازند، می‌توانند روی مدل معنایی Governed مشترک تکیه کنند.

۱۳.۱۶. Single Source of Truth؛ با احتیاط

عبارت Single Source of Truth جذاب است، ولی در عمل باید مشخص کنیم Truth درباره چه Domain و چه KPI است.

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

۱۳.۱۷. Domainهای کسب‌وکار

در سازمان بزرگ می‌توان Domainهایی مثل Sales، Finance، HR، Supply Chain و Production داشت.

Enterprise Data
 ├─ Sales
 ├─ Finance
 ├─ Supply Chain
 └─ Production

هر Domain می‌تواند مالک، مدل و نیازهای خاص داشته باشد ولی استانداردهای مشترک Governance را رعایت کند.

۱۳.۱۸. Conformed Dimensions

اگر Sales و Finance هر دو از Customer استفاده می‌کنند، Dimension مشترک و هم‌معنی می‌تواند تحلیل بین‌دامنه‌ای را قابل اعتمادتر کند.

DimDate
DimCustomer
DimProduct
DimBranch

تعریف مشترک Dimensionها باید با Master Data و مالک داده هماهنگ باشد.

۱۳.۱۹. Slowly Changing Dimension؛ مفهوم

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

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

۱۳.۲۰. Fact Granularity

قبل از ساخت Fact باید Grain را دقیق مشخص کنیم: هر ردیف نماینده چیست؟

FactSales grain:
One row = one order line

اگر Grain مبهم باشد، Measureها و Relationshipها هم دیر یا زود مشکل پیدا می‌کنند.

۱۳.۲۱. Aggregate

در داده بسیار بزرگ ممکن است برای برخی تحلیل‌ها Aggregateهای از پیش آماده مفید باشند.

ولی Aggregate نباید باعث شود تعریف KPI یا جزئیات مورد نیاز از بین برود. طراحی آن باید بر اساس الگوی Query واقعی انجام شود.

۱۳.۲۲. Batch و Near Real-Time

همه Dashboardها Real-Time لازم ندارند. گزارش مالی ممکن است روزانه Refresh شود، ولی مانیتورینگ خط تولید شاید تأخیر بسیار کمتری بخواهد.

معماری را بر اساس SLA واقعی بساز، نه هیجان Real-Time.

۱۳.۲۳. Data Contract؛ مفهوم

وقتی تیم منبع ستونی را حذف یا معنی آن را تغییر می‌دهد، BI ممکن است بشکند. Data Contract کمک می‌کند انتظار بین تولیدکننده و مصرف‌کننده داده روشن باشد.

Field: SalesAmount
Type: Decimal
Meaning: approved net sales
Owner: ERP team
Change notice: required

۱۳.۲۴. Lineage

باید بتوانیم مسیر KPI را تا منبع دنبال کنیم.

Executive KPI
→ Measure
→ Semantic Model
→ Gold FactSales
→ ERP Sales Transaction

این قابلیت برای Audit، رفع خطا و Governance بسیار ارزشمند است.

۱۳.۲۵. Data Mart

Data Mart یک لایه تحلیلی متمرکز روی یک حوزه مثل فروش یا مالی است. در بعضی معماری‌ها Martها روی Data Warehouse یا پلتفرم مرکزی ساخته می‌شوند.

هدف Mart این است که داده مناسب یک Domain را قابل مصرف‌تر کند.

۱۳.۲۶. معماری شرکت هانا؛ نسخه ساده

ERP + CRM + Targets + Branch Files
                ↓
        Ingestion / ETL
                ↓
       Enterprise Data Layer
                ↓
          Sales Data Mart
                ↓
      Sales Semantic Model
                ↓
Executive | Branch | Product Reports

این معماری باعث می‌شود منطق فروش فقط داخل یک فایل PBIX دفن نشود.

۱۳.۲۷. نقش SQL Server در معماری

اگر زیرساخت سازمان SQL Server محور باشد، می‌توان Warehouse یا Data Mart را روی SQL Server طراحی کرد و Power BI را به لایه تحلیلی متصل کرد.

انتخاب فناوری باید بر اساس حجم، بودجه، Cloud/On-premises، مهارت تیم و نیاز آینده انجام شود.

۱۳.۲۸. Cloud یا On-Premises

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

۱۳.۲۹. Microsoft Fabric؛ جایگاه مفهومی

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

جزئیات قابلیت‌ها و Licensing ممکن است تغییر کنند؛ برای تصمیم پروژه واقعی باید مستندات جاری مایکروسافت بررسی شود.

۱۳.۳۰. چه زمانی معماری ساده کافی است؟

اگر یک تیم کوچک با داده محدود و یک منبع پایدار داریم، ساختن معماری Enterprise پیچیده ممکن است Overengineering باشد.

معماری باید به اندازه مسئله باشد و امکان رشد منطقی داشته باشد.

۱۳.۳۱. چه زمانی باید معماری را جدی‌تر کنیم؟

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

۱۳.۳۲. Anti-Pattern؛ PBIX به عنوان Data Warehouse

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

نکته: Power BI ابزار قدرتمندی است، ولی قرار نیست تمام مسئولیت پلتفرم داده سازمان را به تنهایی حمل کند.

۱۳.۳۳. معماری و Governance

معماری بدون Governance هم کافی نیست. باید Owner، Quality Rule، Security، Lineage و Lifecycle لایه‌های داده مشخص باشند.

فصل دوازدهم و سیزدهم در پروژه واقعی مکمل هم هستند.

۱۳.۳۴. خطاهای رایج Enterprise BI

خطای اول: اتصال هر Report مستقیم به هر Source.

خطای دوم: تعریف دوباره KPI در هر PBIX.

خطای سوم: Grain نامشخص Fact.

خطای چهارم: نبود Lineage.

خطای پنجم: Real-Time کردن همه چیز بدون نیاز.

خطای ششم: Data Lake بدون لایه Business-ready.

خطای هفتم: معماری پیچیده برای مسئله کوچک.

۱۳.۳۵. Best Practiceها

Grain را قبل از Fact مشخص کن.

لایه عملیاتی و تحلیلی را آگاهانه جدا کن.

تعریف KPI را در Semantic Model قابل استفاده مجدد قرار بده.

Dimensionهای مشترک را استاندارد کن.

Lineage و Ownership را حفظ کن.

SLA داده را بر اساس نیاز کسب‌وکار تعریف کن.

معماری را متناسب با مقیاس پروژه انتخاب کن.

۱۳.۳۶. تمرین پایه

برای شرکت هانا چهار Source فرضی ERP، CRM، فایل Target و سیستم شعب را رسم کن و مشخص کن هرکدام چه داده‌ای تولید می‌کنند.

۱۳.۳۷. تمرین متوسط

برای FactSales Grain تعریف کن و Dimensionهای Date، Product، Customer و Branch را مشخص کن.

۱۳.۳۸. تمرین کاربردی

یک معماری Bronze/Silver/Gold برای داده فروش طراحی کن. برای هر لایه سه نمونه Transform یا مسئولیت بنویس.

۱۳.۳۹. تمرین چالشی

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

۱۳.۴۰. پروژه نهایی فصل؛ Enterprise BI Blueprint شرکت هانا

برای شرکت هانا یک Blueprint معماری بساز.

در پایان باید بتوانی برای مدیر IT توضیح بدهی هر لایه چرا وجود دارد و برای مدیر کسب‌وکار توضیح بدهی چطور این معماری باعث اعتماد بیشتر به اعداد می‌شود.

جمع‌بندی فصل سیزدهم

Power BI در معماری Enterprise آخر زنجیره نیست، بلکه لایه مهم مصرف و تحلیل روی یک اکوسیستم داده است. هرچه سازمان بزرگ‌تر می‌شود، جدا کردن Source، Integration، Storage، Business Layer و Semantic Model ارزش بیشتری پیدا می‌کند.

Operational Systems
       ↓
Data Platform
       ↓
Business-ready Data
       ↓
Semantic Model
       ↓
Power BI
       ↓
Decision

در فصل بعد وارد پروژه جامع End-to-End می‌شویم و از دریافت نیاز مدیر تا ساخت مدل، DAX، Dashboard، امنیت، انتشار و Governance یک پروژه Power BI واقعی را یک‌جا اجرا می‌کنیم.