Ola retweeted
What is the grain of a table?
It is one of those terms that sounds like modelling jargon, gets skipped in every beginner course, and then quietly causes more wrong numbers than any other single idea in analytics.
Worse, people are handed joins long before anyone explains grain to them, which is roughly like being taught to drive before anyone mentions which side of the road to use.
The usual definition is level of detail, which is accurate and completely useless, because it does not tell you what to do differently on Monday.
1. The test, which is better than a definition
Finish this sentence about any table in front of you.
“One row in this table is one _________”
If you can complete it in a single clause, you know the grain. One row is one order. One row is one order line. One row is one customer per month. One row is one page view.
If you find yourself needing an "and sometimes" or a "depending on", you do not know the grain yet, and nothing you build on top of that table is safe.
2. Grain is a decision, not a property
Take the same handful of facts and you can build three different tables.
• One row per order, which gives you two rows and the amount sitting once against each
• One row per order line, which gives you four rows because one order had three items in it
• One row per customer per month, which gives you two rows again but means something entirely different
None of these is more correct than the others. Somebody chose, and if you do not know which choice they made, you are guessing.
3. The join that doubles your money
Here is the part that costs people their afternoon.
Two orders, worth 150 between them. Join them to their order lines on order_id, then sum the amount.
Order 1001 has three lines, so its 100 appears three times in the result. Order 1002 has one line, so its 50 appears once.
The sum comes back as 350.
The real revenue is 150. The query threw no error. The join did exactly what a join is supposed to do, which is multiply rows, and the amount stopped being safe to add the moment it was repeated.
4. Why it survives review
Because 350 looks like money.
It is not a negative number, it is not a null, it is not a date in 1970. It is a plausible figure sitting in a plausible column, and it will be read out in a meeting by somebody who has no reason to doubt it.
Wrong numbers that look wrong get caught in an afternoon. Wrong numbers that look right get caught in a quarter, usually by someone outside the team.
5. The four checks
- Say the grain out loud before writing any SQL, for every table in the join, not just the one you are starting from
- Count the rows before and after. If the count grew, you fanned out, and you now have a decision to make rather than a result
- Confirm the join key is unique on at least one side, because uniqueness on one side is the entire thing that makes a join safe
- Never sum a column that arrived from the one side of a one to many join, and if you must, aggregate the many side down first
The questions that actually matter
→ What is one row here, said in one clause?
→ After this join, what is one row now?
→ Which of these columns are still safe to add?
→ If this total is wrong, how long before anybody notices?
If you step back, grain is not really a modelling concept at all. It is the habit of knowing what you are counting before you count it.
Which sounds obvious written down, and is the single most commonly skipped step in the whole job.
#DataAnalytics #datascience #DataEngineering
Ola retweeted
The amount of companies using humans to train their own replacements is mad.
The future is in the hands of robots at this point. Bleak.
Ola retweeted
Dear Data Analyst,
Two orders worth $150 between them. Join to order lines, sum the amount, and the answer comes back $350.
Nothing in the query is broken. Order 1001 had three lines, so its $100 came along three times, and the moment it was repeated it stopped being safe to add.
The grain of a table is what one row represents. Joining two tables at different grains is how revenue quietly doubles.
#dataanalytics #dataengineering #datascience
Ola retweeted
Why Excel never clicks, and what to learn instead of fifty formulas
Ask how to get started with Excel and you will be handed a list of functions, usually fifty of them, sorted alphabetically and useless.
It is the wrong shape for the problem, because Excel is not a collection of functions that happen to share a window. It is one idea with about forty years of features built on top of it, and the idea is that a cell can point at another cell.
Once that lands, most of the confusion goes with it.
1. Everything is a reference
Columns are letters, rows are numbers, so every cell has an address and every formula is built out of addresses. B4 is column B, row 4. B2:B50 is everything down that stretch.
The equals sign is the switch. Type 2+2 and Excel stores the text 2+2, because you have given it a note. Type =2+2 and you have given it an instruction.
That is the entire grammar.
2. Which is why the dollar sign matters more than any function
Here is where almost every beginner loses an afternoon.
Write =B2*E1 where E1 holds your VAT rate, drag it down the column, and the B2 helpfully becomes B3 and B4 as it goes, which is what you wanted. The E1 also becomes E2 and E3, which is not, and now your formula is multiplying by empty cells.
The totals do not throw an error. They just come out wrong in a way that looks close enough to pass.
→ Write it as =B2*$E$1 and the rate stays pinned while the rows move
→ F4 cycles through the pinning options while you are still typing
No function on any list will save you from not knowing this.
3. Learn to read the cell, not just the formula
Excel tells you what it thinks your data is, and almost nobody looks.
Numbers sit against the right edge of a cell. Text sits against the left. So a column of figures hugging the left is not a column of figures, it is a column of text that looks like figures, and SUM will return zero without a word of complaint.
It is a free diagnostic sitting in plain sight, and it is the first thing to check whenever a total refuses to behave.
4. Name things, or your future self will not know what you meant
Ctrl and T turns a range into a Table, which names its own columns and stretches as new rows arrive.
Your formula then reads =SUM(Sales[total]) rather than =SUM(D2:D500), which still makes sense when you open the file next year, and it stops breaking every time someone adds a row underneath.
→ One header row, no merged cells, no blank rows in the middle
5. You need five functions, not fifty
SUM to add up, AVERAGE for the middle, COUNT for how many, MIN and MAX for the ends. Then IF when you need the sheet to choose rather than calculate, and XLOOKUP when you need to pull a value out of another table.
That is genuinely most of it. XLOOKUP needs Microsoft 365 or Excel 2021 and later, so on anything older you are stuck with VLOOKUP, which is worth knowing only because you will inherit it in other people's files.
6. The PivotTable replaces the work you are about to do by hand
If you find yourself grouping rows manually to produce a summary, stop, because dragging one field into rows and another into values does it in about four seconds and updates when the data changes.
Most of the manual spreadsheet work I see people doing is a PivotTable they have not met yet.
The questions that actually matter
Once the grammar is in place, the useful questions stop being about formulas:
- Is this cell a value, a formula, or text pretending to be a number?
- If I drag this down, which parts of it should move and which should not?
- Will this formula still make sense to someone opening it in a year?
- Am I doing by hand something the tool was built to do?
If you step back, getting started with Excel is not about collecting functions at all. It is about understanding that a cell can point somewhere, and then being deliberate about where.
Everything on the function list is just that idea wearing different clothes.
Ola retweeted
NVIDIA’s $100 Billion Bet: Why NVIDIA Just Re-Engineered Personal Computing From Scratch
Ola retweeted
Hate or Love, coming from someone you don’t know shouldn’t bother you. Take it as a feedback!
Ola retweeted
Excel is not a list of functions, and learning it as one is why it never clicks for you.
People go looking for fifty formulas when the whole thing rests on a single idea, which is that a cell can point at another cell. Everything else is consequences of that.
Which is why the dollar sign matters more than any function on the list. Write =B2*E1, drag it down, and the E1 quietly becomes E2, then E3, and your formula is now multiplying by empty cells while the totals still look almost plausible. Pin it as $E$1 and it stays where you put it. F4 cycles through the options while you type.
After that, learn to read the cell rather than the formula. Numbers sit on the right, text sits on the left, so a column of figures hugging the left edge is secretly text and SUM will return zero without telling you anything is wrong.
Then Ctrl and T, because a Table names its own columns and grows as rows arrive, so your formula reads SUM of Sales total instead of a range of coordinates that means nothing to you in six months.
#excel #DataAnalytics
Ola retweeted
Dear Data Analyst,
If ten people in a room earn £30k each and then a millionaire walks in, the "average" salary in that room jumps to over £100k, even though nobody else got a pay rise.
That's why as an analyst you often look at the median as well, because it tells you what's normal rather than what's been dragged up by one value.
#DataScience #DataAnalytics
Ola retweeted
What statistics do you actually need as a data analyst?
This is one of those questions where the honest answer sounds like a let down, because people expect a reading list and what they actually need is the ability to read about eight numbers properly.
In Python, when using the Pandas library, run df.describe() on a table and that is roughly what comes back. Count, mean, standard deviation, min, 25%, 50%, 75%, max. For most reporting work, being fluent in those eight is the bulk of it, and the gap between knowing the words and knowing what they oblige you to do is where the real skill sits.
1️⃣ The gap between the mean and the median is the whole story
Take one column of order values. Mean 68.40, median 44.50, max 2450.
Those three numbers together tell you everything. The mean sitting well above the median means a long tail of large orders is dragging it upward, and the max confirms where that tail goes.
So when someone asks what a typical order is worth, the answer is 44.50 and not 68.40.
Both are correct. Only one is honest. Reporting the mean on skewed money or skewed time is the most common way a report ends up technically accurate and completely misleading, and nobody catches it because the number looks fine.
2️⃣ An average with no spread beside it is not information
Two teams can both average three days to deliver, where one is consistently between two and four and the other swings between one and twenty one. Same average, completely different business.
Standard deviation and the interquartile range are what separate those two stories, and without one of them the average is just a shape with no content.
👉 Quote the spread next to the average, every time
3️⃣ The count is not decoration
A conversion rate off twelve rows is a rumour. The same rate off twelve thousand is a finding. The percentage itself gives you no way to tell which one you are holding, so the count has to travel with it wherever it goes.
This is also why percentages in small segments look so exciting and so often evaporate the following month.
4️⃣ Percentiles are where promises get made
Delivery times, page loads, support response, all of it is agreed at p95 rather than at the average, because nobody has ever complained about having the median experience.
If your target is an average, you have promised nothing to the people most likely to be upset.
5️⃣ The two that make you confidently wrong
Correlation and causation is the one everyone can recite and almost nobody applies. Ice cream sales and drowning rise together, the weather drives both, and the useful habit is asking what third thing could be moving both before you write a recommendation.
Simpson's paradox is the sharper one, and it gets reported backwards constantly. A version of a page can win on desktop, win on mobile, and still lose the overall total, purely because the traffic sat in different proportions. Win every segment, lose the headline.
👉 Always check the aggregate against the breakdown, in both directions
6️⃣ What a p-value does not say
A p-value is the probability of seeing data at least this extreme if nothing is really going on.
It is not the probability that your finding is real, and it is not the probability that the result was a fluke. Those two readings are everywhere, including in a lot of beginner material, and they are both wrong.
The questions that actually matter
Once the vocabulary stops being intimidating, the useful questions are not statistical any more:
• Which average am I entitled to quote here, and why?
• How many rows is this percentage standing on?
• Does the total still hold when I split it?
• If I am wrong about this, who makes a bad decision?
If you step back, none of this is about statistics as a subject. It is about not accidentally telling your organisation something untrue while holding a correct number.
Which is a lower bar than a statistics degree, and a much harder one to clear in practice.
#statistics #DataScience
Ola retweeted
⚠️Why Millions of People Are Quietly Trusting AI More Than Humans, says Yuval Noah Harari
Ola retweeted
What actually happens when you create a Fabric Lakehouse?
Most guides tell you to click New item, choose Lakehouse, give it a name, and congratulations, you have a lakehouse. All of which is true, and all of which stops being useful the moment you try to do anything real with it.
The confusion is not about the clicking. It is about what you actually received when you clicked, because one click hands you three separate things and each one behaves differently from the others.
A lakehouse is not a database you write into. It is a storage layer with a read surface attached, and nearly every problem people hit in their first project comes from not knowing which half of it they are standing in.
1️⃣ One click, three items
When the lakehouse is provisioned you get the lakehouse itself, a SQL analytics endpoint, and a semantic model. They share a name, they live in the same workspace, and they do completely different jobs.
• The lakehouse is where data gets written, through Spark
• The SQL analytics endpoint is where data gets read, through T-SQL
• The semantic model is what Power BI connects to, through Direct Lake
Nobody says this out loud at the start, so people lose a day trying to make one of them behave like the other two.
2️⃣ The endpoint is read only, and this is the biggest time sink in Fabric
You can run SELECT against your Delta tables, you can create views, functions and stored procedures, you can apply object, column and row level security, and you still cannot insert, update or delete a single row through it.
If you need to change data, you go back to the lakehouse and use Spark.
That is not an oversight waiting to be fixed in a future release, it is the shape of the product, and accepting it early saves you an afternoon of assuming you have configured something wrong.
3️⃣ Files and Tables are not two words for the same place
A lakehouse has two sections, and the difference between them decides what is actually queryable.
• Files holds raw drops, CSV, JSON, Parquet, whatever arrived
• Tables holds managed Delta tables
Only the Tables folder gets scanned, and only Delta Parquet gets discovered automatically. So the CSV you uploaded is sitting there in plain sight and will never show up as a table until something writes it out properly. That is usually the first hour a beginner loses, and it looks like a bug rather than a rule.
4️⃣ Shortcuts mean you often do not need to load anything at all
A shortcut points at data living somewhere else, ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse, or another workspace in OneLake, and queries it where it already is without copying a byte.
Which is worth sitting with before you build an ingestion pipeline, because the question is not how do I move this data, it is whether this data needs moving.
The questions that actually matter.
Once the mechanics stop being mysterious, the useful questions are not technical any more:
• Which layer does this table belong to, bronze, silver or gold?
• Who is allowed to write to it, and with what?
• What breaks downstream if it arrives late?
• Is anyone actually reading the gold tables, or did we build them for ourselves?
If you step back, getting started with a lakehouse is not really about the clicking at all. It is about holding two ideas at once, that you have a write side and a read side, and that keeping them straight is most of the job.
Everything after that is Delta tables in a folder.
#fabric #DataScience #dataengineering
Ola retweeted
Creating a Fabric Lakehouse gives you three things, not one.
1️⃣ A lakehouse, where data is written with Spark.
2️⃣ A SQL analytics endpoint, where data is read with T-SQL.
3️⃣ A semantic model, which Power BI connects to.
Most of week one is spent trying to make one of them behave like another. The endpoint in particular is read only, so no insert, no update, no delete.
#fabric #dataengineering #dataanalytics
Ola retweeted
Why Millions of People Are Quietly Trading Human Trust for AI - Yuval Noah Harari’s Shocking Warning
Ola retweeted
SQL for Beginners 🎯
SELECT, FROM, WHERE. That's most of SQL. Everything else is detail people argue about.
Three words and you can already ask a table a real question. Which columns you want, which table they're in, which rows to keep.
Then four more do the heavy lifting. ORDER BY sorts it. LIMIT cuts it short. GROUP BY turns a list of orders into an actual answer. JOIN sticks two tables together, and it's nowhere near as scary as people make out.
Slide 9 is the one that saves you a week. SQL doesn't run in the order you write it, which is why your errors make no sense at first.
Slide 10 is every piece doing one job in a single query. Screenshot that one.
Every example uses the same shop, so you're never learning two things at once.












