跟讀練習: Vocabulary for Data Engineers - Data Engineering 101 - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

219 句

如果句子過短或過長，請點選 Edit 進行調整。

have probably all done it.

We have probably all assumed that the people we're talking to

understands the words and terms that we're using that might be very specific to whatever role we have at a company,

even if it's their first day on the job.

Again, I think we're all guilty of doing this.

So I wanted to put together a video for people who are just starting out in the industry

or maybe are just trying to understand what their data engineers are talking about

by putting together a kind of core set of vocabulary that a lot of data engineers tend to use.

To kick this off, let's use the term DAG, D -A -G, or Directed Acyclic Graph.

Basically, this is often an abstraction of tasks that need to happen in a certain series of steps.

That's kind of the whole point.

The directed point of the word basically means that there are multiple tasks, some of which are like going to be upstream and some downstream,

so it's going to go in a certain direction.

Acyclic just refers to the fact that the DAG itself

or the tasks that need occur can't or will only take on one cyclo

so it won't like ever get into an infinite loop

and the graph in this case represents that there's a finite set of nodes and vertices

that all kind of connect to each other those nodes essentially being tasks basically

it ends up looking kind of like this

so often you'll have something like a task a or first task

that then you know task b depends on and then maybe c

and d depend on b but c

and d can both happen at the same time

and then maybe both of those tasks go into you know something like task e to kind of finish it off.

So it's a very basic and simplistic graph of basically tasks.

It's just basically a chart of tasks that go from A to E.

And when someone references the term DAG, that's what they're referencing, a set of tasks that need to occur in a certain order.

And in the data engineering context, when we use the term DAG, we're often also kind of connecting to the concept of a data pipeline,

which will be the next word we're kind of pointing to.

The interesting thing to me about data pipeline is it can honestly cover a lot of different things.

There's a lot of different ways we use and design data pipelines.

There are the more standard data pipelines, often referred to as like batch data pipelines,

which occur at certain time intervals and often follow a pattern of either ETL or ELT,

which just references extract transform load or extract load transform.

And these are just your kind of standard ingestion pipelines,

which will often just take data from sources and then push it into an analytical storage system, which we will get to later.

And that's kind of your standard set of data pipelines.

But on top of that, you also have streaming data pipelines, which often push events directly into often your analytical storage system,

or one of those could be a data lake, could be a data warehouse, which we'll get to.

But there's also, to me personally, integration pipelines that are often managed by things like IPaaS systems,

which IPaaS or IPaaS stands for integration platform as a service.

So these kind of data pipelines tend to integrate across multiple systems.

So whereas your kind of standard ETL will just end up pushing data from source systems like Salesforce

or HubSpot into your either data lake or data warehouse, an iPaaS or an integration style data pipeline often integrates two different source systems together.

So maybe you want to pull data from Salesforce and integrate it with HubSpot.

And then those often connect.

These pipelines, data engineers don't generally develop too often.

These are more, I think, the work that's either done by like enterprise engineers, or, you know, someone who is a Salesforce expert,

because unlike ingesting data and storing it into a data warehouse, you need to understand how the underlying system actually works.

So if you're pulling data, let's say from HubSpot to Salesforce, you actually need to understand what's happening in Salesforce.

And there's a lot of people who are Salesforce admins and Salesforce experts and developers who understand that kind of work.

And so they often I think, are either involved or just the ones who develop those kinds of pipelines.

And look at that.

I've unavoidably added IPaaS, ETL, and ELT along with my data pipeline terminology here, because that's just how it ends up working.

When we end up having a conversation in any field, it's almost hard not to bring in other terms

that we rely on while you're trying to describe the current term you're working with.

So that's the interesting thing to me about data pipelines is

it can honestly mean a lot of different things from more standard batch data pipelines

which usually are again ETL and ELT based

and there's even some other things you could add in there as well to streaming to some things

that are more integration based where you're just trying to integrate data across different systems.

Now often these more standard data pipelines are utilized in such

a way to extract data from some sort of source system like Salesforce

and then push it into an analytical storage system like a data lake data warehouse or data lake house.

So now you've got even more new terms.

So let's start with the classic data warehouse,

which is just basically a place to store your kind of company's information in a way that first of all,

attempts to integrate all of your various entities.

So you might have your finance data, you might have hiring data,

you might and you try to create some sort of model in that data warehouse that represents your business, essentially.

It tries to replicate a lot of everything that you're doing in such a way that one,

it tracks historical information, which is one of the key things.

And two, it tries to integrate all that data across all of these complex systems.

So that way, when I ask a question that maybe involves multiple departments, I can answer that question because I can connect all this data together.

