> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 数据工程师应该掌握的 6 个技能
- URL: https://www.hubwiz.com/blog/6-skills-every-data-engineer-should-have/
- Published: 2026-08-07T15:06:58.000Z
- Updated: 2026-10-13T15:46:59.000Z
- Description: 在这篇文章中，我分享了我认为每个数据工程师都应该掌握的六项技术技能。它们短期内不会过时。
- Author: admin
- Tags: JOB MARKET, #Import 2026-10-14 14:41

如果我现在才进入数据工程领域，我会感到极度手足无措。大量的工具、大量的技能，而且我还没把 AI 相关的东西摆到桌面上来。

我在某处读到过，这个时代最有效的学习方式，是去学习那些不会改变的东西。回顾我作为数据工程师的旅程，我意识到确实存在这样的一些东西。

在这篇文章中，我分享了我认为每个数据工程师都应该掌握的六项技术技能。它们短期内不会过时。

## 1、在我们继续之前

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-7U3QX3DwVD6QuK9Y.png)

对我来说，学习某样东西最重要的方面，是拥有一个可靠的反馈回路，并有人为你提供反馈：你的朋友、你的资深同事，或者互联网社区。

让 Gemini 或 ChatGPT 扮演一个了解你正在做什么的人（例如，"想象你是一位有 20 年经验的数据工程师，帮我点评一下这个转换 SQL 脚本"）也不失为一个好选择。

关键是要知道你所做的事情是否走在正确的轨道上。

## 2、数据建模

你很快会意识到一个事实：后续的每一个流程——每一条管道、每一个查询、每一个机器学习模型——都建立在数据模型所定义的结构之上。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-NrG0IW3HCXV5HZ_p.png)

如果数据仓库是一座建筑，那么数据建模就是建筑蓝图。没有它，我们根本不知道下一步该做什么。我们可以盲目地加载和查询数据几个月；然而，噩梦很快就会来临：

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-H1cSbfFoXjPccaTz.png)

- **维护成本**：没有清晰的蓝图，我们会留下一堆乱七八糟的 SQL 脚本和数据表，使维护成为一个昂贵且令人沮丧的过程
- **处理效率低下**：针对设计糟糕的结构进行查询，通常既慢又消耗大量资源
- **数据完整性问题**：如果不强制实施关系和约束，就很难确保数据完整性，这可能使信息变得不可靠
- **奇怪的洞察**：没有可靠的数据以及标准的加载和检索方式，分析师和数据科学家很可能会产出糟糕的报告和机器学习模型
- **缺乏信任**：业务用户随后会利用这些奇怪的洞察来做决策，这可能导致代价高昂的错误。流程很快就会多出一步：检查洞察是否有效

让我们想象一个更美好的场景：如果我们有一套精心设计的数据建模方案摆在那里：

- **共同语言**：有了数据建模，我们就有了对组织数据的共享、统一视图，促进了利益相关者之间的清晰沟通
- **数据质量和完整性**：建模约束和关系为我们确保数据质量提供了一个良好的起点

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-Vabv-W0IN1GiyGpU.png)

- **减少错误**：数据分析师确切知道如何查询某条洞察。数据工程师确切知道数据将被加载到哪个位置。所有必要的转换都事先完成，让数据组织得井井有条，随时可以对外提供。一个好的数据模型会尽可能减少错误。

### 2.1 如何学习它？

我们首先需要知道的是，数据建模是一个从高层业务概念走向底层技术实现的过程：

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-SA6ONtYDuNHH40_m.png)

- **概念数据模型**：这是最高层次的视图，专注于捕捉业务需求。它识别核心业务实体（例如*客户*、*产品*、*订单*）以及它们之间的关系。在这个阶段我们不关心底层技术。**概念模型**用于与利益相关者对齐。
- **逻辑数据模型**：这一层比概念模型更详细。我们为每个实体添加属性（例如，Customer 有 first\_name、email、customer\_id），确定主键和数据类型（例如，string、integer）。这里我们同样不关心技术。逻辑模型充当业务概念与物理实现之间的桥梁。
- **物理数据模型**：这是针对特定数据库系统的具体实施蓝图。它将逻辑模型转化为表、列、约束或优化技术，例如聚簇（clustering）或分区（partitioning）。这里我们使用所选技术的术语和特性（例如，BigQuery、Snowflake、Databricks）。

接下来是探索数据建模方法论。

