Microsoft Fabric Data Warehouse - Simply Explained

1
00:00:00,000 --> 00:00:02,360
Welcome to another episode of Microsoft Knowledge Nuggets.

2
00:00:02,360 --> 00:00:04,200
I'm your host, Mirko Peters.

3
00:00:04,200 --> 00:00:06,400
Today's topic is one that almost everyone has heard of,

4
00:00:06,400 --> 00:00:08,960
but few understand Microsoft Fabrics Data Store.

5
00:00:08,960 --> 00:00:10,760
You've probably seen the marketing,

6
00:00:10,760 --> 00:00:14,280
one platform, unified analytics, end-to-end solution.

7
00:00:14,280 --> 00:00:16,640
But when someone inside Fabrics says data warehouse,

8
00:00:16,640 --> 00:00:18,040
what does that actually mean?

9
00:00:18,040 --> 00:00:20,120
Most people think it's just another SQL database.

10
00:00:20,120 --> 00:00:22,960
You create a table, run a select query, get results back,

11
00:00:22,960 --> 00:00:24,320
and on the surface, that's true.

12
00:00:24,320 --> 00:00:26,200
But underneath, it works very differently.

13
00:00:26,200 --> 00:00:28,040
That difference matters, especially if you're just getting

14
00:00:28,040 --> 00:00:30,080
started by the end of this episode,

15
00:00:30,080 --> 00:00:32,520
you'll understand what a fabric warehouse really is,

16
00:00:32,520 --> 00:00:34,760
how it's different from a traditional database,

17
00:00:34,760 --> 00:00:36,600
and why those differences matter

18
00:00:36,600 --> 00:00:38,720
for someone who just wants to work with data.

19
00:00:38,720 --> 00:00:42,240
No marketing fluff, no deep technical jargon, just plain English.

20
00:00:42,240 --> 00:00:43,720
So let's start with the basics.

21
00:00:43,720 --> 00:00:46,040
What is a data warehouse in the first place?

22
00:00:46,040 --> 00:00:47,320
What is a data warehouse?

23
00:00:47,320 --> 00:00:48,240
The old way.

24
00:00:48,240 --> 00:00:50,160
A data warehouse is a central place to store

25
00:00:50,160 --> 00:00:52,320
cleaned, structured data for reporting.

26
00:00:52,320 --> 00:00:53,600
Think of it like a library.

27
00:00:53,600 --> 00:00:55,840
Raw data comes in from different places,

28
00:00:55,840 --> 00:00:57,800
sale systems, customer databases,

29
00:00:57,800 --> 00:01:01,880
inventory logs, and it gets cataloged, sorted and organized.

30
00:01:01,880 --> 00:01:04,240
Then it sits on the shelves waiting for someone to check it out.

31
00:01:04,240 --> 00:01:06,840
That checkout is you running a report or a query.

32
00:01:06,840 --> 00:01:09,520
Traditional data warehouses have a few main characteristics.

33
00:01:09,520 --> 00:01:12,720
They store data, instructed tables with rows and columns.

34
00:01:12,720 --> 00:01:14,120
You talk to them using SQL.

35
00:01:14,120 --> 00:01:16,160
They're designed for analytics, not transactions.

36
00:01:16,160 --> 00:01:17,040
That's a big difference.

37
00:01:17,040 --> 00:01:18,880
A transaction system like a bank's database

38
00:01:18,880 --> 00:01:20,880
handles lots of small, fast operations.

39
00:01:20,880 --> 00:01:23,120
A data warehouse handles big, complex queries

40
00:01:23,120 --> 00:01:25,800
that scan millions of rows to answer questions like,

41
00:01:25,800 --> 00:01:27,760
what were our total sales last quarter?

42
00:01:27,760 --> 00:01:30,000
20 years ago, if you wanted a data warehouse,

43
00:01:30,000 --> 00:01:33,120
you'd buy a server, install SQL server or Oracle.

44
00:01:33,120 --> 00:01:34,120
And that was your warehouse.

45
00:01:34,120 --> 00:01:36,040
You owned the hardware, managed the backups,

46
00:01:36,040 --> 00:01:38,000
worried about disk space, and your data

47
00:01:38,000 --> 00:01:39,840
was locked in proprietary formats.

48
00:01:39,840 --> 00:01:41,920
Moving it anywhere else meant exporting,

49
00:01:41,920 --> 00:01:43,840
transforming, and duplicating.

50
00:01:43,840 --> 00:01:45,720
The old model worked, but it had a big problem.

51
00:01:45,720 --> 00:01:47,240
Data warehouses were isolated.

52
00:01:47,240 --> 00:01:49,880
You had to move data into them, store it in whatever format

53
00:01:49,880 --> 00:01:52,800
the vendor required, and pay for separate compute and storage

54
00:01:52,800 --> 00:01:54,480
that lived in the same box.

55
00:01:54,480 --> 00:01:57,080
If you needed more power, you bought a bigger server,

56
00:01:57,080 --> 00:01:58,880
more space meant more disks.

57
00:01:58,880 --> 00:02:01,360
And if you wanted to use that same data in a different tool,