And the fact that it actually tracks historical information, unlike often a lot of source systems,

means that when I ask a question that wants to go back over years, you can actually do that.

You can actually can select data using something

we call slowly changing dimensions often in such a way to actually look at data from a historical point of view,

which we'll get to what we often also reference as SCD here in a second.

But first, let's jump into a data lake.

Obviously, I'm not going in crazy depth in terms of explaining exactly what a data warehouse is.

But one thing I didn't explain there was

that data warehouses tend to have a pretty rigid schema that is predefined when you start.

And thus the data types that are required and used in a data warehouse are limited.

Whereas a data lake is often more of a place that you can start storing raw data.

Often it might be schema -less when you store it

and you might do something that we often reference as schema on RAID,

which is define kind of the schema as you're processing data in the data lake.

And so it's a place where you can often store data that maybe isn't as naturally fitting into your data warehouse,

or maybe it's just too expensive to store in your data warehouse in a more traditional way.

It could also be things like images, text, that is maybe a little more free formatted,

XML, JSON, just again, things that are maybe less structured or semi -structured is often what we reference.

And that's something that often fits into the data lake.

There are multiple reasons why people might store data in a data lake or a data warehouse.

Some of the things have to do with cost, you know, again, size of the data or maybe time,

like maybe you don't have time to figure out

if this data belongs in the data warehouse or

if it even could provide value or how to model it properly to fit in.

And so you might end up storing it in the data lake as a place

100

that you can kind of do some work on it.

101

You might provide, you know, data scientists or someone the ability to access it

102

and work with it in such a way

103

that often requires a little bit more of a technical know -how

104

because you have to do some either sort of coding or work with it in such a way that's not SQL friendly,

105

like you would in often the data warehouse, unless of course you put, you know, something like

106

Hive or Presto on top.

107

You know, there's, there's definitely a lot of nuances to this.

108

And I'm again, speeding over this to just help most people understand what a data lake is from high up above,

109

but that's generally a data lake.

110

It's often data that's semi -structured to maybe even not structured at all

111

that people can store in such a way that should be organized.

112

Try not to make a data swamp as many of us describe, but can be utilized for future use.

113

Now let's dig into a data warehouse

114

because there's a lot of different things you're going to hear the first time you've ever worked in a data warehouse.

115

Like the first time I ever worked in a data warehouse, I didn't even realize it was a different thing,

116

like in terms of like database versus data warehouse.

117

I'd learned relational models.

118

And so when I was kind of working in a data warehouse, I was like, okay, there's some things called facts,

119

some things called dimensions, but you know, there's like keys and keys are like IDs.

120

And so you can connect that way.

121

And a lot of it, you know, I just didn't understand that it was a totally different system.

122

So let's kind of dive into some of the different key components you can hear.

123

Starting with some of the tables, you're going to hear tables that are often referenced as dimensions.

124

Dimensions are generally more like categories or descriptors.

125

Things like product might be a dimension, person or customer is also generally a dimension.

126

You also might have things like category

127

and actually even date plays a role in terms of dimension because this tends to describe things like interactions or sales.

128

And those sales, like total sales, are often what we reference as facts.

129

Facts generally are things that involve business transactions.

130

And then everything around that, they used to basically describe that business transaction is generally the dimension.

131

So think like location.

132

Another way to think about this is, generally speaking, a lot of the times when you're creating like a pivot table,

133

a lot of the things that you're going to pivot on are generally dimensions, right?

134

Because most of the time someone's going to ask for the average sales by location and maybe quarter.

135

So in this case, location and quarter are both dimensions,

136

and the total sale end is a summed up version of what would often be data coming from a fact table,

137

those sales numbers, or the amount that was sold.

138

So that's often what people are referencing when they say fact or dimension.

139

They're just different types of tables, and often you're going to be querying around the fact table

140

because that's the table that's going to tell you the numbers that you're trying to calculate.

141

Now in that, there's also something that I referenced earlier, if you remember, slowly changing dimensions or often as we just call it, SCD.

142

And these are thrilling things that basically allow you to track historical data.

143

The problem with a lot of source systems is they don't often track historical data.

144

Sometimes they do in logs, and that's why we have things like

145

Change Data Capture to kind of pull in and track every change that occurs in the data system.

146

But Slowly Changing Dimensions allows data warehouses to track changing dimensions over time using different methods.

147

You'll hear a lot of different ways that people can do this.

148

You'll hear someone say, oh, we're using SCD2 or SCD6.

149

And these are just different ways to kind of capture historical information.

150

And let me give you some context around this.

151

Let's say you're going to create a report

152

and you want to count the number of customers in New York City over the last three years.