**Kimball 方法（维度建模）**提供了一种自下而上的方法，专为快速、易于理解的分析而优化。该方法在[《数据仓库工具箱》](https://www.amazon.com/Data-Warehouse-Toolkit-Definitive-Dimensional/dp/1118530802?ref=hubwiz.com)中有详细记载，该书是维度建模的权威指南。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-Q4nO_3E8YYSuFJWz.png)

其核心结构是**星型模式**，由一个包含定量度量或事件的中心**事实表**和提供描述性上下文的**维度表**（例如，客户详情、产品信息、日期）包围组成。

相比之下，**Inmon 方法**采取自顶向下的方式，主张创建一个集中的、高度规范化（通常达到第三范式，即 3NF）的企业数据仓库（EDW）。这个 EDW 充当唯一的真相来源。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-HGqw810txUcXezq2.png)

然后从这个规范化的核心构建部门级数据集市，以满足特定的分析需求。这种方法更复杂、敏捷性更低，但在大规模数据集成和最小化数据冗余方面表现出色。

我建议先学习 Kimball 方法，因为我个人认为它更容易上手和实践。如果我要重新学一遍 Kimball，我会尝试从书中掌握它的基本原理，包括事实、维度以及四步流程。如果你不想在理论上花太多时间，那么[阅读指南](https://www.holistics.io/blog/how-to-read-data-warehouse-toolkit/?ref=hubwiz.com)正是你需要的。

之后，我们需要实践：

- 选择你最喜欢的业务领域。
- 从定义业务问题开始。例如，"我们需要跟踪哪些关键绩效指标？"答案（例如，每日销售收入、新增订阅用户数）将构成事实表的基础。
- 然后，问"我们希望如何对这些指标进行切分？"答案（例如，按客户地理区域、按产品类别、按时间）将定义维度表。
- 构建一个简单的星型模式。
- 检查你的建模能否帮助你顺畅地回答你的问题。
- 如有需要，调整并改进你的建模。
- 获取反馈并迭代。

## 3、Git

我们很少独自工作。我们很少只与单一版本的数据管道、Python 应用或 SQL 脚本打交道。组织需要一种方式对工作做版本控制并支持协作。

Git 就是做到这一点的标准方式。它是一个由 Linux 开发社区于 2005 年开发的[开源](https://git-scm.com/about/free-and-open-source?ref=hubwiz.com)分布式版本控制系统。如果你对 Git 完全陌生，你可能会发现它需要花不少时间学习。（为什么我们需要 `git clone`，而明明可以压缩并下载整个仓库？）。

然而，你很快会体会到 Git 的版本控制能力，它在开发中为你节省大量时间，也让分享你的工作变得更加容易。无论你的代码有多好，如果你不懂 Git，你就很难与他人协作。

防止生产环境发生奇怪的事情、追踪 bug（为什么之前的版本没发现这个 bug）、构建 CI/CD 流水线、将你的工作与队友隔离开来，等等。

有无数的好处和实际用途。

### 3.1 如何学习它？

在这篇文章列出的技能中，我认为 Git 是最容易学习的。在 GitHub 上做一个玩具项目、在笔记本电脑上安装 Git、练习各种命令。

关键是在实践之前理解它的基本原理。

Git 以快照的形式存储数据，通过利用指针提供强大的分支能力。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-rLZq9jBV4RdMVT8n.png)

一次提交（commit）是项目在特定时间点的完整快照。它是仓库中每个文件和文件夹在提交时刻的完整画面。一次提交会有指向其父提交的指针。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-ANx_Pz8hmoNhJC5U.png)

Git 分支只是一个可以移动的、指向某次提交的指针。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-lsvw_NNUz3UhtNL4.png)

更多细节，你可以查看我写的 15 分钟学习 Git 指南：[Git for Data Engineers](https://vutr.substack.com/p/git-for-data-engineers)。

## 4、SQL

如果你在数据领域工作，无论你是数据工程师、数据分析师还是数据科学家，你都"说"SQL。这种语言诞生于 20 世纪 70 年代，用于操作和检索关系数据库中的数据。从那时起，它作为处理这些数据库的主要接口，在全球范围内被越来越广泛地采用。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-et7BXp1_QCpMSoGm.png)

OLAP 数据库的演进以及 DBT、SQLMesh 等转换工具的兴起，使 SQL 成为数据转换的有吸引力的选择——而数据转换过去主要由 Java 或 Python 等过程式语言处理。一些云数据仓库，如 BigQuery，甚至允许用户用 SQL 做机器学习。

