一名数据工程师的自述

2011的时候年我以商业智能工程师的身份加入脸书（Facebook），但在13年离开时我的职位却是数据工程师。这期间我并没有升职也没有被调到一个新职位上，我只是意识到我们的工作已经超越了传统商业智能的范畴，并且我们为自己创造的这个角色属于一个全新的领域。

由于我的团队处在这种转变的最前沿，我们正在培养新的技能、新的做事风格、开发新工具，并基本放弃了旧有的方法。我们是这个领域的开拓者。我们是数据工程师！

什么是数据工程？

▼

现在，当数据科学领域正在经历它的青春期时，数据工程在肯定和定义它自己，同时它也像数据科学的“同胞兄弟”一样也经历着类似的事情。数据工程一边借鉴着数据科学，一边也从数据科学的对立面去定义它自己，找到它的身份。

就像数据科学家似的，数据工程师也编程。他们善于分析，并且对数据可视化感兴趣。但他们也不像数据科学家，数据工程师受到一位更成熟的“父亲”– 软件工程师 – 启发。数据工程师创造工具、基础、框架和服务。事实上，相比于数据科学家，数据工程师可以说是更接近于软件工程师。

联系到过去已有的职位，数据工程领域可以被当作是从软件工程衍生出的，包含了商业智能和数据仓储的一个超集。同时，这个学科也整合了“大数据”分布系统相关的特色，以及拓展了的Hadoop生态系统、流处理、大规模计算有关的概念。

在一些还没有正式数据基础设施团队的小型公司里，数据工程方面的工作也涵盖了建设和运作数据基础设施。具体任务类似于建设和运作像Hadoop/Hive/HBase、Spark之类的平台。注意到在更小的环境里，人们倾向于使用由亚马逊、Databricks提供的托管服务，或者从Cloudera、Hortonworks这样的公司得到技术支持。这样的小企业本质上是将数据工程转包给了其他公司。但在更大的环境里，企业对数据基础设施团队的需求会不断增加，这使得它们更倾向于创建正式的职位来负责这类工作。在那些组织里，自动化某些数据工程过程的任务一般是由数据工程和数据基础设施团队负责。这些团队通常也会合作解决一些更高层次的问题。

随着数据工程角色的工程一面在范围上不断提升，旧有商业工程的一些方面慢慢变成次要的了。创建并维护产品组合报告和面板并不是一个数据工程师的主要关注重点了。我们现在有了更好的自助工具，凭借这些工具，数据科学家和广义上的“信息工作者”对数据的理解能力正在提高，他们也能自主地处理数据消耗资料。

数据提取、转换

和加载方式正在改变

▼

我们也观察到一种普遍的转变，就是从拖拽ETL（提取、转换和加载）工具转向一种更编程化的方式。在一些平台，如Informatica、IBM Datastage、Cognos、AbInitio或者微软 SSIS，上面的产品知识在现代的数据工程师之中并不普及。伴随着对编程或结构驱动的平台比如Airflow、Oozie、Azkabhan或Luigi的理解，这些产品知识并正在被更一般的软件工程技术所取代。同时，发展和管理他们自己的职业规划，对工程师来说也是相当普遍的。

我们可以找到很多理由来解释为什么我们不使用拖放工具来开发复杂的软件：最终，计算机编码对软件来说才是最佳的抽象和提炼方式。虽然对这个主题的讨论超出了本文的范围，但是我们很容易就能推断出，同样的理由也适用于编写ETL，正如适用于其他任何一款软件。编码允许任意水平的抽象，允许以熟悉的方式进行所有逻辑操作，和源代码管理结合地很好，也易于进行版本控制和众人合作。在数据处理的历史上，ETL工具演化成使用图形界面似乎是走了条弯路。当然，会有其他有趣的博客来讨论这个问题。

让我们重点强调一下，传统ETL工具做的抽象提炼是偏离目标的。不可否认，我们对数据处理复杂性的提炼、计算和储存有需要，但我认为解决的方式绝不是将ETL的程序要素（数据源/目标、集成、过滤……）塑造成一个拖放的样式。我们需要的对数据的抽象提炼是更高层次的。举个例子，在现代数据环境里我们所需要的抽象是在一种A或B测试框架下的实验的结构：试验是什么？试验的相关处理是什么？多少比例的使用者是被试者？每个试验期望去影响的指标有哪些？试验何时生效？在这个例子里，我们有一个接收精准、高水平输入，能运转复杂统计计算并传递计算结果的框架结构。我们期望每输入一条新试验条目，都能有一次计算，并且能得到计算结果。值得注意的是，在这个例子中，进行抽象所需的输入参数和传统ETL工具提供的是不同的。同时，在拖拽软件界面里建立这样的抽象是很难办到的。

对现代数据工程师来说，传统的ETL工具很大程度上已经过时了，因为逻辑不能被编码表达。因此，我们需要的抽象不能被这些工具直观表达出来。当我们已经知道数据工程师的角色主要包括定义ETL，也知道需要新的一套工具和方法论，我们就能断言这些将迫使这门学科去彻底重构它自己。新的工作栈、新的工具、新的一套约束条件，在很多情况下，也意味着新的一代人。