58
00:02:01,360 --> 00:02:03,560
like a machine learning model or a real-time dashboard,

59
00:02:03,560 --> 00:02:05,360
you had to copy it somewhere else.

60
00:02:05,360 --> 00:02:06,920
That's how data silos were born.

61
00:02:06,920 --> 00:02:08,600
Compare that to what we expect today.

62
00:02:08,600 --> 00:02:11,320
Cloud, scalability, no manual maintenance.

63
00:02:11,320 --> 00:02:13,160
The idea is that you can spin up a warehouse

64
00:02:13,160 --> 00:02:15,920
without provisioning hardware, without managing backups,

65
00:02:15,920 --> 00:02:17,360
without worrying about storage limits.

66
00:02:17,360 --> 00:02:18,240
That's the shift.

67
00:02:18,240 --> 00:02:19,960
And that's where fabric comes in.

68
00:02:19,960 --> 00:02:22,160
How fabric warehouse works under the hood.

69
00:02:22,160 --> 00:02:24,680
Fabric warehouse looks familiar on the surface.

70
00:02:24,680 --> 00:02:26,680
You open it, see schemers and tables,

71
00:02:26,680 --> 00:02:28,960
write SQL queries, but under the hood,

72
00:02:28,960 --> 00:02:31,840
it stores data in Delta Park K format on one lake.

73
00:02:31,840 --> 00:02:33,960
Exactly the same way a lake house does.

74
00:02:33,960 --> 00:02:35,240
Here's what that means in practice.

75
00:02:35,240 --> 00:02:37,120
Imagine a library where every book is stored

76
00:02:37,120 --> 00:02:40,800
in a universal format that any librarian or any tool can read.

77
00:02:40,800 --> 00:02:43,320
No special shelving or proprietary card catalog.

78
00:02:43,320 --> 00:02:46,320
A Python script can open the same file that Power BI reads,

79
00:02:46,320 --> 00:02:48,480
and a Spark notebook can process the same data

80
00:02:48,480 --> 00:02:49,800
that a T-School query scans.

81
00:02:49,800 --> 00:02:51,120
There's no translation layer.

82
00:02:51,120 --> 00:02:53,360
The format is open and accessible to everything.

83
00:02:53,360 --> 00:02:54,720
One lake is the foundation here.

84
00:02:54,720 --> 00:02:57,000
Think of it as the one drive for your data.

85
00:02:57,000 --> 00:02:59,560
You have one copy of your data, stored in one place,

86
00:02:59,560 --> 00:03:01,800
and every fabric experience can access it.

87
00:03:01,800 --> 00:03:03,800
The warehouse reads from the same Delta tables

88
00:03:03,800 --> 00:03:07,080
as your notebooks, data pipelines, and Power BI reports.

89
00:03:07,080 --> 00:03:08,680
There's no data movement between silos,

90
00:03:08,680 --> 00:03:09,760
and that's the big shift.

91
00:03:09,760 --> 00:03:12,480
Traditional databases couple compute and storage together.

92
00:03:12,480 --> 00:03:14,560
When you run a query, you're using the same hardware

93
00:03:14,560 --> 00:03:15,720
that stores the data.

94
00:03:15,720 --> 00:03:18,240
But in fabric warehouse, those two things are separate.

95
00:03:18,240 --> 00:03:20,000
You pay for compute when you query,

96
00:03:20,000 --> 00:03:22,480
and storage is shared across all fabric experiences.

97
00:03:22,480 --> 00:03:24,880
That means you don't need to provision a giant warehouse

98
00:03:24,880 --> 00:03:26,400
just to hold your data.

99
00:03:26,400 --> 00:03:29,200
You only provision compute for the queries you actually run.

100
00:03:29,200 --> 00:03:30,880
And because everything lives in one lake,

101
00:03:30,880 --> 00:03:32,840
you don't need to worry about which version of the data

102
00:03:32,840 --> 00:03:33,600
is the right one.

103
00:03:33,600 --> 00:03:35,280
There's one copy, your warehouse,

104
00:03:35,280 --> 00:03:38,040
lake house, and Power BI reports all read from it.

105
00:03:38,040 --> 00:03:40,080
If someone updates a table in the warehouse,

106
00:03:40,080 --> 00:03:41,760
that change is visible everywhere.

107
00:03:41,760 --> 00:03:43,240
There's no manual synchronization,

108
00:03:43,240 --> 00:03:45,960
so you never wonder if the report is looking at stale data.

109
00:03:45,960 --> 00:03:48,280
This is the fundamental difference between fabric warehouse

110
00:03:48,280 --> 00:03:49,640
and a traditional database.

111
00:03:49,640 --> 00:03:51,840
Traditional databases are islands,

112
00:03:51,840 --> 00:03:54,760
but fabric warehouse is a room in a connected building.

113
00:03:54,760 --> 00:03:56,000
The walls are still there.

114
00:03:56,000 --> 00:03:58,080
You still have schemas, tables, and sickle,

115
00:03:58,080 --> 00:04:00,040
but the data flows freely between rooms.

