一名数据工程师的自白

2011年，我作为一名商业智能工程师加入 Facebook。到了 2013 年离开的时候，我的职称是数据工程师。

获得这个职称，并不是因为我被升职或是分配。而是 Facebook 觉得我们的工作已经超越了典型的商业智能。我们为自己创造的这个新角色是个全新的学科。

我的团队处在这场变革的前线。我们一直在开发新的技能呢、新的处理方式、新的工具，而且通常与传统方式背道而驰。

我们是先头部队！我们是数据工程师！

数据工程是什么？

数据科学作为一个学科，已度过其自我肯定和自我定义的青春期。而处在同期的数据工程，是个年龄稍小的弟弟，但是也在度过相似的阶段。数据工程学科以其兄长为榜样，但也在相反的领域定义自己，并找寻属于自已的身份。

数据工程师也像数据科学家一样要写代码。数据科学家有很好的分析能力，并且对数据可视化很感兴趣。与数据科学家不同，而且受启发于我们更显成熟的父学科——软件工程，数据工程师要构建工具、基础设施、框架和服务。事实上可以证明，相比数据科学，数据工程更接近软件工程。

如果讨论与既有职责的关系，数据工程领域可以认为是商业智能和数据仓库的超集，而且更多的元素是从软件工程得来的。这个学科也囊括了所谓的“大数据”分布式系统的相关领域内容，以及广泛的Hadoop生态圈、流式处理和大规模计算的相关概念。

在还没有正规化的数据基础架构团队的小公司里，数据工程的职责也会涵盖搭建和维护组织数据基础架构的工作任务。这包括搭建和维护像 Hadoop/Hive/HBase、Spark 平台之类的活。

在小一些的环境里，人们倾向使用 Amazon 或 Databricks之类的托管服务，或者从 Cloudera 或 Hortonworks 之类的厂商获取支持，这本质上就是将数据工程的职责外包给了其他公司。

在大一些的环境里，由于对数据基础架构团队的需求越来越高时，组织更倾向于专门指定或者开设一个正式的角色来处理这些工作。在这些组织中，这个把数据工程流程自动化的职责，同时落到了数据工程团队和数据基础架构团队手中，而且两个团队合作解决高级问题也是很常见的。

虽然这个角色在工程方面的范围在扩大，但其他原本作为商业工程角色的应关注的方面，却变得越来越次要。比如像构建和维护大量的报表和仪表板，已不是一个数据工程师的主要关注领域。

我们现在有了更好的自服务工具，可以让分析师、数据科学家和广义的“信息工作者”变得更精通数据，可以独自应付数据的使用。

ETL 在变化

我们也观察到从拖拽式 ETL （Extract Transform and Load） 工具到一种更加可编程化的方式的大体转变。像 Informatica、IBM Datastage、Cognos、AbInitio 和 Microsoft SSIS 之类的平台技术掌握在现在的数据工程师中并不常见，取而代之的是更通用的软件工程技能，和对编程或配置驱动的平台技术的掌握，像 Airflow、Oozie、Azkabhan 或 Luigi。工程师开发和维护自己的任务编排器/调度器也是很常见的。

有很多不使用拖拽工具开发复杂软件的理由：但最重要的是代码才是对软件最好的抽象。讨论这个话题超出了本文的范围，但是也很容易推导出为什么要用代码写 ETL，原因和写其他软件是一样的。代码允许任意程度的抽象，允许使用熟悉的方法进行所有逻辑处理，可以很好地和源控制集成，也易于版本管理和协作。事实上 ETL 工具暴露图形接口给用户像是数据处理发展史上的一个迂回，这个话题都可再单独写成一篇有意思的博客了。

让我们强调下这个事实，传统 ETL 工具所暴露出的这种抽象是达不到目的的。我们当然需要将数据处理、计算以及存储进行抽象，但我觉得解决的方法并不是将 ETL 元语（比如源/目标、聚合、过滤条件）展现为一种拖拽风格，需要的是一种更高级的抽象。

举例说明，在现代数据环境中做抽象， A/B 测试框架的试验设置：整个试验是什么样的？相关的处理操作是什么？应该暴露给多少比例的用户？预期每个试验会影响哪些度量？试验什么时候生效？在这个例子中，我们有一个需要接收精确、高级输入，需要进行复杂统计学运算以及得出计算结果的框架。我们期望如果引入一个新的试验，就可以相应进行额外的运算并得到额外的结果。在这个例子中，我们要注意的重点是，在这个抽象中输入变量并不是由传统 ETL 工具给出的，而且在拖拽界面中构建这样一个抽象也毫无操作性可言。

