数据工程师（Data Engineer）们都在做什么？
数据工程师（Data Engineer，下称 DE）是属于软件工程师下的一个细分方向，但是随着行业需求的增多，这个岗位越来越引人注目。我在这篇博文会大致介绍其主要职责，行业内不同的细分方向，和解答在转型数据工程师时的常见问题。
那么 DE 是做什么的呢？这个岗位的核心职责是解决公司关于数据存储与处理的问题。随着企业数据解决方案从关系型数据库到分布式数据库，再到基于云的数据仓库/数据湖的变迁，对应的岗位也从数据库管理员、ETL 工程师等发展为数据工程师。现今所指的 DE 基本是指关于大数据处理的岗位。
具体而言，DE 的主要工作有两大类：
- 数据平台：建设与维护数据平台以提供储存、转换、分析数据的能力
- 数据业务：将处理数据的商业逻辑与业务流程转化为代码形式的数据管道，并在数据平台上管理数据的整个生命周期
但由于公司组织结构、规模、和选用的解决方案的不同，实际的工作内容可能是以上两类中的一部分，也可能是两类都包含。
例如，在 Facebook 和 Uber，DE 几乎只负责数据业务逻辑，大部分工作是在比较成熟的内部数据平台里实现商业指标的计算和处理流程。换言之，他们的主要工具是 SQL，核心任务是通过 SQL 建立起数据处理任务。所依赖的数据平台则是由软件工程师构成的其他部门来开发和维护。
而对于众多使用 AWS 或 GCP 等公有云的中小公司，通过云服务商购买了现成的数据平台解决方案，基础建设的难度大大降低。在这样的公司数据工程师们可以像搭乐高一样，通过选取最适合的云服务来搭建数据平台。这些工程师处于 DE 和 SDE 的交叉领域，可能既要负责数据平台的基建，又要处理数据处理的业务逻辑。
我曾工作过的另一家公司 Expedia 则处于一种中间情况。由 SDE 们维护一套开源数据湖组件，各业务线的数据组自行在 AWS 上部署这套工具，建立与维护专门服务该部门的数据平台。
数据平台
搭建数据平台具体包含这些工作：
- 规划稳定且可拓展的数据储存方案和数据处理架构。数据来源主要是批数据还是流数据，数据的输出是需要实时还是定时更新，数据的增长速度有多快，要根据这些具体的需求和场景建立适当的数据解决方案。
- 选择合适的数据编排（Data Orchestration）工具建立可靠的数据管道，最常见的工具是 Airflow。
- 提供数据平台的支持和管理工具，包括数据目录（Data Catelog）、数据沿袭（Data Lineage）、元数据管理、权限管理、状态监测与报警等等。这些工具可能是自行开发，也可能是选购第三方服务。
- 提供数据质量管理工具，能够监测数据的新鲜度、准确度、完整度等指标。
- 提供数据查询引擎和查询服务或界面，确保下游团队可以按照他们不同的需求来获取数据。
- Terraform、Ansible 等运维自动化工具，和 AWS CloudFormation 等自动化运维云服务。
- 云服务选型。了解市场上的云提供商的功能，和主流的 SaaS 数据服务，考察哪些值得被引入公司的数据平台。
这些工作内容因公司的规模与技术选型而可大可小。对于使用私有数据中心的公司，数据平台的各个部分都很可能需要开发自己的内部实现，那么每一个部分都可能是由一个团队来完成。而对于已经积极拥抱云服务的公司，几个人的小团队也可以完成所有这些内容。
数据业务
有了数据平台，下游组的 DE 就可以在平台上运行具体的数据任务。要将商业上的需求转化成数据工程的任务，具体包括这些工作：
- 数据指标的构思和落地。数据指标通常是由下游的分析师提出，但是如果理解了如何计算这些指标，和为什么要计算它，这对 DE 将商业需求转化成代码会有极大帮助。
- 数据建模。根据数据输入输出时的各种需求创建相适应的数据模型。
- 对各种格式的来源数据的处理，和进入数据平台后的数据清理、标准化、转换等处理。
- 处理程序和查询语句调优。最常见的是 SQL 调优，根据查询引擎的不同，有着各异的调优方式。处理程序调优也是由平台选用的工具而定，常见工具包括 Spark、Hive、Flink、Kafka 等。
- 监测任务状态。比如上游数据库是否稳定可用，平台内各服务状态监测，数据质量监测等。
要注意的是，实际工作中数据平台与数据业务两个方向的职责范围并没有明确的区分。无论是在大小公司，DE 的实际职责可能是上面任意几点的组合。
在前文我泛泛地描述了数据工程师职责范围，但对于有意转往这个方向的朋友恐怕描述地太粗糙了。因此我也尝试回答一些想换方向的人可能会问的问题：
数据工程师需要的编程能力高吗？
DE 需要多少编程能力主要取决于团队对这个岗位的需求。简而言之，是这个岗位更偏平台，还是偏业务。
对于需要自行开发数据平台各个组件的团队而言，他们对数据工程师的编程能力基本和软件工程师无异。这类工程师的核心产出是一个供内部使用数据的服务或软件。
但市场上大部分的 DE做的是数据业务的工作，对于编程能力的要求略低于软件工程师，但对使用 SQL 处理数据的能力要求会高很多。他们典型的编程场景是数据处理任务和数据任务编排（Data Orchestration）。此外，DE 岗位通常对大数据处理的经验也有要求，因为实际工作中有许多项目依赖成员对分布式工具的理解。这些经验的积累往往也与代码阅读和编写能力息息相关。
数据工程师的 On-call 通常是什么内容？会不会比 SDE 轻松？
对于数据平台方向，其本质是维护一套供内部人员使用的各种数据工具，那么他们的 On-call 就是维护这些工具的正常使用，处理用户提交的问题。因为使用者都是内部用户，沟通或测试起来都要比外部用户容易得多，他们通常也不会产生千奇百怪的软件输入，On-call 压力也就比较轻松。
对于数据业务方向的 DE，具体内容和压力取决于其维护的数据在整个公司中的位置。公司的业务线如果多的话，通常中上游部分有专门的数据组管理核心数据，下游各业务线也有各自的组管理其业务数据。那么可想而知，核心数据组的压力远大于业务组的压力。上游的组只能对数据提出严格的 SLA，例如数据新鲜度比较高的 SLA，才能确保下游数据的可用性。而其 On-call 内容通常就是保障数据任务的正常处理，出现异常就及时寻找替代方案进行 backfill，避免违反 SLA。
下游的业务组的压力取决于其终端用户，也就是数据消费者。例如 BI 组，其数据产出是服务于内部 BI 分析的，像供 Business Analyst 们在 Tableau 上做数据可视化使用。这些用户对实时数据的需求度一般比较低，对数据可用性的要求也比外部用户低，可说是 On-call 最轻松的组。但如果终端用户是外部用户，例如政府监管部门，可能会因数据延迟、缺失而导致罚款或吊销牌照，那么就需要足够的人力保障数据可用，其 On-call 压力在 2B 产品中应该算比较高的。
数据工程师的职业发展有哪些选择？
作为软件开发行业中的一个子类，DE 的职业发展和 SDE 没有太大区别。对于主要从事数据平台开发工作的工程师来说，可以深入数据平台的架构，成为数据平台架构师，或者转向为 SDE 做更加 infra 的工作。对于主要做数据业务的工程师来说，除了一样的转型为 Data infra 方向的 SDE，还可以在各种数据使用场景上深挖，例如转型为 Machine Learning Engineer，Data Vidualization Engineer，和 Data Scientist 等。
如果是转型管理岗位，数据平台组是一个不错的起点。随着数据驱动决策的流行，数据平台正在成为核心部门。相较业务部门而言通常更为稳定，且做的事情往往有更大的影响力。
Buy me a Coffee