116
00:04:00,040 --> 00:04:03,840
The result is less duplication, less cost, and less confusion.

117
00:04:03,840 --> 00:04:06,960
The building blocks of a fabric warehouse,

118
00:04:06,960 --> 00:04:09,200
so what actually lives inside a fabric warehouse?

119
00:04:09,200 --> 00:04:11,320
If you've worked with any relational database before,

120
00:04:11,320 --> 00:04:12,760
the objects will look familiar.

121
00:04:12,760 --> 00:04:15,760
You have schemas, tables, views, stored procedures, and functions.

122
00:04:15,760 --> 00:04:17,200
The names and concepts are the same,

123
00:04:17,200 --> 00:04:18,880
but there's a twist under the hood.

124
00:04:18,880 --> 00:04:20,280
Let's start with schemas.

125
00:04:20,280 --> 00:04:22,400
Schemas are like folders that organize your data.

126
00:04:22,400 --> 00:04:24,240
You might have a sales schema that holds

127
00:04:24,240 --> 00:04:27,320
all your sales-related tables and an HR schema

128
00:04:27,320 --> 00:04:28,440
for employee data.

129
00:04:28,440 --> 00:04:30,160
It's a simple way to keep things tidy,

130
00:04:30,160 --> 00:04:32,120
especially as your warehouse grows.

131
00:04:32,120 --> 00:04:35,520
Without schemas, everything ends up in one big flat list,

132
00:04:35,520 --> 00:04:37,520
and that gets messy fast.

133
00:04:37,520 --> 00:04:40,880
Tables are where the actual data lives, rows and columns,

134
00:04:40,880 --> 00:04:44,440
with customer IDs, product names, sales amounts, dates,

135
00:04:44,440 --> 00:04:46,480
that part is exactly what you'd expect.

136
00:04:46,480 --> 00:04:47,320
But here's the twist.

137
00:04:47,320 --> 00:04:49,440
These aren't regular sickle-server tables.

138
00:04:49,440 --> 00:04:51,520
Under the hood, every table in fabric warehouse

139
00:04:51,520 --> 00:04:52,560
is a delta table.

140
00:04:52,560 --> 00:04:55,360
That means the data is stored as parquet files in one lake,

141
00:04:55,360 --> 00:04:57,440
with a transaction log that tracks every change.

142
00:04:57,440 --> 00:04:59,440
We'll come back to why that matters in a minute.

143
00:04:59,440 --> 00:05:01,920
Views are saved queries that act like virtual tables.

144
00:05:01,920 --> 00:05:04,320
Say you have a complex join that you run all the time,

145
00:05:04,320 --> 00:05:06,600
joining customer data with orders and products.

146
00:05:06,600 --> 00:05:09,320
Instead of writing that join from scratch every time,

147
00:05:09,320 --> 00:05:12,000
you save it as a view, and then you can query the view

148
00:05:12,000 --> 00:05:13,080
just like a table.

149
00:05:13,080 --> 00:05:14,720
Views are also useful for security.

150
00:05:14,720 --> 00:05:16,280
You can give someone access to a view

151
00:05:16,280 --> 00:05:18,120
that only shows certain columns,

152
00:05:18,120 --> 00:05:20,160
without letting them see the underlying table.

153
00:05:20,160 --> 00:05:22,720
Stored procedures are reusable blocks of SQL logic,

154
00:05:22,720 --> 00:05:25,040
where you can pass parameters, automate tasks,

155
00:05:25,040 --> 00:05:27,840
run updates, and handle more complex workflows.

156
00:05:27,840 --> 00:05:30,560
If you've used stored procedures in SQL server,

157
00:05:30,560 --> 00:05:31,920
the syntax is the same.

158
00:05:31,920 --> 00:05:34,000
You write your logic once, and then you can call it

159
00:05:34,000 --> 00:05:35,000
whenever you need it.

160
00:05:35,000 --> 00:05:36,360
And here's the important part.

161
00:05:36,360 --> 00:05:37,880
If you've used SQL server before,

162
00:05:37,880 --> 00:05:39,840
the interface, syntax and object navigation

163
00:05:39,840 --> 00:05:41,280
will all feel very familiar.

164
00:05:41,280 --> 00:05:43,880
But under the hood, every table is backed by delta files

165
00:05:43,880 --> 00:05:44,720
in one lake.

166
00:05:44,720 --> 00:05:48,000
That means your data isn't locked into a proprietary format.

167
00:05:48,000 --> 00:05:49,920
It's open, portable, and accessible

168
00:05:49,920 --> 00:05:51,880
to other tools without any extra work.

169
00:05:51,880 --> 00:05:53,120
One more thing worth mentioning.

170
00:05:53,120 --> 00:05:55,000
Fabric has a visual query editor.

171
00:05:55,000 --> 00:05:57,080
If you're not comfortable writing SQL from scratch,

172
00:05:57,080 --> 00:06:00,360
you can drag and drop tables onto a canvas, join them visually,

173
00:06:00,360 --> 00:06:02,480
and the tool generates the school for you.

174
00:06:02,480 --> 00:06:04,360
It's a nice entry point for beginners