对于现代数据工程师而言，传统的 ETL 工具大多数都已过时了，因为无法用代码表达逻辑。因此所需要的抽象也就不能用这些工具直观表达。现在大家知道了数据工程师的职责包括了设计大量的 ETL，并且知道了一套全新工具和方法论是必需的，可以说这迫使这个学科从头重建。数据工程师需要新的技术栈、新的工具、一套新的约束，并且很多时候，是新的一代人。

数据建模在改变

典型的数据建模技术（比如星型模型），曾经定义了我们典型地通过数据仓库为分析工作进行数据建模的方法，但现在已不像之前那样重要。传统的数据仓库最佳实践已经改变。存储和计算要比以前便宜，而且随着可线性扩展的分布式数据库的出现，工程时间成了更紧缺的资源。

这里列举一些数据建模技术方面的变化：

进一步反范式化：在维度中维护代理键这件事可能很棘手，而且这使得事实表的可读性变差。而在事实表中使用自然的让人可读的键和维度属性变得越来越普遍，省去了在分布式数据库中大量繁重的 join 操作。同时要注意像 Parquet 或者 ORC 之类的序列化格式，或者 Vertica 之类的数据库引擎，都提供了编码和压缩的支持，这可以减少通常由于使用反范式化所带来的性能损失。那些系统本身具备为存储进行范式化的能力。

blobs（二进制大对象）：现代数据库已经逐渐通过本地类型和方法支持 blobs。这让数据建模师学会了新的招式，并且可以让事实表根据需要一次存储多个粒度的数据。

动态模式：由于 MapReduce 的出现，以及文档存储越来越流行，和 blobs 在数据库中的支持，不需要执行 DML（数据操作语言）就改进数据库模式变得更容易。这使得以迭代方式去建数据仓库更加容易，也免得开发前需要达成完全一致和认同。

系统化维度快照（在每个 ETL 调度周期为维度存储一个全量副本，通常存储在独立的表分区）作为一种处理缓慢变化维（SCD， slowly changing dimension）的通用方法，只要很少的工作量，是一种简单通用的方式。而且这种方式不像经典方式，在写 ETL 或者类似的查询时可以很容易掌握。将维度属性反范式化到事实表，在事务发生时就直接记录维度属性值，，也是一种容易并且相对廉价的方式。回想一下，复杂的 SCD 建模技术其实是不直观的，而且降低了可访问性。

一致性：一致性维度和度量在现在的数据环境中，依然是极为重要的。但是随着数据仓库需求的快速变化，随着更多的团队和角色被邀请到这项工作中贡献力量，一致性就少了一分必要性，更多的是一种权衡。当分歧的痛点变得无法控制，其背后也会产生一致和趋同。

角色和任务

数据仓库

“数据仓库是一个专门为查询和分析而构造的事务数据副本。” — Ralph Kimball

数据仓库是一个面向主题的、集成的、时变的、非易失的集合，用来支持管理层的决策制定过程。 — Bill Inmon

数据仓库依然像之前一样重要，数据工程师负责了很多方面的数据仓库建设和运维的工作。数据工程师的焦点就是数据仓库和相关工作。

现代数据仓库应该是比之前更加开放的设施，欢迎数据科学家、分析师和软件工程师去参与到建设和维护中。如果企业活动限制了什么角色才能够管理数据流程，那数据显然就过于中心化了。虽然这允许随着组织的数据需求而相应扩展，但是经常导致形成了更混乱的、走形的、不完善的基础设施。

数据工程团队通常会拥有数据仓库中几片有保证的、高质量的区域。比如在 Airbnb，有一组“核心”模式（schema）由数据工程团队管理，这里有清晰定义和度量的服务等级协议（SLA，service level agreement），严格遵守命名约定，并且相关的流水线代码遵循一套最佳实践。

为数据对象制定标准、最佳实践和认证流程的“卓越中心”，这也成为数据工程团队的职责之一。团队可以进而去参与或领导一个项目来分享其核心能力，以帮助其他团队成为更佳的数据仓库公民。比如，Facebook 有一个“数据夏令营”的培训项目，Airbnb 正在开发一个类似的“数据大学”的项目，数据工程师在这里主持会议来教大家如何熟练使用数据。

数据工程师也是数据仓库的“图书管理员”，编目和组织元数据，定义从仓库归档或提取数据的流程。在一个快速生长、迅速演变、轻度混乱的数据环境，元数据管理和元数据工具成为一个现代数据平台的关键组件。

性能调整和优化

随着数据变得比以前更加具有战略意义，企业为他们的数据基础设施建设所提高的预算确实令人印象深刻。这样，数据工程师把时间花在数据处理和存储的性能调整和优化上也就更加合理。由于在方面的预算极少缩减，优化往往从在相同的资源下完成更多事情的角度出发，或者是从试图使资源利用和开销的指数级增长线性化的角度。