数据工程师用 SQL 做很多事情。

### 4.1 如何学习它？

首先，学习语法。

从简单开始，先处理单张表：SELECT、FROM、WHERE、GROUP BY、ORDER BY、HAVING、SUM、COUNT、LIMIT…… 用于检索数据，以及 INSERT、UPDATE、DELETE 用于修改数据。

然后，我们开始处理多张表。学习 INNER JOIN、LEFT JOIN、RIGHT JOIN 和 FULL OUTER JOIN 之间的区别。

接下来，当进入 WINDOW FUNCTION（窗口函数）时，难度会稍微加大。和 GROUP BY 一样，它对行组执行计算，但两者有区别：

- **GROUP BY** 会折叠行。它把多行聚合成单个汇总行。例如，`SELECT country, SUM(sales) FROM products GROUP BY country` 会为每个类别返回一行，显示该类别的销售总额。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-J7grFEyQTJ8Icm3L.png)

- **窗口函数** 对一行"窗口"进行操作，但不会折叠它们。它们根据定义的窗口为每一行返回一个值。例如，
- `SELECT country, SUM(sales) OVER (PARTITION BY country) AS category_total_sales FROM products` 会返回所有原始产品行。但是，它会在每一行上添加一个新列（category\_total\_sales），显示该产品所属类别的销售总额。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-5PTp5m7MS96-BUE7.png)

然后，我们来到 CTE（公共表表达式）。它们对于将复杂查询分解为逻辑清晰、可读的步骤至关重要，这提高了可维护性。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-pCIXe73GPNkkv4zt.png)

然而，仅学习语法是不够的。数据工程师必须知道底层发生了什么，因为我们不仅要编写 SQL 查询，还要编写优化过的查询。理解执行顺序至关重要。一个完整的查询会按照以下顺序执行。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-AcQa2QOyEyKDbT6c.png)

1. **FROM / JOIN**：数据库首先识别所需的表，并执行任何连接以创建完整的数据集。
2. **WHERE**：然后过滤这个数据集，跳过不满足条件的行。（例如，X > 3）
3. **GROUP BY**：剩余的行根据一列或多列的值进行分组，为聚合做准备（例如，SUM、COUNT、AVG……）
4. **HAVING**：行分组后，此子句过滤掉不满足聚合条件的记录（例如，SUM(X) > 3）
5. **SELECT**：引擎处理 SELECT 列表，确定最终结果中包含哪些列、表达式和聚合值。窗口函数也在这里处理。
6. **DISTINCT**：如果指定了，则从结果集中移除重复行。
7. **ORDER BY**：最终结果集根据指定的列或表达式进行排序。
8. **LIMIT / OFFSET**：查询将输出限制为特定数量的行。

> **注意**[QUALIFY](https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax?ref=hubwiz.com#qualify%5Fclause)

## 5、Python

正如我提到的，数据工程师将 SQL 用于各种目的，但不是所有事情。Python 可以弥补这一点。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-wpBZ-ECs_yhgVSqG.png)

你看到重复的任务并想将其自动化。Python 可以做到。

你面临难以用 SQL 表达的复杂转换。Python 配合 PySpark、Pandas 或 Polars 可以帮上忙。

数据来自许多系统。Python 可以通过 REST API 帮助拉取它们。

你需要编排许多数据管道步骤。Python 可以借助 Airflow 或 Dagster 等工具提供帮助。

或者，你想构建一个数据应用。Python 可以借助 Streamlit 或 FastAPI 等后端框架提供帮助。

学习 Python 是必须的。

### 5.1 如何学习它？

与其他语言相比，学习 Python 相当容易，因为它的语法简单得多。有大量的资源可以帮助我们学习如何在 Python 中编写函数、if 子句或类。

然而，仅学习语法永远不够。再说一次，我们很少独自工作。写代码不难，但写出可读、可维护、可扩展的代码需要时间。我们中的许多人都是通过自学 Python 开始这段旅程的；因此，写出凌乱的代码是可以理解的。

随着时间的推移，我们需要关心与我们共事的其他人。无论你的 Python 程序性能多好，如果你的同事不明白你在做什么，或者觉得扩展你的工作极其困难，那么你漂亮的代码就毫无用处。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-DMKe5oEEFlYVbzEj.png)