153

Well, over the last three years, people have moved.

154

And if you just pull that data out and replace where someone currently lives in your data warehouse,

155

they lived in New York and now they moved to Connecticut, or maybe they lived in California and now moved to New York.

156

When you run that query, and especially when you do that over time, if you haven't tracked that historical information over time,

157

you're going to give the wrong numbers

158

because whatever information you're giving is just who currently lives in New York over multiple years, which isn't accurate.

159

If someone's moved, they need to not be included in that year that they moved.

160

And so that's why slowly changing dimensions are beneficial.

161

Often what these look like, if you were to actually see it, is you'll see like, let's say two or three rows with this same,

162

let's say, customer's information, or let's say this case let's say employees a job title now with

163

that you'll also see start date and end date

164

and this is a very simplistic way of looking at it

165

so start date end date that gives you that range now when

166

that employee changes roles you'll have a new row for the same employee the end date will likely be filled

167

or maybe there's often also the option of putting a flag

168

that says this row is no longer active

169

and then a new row will be created with their new job title

170

that will now capture when they started this current job

171

so now you've tracked the information of when they worked in this role

172

so when someone asks to kind of track historical information on employee roles

173

you have it another term that i recall got me in an amazon interview was

174

when i think it was someone

175

that has to do with like project management was interviewing me

176

and asked me about slas

177

and i had no idea what in the world an sla was

178

because i never had to work with the concept which sla just means service level agreement.

179

So when you're building all this stuff, like these data pipelines, these data warehouses, people rely on these systems.

180

And if you don't deliver data on time, if your data doesn't have a certain level of quality,

181

if you don't know who's responsible for all these things, problems happen throughout the process.

182

There's going to be days that something happens upstream that you can't predict and now your data is wrong, or maybe it's late.

183

So SLAs, and I'm just going to steal this from locally optimistic, is basically a commitment between a service provider and a client,

184

particular aspects of the service, kind of quality, availability, responsibilities that are agreed upon between the service provider and the service user.

185

The goal here is that in situations where often this data is required, like let's say for a report every Monday at 8 a .m.,

186

that everyone is in full understanding of, one, that there is a due date for this data to exist.

187

Two, that there will be people like on call and ready in case at 7 .30 you've figured out that, hey, this data is not there.

188

And we know who to call.

189

And it just makes sure that everyone is in agreement on what services need to occur

190

because here's what happens if you don't have an SLA.

191

And I've seen this happen.

192

Oh, hey, I made a change to a, let's say a data pipeline last night and it broke some things.

193

And in general, no one ever complains when this breaks, but it was Tuesday evening.

194

And on Wednesday, there's a board meeting that occurs.

195

And in that board meeting, they look at this report that depends on this pipeline being successful.

196

And if it's not, you know, the analysts look bad and everyone looks bad.

197

But if I don't know that it's happening and that I should be extra careful on Tuesday, hey, I'm going to keep pushing data,

198

and then everyone's going to be upset.

199

Now, obviously, I shouldn't be breaking data pipelines.

200

But the point more is that everyone knows.

201

So that way, software engineers, as they're making changes to their systems upstream, you know, those conversations can happen.

202

And so that's the goal of an SLA.

203

It's to make sure you're building trust.

204

It's to make sure everyone understands what needs to occur when.

205

Because, again, it's hard to say that, you know, let's say data engineering is responsible if they're unaware

206

that there is some sort of end goal that needs to always be successful at a certain time.

207

And so that's why you'll hear things like SLAs is because oftentimes you need to kind of branch this gap between,

208

you know, the engineering side and maybe more the analytical side

209

and the business side so that everyone understands when things are supposed to exist or when things are supposed to happen.

210

And there's a certain level of trustworthiness

211

and a level of like knowing this data will be here 99 .999 % of the time.

212

Now with that, this will end video one of data engineering vocab.

213

I really want to do some others where we're going to talk about things like Hedipotent, acid.

214

We're going to talk about some of the SQL terms that you might hear that people just throw around.

215

You're like, why did this person say CTE?

216

What is that?

217

So I have hopefully more of these planned depending on how this video goes.

218

And so, yeah, I really appreciate all of your guys' time and I will see you next time.

219

Thank you and goodbye.

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

FOR YOU

本課的詞彙與口語要點

這節口語課以影片“Vocabulary for Data Engineers - Data Engineering 101”為素材。影片中反覆出現的詞有：warehouse, pipeline, dimension, task, lake。這段影片共有 219 個句子、3114 個單詞可供跟讀。講話部分時長為 15:05。說話人語速較快，每分鐘約 206 個詞，會出現較多連讀和弱讀。 85% 的單詞屬於英語最常用的 3,000 詞，其餘的詞建議在練習前先學一下。