数据建模正在改变

▼

典型的数据建模技术，比如“星模型（Star Schema）”就是一个传统的、定义清晰的数据建模手段。这样的建模手段是为和数据仓库相连的分析工作服务的。但今时不同往日了，传统最佳的数据仓储手段的地基正在慢慢松动。存储和计算比过去任何时候都要廉价，并且随着能够线性扩展的分布式数据库的出现，更稀缺的资源是工程时间。

以下是在数据建模技术上观察到的一些变化：

更进一步的逆规范化：在多个维度上维持代理关键字（“surrogate keys”数据库名词，用于维度表和事实表的连接）是不容易的，这会使得事实表格不易阅读。在事实表中使用自然的或人可读的关键字和维度特征正变得更加普遍，这减少了对昂贵连接的需要。昂贵的连接对分布式数据库来说是个沉重的负担。同时我也注意到，在序列化格式（如Parquet或ORC）或在数据引擎（如Vertica）中的对编码和压缩的支持，解决了绝大部分经常和逆规范化联系在一起的性能损失的问题。那些系统已经具有自动地为存储规整数据的功能。

BLOBS （“binary large object”，二进制大对象）：现代数据库通过本地类型和功能正在为BLOB提供越来越大的支持。这为数据建模者的“剧本”开启了新“剧情”。并且，这样的支持也允许事实表在需要的时候一次性存储多样的粒度（“grain”，数据库名词）。

动态模型：随着文件存储日益流行和对BLOB的数据库支持，映射归纳（MapReduce）技术的出现使得在无须执行DML（“Data Definition Language”，数据库模式定义语言）的情况下进化数据库变的越来越容易。这不仅使迭代式地存储变得更容易，也降低了在建立数据库之前获得完全的共识和支持的需求。

有系统地快照维度（为每个ETL调度周期的维度存储一个完整的副本，经常用在不同的表格划分中）作为控制渐变维度（SCD）的一般方法，已经成为一种简单的方式。它不要求工程上的投入，同时，不同于传统方式，在写ETL和提取信息的时很容易掌握。再者，为了追踪交易那刻的数值而逆正规化维度的特征到事实表中，也是更加简便和相对廉价了。回顾过往我们可以看到，复杂的SCD建模技术不是那么直观并且不那么平易近人。

一致性，正如在一致的维度和尺度下，对现代数据环境来说仍旧是极度重要的。但随着对数据仓储的需要的快速增加，同时让更多团队以及职位投身于这个领域，一致性的问题又变的不那么急切，多少可以有一些折衷。但是在问题分歧失控的地方，一致性和收敛性可以作为一种后台处理而存在。

而且，更一般地来说，以下这种说法优待商榷：伴随着计算周期的便利和比过去更多的人了解数据知识，预先计算并在数据仓库中存储结果的需求降低了。举个例子，你可以有能够只进行响应式复杂分析的复杂 Spark 任务，但不用为了成为占用数据仓库的而提前预定时间。

角色&责任

▼

数据仓库

数据仓库是满足查询和分析的事务处理数据特定结构的拷贝。——Ralph Kimball

数据仓库是面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合。－Bill Inmon

相应得，数据仓库还是与以前一样，数据工程师负责数据仓库的多方面搭建并在其上操纵。数据工程师总是关注于在数据仓库及其附属产品。

现代数据仓库是一个比它历史上更开放机构平台，随时欢迎着数据科学家、分析师和软件工程师参与它的构建和操作。由于数据单纯的过于集中在公司业务上，局限了管理数据流向的角色。在规模上满足了机构的数据需求，却会经常导致基础设施更加的混乱、易变不够完善。

数据工程师团队往往拥有着数据仓库中最有保障的、高质量的模块。例如在Airbnb，数据工程师团队管理着一组‘核心’架构，其中有着定义明确及可度量的服务等级协议、遵守严格的命名规则、最高质量的业务元数据和文档，以及遵循意义明确的最佳实践的相关管道代码。

数据工程师团队通过制定标准、提供最佳案例和数据对象认证流程，充当了一个“卓越中心”的角色。这个团队逐渐发展，通过带领教学项目分享他们的核心竞争力，帮助其他团队成为数据仓库更好的参与者。例如，脸书（Facebook）有一个叫做“数据训练营（data camp）”的项目，Airbnb正在发展一个类似的“数据大学（Data University ）”项目。在这些项目中数据工程师教会人们怎么样更专业地操作数据。

数据工程师同时也是数据仓库的管理员，编目、整理元数据，定义从数据仓库抽取数据的过程。在一个急速增长，快速发展及轻微混乱的的数据生态环境下，元数据管理和工具化成为了现在数据平台的一个至关重要的组建部分。

性能调整和优化

