Getting data with Power BI¶
Exercise power-bi-get-data-annex.pdf · PDF
You have spent this unit inside one tool. You connected Superset to a database, asked it questions in SQL, and saved the answers as datasets and tables. Then you arrive at your work placement, and nobody there has heard of Superset. "We use Power BI", they say, and they give you a Windows laptop.
Do you start from zero? No. The sources are the same six. A database still asks for host, port, database, user and password. A CSV still has a separator. What changes is where the data end up once you have fetched them, and that one difference explains almost everything else about the tool.
On the last page you kept your work in two ways: a recipe (a saved query) or a tupperware (stored rows). Keep that kitchen in mind. Today's question is: does this tool keep the recipe or the tupperware?
What you will learn
- Say what Power BI Desktop is and how it differs from a tool that runs on a server
- Find a connector in the Get data window and say what kind of source it reaches
- Load a CSV file and a PostgreSQL table into Power BI, with the same connection settings you used in Superset
- Explain the difference between Import and DirectQuery, and choose one for a given case
- Compare where the data end up in Superset and in Power BI
- Avoid the trap: believing that "live" is always better than a copy
A tool with no server in the middle¶
Power BI is Microsoft's family of tools for turning data into charts and reports. Power BI Desktop is the program you install on a computer to build those reports.
Microsoft released Power BI to the general public on 24 July 2015, the same year Superset was born at Airbnb. It is a commercial product: a company owns it and sells services around it. Power BI Desktop itself is a free download, with one catch: it only runs on Windows. There is no version for Linux or macOS.
The big difference is in the plumbing. Compare the two pictures:
flowchart TB
subgraph SUP ["<b>Superset</b>: a server in the middle"]
direction LR
B1["Your browser"] --> S["Superset<br>on a server"] --> D1[("PostgreSQL")]
end
subgraph PBI ["<b>Power BI Desktop</b>: everything on your PC"]
direction LR
P["Power BI Desktop<br>on your Windows PC"] --> D2[("PostgreSQL")]
P --> F["<b>.pbix file</b><br>(the fridge)"]
end
In Superset, the connection is set up once, on the server, and everybody queries through it. In Power BI Desktop there is no server in the middle: the program runs on your PC, connects from your PC, and saves the result in a file on your PC.
A
.pbixfile is a Power BI report saved on disk: its charts, the description of where its data come from and, very often, a copy of the data.
Remember that file. In today's kitchen, it is the fridge.
A wall of connectors¶
In Power BI Desktop, every source starts at the same button: Home → Get data. Choose More... and the Get Data window opens with a long list of sources, grouped by category: File, Database, Online Services and others.
A connector is the piece of a tool that knows how to talk to one kind of source.
It is the same idea as the driver from Connecting Superset to a database, with a form in front of it. Scan the list and you will recognise old friends from Data sources:
| Connector | Category | The source it reaches | You already did this in Superset when... |
|---|---|---|---|
| Text/CSV | File | A CSV file | ...you uploaded pokemon_df.csv |
| PostgreSQL database | Database | A PostgreSQL server | ...you used the Dades classe connection |
| Excel workbook | File | An .xlsx file |
|
| JSON | File | A JSON file | |
| Web | Other | A web address, including an API | ...you could not: Superset needed a script first |
Same six kinds of source as always. Only the buttons are new.
Power BI changes every month
Microsoft updates Power BI Desktop monthly, and labels move. If a menu on your screen does not match this page word for word, look for the nearest name. The ideas here (connector, Import, DirectQuery) do not move.
Three ways in¶
You will bring the Pokémon into Power BI three times: from a file, from the database as a copy, and from the database live.
From a file¶
| Step | Do this | You should see |
|---|---|---|
| 1 | Home → Get data → Text/CSV, choose pokemon_df.csv, Open |
A preview of the table |
| 2 | Before pressing anything, read the three boxes at the top | File Origin (the encoding), Delimiter (Comma) and Data Type Detection (Based on first 200 rows) |
| 3 | Load | The Data pane on the right lists pokemon_df |
| 4 | Open the Table view (icon on the left bar) and find charmander |
949 rows. Look at its type_2 cell. |
Look at step 2 again. Those three boxes are the same three checks you learned to do in a text editor: encoding, separator, and what kind of value each column holds. Power BI guesses all three for you. A guess can be wrong.
Careful: \"it is the same file, so both tools read the same thing\"
Not quite. Our CSV writes a missing value as the two letters NA.
| Superset upload | Power BI | |
|---|---|---|
Charmander's type_2 |
NULL: an empty cell |
The text NA |
There is more. Power BI decides what kind of value each column holds by looking at the first 200 rows only, unless you change the Data Type Detection box. In the column generation_id, the first NA is in row 803, long after those 200 rows. So Power BI decides the column is a number, and then meets 147 cells that are not numbers. Go and look at what it did with them.
Same ingredients, two cooks, two dishes. Always look at what the tool did with your file before you trust a count.
From the database, as a copy¶
Now the same connection you know from Superset, in a new form. You need the table pokemon_by_generation that you built in Datasets and destination.
| Step | Do this | You should see |
|---|---|---|
| 1 | Home → Get data → More... → Database → PostgreSQL database → Connect | A window with two boxes: Server and Database |
| 2 | Server: the host of your database. Database: its name. | Both are given to you in class |
| 3 | Data Connectivity mode: choose Import, then OK | A window asking who you are |
| 4 | On the left choose Database (not Windows), type your user name and password, Connect | A warning that the connection is not encrypted |
| 5 | Read the warning, then OK | The Navigator: the list of tables you may read |
| 6 | Tick public.generations and public.pokemon_by_generation, then Load |
Both tables in the Data pane; each has 8 rows |
| 7 | File → Save as, name it pokemon_import.pbix |
A file on your disk |
Where did the five settings go?
| Setting | In Superset's form | In Power BI's PostgreSQL window |
|---|---|---|
| Host | Host | Server |
| Port | Port | Nowhere, if it is the usual 5432. Otherwise, added to the server as host:port. |
| Database | Database name | Database |
| User and password | Username, Password | The next window, on the Database tab |
| Driver | Installed on the Superset server (psycopg2) |
Built into Power BI Desktop |
Five settings and a translator, exactly as before. If the Server box gives you trouble, remember what a host is: a machine's name or address. No http:// in front, and not Superset's port 8088. That door belongs to Superset's web page, not to PostgreSQL.
What the encryption warning means
Encryption scrambles what travels over the network so that only the two ends can read it. Power BI is telling you that this connection is not scrambled: your password and your data cross the network in readable form. On a closed classroom network that is acceptable. On a real company network or over the internet, it is not, and the database should be set up to accept encrypted connections.
From the database, live¶
One more time, with one box changed.
| Step | Do this | You should see |
|---|---|---|
| 1 | File → New: a second, empty report | |
| 2 | Repeat steps 1 to 5 above, but choose DirectQuery instead of Import | The Navigator again |
| 3 | Tick only public.pokemon_by_generation, then Load |
The table in the Data pane |
| 4 | In the Data pane tick region and n_pokemon |
Power BI draws a chart of the eight regions. Unova is the tallest, with 156; Galar has 0. |
| 5 | Look at the left bar, and at the bottom-right corner of the window | The Table view is gone, and the status bar names the storage mode |
Why is the Table view gone? Because there is no table to view. In DirectQuery, Power BI holds no rows. Every chart you draw, every box you tick, sends a fresh query to the database.
Import or DirectQuery: tupperware or recipe¶
That one box, Data Connectivity mode, is the most important choice on this page.
Import copies the data into the report. DirectQuery leaves the data in the database and asks again every time a chart needs them.
In the kitchen:
- Import is the tupperware. You cooked once and stored the result. The fridge is the
.pbixfile. - DirectQuery is the recipe. Nothing is stored. Every chart orders from the kitchen again.
| Import (tupperware) | DirectQuery (recipe) | |
|---|---|---|
| Where the data live | A copy inside the .pbix file |
In the source database; nothing is copied |
| Speed | Fast: charts read the copy | As fast as the database answers each query |
| Freshness | As of the last time you pressed Refresh | Current: each chart asks the source |
| Works with | Every connector: files, web, databases | Only some connectors, mostly databases. Not Text/CSV. |
| Watch out | Big tables make big files. Cannot be switched to DirectQuery later. | A query that returns more than one million rows fails. Can be switched to Import, with no way back. |
And Superset? Which of the two does it resemble? DirectQuery. Superset never keeps your rows: every chart sends a query to the database. That was the first idea of Connecting Superset to a database, and now it has a name in another tool.
Careful: \"DirectQuery is better, it is live\"
It sounds better. It is slower and more limited. Microsoft's own documentation says to use Import by default, and to move beyond it only when something forces you to: data too big to copy, or changing too fast for a copy to be useful.
A CSV with 949 rows that never changes? Import, obviously: a file can only be imported, and the copy is tiny. A sales database with new rows every minute, shown on a screen in the shop? That is a case for DirectQuery.
Careful: \"Power BI is connected to my CSV\"
It read the file once and kept a copy. Edit the CSV afterwards and the report will not notice, until somebody presses Refresh. A tupperware does not refill itself.
An API in one window¶
Remember what it took to get 20 Pokémon from the PokéAPI into Superset: a Python script, a CSV file and an upload. Superset only talks to databases, so the API had to be extracted and loaded first.
Power BI has a connector for that.
| Step | Do this | You should see |
|---|---|---|
| 1 | Get data → Web, keep Basic, paste https://pokeapi.co/api/v2/pokemon?limit=20, OK |
A window asking how to sign in |
| 2 | Choose Anonymous, then Connect | The Power Query Editor opens with the JSON already read: count, next, previous, and results shown as a List |
| 3 | Click into results, convert the list to a table and expand it |
20 rows, with the columns name and url |
No script. Is the API problem solved, then? Be honest about what you got:
| Still your problem | Why |
|---|---|
| Only page 1 arrived | The API hands out its list in pages. The next field holds the address of the following page, and nobody fetched it. |
| The details are elsewhere | Each Pokémon's stats live at its own address: the url column. That is 20 more questions to ask. |
| It is a tupperware again | The Web connector imports. The report shows the API as it was when you loaded it. |
What Power BI adds is that the flattening step (turning nested JSON into rows and columns) is done with clicks instead of code. Those clicks have a name, Power Query, and a page of their own in the next unit: Power Query.
Superset and Power BI, side by side¶
Everything on this page in one table.
| Superset | Power BI Desktop | |
|---|---|---|
| Who makes it | An open-source project of the Apache Software Foundation | Microsoft, a commercial product |
| Where it runs | On a server; you use it from a browser | On your Windows PC |
| PostgreSQL | One shared connection, set up once. Driver installed on the server. | Each report connects by itself. Driver included in the program. |
| A CSV file | Uploaded into the database: it becomes a table everybody can query | Read into the report: a copy inside the .pbix file |
| Where the data end up | In the database, always. Superset asks again each time. | Import: a copy in the .pbix. DirectQuery: they stay in the database. |
| An API that answers in JSON | Not directly: extract, flatten and load into the database first | The Web connector reads it; you flatten with clicks. Import only. |
Neither column is "the good one". A team that shares one database and wants everybody to see the same numbers is well served by a server in the middle. One person exploring a file on a laptop is well served by a program that just opens it. Knowing which situation you are in is the skill.
Try it: same data, another tool¶
You need a Windows PC with Power BI Desktop, the file pokemon_df.csv from the Resources page, and the connection details of your class database.
Do the three routes of this page, then fill in this card:
| Field | What to write |
|---|---|
| The three boxes of the CSV preview | File origin, delimiter, data type detection |
charmander, type_2 |
What Power BI shows, and what Superset showed for the same cell |
| The five connection settings | Where each one went in the PostgreSQL window |
| The encryption warning | One sentence: what is not protected? |
generation_id |
What did Power BI do with the 147 cells that say NA? |
| Import and DirectQuery | Two differences you saw on screen |
No Windows PC at home? Do the card from your class notes, and answer the last question from the comparison table instead.
Key takeaways¶
- Power BI Desktop is Microsoft's report-building program. It is free to download, runs only on Windows, and has no server in the middle: the result is a
.pbixfile on your PC. - A connector is Power BI's version of a driver with a form in front. The sources are the same six as always, and a database still asks for host, port, database, user and password.
- Import copies the data into the
.pbix(the tupperware); DirectQuery leaves them in the database and asks again each time (the recipe). - Microsoft's advice is Import by default. DirectQuery is for data too big or too fast-changing to copy, and it only works with some connectors.
- Superset behaves like DirectQuery: it never keeps your rows. A CSV uploaded in Superset becomes a table in the database; a CSV loaded in Power BI becomes a copy in the report.
- Two tools can read the same file differently:
NAbecameNULLin Superset and stayed as text in Power BI. Always check what the tool did.
Quick check¶
1. What is a connector in Power BI?
- The cable between the PC and the server
- The piece of the tool that knows how to talk to one kind of source
- A saved query that Power BI runs every morning
- The file where the report is stored
A connector is the same idea as a driver, with a form in front: one for Text/CSV, one for PostgreSQL, one for Web, and so on. The file where a report is stored is the .pbix.
2. You load a table with Import and save the report. Where are the rows now?
- Only in the database
- On Microsoft's servers
- In a copy inside the
.pbixfile - Nowhere: Power BI asks the database again for each chart
Import is the tupperware: the rows are copied into the report file. Asking the database again for each chart is what DirectQuery does.
3. Which Power BI mode behaves most like Superset?
- Import, because both keep a copy of the data
- DirectQuery, because both leave the data in the database and send a query each time
- Neither: Superset stores data in
.pbixfiles too - Both, depending on the chart
Superset is a client that never keeps your rows: every chart is a query to the database. That is exactly what DirectQuery does in Power BI.
4. In the PostgreSQL window of Power BI, where does the host go?
- In the Database box
- In the Server box
- In the user name box, after an
@ - Nowhere: Power BI finds the database by itself
Power BI calls the host Server. The port is only added (as host:port) when it is not the usual 5432, the database name goes in Database, and user and password are asked in the next window.
5. Charmander's type_2 is NULL in Superset and the text NA in Power BI. Both read the same CSV. What is the lesson?
- One of the two tools has a bug
- The CSV file was damaged by the second tool
- Each tool makes its own decisions when it reads a file, so you must check what it did
-
NULLandNAare two names for exactly the same thing
The file only contains the letters NA. Superset's upload turned them into a real empty value, NULL; Power BI kept them as text. A count of "Pokémon with no second type" would be written differently in each tool. Same ingredients, two cooks.
6. Why does Microsoft recommend Import by default?
- Because DirectQuery costs extra money
- Because Import always shows the most recent data
- Because charts read a local copy, so it is fast and works with every connector
- Because DirectQuery does not work with databases
Import is fast (charts read the copy) and every connector supports it. Its price is freshness: the data are as old as the last Refresh. DirectQuery is the opposite trade: current, but slower and limited to some connectors, mostly databases.
7. A shop's sales database gets new rows every minute and a screen in the shop must show today's sales right now. A teacher has a CSV with 949 rows that never changes. Pick the two right choices.
- The shop screen uses DirectQuery: the data stay in the database and every chart asks again
- The shop screen uses Import: a copy is always up to date
- The teacher's CSV is imported: a file can only be imported, and a copy of 949 rows is small and fast
- The teacher's CSV uses DirectQuery so that it stays live
Data that change too fast for a copy are the case for DirectQuery. A small file that never changes is the perfect tupperware, and the Text/CSV connector only supports Import anyway.
That closes Unit 1: you can find a source, get in, ask for exactly what you need, store the result, and do it in two different tools. But what you fetched is not clean yet. You have already seen NA, NULL and a column that could not make up its mind. Next unit, you fix that: Unit 2 · Cleaning and transforming data.