数据工程师
数据工程师让数据按时抵达、保持约定的结构，并留下可追溯的来源记录。报表、建模和依赖数据的产品功能，都会继承这一层交付的一切，包括其中的错误。本指南说明这一学科具体包含哪些工作，以及运维过数据平台的候选人与只写过尚未出错的管道的候选人之间，差别究竟在哪里。
数据工程师做什么？
数据工程师构建并运维那些把数据从产生处送到使用处的系统。工作范围包括：从应用、第三方服务和事件流中接入数据；将其转换为分析师和下游系统可以依赖的模型；调度与依赖管理；生产方与消费方团队之间关于结构和含义的约定；自动化的质量校验；让任何一个数字都能追溯回源头的血缘；以及决定平台每月运行成本的存储与计算选型。衡量成功的标准不是数据存在于某处，而是它正确、及时且可解释。
这一层的失效通常是无声的。任务崩溃反而接近好结果，因为有人会被告知。代价高昂的情况是任务正常完成、却写入了错误的数据：上游改了列名、时区假设发生变化、文件被投递了两次，或者迟到的记录落进了错误的分区。这些都不会抛出错误，能否被发现，取决于事先设计好的校验，而不是等到某位高管觉得某个数字看起来不对之后才补上的检查。
大部分难度出现在组织边界上。生产数据的团队往往不知道谁在消费这些数据，于是应用里一次例行重构，会让三个部门之外的一张报表失效。真正持久的答案是约定而非工具：关于结构与含义的显式契约、在生产侧就做校验、把新增式变更作为默认做法，以及带有提前通知的废弃路径——而这些都需要有人愿意在变更上线之前把话说清楚。
成本已经成为一个设计面，而不是事后才考虑的事情。存储与计算分离让原本负担不起规模的团队用得起了，同时也让人可以在毫无察觉的情况下花掉大量费用。分区、聚簇、文件大小、合并压缩、增量还是全量重建，以及分析师实际执行的查询模式，都会让账单成倍变化，而这些从产出结果上完全看不出来。
团队在什么时候需要这项能力
数据工作通常由应用工程师和分析师顺带承担，直到接缝开始显现。以下这些情形，说明这种安排已经不再划算。
报表之间互相矛盾
两个看板对同一个指标、同一个月份给出不同的答案，因为同一个口径由不同的人、在不同的时间、在各自的工具里分别实现了一遍。此后每次会议的前十分钟，都花在争论谁的数字才对。
上游服务一变更，管道就出问题
某个字段被改名或类型被修改，没有任何预警，直到某张图表渲染为空才被发现。边界上没有约定，这种情况就会无限重演，而修复永远是事后的。
分析师一周的大部分时间都在准备数据
本该做分析的人，在动手之前先要手工清洗、关联和去重——而且每个人的做法都略有不同，这正是报表口径互相矛盾的来源。
平台账单的增速快过业务本身
计算开销上升，平台交付的价值却没有相应增长。诊断的方式是审视查询模式、表的物理布局、物化策略，以及那些本可以做成增量的全量重建，而不是去和厂商谈价格。
时效要求从按天变成了按分钟
某个运营场景现在需要的数据，已经不是夜间批处理能够提供的。引入流处理意味着要面对投递语义、乱序到达、窗口与水位线，以及一整套团队在做决定之前通常会低估的运维负担。
没有人说得清一个数字是怎么来的
审计方、监管方或客户询问某个数字是如何得出的，诚实的回答是一串没有人记录过的转换过程。血缘变得紧迫的时刻，恰恰是它最难被重建的时刻。
核心能力
数据接入
批量抽取、从业务数据库做变更数据捕获（CDC）、消费事件流，以及对接第三方连接器——同时还包括那些不体面的部分：重放、回补、限流，以及导出偶尔并不完整的供应商。
转换与建模
把原始到达的数据整理成人们能够理解的表：在合适的地方使用维度模型，在不合适的地方有意识地做反范式，编写可以安全重跑的增量逻辑，并让测试与模型放在一起而不是各管各的。
任务编排
依赖图、重试策略、回补语义、分区感知和时效承诺——目的是让一个延迟的数据源只影响一个数据集，而不是把影响级联到它之后调度的所有任务。
数据契约与 schema 演进
约定生产方保证什么、在数据产生的地方就做校验、用版本化而不是原地修改，并在下线任何东西之前给消费方留出通知期和迁移路径。
质量校验
时效性、行数、唯一性、参照完整性和分布校验，放在能够先于消费方发现问题的位置上，并把告警阈值调校到一个月之后人们仍然愿意响应的程度。
血缘与可观测性
列级来源追溯、在变更之前而非在它弄坏什么之后做影响分析，以及无需逐条阅读转换逻辑就能回答某个具体数字来自何处的能力。
存储架构
在数仓、湖仓与业务存储之间做选择，选定开放表格式，并把分区、文件大小和合并压缩做对——这些决策会悄悄决定查询速度和每月支出。
流处理
窗口、水位线、乱序与迟到数据、投递保证、状态管理，以及一种判断力：识别出某条流所支撑的决策，并不值得它带来的运维重量。
成本工程
知道哪些负载主导了账单，按任务规模配置计算资源，在划算的地方用物化替代重复计算，对存储做分层，并按数据集而不是按一个月度总额来衡量支出。
治理与访问控制
对个人数据分级，做脱敏与令牌化，在行级和列级上落实访问控制，执行留存策略，并确保敏感字段不会在某张无人分级的衍生表里重新出现。
技术生态
以下列出数据工程领域常见的技术。这描述的是该学科在业界的一般实践，而不是对任何特定工程师技术栈的说明。这个领域里产品的更替速度，远快于失效模式的变化，因此关于正确性、幂等性和成本的推理能力，比清单上任何一个具体名称都更能在不同技术栈之间迁移。
编程语言
- Python
- SQL
- Scala
- Java
数据接入与流处理
- Apache Kafka
- Debezium
- Apache Flink
- Airbyte
- Fivetran
- Amazon Kinesis
计算与转换
- Apache Spark
- dbt
- Apache Beam
- Polars
- DuckDB
任务编排
- Apache Airflow
- Dagster
- Prefect
- Temporal
数仓与查询引擎
- Snowflake
- BigQuery
- Databricks
- Amazon Redshift
- ClickHouse
- PostgreSQL
表格式与存储
- Apache Iceberg
- Delta Lake
- Apache Hudi
- Apache Parquet
- Amazon S3
质量与元数据
- Great Expectations
- Soda
- dbt tests
- OpenMetadata
- DataHub
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应该关注什么
这个领域的候选人通常按工具熟悉度来评估，而这是个错误的坐标轴。产品每隔几年就换一轮，失效模式却分毫未变；真正有信息量的，是那些只有当一个平台运行得足够久、至少错过一次之后才会浮现的方面。
对无声失效的处理方式
问他们会怎样发现一个成功完成的任务写入了错误的数据。经历过的工程师会事先设计检测手段，并能说出具体的校验项；没经历过的会描述如何监控任务状态，而那监控的是错误的对象。
- 无需提示就能区分“任务失败”和“数据集失败”
- 会与源系统对账，而不是默认加载结果可信
- 能讲清楚错误数字进入报表的经过，以及最终是怎么被发现的
- 把校验放在能保护消费方的位置，而不只是放在最后一步
schema 变更与边界
问当生产方团队修改一个字段时会发生什么。回答会暴露他们是把这看作下游要承接的工程问题，还是看作需要向上游协商的约定；只有后者才能撑过屈指可数的几个数据源。
- 曾与生产数据的团队协商过数据契约
- 把新增式变更当作默认，把破坏性变更当作一次事件
- 在改动某些列之前，先弄清楚哪些消费方依赖它们
- 会提前通知并给出迁移窗口，而不是宣布既成事实
幂等性与恢复
问一个任务跑了两次会怎样，或者当数据源做了订正、昨天的数据需要重建时会怎样。这是这个学科中最可靠的技术区分点，而它很少被直接问到。
- 在设计上保证重跑同一时间段会得到相同结果
- 能够回补一段区间而不重复也不丢行
- 能处理在其分区已被处理之后才到达的记录
- 按分区和水位线思考，而不是按整张表思考
建模判断力
问他们如何决定一张表的形态。强的候选人围绕人们真正会问的问题建模，并能为一次反范式给出理由；弱一些的会把某套方法论统一套用，做出一层优雅但没人查询的东西。
- 一个业务指标只在一个地方定义
- 能解释某次有意偏离范式的理由
- 用清晰的边界把原始数据与加工后的产出分开
- 能意识到某些问题并不需要一整套完整的建模层
对时效性的诚实
问他们什么时候反对过使用流处理。实时经常被提出，但真正被需要的次数要少得多；一个会追问“哪个决策依赖这个时效”的工程师，能为团队省下大量运维负担。
- 从数据所支撑的决策出发，而不是从技术出发
- 在别人预期用流处理的场合建议过用批处理
- 能精确地解释投递保证，而不是喊口号
- 把一套流处理系统在凌晨三点的运维代价也算进去
成本意识
问他们上一个平台账单里最大的一项是什么，以及他们为此做了什么。扛过预算的工程师会答得很具体；没扛过的会把支出当作别人的事，而这正是一个平台悄悄变成工程预算里第二大开销的过程。
- 知道哪些负载主导了支出，以及为什么
- 基于证据调整过分区、文件布局或物化策略
- 把成本归因到具体数据集，而不是只看一个总数
- 能把存储与计算分开来推理
与消费方协作
带来最大差别的工程师，会去和使用其产出的分析师与产品团队交谈。问他们会为一个数据集写下什么、写给谁看——答案能区分服务心态和交付心态。
- 记录一个列的含义，而不只是它的类型
- 知道自己最重要的那些数据集是为回答什么问题而存在的
- 在做出变更之前先通知消费方
- 曾经有计划地下线过一个数据集，而不是任其腐烂
值得一问的面试问题
以下问题供您自己的面试流程参考，如何使用由您决定。评估每位候选人并做出判断的是您；之所以选择这些问题，是因为如果没有真正运维过一个被他人依赖的平台，很难答得好。
一个夜间任务成功完成，却写入了错误的数据。您本来会怎样发现它？
What a strong answer shows
这是这个学科的核心问题。好的回答会描述事先设计好的校验——与源系统对账、分布与数据量监控、唯一性约束——而不是等有人投诉之后再去排查的计划。
上游团队在没有告知任何人的情况下改了一个字段名。本来应该发生什么，现在您又会怎么做？
What a strong answer shows
他们是按约定思考还是按补救思考。眼前的处置并不复杂；有意思的部分是他们提出什么办法，让下一次变更是被提前告知的，而不是被撞见的。
请说明您如何让一条管道可以安全地跑两次。
What a strong answer shows
实操层面的幂等性。关注确定性的分区键、用覆盖而非追加的语义、基于稳定标识的去重，以及对哪些副作用无法靠重跑撤销的认识。
两个团队对同一个月份报出了不同的收入数字。请带我走一遍您解决它的过程。
What a strong answer shows
在含糊情境下的方法。期待他们先比对口径再比对数字，把两个数字都追溯到源头，找出逻辑分叉的位置，然后提出一个有归属的统一口径，而不是只对齐这一次。
您在什么时候反对过使用流处理，当时您提议改用什么？
What a strong answer shows
对复杂度的判断力。强的候选人会从这个决策真正需要的延迟出发，并且能坦然地说一个小时级批处理就已经满足要求，而运维代价只是零头。
数仓账单在三个月里翻了一倍。请带我走一遍排查过程。
What a strong answer shows
对成本的熟悉程度。关注查询级别的归因、某个增量任务被换成了全量重建、小文件泛滥、一次未走分区的全表扫描，或者某个有人加上、却没人复核的定时任务。
您如何处理迟到或乱序到达的记录？
What a strong answer shows
时间是否被显式建模。期待他们区分事件时间与处理时间，给出明确的迟到容忍度，并对超出容忍度的记录如何处理有一个决定。
关于一个数据集，您会写下什么，又是谁来读？
What a strong answer shows
服务意识。最好的回答会覆盖含义、粒度、时效承诺、已知注意事项和归属——写给临时要用它的分析师，而不是写给下一位工程师。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某个组织的报表已经变得不可信。同一指标的口径在不同工具之间彼此不同，只要生产方服务做一次重构管道就会失效，分析师花在核对数据抽取上的时间比分析还多，而平台支出上升之后，没有人能把它归因到某个具体负载。
- Approach
- 新增的工程力量在团队已有的实践之内工作——他们的仓库结构、编排约定、评审流程，以及他们已经选定的平台方向。关于路线图、架构和待办事项排序的决策仍然属于内部团队；新增的力量按同样的迭代节奏承接数据契约、质量与建模方面的工作。
- What this adds to the team
- 团队在不让渡平台控制权、也不让渡优先级决定权的前提下，扩展了自己能够交付的范围。哪些数据集重要、必须达到什么标准，始终由对结果负责的人来决定。
Related disciplines
Frequently asked questions
- 数据工程师和数据科学家有什么区别？
- 数据工程师对数据是否正确、按时抵达以及含义是否被记录负责。数据科学家对这些数据意味着什么负责：界定问题、设计分析、把真实效应与巧合区分开，并在报告结果时完整保留其不确定性。前者修路，后者决定往哪儿开，以及这趟行程是否支撑得起那个结论。只招后者的团队，常常发现自己买到的是昂贵的数据清洗。
- 数据工程师与分析工程师有什么不同？
- 分析工程师主要在数仓内部工作，把已加载的数据变成建模良好、有测试、有文档的表，并与使用这些表的分析师一起维护指标口径。数据工程师负责更宽的面：数据接入、流处理、编排基础设施、与生产方团队的契约、存储架构和成本。两者在转换层相遇；在规模较小的组织里一个人两头都做，这没问题，直到接入侧真正需要投入注意力为止。
- 我们需要的是数据工程师，还是更好的工具？
- 工具在连接器、编排和质量校验上确实有帮助，也没有理由把这些都手写一遍。但工具不会决定一个指标意味着什么，不会去和那个总在改 schema 的团队谈契约，不会决定一条迟到的订正数据该怎么处理，也不会注意到一张无人认领的表已经给董事会报表供数一年了。这些才是反复出现的问题，而它们既是技术问题，也是组织问题。
- 这个角色需要多少软件工程能力？
- 比通常设想的要多。管道就是生产系统：它们需要版本控制、测试、代码评审、持续集成、环境隔离、依赖管理，以及安全发布变更的能力。一个由能写好 SQL、却从未在规范工程流程里工作过的人组成的团队，积累出难以维护的资产的速度会比他们预期的快。
- 在做机器学习之前，我们必须先具备这项能力吗？
- 几乎总是如此。模型会继承训练数据中的每一个缺陷，而建模项目停滞最常见的原因不是建模本身，而是缺少可靠、有文档、被充分理解的输入。团队可以在没有平台的情况下做原型，但无法在每周由人手工拼凑的数据抽取之上稳定运行。
- 到什么时候，团队需要第二位数据工程师？
- 通常是在平台已经有了会察觉到故障的消费方之后——这会让单个工程师同时成为瓶颈和值班风险，并且掌握着别人没有的知识。另一种情形是接入与转换同时处于活跃开发状态，因为两者的工作节奏不同，一个人在两者之间来回切换，哪一边都做不好。
- 数据工程师如何与现有的工程团队协作？
- 在技术团队扩展的模式下，工作由您的团队主导：您的规范、您的评审流程、您的路线图以及您对待办事项的排序，决定构建什么以及何时构建，技术层面的讨论也发生在您自己的团队内部。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.