175
00:06:04,360 --> 00:06:07,480
who want to explore data without memorizing syntax.

176
00:06:07,480 --> 00:06:09,040
Getting data into the warehouse.

177
00:06:09,040 --> 00:06:10,080
So you've got a warehouse.

178
00:06:10,080 --> 00:06:13,320
Now the big question, how do you actually get data into it?

179
00:06:13,320 --> 00:06:15,360
Let's look at the options, and most of them are easier

180
00:06:15,360 --> 00:06:16,400
than you might think.

181
00:06:16,400 --> 00:06:18,240
The first option is data pipelines.

182
00:06:18,240 --> 00:06:20,720
Think of a pipeline like a guided wizard.

183
00:06:20,720 --> 00:06:21,800
You pick a source.

184
00:06:21,800 --> 00:06:25,160
As you are SQL database, a CSV file in Blob storage,

185
00:06:25,160 --> 00:06:28,360
another fabric warehouse, or even a simple Excel file,

186
00:06:28,360 --> 00:06:31,600
then map the columns to your destination table and run it.

187
00:06:31,600 --> 00:06:32,680
That's all there is to it.

188
00:06:32,680 --> 00:06:34,560
It's a simple point and click process.

189
00:06:34,560 --> 00:06:37,800
And for beginners, this is the easiest way to get started.

190
00:06:37,800 --> 00:06:41,520
Next up is data flows Gen2, which is more visual and low-code.

191
00:06:41,520 --> 00:06:44,240
You build transformations using a graphical interface,

192
00:06:44,240 --> 00:06:46,800
and the output lands directly in your warehouse tables.

193
00:06:46,800 --> 00:06:49,680
If you're coming from Power Query in Excel or Power BI,

194
00:06:49,680 --> 00:06:51,000
this will feel familiar.

195
00:06:51,000 --> 00:06:53,960
For people who prefer writing SQL, there's the copy into command.

196
00:06:53,960 --> 00:06:56,520
It's a single T-secle statement that loads data directly

197
00:06:56,520 --> 00:07:00,000
from external storage, like Azure Blob storage or ADLS,

198
00:07:00,000 --> 00:07:01,200
into a warehouse table.

199
00:07:01,200 --> 00:07:03,280
You specify the file path, the format,

200
00:07:03,280 --> 00:07:05,760
and any options for handling headers or delimiters.

201
00:07:05,760 --> 00:07:09,000
It's clean, fast, and works with CSV and parquet files.

202
00:07:09,000 --> 00:07:12,040
And if you're a developer, you can use notebooks with Spark

203
00:07:12,040 --> 00:07:14,360
to transform and load data at scale.

204
00:07:14,360 --> 00:07:16,760
Notebooks give you the most flexibility,

205
00:07:16,760 --> 00:07:18,920
but they also have the steepest learning curve.

206
00:07:18,920 --> 00:07:20,360
Here's something important to understand

207
00:07:20,360 --> 00:07:22,440
about the warehouse versus the lake house.

208
00:07:22,440 --> 00:07:25,360
The lake house has a SQL endpoint that lets you query data,

209
00:07:25,360 --> 00:07:26,480
but it's read only.

210
00:07:26,480 --> 00:07:29,920
You can select from it, but you can't insert, update, or delete.

211
00:07:29,920 --> 00:07:31,280
The warehouse is different.

212
00:07:31,280 --> 00:07:34,600
It supports full DML, insert, update, delete, merge.

213
00:07:34,600 --> 00:07:35,760
That's a big difference.

214
00:07:35,760 --> 00:07:38,000
With a lake house, you can query data via SQL,

215
00:07:38,000 --> 00:07:39,280
but you can't modify it.

216
00:07:39,280 --> 00:07:41,520
With warehouse, you have full read write control.

217
00:07:41,520 --> 00:07:43,640
So if you need to clean data, fix errors,

218
00:07:43,640 --> 00:07:45,760
or run incremental updates, the warehouse

219
00:07:45,760 --> 00:07:47,360
is the right place to do it.

220
00:07:47,360 --> 00:07:50,040
Quarring your data, familiar SQL, new tricks.

221
00:07:50,040 --> 00:07:51,600
Once your data is in the warehouse,

222
00:07:51,600 --> 00:07:53,640
querying it works exactly how you'd expect.

223
00:07:53,640 --> 00:07:55,320
Fabric warehouse supports T-School,

224
00:07:55,320 --> 00:07:58,680
so if you know SQL Server, you already know how to query this.

225
00:07:58,680 --> 00:08:00,880
Select, join, group by, where.

226
00:08:00,880 --> 00:08:02,960
It all works the same way.

227
00:08:02,960 --> 00:08:05,680
You can connect using any tool you're comfortable with,

228
00:08:05,680 --> 00:08:07,480
SQL Server Management Studio,

229
00:08:07,480 --> 00:08:09,680
Azure Data Studio, or the query editor

230
00:08:09,680 --> 00:08:11,440
inside the fabric portal itself.

231
00:08:11,440 --> 00:08:12,280
They all work.

232
00:08:12,280 --> 00:08:14,800
Just grab the SQL endpoint from the warehouse settings,

