Microsoft Fabric، OneLake، Lakehouse، Warehouse و Direct Lake برای Power BI

شروع جلسه؛ Power BI دیگر فقط یک ابزار Report نیست

تا چند سال پیش معمولاً مسیر این بود: SQL Server یا Data Warehouse داشتیم، Power BI به آن وصل می‌شد و Report می‌ساختیم. در معماری جدید مایکروسافت، Power BI بخشی از یک پلتفرم Analytics بزرگ‌تر به نام Microsoft Fabric است.

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

۴۸.۱. Microsoft Fabric چیست؟

Fabric یک پلتفرم یکپارچه برای سناریوهای داده و Analytics است؛ هدفش این است که ingestion، engineering، warehousing، real-time analytics و BI را در یک تجربه نزدیک‌تر به هم قرار دهد.

۴۸.۲. تصویر کلی معماری

۴۸.۳. چرا Fabric برای Power BI مهم است؟

چون در پروژه‌های بزرگ مشکل فقط Visual نیست. باید Pipeline، Storage، Transformation، Warehouse، Security، Governance و Semantic Layer هم کنار هم طراحی شوند.

۴۸.۴. OneLake

OneLake را می‌توان به‌صورت مفهومی فضای ذخیره‌سازی یکپارچه داده در Fabric دید؛ هدف این است که تیم‌ها به جای ساخت جزیره‌های متعدد داده، روی یک پایه مشترک کار کنند.

۴۸.۵. OneLake با یک Folder ساده فرق دارد

موضوع فقط محل فایل نیست؛ OneLake بخشی از معماری داده Fabric است و تجربه‌های مختلف Fabric می‌توانند روی داده‌های آن کار کنند.

۴۸.۶. Lakehouse

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

۴۸.۷. چه چیزی داخل Lakehouse داریم؟

۴۸.۸. Warehouse

Warehouse برای سناریوهای تحلیلی SQL محور و مدل‌های ساختاریافته سازمانی مناسب است. تیم‌هایی که تجربه T-SQL و Data Warehouse دارند معمولاً با این الگو راحت‌ترند.

۴۸.۹. Lakehouse یا Warehouse؟

۴۸.۱۰. انتخاب مطلق نداریم

این‌طور نیست که یکی همیشه بهتر باشد. نوع تیم، Source، حجم داده، مهارت‌ها و معماری سازمان تعیین می‌کند کدام تجربه مناسب‌تر است.

۴۸.۱۱. Data Factory در Fabric

Data Factory برای ingestion، pipeline و orchestration داده استفاده می‌شود؛ یعنی داده را از Source بگیریم، جابه‌جا کنیم و مراحل پردازش را هماهنگ کنیم.

۴۸.۱۲. Pipeline

ERP / CRM / API → Ingestion → Raw data → Transform → Curated data → Semantic model

۴۸.۱۳. Dataflow

Dataflowها برای transformationهای low-code و Power Query محور مفیدند؛ اما برای هر حجم و هر مسئله‌ای تنها گزینه نیستند.

۴۸.۱۴. Notebook

در Data Engineering می‌توان از Notebook و ابزارهای پردازشی مناسب برای transformationهای پیچیده‌تر استفاده کرد.

۴۸.۱۵. Medallion Architecture

۴۸.۱۶. Bronze

Bronze معمولاً نزدیک‌ترین لایه به داده خام Source است. هدف این است که داده اصلی را با کمترین تغییر منطقی نگه داریم.

۴۸.۱۷. Silver

در Silver داده پاک‌سازی، استاندارد، Deduplicate و تا حدی یکپارچه می‌شود.

۴۸.۱۸. Gold

Gold داده آماده مصرف Business است؛ مثلاً FactSales، DimCustomer و Aggregateهای موردنیاز.

۴۸.۱۹. چرا Medallion مفید است؟

چون Transformation خام، Data Quality و منطق Business را از هم جدا می‌کند و Debug و Governance ساده‌تر می‌شود.

۴۸.۲۰. Semantic Model هنوز مهم است

حتی اگر Lakehouse عالی داشته باشی، Business User نباید برای هر نمودار خودش Join و تعریف KPI را دوباره بسازد. Semantic Model همچنان لایه معنی کسب‌وکار است.

۴۸.۲۱. Direct Lake

Direct Lake یک حالت دسترسی تحلیلی در اکوسیستم Fabric است که هدفش کاهش نیاز به Import سنتی و استفاده مستقیم‌تر از داده‌های موجود در OneLake برای Semantic Model است.

۴۸.۲۲. Direct Lake را جادو فرض نکن

Performance و رفتار واقعی به معماری، حجم، مدل و ظرفیت بستگی دارد. قبل از Production باید Benchmark و محدودیت‌های محیط واقعی بررسی شوند.

۴۸.۲۳. Import vs DirectQuery vs Direct Lake

۴۸.۲۴. هدف Direct Lake

