ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: 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

วิดีโอแนะนำ

220 ประโยค

คำศัพท์และข้อสังเกตด้านการพูดสำหรับบทเรียนนี้

บทเรียนฝึกพูดนี้ใช้วิดีโอ “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/	คลังสินค้า, โกดัง
occur คำกริยา	/əˈkɜː/	เกิด
connect คำกริยา	/kəˈnɛkt/	เชื่อม, ต่อ
depend คำกริยา	/dɪˈpɛnd/	พึ่ง
capture คำกริยา	/ˈkæp.(t)ʃɚ/	ยึด
graph คำนาม	/ɡɹæf/	กราฟ
query คำนาม	/ˈkwɪɹ.i/	สอบถาม
chart คำนาม	/t͡ʃɑɹt/	ผัง, แผนผัง
acid คำนาม	/ˈæsɪd/	กรด
select คำกริยา	/sɪˈlɛkt/	คัดเลือก
steal คำกริยา	/stiːl/	ขโมย, ลัก
hire คำกริยา	/ˈhaɪɹ/	จ้าง
enterprise คำนาม	/ˈɛntəˌpɹaɪz/	ธุรกิจ
log คำนาม	/lɔɡ/	ซุง, ท่อน
database คำนาม	/ˈdeɪtəˌbeɪs/	ฐานข้อมูล

ไวยากรณ์ในวิดีโอนี้

โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:

โครงสร้าง	ในวิดีโอ
Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ	are often managed · are utilized · is predefined
Present perfect have/has + กริยาช่อง 3 — เหตุการณ์ในอดีตที่ยังเกี่ยวข้องกับปัจจุบัน	I've unavoidably added · you've ever worked · have moved
Relative clauses 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/

เสียงที่คนไทยมักออกเสียงยาก:

เสียงท้ายคำ — ออกเสียงให้ครบ ไม่เปลี่ยนเป็นตัวสะกดแบบไทย: warehouse /ˈwɛə(ɹ)haʊs/, analytical /ˌæn.əˈlɪt.ɪ.kəl/, graph /ɡɹæf/, whereas /(h)wɛɹˈæz/, involve /ɪnˈvɑlv/
/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/
/z/ — เสียงก้อง ไม่ใช่ /s/: whereas /(h)wɛɹˈæz/, transaction /tɹænˈzækʃən/, enterprise /ˈɛntəˌpɹaɪz/, organize /ˈɔɹɡənaɪz/, oftentimes /ˈɔf.ənˌtaɪmz/

วิธีฝึกกับวิดีโอนี้

ฟังวิดีโอให้จบหนึ่งรอบโดยยังไม่ต้องพูด แล้วจดคำที่ยังไม่รู้จัก
เริ่มที่ความเร็ว 0.75× พูดตามทีละประโยค แล้วกลับไปใช้ความเร็วปกติเมื่อเริ่มคล่อง
อัดเสียงตัวเองแล้วเทียบกับต้นฉบับ โดยสังเกตคำอย่าง warehouse, occur, connect เป็นพิเศษ

เทคนิค Shadowing คืออะไร?

Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ

เทคนิค shadowing: อ่านคู่มือฉบับเต็มทีละขั้นตอน →

ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: 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