Forum Discussion

jochenj's avatar
jochenj
Advocate III
2 years ago
Solved

Azure AS Migration Migration Experience from the Fields, Open Questions

we plan to migrate an existing Enterprise Reporting Solution to MS Fabric which is baed on Azure Analysis Services + around 250 Power BI Pro and ~300 AzureAS-XMLA-Endoint Users (3rd Party OLAP Tool).  I wanted to share my experience on this journey so far and hope that anyone can bring new ideas to make that planned migration a success.

We struggle to find the right architecture/setup to bring operational costs and added values and opportunies by new fabric features in a balance.  For the evaluated scenarios so far the costs with fabric would explode (would need to use at least F256 or maybe even F512 which would be basically 12 times more expensive then the current solution which is ~3500€/Month).

Situation:

  • Azure Analysis Services (AzureAS) hosting one Model with Import-Mode
  • daily scheduled load via on premises Gateway from SQL Server DB/DWH (~700GB but only fraction is loaded to AzureAS)
  • SSMS shows in DB properties ~40GB estimated Size of Model,  ~250 Tables and hundreds of DAX Measures in Model
  • processing mode (early morning for 2hours)
    • Pricing-Tier used = S8v2   (which is 200 GB Memory, 640QPUs)
    • Azure Metric for "Memory" show peaks up to 111GB  
  • normal reporting mode during day
    • Pricing-Tier used = S4 (which is 100GB Memory, 400QPUs)
    • Azure Metric for "Memory" shows peaks up to 79GB, baseline average ~50-60GB)

 

Challenges:

Memory in AzureAS world is very "cheap" or otherwise available Memory in Fabric SKUs is very rare/expensive:

 

Scenarios we evaluated so far:

  1. Fabric Warehouse -> Shortcuts > Fabric Lakehouse > DirectLake > Power BI
    • Findings: Most promising but get "capacity limit" reached errors on report queris, maybe because no table-partitions?!
    • Is there any option to create Table-Partitions in Model when using DirectLake Mode?
  2. Fabric Warehouse > DirectQuery > Power BI
    • Findings: Works in some report-query cases really great,
    • but also many report-query cases where we run in timeouts (DirectQuery SQL Execution Plan shows nightmares when trying to translate DAX to SQL)
  3. Fabric Warehouse > ImportMode > Power BI
    • Even when creating small table permission we get "out of memory" on processing when using up to F256-SKU
    • For report-query loads we would also need at least F256

Constraints

  • Massive Re-Modelling the existing Model to increase performance is no option 

Any ideas/thougts are higly welcome !

 

 

1 Reply