ترکیب تجربه سریع تحلیلی با کاهش عملیات Import سنتی در سناریوهای مناسب.

۴۸.۲۵. Semantic Model در Fabric

مدل معنایی باید Measureها، Relationshipها، Formatting، Security و تعریف KPI را برای مصرف Power BI آماده کند.

۴۸.۲۶. Shortcut

یکی از ایده‌های مهم OneLake استفاده از Shortcut برای دسترسی منطقی به داده بدون تکثیر بی‌دلیل آن در بعضی سناریوهاست.

۴۸.۲۷. Data Duplication

هر Copy اضافه هزینه Storage، Refresh و Governance ایجاد می‌کند. معماری مدرن تلاش می‌کند Duplication غیرضروری را کاهش دهد.

۴۸.۲۸. Data Domain

داده‌ها را بر اساس Domainهایی مثل Sales، Finance و Operations سازمان‌دهی کن تا Ownership و Governance روشن‌تر باشد.

۴۸.۲۹. Data Product

یک Data Product فقط Table نیست؛ داده قابل اعتماد با Owner، SLA، Definition، Quality و مصرف‌کننده مشخص است.

۴۸.۳۰. مثال Data Product فروش

۴۸.۳۱. Data Quality در Fabric

Pipeline موفق به معنی داده صحیح نیست. همان Quality Gateهایی که در Session 44 گفتیم باید در معماری Fabric هم وجود داشته باشند.

۴۸.۳۲. Schema Evolution

تغییر Schema Source می‌تواند Pipeline، Lakehouse و Semantic Model را تحت تأثیر قرار دهد. Data Contract هنوز اهمیت دارد.

۴۸.۳۳. Security

امنیت باید از Storage و Workspace تا Semantic Model و Report طراحی شود؛ RLS فقط یک لایه از امنیت است.

۴۸.۳۴. Workspace Design

Workspaceهای Fabric را بر اساس Domain، Environment و Ownership طراحی کن؛ همان Governance جلسه 47 اینجا هم کاربرد دارد.

۴۸.۳۵. DEV/UAT/PROD

Fabric هم محصول داده است؛ پس محیط‌های توسعه، تست و Production و ALM جلسه 46 همچنان لازم‌اند.

۴۸.۳۶. Capacity

Fabric از مدل Capacity استفاده می‌کند و Workloadهای مختلف می‌توانند منابع مشترک را مصرف کنند. Capacity Planning بخش مهم معماری است.

۴۸.۳۷. همسایه پرمصرف

اگر Data Engineering Job سنگینی همزمان با Dashboardهای مدیریتی اجرا شود، ممکن است منابع مشترک تحت فشار قرار گیرند؛ Monitoring لازم است.

۴۸.۳۸. Cost Thinking

فقط هزینه License را نبین؛ Storage، Compute، Refresh، Engineering Time و عملیات هم هزینه‌اند.

۴۸.۳۹. Monitoring

Pipeline Duration، Failure، Capacity Utilization، Query Performance و Adoption باید مانیتور شوند.

۴۸.۴۰. Real-Time Analytics

برای سناریوهای نزدیک به Real-time، Fabric تجربه‌های مرتبط با Event و Real-Time Intelligence دارد؛ انتخاب معماری باید بر اساس Latency موردنیاز Business باشد.

۴۸.۴۱. همه Dashboardها Real-time نمی‌خواهند

گزارش مالی ماهانه نیازی به پیچیدگی Real-time ندارد. Latency را از Business Requirement بگیر.

۴۸.۴۲. Batch vs Near Real-time

۴۸.۴۳. Fabric برای تیم کوچک

اگر پروژه کوچک و SQL Server موجود کاملاً جواب می‌دهد، مهاجرت فوری به معماری پیچیده فقط برای استفاده از فناوری جدید لازم نیست.

۴۸.۴۴. Fabric برای Enterprise

وقتی Sourceها زیاد، حجم داده بالا، Data Engineering جدی و چند تیم مصرف‌کننده داریم، Fabric می‌تواند گزینه معماری مهمی باشد.

۴۸.۴۵. Migration Strategy

مهاجرت را Big Bang نکن. یک Domain یا Use Case را Pilot کن و Performance، Cost و Operations را اندازه بگیر.

۴۸.۴۶. Pilot

Select domain → Ingest → Bronze/Silver/Gold → Semantic model → Power BI → Measure outcome

۴۸.۴۷. معیار موفقیت Pilot

۴۸.۴۸. پروژه شرکت هانا؛ Sourceها

فرض کنیم ERP روی SQL Server، CRM، فایل‌های تولید و API فروش داریم.

۴۸.۴۹. پروژه؛ Ingestion

Data Factory داده‌ها را وارد لایه Bronze می‌کند. Raw data برای Traceability نگهداری می‌شود.

۴۸.۵۰. پروژه؛ Silver