尽早注意编写有条理的代码。学习设计模式（[Python 通用](https://python-patterns.guide/?ref=hubwiz.com)或[数据管道专用](https://www.startdataengineering.com/post/code-patterns/?ref=hubwiz.com)）、[SOLID](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design?ref=hubwiz.com) 等编码原则，或者读一读[《代码整洁之道》](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882?ref=hubwiz.com)。

一开始这可能会很无聊，因为它不会给你带来 Python 程序第一次运行时的感觉。但是，当你添加一段代码而没有让应用崩溃、看到同事毫不费力地无缝接手你的工作、或者有人把你的工作当作他们组织代码的参考时，那种感觉会更加令人满足。

## 6、OLAP 系统

哦哦，这是我最喜欢的一个。

数据仓库是一个逻辑实体，它整合来自多个来源的数据以满足分析需求。然而，仓库需要一个物理数据库来存储和提供数据。过去，组织也使用支撑其应用的数据库来达到这个目的。

随着时间推移，越来越多的公司意识到，他们需要从数据中提取洞察以获得商业优势。数据库研究者看到了机会。事务型数据库（OLTP）无法很好地服务分析工作负载，因为它们本来就不是为此设计的。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-gDu59C1P8mpAUCDY.png)

OLAP 系统的繁荣开始了。BigQuery、Databricks、Snowflake、Redshift 或 Clickhouse。它们被设计用来以最先进的优化技术处理 TB 甚至 PB 级的查询。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-PCTAXe3irKoCp-rk.png)

如今，OLAP 数据库是数据基础设施中最重要的组成部分。大多数与数据相关的任务都在这里发生：摄取数据、转换数据、提供数据，或执行数据治理。

### 6.1 如何学习它？

学习任何 OLAP 系统的关键在于理解两件事：它如何处理数据以及它如何存储数据。好消息是，这些系统有一些共同点：

**总体**：大多数 OLAP 系统采用无共享（share-nothing）架构；计算层和存储层分离以实现高可扩展性。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-RMGzBlui-Az3MgNX.png)

**处理**：由于数据量巨大，数据通常由多个工作节点处理。这些系统还采用[向量化执行](https://www.youtube.com/watch?v=FrspnYbFSxQ&ref=hubwiz.com)和/或[代码生成](https://www.youtube.com/watch?v=UPQ53hM6AWE&ref=hubwiz.com)等技术来提升性能。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-uVqUbg41r-WrOwlN.png)

**存储**：

- OLAP 系统中的数据以[列式或混合格式](https://vutr.substack.com/p/we-might-not-completely-understand)存储。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-PPl15g4eaLsn8Fqe.png)

- 数据还带有丰富的元数据，帮助查询引擎在处理查询时尽可能跳过更多数据。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0--VcTMaaQ4_FtXwoE.png)

- 为了实现版本控制并支持工作负载隔离（ACID 中的"I"），这些系统不允许覆盖数据，因为已写入的数据是不可变的，变更会导致写入新文件。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0--C1dvaF5fYr8eAwj.png)

- 为了实现可扩展性和成本效益，大多数系统使用对象存储（或具有共享对象存储特性的存储）。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-JrsmRrKmQwaJZrlH.png)

记住这些要点，你就可以探索任何你想要的 OLAP 系统了。对于具体的解决方案，最好的方法就是亲自试一试。大多数云数据仓库都为其服务提供试用期。

试一试，应用他们推荐的最佳实践，看看它对数据治理有什么帮助，理解它的定价模式，以及它如何与其他系统集成。

湖仓一体（lakehouse）范式的兴起意味着 OLAP 系统不再是厂商的专属领域。一个查询引擎（Spark、Trino）+ 对象存储（GCS、S3）+ 表格式（Delta Lake、Iceberg），你就拥有了自己的 OLAP 系统。上面提到的观察（**总体、处理、存储**）在这里依然适用。

与云数据仓库相比，自己管理这些系统需要付出更多努力，但作为回报，你对你的 OLAP 系统拥有更多的控制权。

## 7、编排（Orchestration）

当我们在做个人项目时，一个单独的 SQL 脚本或 PySpark 应用就足够了。然而，在生产环境中事情会变得复杂，因为你的团队有许多 dbt 模型和 Python 脚本需要运行。

更重要的是，它们需要按顺序运行。一个将数据加载到暂存表的任务必须成功完成，转换任务才能开始；而转换任务又必须在最终报表表更新之前完成。