影片中的重點詞彙

影片中 15 個值得學習的單詞，附發音和釋義：

單詞	發音	釋義
warehouse 名詞	/ˈwɛə(ɹ)haʊs/	倉庫 /倉庫
pipeline 名詞	/ˈpaɪpˌlaɪn/	管道, 管線 /管線
dimension 名詞	/daɪˈmɛn.ʃən/	方面, 特點 /特點
occur 動詞	/əˈkɜː/	發生 /發生
connect 動詞	/kəˈnɛkt/	連線 /連線
integration 名詞	/ˌɪn.tɪˈɡɹeɪ.ʃən/	融合, 統合 /統合
depend 動詞	/dɪˈpɛnd/	信任, 信賴 /信賴
capture 動詞	/ˈkæp.(t)ʃɚ/	捕獲 /捕獲, 佔領 /佔領
graph 名詞	/ɡɹæf/	圖表 /圖表
extract 名詞	/ˈɛkstɹækt/	精
upstream 形容詞	/ʌpˈstɹiːm/	上游
refer 動詞	/ɹɪˈfɜː/	談到 /談到
essentially 副詞	/ɪˈsɛnʃəli/	本質上 /本質上, 基本上
whereas	/(h)wɛɹˈæz/	然而
rely 動詞	/ɹɪˈlaɪ/	依賴 /依賴, 依靠

影片中出現的短語動詞

單詞	釋義
end up 動詞	到達
figure out 動詞	弄清楚
put together 動詞	拼合, 組合 /組合

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	are often managed · are utilized · is predefined
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事	I've unavoidably added · you've ever worked · have moved
定語從句 who / which + 從句 — 補充說明人或事物	people who are · someone who is · ones who develop

需要注意的發音

說話人用了 68 次縮略和弱讀形式，例如 you're, we're, don't。請按聽到的簡短形式來說。

“th” 音: thrill /θɹɪl/, trustworthiness /ˈtɹʌst.wɜɹ.ði.nɛs/
“sh” 和 “zh” 音: dimension /daɪˈmɛn.ʃən/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, capture /ˈkæp.(t)ʃɚ/, essentially /ɪˈsɛnʃəli/, transaction /tɹænˈzækʃən/
長單詞——注意重音位置: integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, analytical /ˌæn.əˈlɪt.ɪ.kəl/, essentially /ɪˈsɛnʃəli/, naturally /ˈnæt͡ʃ.(ə.)ɹə.li/, interaction /ˌɪn.təˈɹæk.ʃən/

中文母語者容易讀錯的音：

/v/ — 不要讀成 /w/，上齒輕觸下唇: involve /ɪnˈvɑlv/, provider /pɹəˈvaɪ.də(ɹ)/, versus /ˈvɝsəs/, developer /dɪˈvɛləpɚ/, availability /əˌveɪ.ləˈbɪl.ɪ.ti/
詞尾子音 — 要讀清楚，後面不要加母音: warehouse /ˈwɛə(ɹ)haʊs/, integrate /ˈɪn.tɪ.ɡɹeɪt/, connect /kəˈnɛkt/, depend /dɪˈpɛnd/, graph /ɡɹæf/
/r/ 和 /l/ 的區別: rely /ɹɪˈlaɪ/, naturally /ˈnæt͡ʃ.(ə.)ɹə.li/, recall /ɹɪˈkɔl/, vocabulary /vəˈkæb.jə.lə.ɹi/, thrill /θɹɪl/

如何用這段影片練習

先完整聽一遍影片，不要開口，記下不認識的單詞。
先用 0.75 倍速逐句跟讀，熟練之後再回到正常速度。
錄下自己的聲音並與原聲對比，特別注意 warehouse, pipeline, dimension 這類單詞。

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: Vocabulary for Data Engineers - Data Engineering 101 - 通過影片學習英語口語

選擇練習模式

下載應用

推薦影片

How Modern Data Teams Work (Engineer, Analyst, Scientist, Architect, ML)

The No-Code Roadmap: How I Approach Prototyping

Engineer's tool list

Art Direction Techniques You Can Use

Master AI in 60 Minutes with Vector Databases!

What is Event Driven Architecture (EDA)?

What are KPIs and Metrics? | Data Fundamental for Beginners

Fastest way to become an AI Engineer in 2026

Every Networking Concept Explained | Networking 101 (2026)

Data Analysis Essentials in Excel

Database vs Data Warehouse vs Data Lake | Explaining the Differences

What Is a Data Mesh? Databricks Unity Catalog Explained