Vocabulary for Data Engineers

Data engineering has undergone a significant transformation in the last five years. The vocabulary has evolved alongside the tooling — from traditional ETL pipelines to modern lakehouse architectures, from hand-rolled transformations to framework-driven analytics engineering. For non-native English speakers working in data, this evolving vocabulary can be confusing.

This guide covers the most important data engineering terms, with clear definitions and examples of how they are used in professional conversations and documentation.

---

Data Movement Patterns

ETL (Extract, Transform, Load)

In the traditional ETL pattern, data is extracted from source systems, transformed (cleaned, joined, aggregated) outside the destination, and then loaded into a data warehouse.

“Our legacy pipeline follows an ETL pattern — data is transformed in a staging area before being loaded into the warehouse.”

ELT (Extract, Load, Transform)

ELT reverses the transformation step: data is loaded into the destination first, then transformed using the compute power of the warehouse itself. This is the dominant pattern in modern cloud data stacks.

“We switched to an ELT pattern when we moved to BigQuery — raw data lands in the landing zone, and dbt handles all transformations inside the warehouse.”

Data Pipeline

A data pipeline is a sequence of steps that move and transform data from source to destination.

“The ingestion pipeline runs every hour, pulling events from Kafka and landing them in S3.”

---

Storage Architecture

Data Warehouse

A data warehouse is a structured, relational system optimised for analytical queries. Examples: Snowflake, BigQuery, Redshift.

“Business analysts query the data warehouse directly using SQL.”

Data Lake

A data lake is a large repository of raw data in its native format — structured, semi-structured, and unstructured — stored cheaply in object storage.

“We dump all application logs and clickstream data into the data lake in S3 before processing.”

Data Lakehouse

A data lakehouse combines the low-cost storage of a data lake with the querying and governance capabilities of a data warehouse. It is the architecture behind platforms like Databricks and Apache Iceberg.

“We’re migrating to a lakehouse architecture using Apache Iceberg — it gives us ACID transactions on top of S3 storage.”

---

Transformation and Modelling

dbt (Data Build Tool)

dbt (pronounced “dee-bee-tee”) is an open-source framework that allows data analysts and engineers to write SQL-based transformations, apply version control, and manage the dependency graph between models.

“All our transformation logic lives in dbt models. When we run dbt build, it executes the entire DAG from raw to mart.”

“We write dbt tests for every mart table — row count checks, not-null assertions, and uniqueness tests.”

Data Model

A data model describes the structure and relationships of data. In analytics, it typically refers to a SQL transformation that shapes raw data into a useful form.

“The orders model joins the raw_orders table with the customers dimension to produce a denormalised analytical model.”

DAG (Directed Acyclic Graph)

A DAG represents the dependency graph of a data pipeline — which tasks must complete before others can start.

“The dbt DAG shows that the orders mart depends on four upstream models.”

---

Orchestration

Orchestration

Orchestration is the scheduling and coordination of pipeline tasks, managing dependencies and retry logic.

“We use Airflow for orchestration — it manages the scheduling of our 200+ DAG tasks and handles retries and alerting.”

Apache Airflow

Apache Airflow is the most widely used open-source orchestration platform for data pipelines.

“The Airflow DAG runs at 02:00 UTC each morning, triggering the ingestion, transformation, and export jobs in sequence.”

---

Data Quality and Governance

Data Lineage

Data lineage tracks where data came from, how it was transformed, and where it flows to. It is essential for debugging and compliance.

“The lineage graph shows that the revenue metric in the dashboard is derived from the orders table in the warehouse, which was last updated six hours ago.”

“We use dbt’s built-in lineage visualisation to trace data from raw source to BI tool.”

Data Quality

Data quality refers to the accuracy, completeness, consistency, and timeliness of data.

“We run data quality checks after every pipeline run — null counts, duplicate checks, and referential integrity tests.”

Data Catalogue

A data catalogue is a searchable inventory of data assets — tables, columns, owners, and descriptions — that helps analysts find and understand data.

“The data catalogue shows that the customer_id column in the orders table matches the id in the customers table.”

Schema Evolution

Schema evolution is the management of changes to the structure of data over time — adding columns, renaming fields, changing data types.

“We use Apache Iceberg because it handles schema evolution gracefully — we can add columns without rewriting the entire table.”

---

Useful Phrases for Data Engineering Discussions

Discussing Architecture

• “We’re evaluating a move to a lakehouse pattern to reduce the duplication between our data lake and warehouse.”
• “The ELT approach lets us load raw data quickly and iterate on transformations without re-ingesting.”
• “We use dbt for all our transformation logic — it gives us version control, testing, and lineage out of the box.”

Discussing Data Quality

• “The pipeline has a data quality gate — if any test fails, the downstream models don’t run.”
• “We track freshness SLOs for every mart table — the orders mart must be updated within two hours of source data landing.”

Discussing Incidents

• “The dashboard was showing stale data because the Airflow task failed silently at 03:00. The lineage helped us trace which models were affected.”

---

Data engineering vocabulary is increasingly standardised across the industry, largely driven by the modern data stack (dbt, Snowflake/BigQuery, Airflow, Fivetran). Learning these terms will help you read documentation, contribute to design discussions, and communicate more precisely with data analysts, analytics engineers, and data scientists.

Navigating Nuances: Addressing Common Challenges for Non-Native Speakers

Let’s be honest – professional English can feel… dense. The speed of communication in a data engineering environment, coupled with the specialized terminology, creates significant challenges for developers whose first language isn’t English. It’s not just about knowing what something is; it’s about understanding how to discuss it effectively, how to phrase requests clearly, and how to interpret feedback accurately. This section focuses on some of those specific hurdles and offers practical strategies.

One common issue is the subtle differences in phrasing that impact clarity. For example, a native speaker might say “Let’s optimize this query” – while technically correct, it can sound demanding. A more diplomatic approach, especially when reviewing someone else’s work, would be “Could we explore potential optimizations for this query? Perhaps adding an index or adjusting the join strategy could improve performance.” Framing requests as questions encourages collaboration and avoids sounding prescriptive. Similarly, describing a problem in terms of impact rather than simply stating the issue can be incredibly effective. Instead of saying “The data is incorrect,” try “This discrepancy in the sales figures is impacting our ability to accurately forecast demand.”

Another frequent stumbling block is understanding the nuances of feedback. Receiving a comment like “This needs more context” isn’t necessarily criticism; it’s an invitation for clarification. It could mean the reviewer doesn’t understand why you made a particular decision, or that they need additional information to assess your reasoning. Responding with something like “I considered [reasoning] when making this change. Would you like me to elaborate on any aspect of my thought process?” demonstrates engagement and proactively addresses the underlying concern. Don’t be afraid to ask for clarification – it’s far better to seek understanding than to assume a misunderstanding.

Finally, remember that technical jargon doesn’t always translate perfectly across languages. A seemingly simple term like “schema” can have different connotations. Be patient with yourself and others, and actively listen for non-verbal cues—a furrowed brow or hesitant pause – which often indicate confusion. Don’t hesitate to ask for a simpler explanation if you don’t understand something immediately. Building a culture of open communication is key to overcoming these barriers.

Here’s an example demonstrating how jq can be used to filter data and highlight the importance of precise phrasing in describing the desired outcome:

jq '.[] | select(.price > 100) | .name' data.json

This command takes a JSON file named data.json, filters for entries where the ‘price’ field is greater than 100, and then extracts the ‘name’ field from those filtered objects. When communicating this to a colleague, you’d want to be precise: “I need you to use jq to extract the names of all products with a price exceeding $100 from the data.json file.”