Customer Codeها استاندارد، رکوردهای تکراری حذف و تاریخ‌ها یکسان می‌شوند.

۴۸.۵۱. پروژه؛ Gold

FactSales، FactProduction، DimCustomer، DimProduct، DimDate و Aggregateهای مدیریتی ساخته می‌شوند.

۴۸.۵۲. پروژه؛ Semantic Model

Measureهای Net Sales، Margin، OTIF و Production Efficiency روی Gold Layer تعریف می‌شوند.

۴۸.۵۳. پروژه؛ Power BI

Executive App و Sales/Operations Reportها از Semantic Modelهای Governed استفاده می‌کنند.

۴۸.۵۴. پروژه؛ Direct Lake

برای مدل مناسب Fabric، Direct Lake به عنوان گزینه Performance بررسی و با Import/DirectQuery Benchmark می‌شود.

۴۸.۵۵. پروژه؛ Governance

Sales و Operations Data Product هرکدام Owner دارند و CoE استاندارد Naming، Security و Deployment را کنترل می‌کند.

۴۸.۵۶. پروژه؛ SLA

۴۸.۵۷. معماری نهایی پروژه

Sources
  ↓
Data Factory
  ↓
OneLake / Bronze
  ↓
Silver
  ↓
Gold Lakehouse/Warehouse
  ↓
Semantic Models
  ↓
Power BI Apps

۴۸.۵۸. خطای رایج؛ Fabric = Power BI جدید

Fabric فقط تغییر نام Power BI نیست؛ پلتفرم گسترده‌تری برای چرخه داده و Analytics است.

۴۸.۵۹. خطای رایج؛ Lakehouse بدون مدل

ریختن همه فایل‌ها داخل Lakehouse به تنهایی معماری تحلیلی ایجاد نمی‌کند.

۴۸.۶۰. خطای رایج؛ Direct Lake برای همه

Storage Mode را باید بر اساس Benchmark و Requirement انتخاب کرد.

۴۸.۶۱. خطای رایج؛ همه‌چیز Real-time

پیچیدگی و هزینه را بالا می‌برد بدون اینکه Business Value داشته باشد.

۴۸.۶۲. خطای رایج؛ Migration یک‌باره

مهاجرت Domain به Domain ریسک را کمتر می‌کند.

۴۸.۶۳. خطای رایج؛ Governance بعداً

اگر Naming، Ownership و Workspace Strategy را از اول نداشته باشی، Fabric هم می‌تواند به مجموعه‌ای از Artifactهای پراکنده تبدیل شود.

۴۸.۶۴. Best Practiceها

Architecture را از Business Requirement شروع کن.

OneLake را پایه مشترک داده در Fabric در نظر بگیر.

Lakehouse و Warehouse را بر اساس Use Case انتخاب کن.

Bronze/Silver/Gold را برای جداسازی مسئولیت‌ها بررسی کن.

Semantic Layer را حذف نکن.

Direct Lake را Benchmark کن.

Data Product Owner داشته باش.

Quality و SLA تعریف کن.

DEV/UAT/PROD را حفظ کن.

Capacity و Cost را مانیتور کن.

Pilot انجام بده و بعد Scale کن.

۴۸.۶۵. تمرین ۱

یک معماری Fabric برای ERP + CRM + Excel طراحی کن و مشخص کن هر Source چطور وارد Bronze می‌شود.

۴۸.۶۶. تمرین ۲

برای Sales Domain جدول‌های Bronze، Silver و Gold را مثال بزن.

۴۸.۶۷. تمرین ۳

برای یک پروژه فرضی تصمیم بگیر Lakehouse بهتر است یا Warehouse و دلیل بنویس.

۴۸.۶۸. تمرین ۴

Import، DirectQuery و Direct Lake را برای مدل 100 میلیون Row مقایسه مفهومی کن.

۴۸.۶۹. تمرین ۵

یک Data Product Card شامل Owner، SLA، Quality، Consumers و Security بساز.

۴۸.۷۰. تمرین چالشی

برای کارخانه‌ای با داده ERP روزانه و IoT نزدیک Real-time، معماری Hybrid طراحی کن که هم Executive BI و هم Monitoring تولید را پوشش دهد.

۴۸.۷۱. پروژه Session؛ Fabric Architecture Pack

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

جمع‌بندی Session 48

Microsoft Fabric کمک می‌کند ingestion، storage، engineering، warehouse و BI را در یک معماری نزدیک‌تر به هم ببینیم. اما ابزار جدید جای اصول قدیمی را نمی‌گیرد: Grain، Data Quality، Semantic Model، Security، Governance و Business Value هنوز اصل ماجرا هستند.

Sources → OneLake → Trusted data products → Semantic models → Power BI decisions

Session 49: Power BI Embedded، REST API، Automation و Integration؛ جاسازی Report در نرم‌افزار، Service Principal، APIها و سناریوهای توسعه‌دهندگان.