there are two fundamentally different approaches to data analytics - code based and visual based. this is possibly why "data science" and "business intelligence" have diverged
As someone who has gotten into the Data world recently, I prefer the visual to the code. In fact, my usual approach to analyse any new dataset is to immediately load it into Power BI to look at some key visuals and what insights it might give before the heavy lifting using code begins. Excel is too clunky for whipping up quick visuals
A few points about Power BI :
1. Data Ingestion using M & Power Query simplies and automates a lot of data cleaning activity
because each transformation is stored as a step which helps avoid repetitive effort as would be
required in Excel
2. Data modeling is very convenient using drag & drop and automatic identification of relationships.
Also the Data model can be comprehended visually which is quite helpful
3. Visual tweaking and formatting features are quite comprehensive
4. The Power BI workspace for deployment, automatic data refresh schedules and flexibility of d
distribution is what makes it the go-to dashboarding environment.This significantly reduces
maintenance of published dashboards
5. Just like in PPT & Excel one can use UI elements ( shapes etc. ) with an embedded action using VB
- one can do the same in Power BI but I have not had the need to use it till now
6. Now there is also support for Python embedding in Power BI - One can do two things, one is data transformation using Python if you dont want to use DAX and M and the second is you can embed python visuals (Seaborn etc.) in Power BI
An expert R/Python programmer would prefer the "code "approach, while a PowerBI expert would bat for the "drag & drop" ("GUI" or "visual") approach. If every visual requirement (think of complex graphs) could be achieved in both the approaches then I think the whole comparison doesn't matter much (it might matter in relatively smaller aspects like re-use and other things). The critical difference is that some visual requirements simply cannot be met by the "visual" approach. I think the visual approach comes handy when the analysis is a one-time activity and straightforward. The biggest advantage with visual tools like PowerBI is the ability to rapidly build visuals, even an expert programmer would require some time to build a basic graph with code.
The formality & software engineering aspect with the "code" approach (con) in the last bullet doesn't hold- you can always work in a prototype/PoC mode and override all software engineering standards. This is quite common now in the industry.
Another big advantage with the "code" approach is that the data analysis might clear out some questions on the data, following this the next phase of building a data science model might start. With a code approach you can continue this smoothly (think of Jupyter notebooks), while in a "visual" approach either you handover to another person or start a new code IDE now.
which is why i think the ideal thing is to have "best of both worlds" such a a notebook interface. where you use code to do ad hoc one time analysis, and hten take it to a separate location to productionise
As someone who has gotten into the Data world recently, I prefer the visual to the code. In fact, my usual approach to analyse any new dataset is to immediately load it into Power BI to look at some key visuals and what insights it might give before the heavy lifting using code begins. Excel is too clunky for whipping up quick visuals
A few points about Power BI :
1. Data Ingestion using M & Power Query simplies and automates a lot of data cleaning activity
because each transformation is stored as a step which helps avoid repetitive effort as would be
required in Excel
2. Data modeling is very convenient using drag & drop and automatic identification of relationships.
Also the Data model can be comprehended visually which is quite helpful
3. Visual tweaking and formatting features are quite comprehensive
4. The Power BI workspace for deployment, automatic data refresh schedules and flexibility of d
distribution is what makes it the go-to dashboarding environment.This significantly reduces
maintenance of published dashboards
5. Just like in PPT & Excel one can use UI elements ( shapes etc. ) with an embedded action using VB
- one can do the same in Power BI but I have not had the need to use it till now
6. Now there is also support for Python embedding in Power BI - One can do two things, one is data transformation using Python if you dont want to use DAX and M and the second is you can embed python visuals (Seaborn etc.) in Power BI
that powerBI is superior to Excel is absolutely not in question.
what i'm wondering, though, is the speed - is doing the analysis visually using PowerBI faster than it would be were you code the thing?
An expert R/Python programmer would prefer the "code "approach, while a PowerBI expert would bat for the "drag & drop" ("GUI" or "visual") approach. If every visual requirement (think of complex graphs) could be achieved in both the approaches then I think the whole comparison doesn't matter much (it might matter in relatively smaller aspects like re-use and other things). The critical difference is that some visual requirements simply cannot be met by the "visual" approach. I think the visual approach comes handy when the analysis is a one-time activity and straightforward. The biggest advantage with visual tools like PowerBI is the ability to rapidly build visuals, even an expert programmer would require some time to build a basic graph with code.
The formality & software engineering aspect with the "code" approach (con) in the last bullet doesn't hold- you can always work in a prototype/PoC mode and override all software engineering standards. This is quite common now in the industry.
Another big advantage with the "code" approach is that the data analysis might clear out some questions on the data, following this the next phase of building a data science model might start. With a code approach you can continue this smoothly (think of Jupyter notebooks), while in a "visual" approach either you handover to another person or start a new code IDE now.
~Mukund
which is why i think the ideal thing is to have "best of both worlds" such a a notebook interface. where you use code to do ad hoc one time analysis, and hten take it to a separate location to productionise