233
00:08:14,800 --> 00:08:18,280
plug it into your tool, authenticate with your Microsoft account,

234
00:08:18,280 --> 00:08:19,360
and you're in.

235
00:08:19,360 --> 00:08:22,560
It feels like connecting to any remote SQL Server database.

236
00:08:22,560 --> 00:08:24,040
But here's where things get interesting.

237
00:08:24,040 --> 00:08:26,880
Because the data is stored in Delta Format under the hood,

238
00:08:26,880 --> 00:08:29,480
you get capabilities that a traditional SQL database

239
00:08:29,480 --> 00:08:30,200
doesn't have.

240
00:08:30,200 --> 00:08:32,400
One of the most powerful is cross database queries.

241
00:08:32,400 --> 00:08:34,000
You can write a single T-School query

242
00:08:34,000 --> 00:08:35,800
that joins data from your warehouse

243
00:08:35,800 --> 00:08:38,040
with data from a lake houses SQL endpoint

244
00:08:38,040 --> 00:08:41,360
using three-part naming, database, schema, table,

245
00:08:41,360 --> 00:08:43,760
and fabric resolves it across both stores.

246
00:08:43,760 --> 00:08:46,280
For example, you can join a table from your lake house

247
00:08:46,280 --> 00:08:48,800
with a table from your warehouse without moving any data.

248
00:08:48,800 --> 00:08:50,200
That's the power of one lake.

249
00:08:50,200 --> 00:08:52,360
Both stores read from the same underlying files,

250
00:08:52,360 --> 00:08:53,480
so the query just works.

251
00:08:53,480 --> 00:08:54,640
This is a big deal.

252
00:08:54,640 --> 00:08:57,560
In a traditional setup, if your data lives in two different systems,

253
00:08:57,560 --> 00:09:00,200
you have to copy one into the other before you can join them.

254
00:09:00,200 --> 00:09:02,600
Taking time, storage, and maintenance.

255
00:09:02,600 --> 00:09:05,080
In fabric, the data is already sitting in one lake,

256
00:09:05,080 --> 00:09:06,400
so the warehouse and the lake house

257
00:09:06,400 --> 00:09:08,560
are just different views into the same files.

258
00:09:08,560 --> 00:09:10,480
Cross database queries aren't a workaround.

259
00:09:10,480 --> 00:09:11,800
They're a natural feature.

260
00:09:11,800 --> 00:09:14,920
One thing to note, the SQL endpoint is at the workspace level.

261
00:09:14,920 --> 00:09:18,120
So when you connect, you see all the databases in that workspace.

262
00:09:18,120 --> 00:09:20,480
If you have a lake house and a warehouse in the same workspace,

263
00:09:20,480 --> 00:09:23,480
they both show up, and you can query across them freely.

264
00:09:23,480 --> 00:09:25,360
That's the kind of integration that makes fabric

265
00:09:25,360 --> 00:09:27,560
feel like a single platform rather than

266
00:09:27,560 --> 00:09:30,280
a collection of separate tools.

267
00:09:30,280 --> 00:09:33,960
Time travel and table cloning features you didn't know you needed.

268
00:09:33,960 --> 00:09:35,600
Today, I want to cover two features

269
00:09:35,600 --> 00:09:37,880
that are impossible in a traditional database.

270
00:09:37,880 --> 00:09:39,840
Time travel and table cloning.

271
00:09:39,840 --> 00:09:42,680
Both exist because your data is stored in Delta format,

272
00:09:42,680 --> 00:09:44,680
which keeps the transaction log of every change.

273
00:09:44,680 --> 00:09:46,840
Time travel is exactly what it sounds like.

274
00:09:46,840 --> 00:09:49,960
You can query a table as it existed at a previous point in time.

275
00:09:49,960 --> 00:09:52,520
It's like having a go-back button for your data.

276
00:09:52,520 --> 00:09:54,200
Say you accidentally deleted some rows.

277
00:09:54,200 --> 00:09:57,720
You can query the table as it was an hour ago before that delete happened.

278
00:09:57,720 --> 00:09:59,040
The syntax is straightforward.

279
00:09:59,040 --> 00:10:01,520
You write your select statement, then add for timestamp

280
00:10:01,520 --> 00:10:04,240
as of followed by the date and time in UTC format.

281
00:10:04,240 --> 00:10:07,080
Something like this, select from your table for timestamp

282
00:10:07,080 --> 00:10:13,360
as of 2026, 0115TE14, 012, which OZ.

283
00:10:13,360 --> 00:10:16,240
And just like that, you're looking at the data from that exact moment.

284
00:10:16,240 --> 00:10:17,400
This is great for recovery.

285
00:10:17,400 --> 00:10:20,400
In a traditional database, if someone accidentally truncates a table,

286
00:10:20,400 --> 00:10:21,720
you're restoring from backup.

287
00:10:21,720 --> 00:10:23,400
That takes time and means downtime.

288
00:10:23,400 --> 00:10:25,480
With time travel, you just adjust your query.

289
00:10:25,480 --> 00:10:28,360
See the data as it was, copy it back and keep moving.

