シャドーイング練習: 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発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

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です。話す速さは速く、1分あたり約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ɜː/	問い合わせる
rely 動詞	/ɹɪˈlaɪ/	頼る, あてにする
transaction 名詞	/tɹænˈzækʃən/	処理
transform 動詞	/tɹænsˈfɔɹm/	変形する, 変換する

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
受動態 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

注意したい発音

話し手はyou're, we're, don'tなど、短縮形や弱形を68回使っています。聞こえたとおりの短い形で発音しましょう。

「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/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: rely /ɹɪˈlaɪ/, naturally /ˈnæt͡ʃ.(ə.)ɹə.li/, recall /ɹɪˈkɔl/, vocabulary /vəˈkæb.jə.lə.ɹi/, thrill /θɹɪl/
/v/ — /b/ にならないように、上の歯を下唇に当てる: involve /ɪnˈvɑlv/, provider /pɹəˈvaɪ.də(ɹ)/, versus /ˈvɝsəs/, developer /dɪˈvɛləpɚ/, availability /əˌveɪ.ləˈbɪl.ɪ.ti/
/f/ — 「フ」ではなく、上の歯と下唇で出す: graph /ɡɹæf/, refer /ɹɪˈfɜː/, transform /tɹænsˈfɔɹm/, format /ˈfɔːɹ.mæt/, define /dɪˈfaɪn/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。warehouse, pipeline, dimensionなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: 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)

Data Analysis Essentials in Excel

Database vs Data Warehouse vs Data Lake | Explaining the Differences