शैडोइंग अभ्यास: 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/	कोठी, मालगोदाम
pipeline संज्ञा	/ˈpaɪpˌlaɪn/	पाइपलाइन
dimension संज्ञा	/daɪˈmɛn.ʃən/	पहलू
occur क्रिया	/əˈkɜː/	बीतना
integration संज्ञा	/ˌɪn.tɪˈɡɹeɪ.ʃən/	एकीकरण
graph संज्ञा	/ɡɹæf/	लेखाचित्र, ग्राफ़
upstream विशेषण	/ʌpˈstɹiːm/	ऊपर को
provider संज्ञा	/pɹəˈvaɪ.də(ɹ)/	प्रदाता, दाता
chart संज्ञा	/t͡ʃɑɹt/	लेखाचित्र, चार्ट
acid संज्ञा	/ˈæsɪd/	अम्ल, एसिड
select क्रिया	/sɪˈlɛkt/	चुनना, चयन करना
commitment संज्ञा	/kəˈmɪtmənt/	प्रतिबद्धता, आश्वासन
aspect संज्ञा	/ˈæspɛkt/	पक्ष
steal क्रिया	/stiːl/	चुराना
hire क्रिया	/ˈhaɪɹ/	नियुक्त करना

इस वीडियो का व्याकरण

वक्ता जिन संरचनाओं का सबसे अधिक प्रयोग करता है, वीडियो के असली शब्दों के साथ:

संरचना	वीडियो में
Passive voice be + past participle — ज़ोर इस पर कि क्या होता है, न कि कौन करता है	are often managed · are utilized · is predefined
Present perfect have/has + past participle — बीता हुआ काम जिसका असर अभी भी है	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/

हिंदी भाषियों के लिए मुश्किल ध्वनियाँ:

/v/ और /w/ का फ़र्क़ — /v/ में ऊपर के दाँत निचले होंठ को छूते हैं, /w/ में होंठ गोल होते हैं: warehouse /ˈwɛə(ɹ)haʊs/, whereas /(h)wɛɹˈæz/, involve /ɪnˈvɑlv/, provider /pɹəˈvaɪ.də(ɹ)/, query /ˈkwɪɹ.i/
/z/ — इसे “ज” (/dʒ/) न बनाएँ: whereas /(h)wɛɹˈæz/, transaction /tɹænˈzækʃən/, enterprise /ˈɛntəˌpɹaɪz/, organize /ˈɔɹɡənaɪz/, oftentimes /ˈɔf.ənˌtaɪmz/
शब्द की शुरुआत में s + व्यंजन — पहले “इ” न जोड़ें: steal /stiːl/, swamp /ˈswɑmp/, schema /ˈskiːmə/

इस वीडियो से अभ्यास कैसे करें

पहले बिना बोले पूरा वीडियो एक बार सुनें और जो शब्द नहीं आते उन्हें लिख लें।
0.75× गति से शुरू करें, एक-एक वाक्य की शैडोइंग करें, और सहज लगने पर सामान्य गति पर लौटें।
अपनी आवाज़ रिकॉर्ड करें और मूल से तुलना करें, ख़ासकर warehouse, pipeline, dimension जैसे शब्दों पर ध्यान दें।

शैडोइंग तकनीक क्या है?

शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 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