知道了数据工程栈发展的复杂性正在暴增，我们可以设想优化这个栈和流程的复杂度也同样充满挑战。可能很容易通过很小的努力获得巨大成功的地方，收益递减法则通常是适用的。

建设可以随企业规模增长的基础设施（或在其上建设），并时刻保持资源意识，无疑是对数据工程师有好处的。

数据集成

数据集成，是通过数据交换来集成业务和系统其背后的实际操作，它和以前同样重要，也和以前同样充满挑战。由于软件即服务（SaaS， Software as a Service）逐渐成为企业运营的新标准方式，跨越这些系统来同步相关数据就成为更加关键的需求了。不仅SaaS服务本身需要最新的数据来运行，我们通常也想把产生在SaaS侧的数据拿到数据仓库，来和我们其他数据一起进行分析。当然SaaS经常会提供它们自己的分析，但是没有系统地支持企业中其余数据所能提供的视角，通常得把这些数据拉取回来。

不集成和共享通用的主键，就让 SaaS 服务重新定义参考数据，这简直是场灾难，应该极力避免。谁也不想人为地在两个不同的系统中维护两份雇员和顾客列表。最糟糕的是，必须要在把他们的 HR 数据拉回仓库时做模糊匹配。

最坏的情况，企业高管经常会在不实际考虑数据集成难度的情况下和 SaaS 提供商签约。提供商特意计划好淡化这些集成任务，以促进他们的销售，然后让数据工程师受困于去做充满疑问的、不被重视的工作。更不用说事实上典型的 SaaS API 经常设计不合理、文档不清晰，并且是“敏捷”的：就是说你可以认为它们会在不做通知的情况下改版。

服务

数据工程师工作在一种更高层级的抽象中，就是说在某些场景下要提供服务和工具来使数据工程师、数据科学家或者分析师要手动来完成的工作自动化。

这里列举数据工程师和数据基础架构工程师可能构建和维护的一小部分服务。

数据摄取：围绕“爬取”数据库、载入日志、从外部存储和API获取数据的服务和工具

指标计算：计算和汇总相关参与指标、增长指标或细分指标量的框架

异常检测：使数据处理自动化，以便当异常事件发生或趋势明显变化时警示相关人员

元数据管理：可以生成和消费元数据，并方便在数据仓库中查找信息的相关工具。

实验：A/B测试和实验框架通常是一个重要的企业分析，并带有一个关键的数据工程模块。

检测仪：从日志时间和相关属性到那些事件，数据工程师

会话：为帮助分析师理解用户行为，为理解时间行为序列专门设计的流水线。

就像软件工程师一样，数据工程师必须不断关注工作自动化、构建抽象来使他们能应对重重困难。虽然环境不同，可自动化的工作的性质不同，但自动化的需求在各个环境是普遍存在的。

技能要求

精通SQL：如果说英语是商业语言，那 SQL 就是数据语言。如果英语都说不好的话，作为一个商务人士又能做的怎么样呢？虽然一代又一代技术老去和退出舞台，但是 SQL 一直作为数据的通用语言顽强地活着。数据工程师应该能够使用 SQL 表达各种复杂逻辑，比如使用“关联子查询”和窗口函数。

SQL/DML/DDL 原语已经足够简单，对于数据工程师来说应该完全掌握了。除了SQL的声明特性，数据工程师还应该有能力理解数据库的执行计划，并明白每个步骤是什么，明白索引是如何工作的，明白不同的 join 算法，以及执行计划的分布维度（distributed dimension）。

数据建模技术：对于数据工程师来说，应该对实体/关系模型形成一种认知反射（cognitive reflex），并且对范式化有清晰的认识，同时对权衡反范式化有敏锐的直觉。数据工程师应该熟悉维度建模和相关概念和用语。

ETL 设计：编写高效、可扩展的、“可演化”的 ETL 才是关键。我正计划在接下来的博文中具体讨论这个主题。

架构规划：就像任何专业领域的专家，数据工程师需要对大多数工具、平台、库和其他可以运用的资源有一个较高层级的理解。比如不同种类的数据库、计算引擎、流处理器、消息队列、工作流编排器、序列化格式和其他相关技术背后的属性、用例和微妙之处。设计解决方案时，数据工程师必须能够对使用哪种技术做出好的选择，能够想象到如何使它们协同工作。

总而言之

通过过去 5 年在硅谷 Airbnb、Facebook、Yahoo！ 的工作，以及和像 Google、Netflix、Amazon、Uber、Lyft 等几十个各种体量的公司的各种类型的数据团队的丰富交流，我发现大家对于“数据工程师”的发展成什么样，看法越来越趋于一致，而且我觉得有必要分享一些我的发现。

我希望这篇文章可作为某种意义上的数据工程宣言，并且我希望可以在从事相关领域的社区中激起回应。