随着数据变得较之前更具策略化，企业逐渐投入了可观的预算在数据基础设施上。这促使数据工程师花费更多的精力在性能调整、数据处理最优化和存储上。由于这个领域的的预算几乎不会缩水，性能优化通常来自于在相同数量的资源下取得更多收益，或者是试图线性化资源使用率和成本上的指数增长。

了解数据工程师工作内容的复杂度爆炸性地提高，我们相信，优化他们的工作内容和流程之复杂同样也是个挑战。在投入低却很容易得到高回报的地方，收益递减规律一般都是适用的。

确切地说，数据工程师的趣味所在是既随着公司扩建基础设施的同时，至始至终又都能节约资源。

数据集成

数据集成，通过数据交换整合业务和系统之间的实践，像他以前一样都既重要又具有挑战性。

由于软件即服务（SaaS）成为公司运营的新标准方式，跨系统同步化参考数据的需求愈加苛刻。不仅仅软件即服务（SaaS）需要最新数据来支持各系统功能，我们还经常想要将在系统端产生的数据写入数据仓库与其他数据一起用于分析。当然软件即服务（SaaS）有它自带的分析产品，但这些自带产品系统性地缺乏公司其他数据提供的信息，所以往往必须将某些数据撤回。

让这些软件即服务（SaaS）产品再定义参考数据却不集成和共享关键字，是一场在所有工作中都应该避免的灾难。没有人想要在两个不同系统中人工维护两套员工或客户列表。更糟糕的是，数据仓库中加载的人力资源数据，还不能完整匹配。

最糟糕的是，公司执行层经常在没有真正考虑数据集成挑战的情况下，和软件即服务（SaaS）提供者签订协议。为了促进软件服务的销售，销售人员不合理的评估数据集成的工作量，将不计入工作量的、不会被重视的工作留给数据工程师。更别提SaaS接口的设计不完善，不清楚的文档和所谓的“敏捷”：不提前通知就随意改变需求。

服务

数据工程师还会做些更高级别的抽象事务，在一些工作场景中提供服务和工具化使数据工程师，数据科学家和分析师可能人工处理的工作自动化。

以下是一些数据工程师和数据基建人员可能提供和操作的服务项：

数据获取：提供高效利用数据库，装载日志，从外部存储或API获取数据的相关服务和将这些流程工具化的工具

指标计算：设计框架，计算和总结约束条件、增长量和分段等指标。

异常检测：提供自动化数据资料分析，提醒异常事件的发生，或趋势变化明显时提出警告。

元数据管理：提供相关自动化工具，方便元数据的生成和更替，更易查找到数据仓库及其关联的信息。

试验：提供A/B测试和框架试验。这是数据工程师参与的企业分析的一个关键环节

仪表检测：从登陆开始及之后所有相关连的操作都会进行分析，数据工程师专注于确保可以从上游系统捕获高质量数据。

会话：提供能及时理解一系列业务操作的特殊渠道，让分析师明白用户行为。

就像软件工程师一样，数据工程师应该不断的寻找使他们工作自动化的方式，构建能让他们爬上更复杂阶梯的抽象概念。虽然由于环境不同，可自动化的工作流程性质不尽相同，却都有着自动化的需求。

所需技能

▼

精通SQL：

如果英语是业务的交流工具，那么SQL就是数据的交流工具。一个不会流利的英语的业务人员能有多大的成就？不管任何技术时代的产生和更替，SQL一直是数据的通用语。数据工程师应该有能用SQL表达任何‘相关子查询’和窗口函数复杂度的技术能力。对数据工程师来说初始SQL／DML/DDL简单到根本没有难度。即使是没有接触过SQL的人，他也能读懂并明白数据库的执行计划，了解所有步骤，知道程序怎么被调用，连接算法的不同和执行计划内的分布式维度。

数据模型技能：

作为一个数据工程师，有对实体－关系模型的认知反射，规范化的清晰认识，权衡反规范化的敏锐直觉。数据工程师应该熟悉维度建模及相关概念与术语。

ETL设计：

能够写出有效率、有弹性的、“可发展”的ETL任务是一个关键。我计划在下一博客中深入这个话题。

架构项目：

就如任何一个领域的专家的专业技能一样，数据工程师需要一个较高层次的综括，对大多数的工具，平台，库，和其他供他支配的资源的了解。认识到不同类型的数据库、计算引擎、流处理器、消息队列、工作流协调器、序列化格式及其他相关技术的属性、用例、微妙之处。在设计解决方案的时候，他应该有能力选择即将要使用的技术，并有一个构想去协调怎么使他们一起更好地工作。

总体来说

▼

过去在硅谷Airbnb，脸书和雅虎工作的五年里，跟来自谷歌、Netflix、亚马逊，优步、Lyft等几十个不同规模大小，不同类型的公司的数据团队交谈过。我观察到越来越多的人对数据工程师的职责范围是什么达成共识，觉得有必要分享我的感悟。

我希望这篇文章能够成为类似数据工程师的一个宣言，我也希望抛砖引玉，使在这个相关领域中，从事这类工作的人之间能产生更多的火花。