290
00:10:28,360 --> 00:10:29,880
No backup restore needed.

291
00:10:29,880 --> 00:10:33,520
There is a limit, though, by default, the history is retained for 30 days.

292
00:10:33,520 --> 00:10:36,360
After that, the warehouse automatically cleans up older versions,

293
00:10:36,360 --> 00:10:38,120
so you can't travel back six months.

294
00:10:38,120 --> 00:10:41,880
But for most scenarios, accidental deletes, bad transformations,

295
00:10:41,880 --> 00:10:43,880
or what did this look like last week?

296
00:10:43,880 --> 00:10:45,120
30 days is plenty.

297
00:10:45,120 --> 00:10:47,960
Table cloning is the second feature, and it's just as powerful.

298
00:10:47,960 --> 00:10:50,320
You can create an instant copy of a table using a simple,

299
00:10:50,320 --> 00:10:52,400
create table as clone of statement.

300
00:10:52,400 --> 00:10:53,200
And here's the keys.

301
00:10:53,200 --> 00:10:54,480
It's a zero-copy clone.

302
00:10:54,480 --> 00:10:56,840
That means it doesn't duplicate the underlying data.

303
00:10:56,840 --> 00:10:58,800
It just points to the same files in one leg.

304
00:10:58,800 --> 00:11:00,840
So the clone is nearly instantaneous to create

305
00:11:00,840 --> 00:11:02,560
and costs almost nothing in storage

306
00:11:02,560 --> 00:11:04,240
because no new data is being written.

307
00:11:04,240 --> 00:11:06,000
Here's when you'd use this, say you're

308
00:11:06,000 --> 00:11:08,880
about to run a big transformation on your sales table,

309
00:11:08,880 --> 00:11:11,560
updating thousands of rows, restructuring columns,

310
00:11:11,560 --> 00:11:13,320
maybe deleting old records.

311
00:11:13,320 --> 00:11:15,000
Before you start, you create a clone.

312
00:11:15,000 --> 00:11:17,520
If something goes wrong, you have your original data intact,

313
00:11:17,520 --> 00:11:19,280
no restore process, no waiting.

314
00:11:19,280 --> 00:11:21,880
You just drop the bad table and point back to the clone.

315
00:11:21,880 --> 00:11:23,800
You can also use clones for testing,

316
00:11:23,800 --> 00:11:25,880
create a clone of your production table,

317
00:11:25,880 --> 00:11:29,040
run your experiments on it, and when you're done, delete it.

318
00:11:29,040 --> 00:11:31,440
The original table never changes, or use it

319
00:11:31,440 --> 00:11:33,600
to create a development copy for a new team member

320
00:11:33,600 --> 00:11:35,880
to explore without risking production data.

321
00:11:35,880 --> 00:11:38,600
Both of these features, time travel and table cloning

322
00:11:38,600 --> 00:11:40,240
are built into fabric warehouse

323
00:11:40,240 --> 00:11:42,200
because of the delta format underneath.

324
00:11:42,200 --> 00:11:43,800
A traditional SQL server database

325
00:11:43,800 --> 00:11:45,200
doesn't have a transaction log that

326
00:11:45,200 --> 00:11:47,840
supports this kind of point in time querying.

327
00:11:47,840 --> 00:11:49,400
You'd need a separate backup strategy,

328
00:11:49,400 --> 00:11:51,760
separate restore procedures, separate everything.

329
00:11:51,760 --> 00:11:53,880
Fabric warehouse gives you these capabilities

330
00:11:53,880 --> 00:11:55,680
out of the box.

331
00:11:55,680 --> 00:11:59,160
Performance, the GPU acceleration and direct leg advantage.

332
00:11:59,160 --> 00:12:00,800
So it's flexible and recoverable.

333
00:12:00,800 --> 00:12:01,840
But how fast is it?

334
00:12:01,840 --> 00:12:06,040
In 2026, Microsoft added GPU acceleration to the warehouse

335
00:12:06,040 --> 00:12:07,560
and it's currently in preview.

336
00:12:07,560 --> 00:12:10,320
You enable it with a single toggle in the workspace settings,

337
00:12:10,320 --> 00:12:12,720
no code changes, no query rewrites.

338
00:12:12,720 --> 00:12:14,120
You flip the switch and the warehouse

339
00:12:14,120 --> 00:12:16,840
starts using Nvidia GPUs to run your queries.

340
00:12:16,840 --> 00:12:19,120
Microsoft published benchmarks using the TPCH

341
00:12:19,120 --> 00:12:21,200
standard at 100 gigabytes of data.

342
00:12:21,200 --> 00:12:23,840
At 1,000 users running queries simultaneously,

343
00:12:23,840 --> 00:12:26,920
the GPU accelerated warehouse finished in about eight seconds.

344
00:12:26,920 --> 00:12:30,520
While the same warehouse running on CPU alone took 43 seconds,

345
00:12:30,520 --> 00:12:32,280
that's roughly six times more throughput

346
00:12:32,280 --> 00:12:33,760
on the same capacity.