手动管理这种复杂性不是解决办法。Apache Airflow 和 Dagster 等工具应运而生。除了 OLAP 系统之外，数据编排工具是数据基础设施中不可或缺的一部分。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-PwBJDUTZWpebkDwr.png)

它自动化了整个数据工作流的调度、执行、监控和管理。这些工作流通常表示为有向无环图（DAG），图中每个节点是一个任务，有向边表示任务之间的依赖关系。

这些工具的必要性源于生产级数据系统的关键需求：

- **依赖管理**：编排器确保下游任务只在其所有上游依赖完成后才运行。这正是我们想要的——例如，从两个来源拉取 API，然后将它们连接起来。
- **调度**：它们提供超越简单基于时间触发的复杂调度能力，支持类 cron 的调度、基于事件的触发（例如，当文件到达 S3 时运行）或数据感知的调度（例如，当上游数据资产可用时运行）。
- **错误处理和重试**：任何事情都可能失败；网络问题、API 服务器宕机或 SQL 语法错误都很常见。这些系统提供内置机制来重试失败的任务并自动进行数据回填。
- **监控和可见性**：编排工具还提供用户界面，给出所有数据管道的完整可视化概览。它们让工程师能够监控 DAG 运行的状态、检查单个任务的日志，并在失败时接收告警，为数据平台的健康状况提供关键的可见性。

### 7.1 如何学习它？

记住这些要点

**基于任务 vs 基于资产的编排**：你会在大多数编排工具中看到这两种方法。第一种方法说的是"先运行这个作业，再运行那个作业"（Airflow 就是按这种方法设计的），而后者问的是"保持这些资产（表、模型……）是最新的吗？"（Dagster 就是按这种方法设计的）。

**幂等性和回填**：这是可靠数据管道的两个关键概念。

- **幂等性**意味着使用相同输入多次运行一个任务会产生相同的结果（例如，f(x) = x \* 1）。幂等管道可以在失败后安全重试，而不会产生重复数据或其他副作用。实现幂等性的一个常见模式是设计覆盖特定数据分区（例如，某一天的数据）而不是追加到该分区的作业。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-u605Gi07hTMOTJp5.png)

- **回填**是为历史时段运行管道以重新处理数据的过程，也许是为了修复原始逻辑中的 bug，或者纳入延迟到达的数据。幂等设计是安全、轻松回填的先决条件。编排工具提供了在特定日期范围内触发和管理这些回填运行的机制。

![None](https://www.hubwiz.com/blog/content/images/2026/08/0-pyLednLXehWb1DwJ.png)

对于具体工具：

- 弄清楚你的凭证（如 API 令牌或云服务账号）是如何管理的。
- 理解这些工具如何隔离任务。
- 依赖：Dagster 支持每条数据管道拥有自己的一组 Python 依赖，而 Airflow 在全局层面管理依赖。
- 资源隔离：Dagster 中的每个任务都在一个专用的 Kubernetes Pod 中运行。最初，Airflow 被设计为一组 Celery 工作节点，任务可以在同一工作节点上运行。后来，Airflow 也支持将任务作为 Kubernetes Pod 运行。
- 理解这些因素将让你更容易维护和监控生产级环境。
- 除了提供的抽象之外，我还可以用哪些其他抽象来扩展工具的功能？（例如，Airflow 有 Hook 和 Operator 的概念，允许用户自定义）
- 这些工具已经对常见的数据源和数据目标有大量支持。然而，这并不全面。按照工具的最佳实践，学习如何扩展对所需数据源/数据目标的支持至关重要。

下一步是在你的笔记本电脑上运行这个工具并编写一些 DAG。**Apache Airflow** 是一个很好的起点，因为它拥有庞大的社区和大量的集成。

### 8、结束语

感谢你读到最后。

在这篇文章中，我概述了六个我认为每个数据工程师都应该优先掌握的技术技能。我分享了每项技能、它们为什么重要，以及我基于观察和经验高效学习和使用它们的体会。

当然，还有其他我们需要学习的东西，比如数据治理、云基础设施、Docker 和 bash 脚本。但我相信，掌握数据建模、Git、SQL、Python、OLAP 系统和编排，将为我们的职业生涯打下坚实的基础。

而且别忘了反馈回路。它是你掌握一项技能快慢的决定性因素。

好了，下次见。

---

原文链接: [6 technical skills every data engineer should have](https://medium.com/data-engineer-things/6-technical-skills-every-data-engineer-should-have-43bb894bd2a5?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)