Forum Discussion
Dataflows vs SSIS
pbiuser10 I would spend my time getting to know and understand dataflows as that is the future. But that opinion doesn't mean anything if you aren't using the cloud, do all your work in SQL on premises, etc. Then learn SSIS.
Dataflows will open doors for the organization above and beyond what SSIS does in terms of centrally locating important data, based on all the M queries and ETL code you write in your Power BI files, and support all the latest and greatest MSFT offers with new features. SSIS is an old standby and really only way you could do ETL, things are changing, if you can - I suggest focusing on dataflows.
pbiuser10 I would spend my time getting to know and understand dataflows as that is the future. But that opinion doesn't mean anything if you aren't using the cloud, do all your work in SQL on premises, etc. Then learn SSIS.
Dataflows will open doors for the organization above and beyond what SSIS does in terms of centrally locating important data, based on all the M queries and ETL code you write in your Power BI files, and support all the latest and greatest MSFT offers with new features. SSIS is an old standby and really only way you could do ETL, things are changing, if you can - I suggest focusing on dataflows.
Sorry I couldn't disagree more. If you have a few dozen sssis packages then ssis integration runtime will be more expensive after that dataflows becomes expontially more expensive. With a few hundred ssis packages dataflows is 2-3 times more expensive that leaving an ssis integration runtime on all the time. What Microsoft is not telling anyone is that once you use a dataflow to spin up the spark cluster and reuse it for the next dataflows you have to take into the price calculation the cosumption cost of each dataflow and the total time the spark cluster was on. In essence you are paying to have the cluster on and everytime you use it, thus double paying.