347
00:12:33,760 --> 00:12:35,280
Here's the thing for beginners.

348
00:12:35,280 --> 00:12:38,040
You don't need to learn any tuning tricks to get this benefit.

349
00:12:38,040 --> 00:12:40,560
No indexing strategies, no query plan optimization,

350
00:12:40,560 --> 00:12:43,400
no materialized views, the hardware does the heavy lifting.

351
00:12:43,400 --> 00:12:45,800
You enable the feature and your queries just run faster,

352
00:12:45,800 --> 00:12:46,920
especially under load.

353
00:12:46,920 --> 00:12:49,360
If you're building dashboards that dozens or hundreds

354
00:12:49,360 --> 00:12:51,440
of people will use, that's a big deal.

355
00:12:51,440 --> 00:12:52,920
There's another performance advantage

356
00:12:52,920 --> 00:12:55,560
that's less obvious but just as important, direct,

357
00:12:55,560 --> 00:12:57,040
lake mode for Power BI.

358
00:12:57,040 --> 00:12:58,800
In a traditional setup, Power BI connects

359
00:12:58,800 --> 00:13:00,440
to a warehouse in one of two ways.

360
00:13:00,440 --> 00:13:03,320
It either imports the data into its own in-memory engine,

361
00:13:03,320 --> 00:13:06,800
which requires a scheduled refresh or it uses direct query,

362
00:13:06,800 --> 00:13:09,240
which sends every chart interaction back to the warehouse

363
00:13:09,240 --> 00:13:11,000
as a live query.

364
00:13:11,000 --> 00:13:13,280
Import means stale data between refreshes

365
00:13:13,280 --> 00:13:16,080
and direct query means every click costs compute.

366
00:13:16,080 --> 00:13:17,800
Direct lake solves both problems.

367
00:13:17,800 --> 00:13:20,640
Power BI reads directly from the delta files in one lake.

368
00:13:20,640 --> 00:13:23,640
No import, no live query hitting the warehouse.

369
00:13:23,640 --> 00:13:26,160
The data is already in memory on the fabric capacity

370
00:13:26,160 --> 00:13:27,840
and Power BI just reads it.

371
00:13:27,840 --> 00:13:29,840
The result is near instant report performance

372
00:13:29,840 --> 00:13:31,640
with no refresh schedule to maintain

373
00:13:31,640 --> 00:13:33,480
and no per query compute charges.

374
00:13:33,480 --> 00:13:35,720
Your Power BI reports can query billions of rows

375
00:13:35,720 --> 00:13:38,840
and get results in seconds, no data movement, no latency.

376
00:13:38,840 --> 00:13:40,760
For someone building reports in an organization,

377
00:13:40,760 --> 00:13:42,200
this is a huge shift.

378
00:13:42,200 --> 00:13:43,760
You don't have to choose between fresh data

379
00:13:43,760 --> 00:13:45,600
and fast performance, you get both.

380
00:13:45,600 --> 00:13:47,600
And you don't need a separate data engineering team

381
00:13:47,600 --> 00:13:49,000
to maintain the infrastructure.

382
00:13:49,000 --> 00:13:49,920
It just works.

383
00:13:49,920 --> 00:13:53,240
When to use fabric warehouse versus lake house versus event house.

384
00:13:53,240 --> 00:13:55,280
So you've got three options, lake house, warehouse,

385
00:13:55,280 --> 00:13:56,040
event house.

386
00:13:56,040 --> 00:13:57,560
How do you actually choose?

387
00:13:57,560 --> 00:13:59,240
Here's the simplest way to think about it.

388
00:13:59,240 --> 00:14:02,840
Ask yourself one question, what kind of data system am I building?

389
00:14:02,840 --> 00:14:05,960
Not which tool sounds coolest, not what your friend recommended.

390
00:14:05,960 --> 00:14:07,600
What does your data actually need?

391
00:14:07,600 --> 00:14:10,240
Warehouse is for structured, model data

392
00:14:10,240 --> 00:14:12,400
that needs to give consistent answers.

393
00:14:12,400 --> 00:14:13,920
Think of it as your silver or gold layer

394
00:14:13,920 --> 00:14:15,480
in the medallion architecture.

395
00:14:15,480 --> 00:14:17,880
The data has been cleaned, transformed, and shaped.

396
00:14:17,880 --> 00:14:20,120
You know the schema, you know the relationships.

397
00:14:20,120 --> 00:14:22,840
When someone asks, what were our Q3 sales?

398
00:14:22,840 --> 00:14:25,280
The warehouse gives you a reliable, repeatable answer

399
00:14:25,280 --> 00:14:26,480
every single time.

400
00:14:26,480 --> 00:14:27,720
Lake house is the opposite end.

401
00:14:27,720 --> 00:14:30,400
It's for flexible raw data that's still taking shape.

402
00:14:30,400 --> 00:14:31,600
This is your bronze layer.

403
00:14:31,600 --> 00:14:35,400
You might have CSV files, JSON logs, images, or nested data

404
00:14:35,400 --> 00:14:36,960
that you haven't fully figured out yet.

