正文
如果讨论与既有职责的关系，数据工程领域可以认为是商业智能和数据仓库的超集，而且更多的元素是从软件工程得来的。这个学科也囊括了所谓的“大数据”分布式系统的相关领域内容，以及广泛的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，并且知道了一套全新工具和方法论是必需的，可以说这迫使这个学科从头重建。数据工程师需要新的技术栈、新的工具、一套新的约束，并且很多时候，是新的一代人。
