编译团队 | Yawei Xia,邱猛，赖小娟，张礼俊

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

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

　　什么是数据工程？

　　▼

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

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

　　联系到过去已有的职位，数据工程领域可以被当作是从软件工程衍生出的，包含了商业智能和数据仓储的一个超集。同时，这个学科也整合了“大数据”分布系统相关的特色，以及拓展了的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工具提供的是不同的。同时，在拖拽软件界面里建立这样的抽象是很难办到的。