405
00:14:36,960 --> 00:14:38,480
The lake house doesn't care about format.

406
00:14:38,480 --> 00:14:40,120
It accepts anything and lets you explore.

407
00:14:40,120 --> 00:14:43,320
It's the place to experiment before you commit to a structure.

408
00:14:43,320 --> 00:14:45,240
Event house is a different beast entirely.

409
00:14:45,240 --> 00:14:47,760
It's built for time-based append-only data.

410
00:14:47,760 --> 00:14:51,120
Think server logs, IoT sensor readings, real-time streams.

411
00:14:51,120 --> 00:14:54,160
Data flows in continuously, you query it over time windows,

412
00:14:54,160 --> 00:14:56,160
and you rarely go back and update old records.

413
00:14:56,160 --> 00:14:59,480
It's optimized for high ingestion and fast time range queries.

414
00:14:59,480 --> 00:15:01,200
Here's the practical guidance for beginners.

415
00:15:01,200 --> 00:15:02,880
Start with a lake house for exploration.

416
00:15:02,880 --> 00:15:05,920
Land your raw data, play with it, figure out what you have,

417
00:15:05,920 --> 00:15:07,560
then move the cleaned, structured version

418
00:15:07,560 --> 00:15:09,200
into a warehouse for reporting.

419
00:15:09,200 --> 00:15:11,160
They work together seamlessly because both read

420
00:15:11,160 --> 00:15:12,480
from the same one lake files.

421
00:15:12,480 --> 00:15:13,920
You're not duplicating data.

422
00:15:13,920 --> 00:15:16,200
You're just layering different views on top of it.

423
00:15:16,200 --> 00:15:18,160
The common pitfall is over-complicating this.

424
00:15:18,160 --> 00:15:19,800
People try to build everything in a warehouse

425
00:15:19,800 --> 00:15:21,280
because it feels more familiar.

426
00:15:21,280 --> 00:15:23,880
Or they try to force raw JSON into relational tables.

427
00:15:23,880 --> 00:15:24,600
Don't.

428
00:15:24,600 --> 00:15:27,160
Use warehouse when you need full transaction support,

429
00:15:27,160 --> 00:15:30,760
insert, update, delete, and a strict relational schema.

430
00:15:30,760 --> 00:15:33,360
Use lake house when you want to experiment and iterate.

431
00:15:33,360 --> 00:15:36,080
Use even house when your data is a firehouse of timestamps.

432
00:15:36,080 --> 00:15:37,120
Don't start with the tool.

433
00:15:37,120 --> 00:15:39,000
Start with the question you're trying to answer,

434
00:15:39,000 --> 00:15:40,840
then pick the store that fits.

435
00:15:40,840 --> 00:15:42,600
Your first step into fabric warehouse.

436
00:15:42,600 --> 00:15:43,760
So let's pull this together.

437
00:15:43,760 --> 00:15:46,040
Fabric warehouse looks and feels like a traditional database.

438
00:15:46,040 --> 00:15:48,520
You write SQL, you create tables, you run queries,

439
00:15:48,520 --> 00:15:51,240
but underneath it's built on modern Delta Parque storage

440
00:15:51,240 --> 00:15:52,280
in one lake.

441
00:15:52,280 --> 00:15:54,000
That one change unlocks everything.

442
00:15:54,000 --> 00:15:58,120
No data silos, built in time travel, zero copy cloning,

443
00:15:58,120 --> 00:16:00,840
GPU acceleration, and direct lake for Power BI.

444
00:16:00,840 --> 00:16:01,840
It's not just a warehouse.

445
00:16:01,840 --> 00:16:04,480
It's your relational data layer inside a unified analytics

446
00:16:04,480 --> 00:16:05,160
platform.

447
00:16:05,160 --> 00:16:06,040
Here's your homework.

448
00:16:06,040 --> 00:16:08,000
Create your first fabric warehouse today.

449
00:16:08,000 --> 00:16:09,880
Even if you just load a small CSV file

450
00:16:09,880 --> 00:16:11,880
and run a select query, feel how it works,

451
00:16:11,880 --> 00:16:13,400
see how the interface responds.

452
00:16:13,400 --> 00:16:16,520
And then try the time travel feature, modify some data,

453
00:16:16,520 --> 00:16:18,040
then query it as it was before.

454
00:16:18,040 --> 00:16:20,560
That's something you can't do in a regular SQL database.

455
00:16:20,560 --> 00:16:22,280
It'll click immediately why this matters.

456
00:16:22,280 --> 00:16:24,920
If you found this useful, subscribe to Microsoft Knowledge

457
00:16:24,920 --> 00:16:27,280
Nuggets on M365 FM.

458
00:16:27,280 --> 00:16:28,520
Share this episode with someone who's

459
00:16:28,520 --> 00:16:29,800
starting their fabric journey.

460
00:16:29,800 --> 00:16:31,920
And if you have questions, drop them in the comments.

461
00:16:31,920 --> 00:16:32,880
I read everyone.

462
00:16:32,880 --> 00:16:33,640
Thanks for listening.

463
00:16:33,640 --> 00:16:36,280
See you in the next episode.