跟读练习: 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

Database Sharding! Designing Data-Intensive Applications chapter 6

Every Networking Concept Explained | Networking 101 (2026)

"Dive Deep" Leadership Principle Explained by Amazon CEO Andy Jassy

Data Analysis Essentials in Excel