Power BI Dataflows vs ADF Mapping Data Flows
An enterprise client wants to migrate many Alteryx workflows created over years by smart business users to the Microsoft ecosystem. During the initial intake, we discussed Power BI dataflows vs Azure Data Factory mapping data flows. Yep, Microsoft loves to confuse us, but these technologies have nothing to do with each other.
| Power BI Dataflows | ADF mapping data flows | |
| Target audience | Business users | Professionals |
| Availability | Power BI Service | Azure Data Factory and Synapse Studio |
| Underlying technology | Power Query | Spark |
| Expression language | M Language | Expression functions evaluated to Spark data types |
| Computation Engine | Power BI Compute Engine | Spark clusters |
| Output | Azure Data Lake Storage (CSV files in CDM folders) | Many sinks |
| Debugging | N/A | Debug mode |
| Monitoring | Very basic (refresh failures) | Detail output |
In a nutshell, Power BI dataflows are meant for self-service ETL, where the business users would be responsible for creating and managing the ETL flows. By contrast, ADF mapping data flows target BI Pros. If you have been following my blog, you know that I’m big proponent for the ELT pattern for various reasons, mainly better performance and avoiding tool dependencies. Despite how much Microsoft promotes ADF mapping data flows, my typical data integration projects don’t use them. The last time I looked at them, they didn’t support ADF self-hosted runtimes, and they are a pain to debug. But if you must do transformations on the fly, e.g. when dumping data into files, then you obviously don’t have a choice.
So, what did the client decide to do? IT decided to take over the Alteryx workflows and convert them to Azure Data Factory. So much about self-service ETL.
