新工具爆发式增长，数据工程师的未来在哪？

作者 | Thalia Barrera

译者 | 平川

策划 | 罗燕珊

(资料图片仅供参考)

本文最初发布于 Airbyte 官方博客。

当前，数据工程是一个令人兴奋的主题，这是有原因的。自出现以来，数据工程领域的发展脚步就从未放缓。新技术和新概念最近出现得特别快。2022 年年底就快到了，现在是时候回过头来评估下数据工程当前的状态了。

如今的数据工程角色未来会是什么样子？还会存在吗？在这篇博文中，我将聊下数据工程角色的过去和现在，并分析新出现的趋势，为对未来做一些预测。

过去：从商业智能到大数据

要把握数据工程的现在和未来，必须了解它的发展历史。因此，让我们首先回顾下数据领域中出现的一些最重要的事件和技术，是它们催生了如今的数据工程角色。

数据仓库是我们为了理解数据所进行的最早的现代化尝试之一，可以追溯到 20 世纪 80 年代。当时，第一个商业数据仓库已经初具雏形。20 世纪 80 年代末，Bill Inmon 开始正式使用“数据仓库”一词，他被认为是数据仓库之父。也是在 20 世纪 80 年代，SQL 成为一种标准的数据库语言，直到今天我们还在使用！

Inmon 为数据仓库原理打下了坚实的理论基础，而 Ralph Kimball 在 1996 年出版的《数据仓库工具包》一书为维度建模奠定了基础。

随着大规模并行处理（MPP）数据库的推出，数据仓库开启了可扩展分析的时代。这使得处理以前无法想象的数据量成为可能。像 商业智能工程师 这样负责管理数据仓库的工作应运而生。

21 世纪初，互联网泡沫破裂，只有少数公司——包括雅虎、谷歌和亚马逊——最终成了科技巨头。他们得到了前所未有的发展，受此影响，工程师们开始寻找更复杂的解决方案，以满足更苛刻的数据需求。为什么会这样？因为当时可用的单体数据库和数据仓库不足以处理新的工作负载。

就是在上述情况下，谷歌在 2003 年发布了那篇著名的论文“谷歌文件系统”，介绍了一种“用于大型分布式数据密集型应用的可扩展文件系统”，并在 2004 年发布了关于MapReduce的论文，介绍了“如何简化大型集群模式上的数据处理”。然后，在 2006 年，雅虎的开发人员发布了 Hadoop 分布式文件系统。与此同时，像服务器和 RAM 这样的硬件也变得便宜而普遍。

21 世纪的创新，以及各种规模的企业积累的 TB 甚至 PB 级的数据，催生了我们所知的大数据，开启了 大数据工程师 的时代。

当时，大数据工程师广泛使用了开源框架 Apache Hadoop。Hadoop项目主要包含以下四个模块：

Hadoop Common：支持其他 Hadoop 模块的标准实用程序； Hadoop 分布式文件系统（HDFS）： 一个分布式文件系统，提供对应用程序数据的高吞吐量访问； Hadoop YARN：一个用于作业调度和集群资源管理的框架； Hadoop MapReduce：一个基于 YARN 的大数据集并行处理系统。

数据工程师需要具备软件开发和底层基础设施操作方面的专业知识，并拥有专门的技能组合，能够充分发挥 Hadoop 框架的作用。后来，他们又需要具备其他与 Hadoop 相关的 Apache 技术（比如 Hive 以及更近一些的 Spark）的使用经验。

大约在 Hadoop 出现的时候，亚马逊决定推出第一个公有云，通过亚马逊云科技（AWS）对外提供其内部技术。其他公有云提供商，如谷歌 Cloud 和微软 Azure，也很快出现。公有云彻底改变了软件和数据应用程序的构建和交付方式，成为这个时代最重要的技术之一。

云计算的一个主要优势是，与自行购买硬件相比，可以帮助企业在前期节省大量的固定成本。

当使用自己的硬件时，为了保证资源够用，公司必须准确预测他们的工作负载有多大，因为硬件的购买周期很长——这不可避免地会导致过度供应，因为未来很难准确预测。另一方面，使用云，公司只需要为他们使用的资源支付增量成本，而且这些资源很容易随着需求的增加或减少而伸缩。

快进到 2010 年代初，一些以数据为中心的技术出现并崭露头角，例如 Amazon Redshift——第一个云原生大规模并行处理数据库——接着是 BigQuery，以及更近一些的 Snowflake。

2010 年代早期到中期是数据世界的一段不平凡的时光。那时候，任何公司都可以使用与最著名的 IT 公司同样先进的数据工具。

随着云数据仓库的出现，我们有了管理数据工作流的新工具，其中最受欢迎的有：

编排：Airflow 转换：dbt BI：Looker、Metabase、Periscope、Mode 等

所有这些数据产品构成了我们所说的现代数据栈。正如Tristan Handy所言，“现代数据栈促成了 2012 年 10 月 Amazon Redshift 的发布。”

最近，Justin Chau采访了 Airbyte 高级数据工程师 Alex Gronemeyer，了解她在数据世界职业生涯的不同阶段亲身经历的所有变化。

Alex 说，“我对数据工程有比较深入的了解，当时我正在用 Spark 和 Scala 编写 Hadoop 管道，我们还没有真正上云；我们做了很多 Hive 查询，并直接调用 API 来获取数据。将新数据存入我们的数据库需要付出很大的努力，所以我非常感激现代数据栈提供的工具。”

随着数据产品和现代数据栈的出现，在某种程度上，大数据工程师的头衔有些过时了（毕竟，现如今的数据都很大，对吧？），出现了一个更简单、使用更广泛的术语： 数据工程师 。

2017 年，Airflow 创建者 Maxime Beauchemin 写了那篇著名的文章，描述了从商业智能工程师到数据工程师的转变。那时，全世界都意识到了数据工程师的兴起。他 2018 年发表的文章“函数式数据工程”发挥了进一步的推动作用。

现在：当代数据工程师

由于数据工具的出现，数据专业人士的职业生涯发生了巨大的变化，以前那些微不足道的任务变得越来越有战略意义。由于大数据框架的特性已经被抽象出来，当代数据工程师可能会更多地关注全局，更多地关心价值链上游的任务，如数据建模、质量、安全、管理、架构和编排。

与此同时，数据工程师越来越多地采用软件工程最佳实践。尽管软件工程和数据工程是不同的学科，但它们本质上也有一些相似之处：都是通过 编写 、 部署 和 维护 代码来解决问题。因此，当代数据工程师非常熟悉敏捷开发、代码测试和版本控制实践，诸如此类。

除了最佳实践，数据工程还采用了来自软件工程的概念。函数式数据工程就是一个很好的例子，这个叫法源于函数式编程。其主要思想是任务（如将数据从系统 A 移动到系统 B）应该是幂等的，就是说它每次执行的结果都一样。当任务失败或需要修改逻辑时，我们得知道，重新运行任务是安全的，不会导致数据重复或任何其他类型的错误状态。因此，幂等性对于数据管道的可操作性而言至关重要。

另一个被数据工程采用的概念是声明式编程，它比命令式编程又高了一个抽象级别，关注的是“ 做什么 ”而不是“ 怎么做 ”。声明式数据管道会说，“将数据从系统 A 移动到系统 B”，而不指定确切的数据流。在数据工程中，声明式管道很重要，因为它们为可观察性、数据质量监控和数据谱系奠定了良好的基础。

这种声明式概念与从数据管道转向数据产品的趋势密切相关——其实现依赖于现代数据编排器提供的抽象。现在，数据工程师考虑更多的是管道要交付的产品，例如特定的仪表板或视图，然后以此为基础构建管道。数据即产品（data as a product）思想是数据网格架构的核心价值所在。

Python 也崛起并进入了数据工程领域，因为多年来，作为一种非常健壮的编程语言，其地位已经很稳固。由于内置了许多用于数据处理和展示的库，所以 Python 在数据社区的应用已经相当广泛。一个突出的例子是pandas（专门用于提取和转换数据）。也出现了其他基于 Python 的重要工具，如PySpark，这是 Apache Spark 的一个接口，让我们可以在分布式环境中进行交互式数据分析。

可以肯定地说，如今，Python 和 SQL 是任何数据工程师都必须知道的语言。

多年来，组织组织数据团队的方式已经发生了变化。现在，为了更好地满足每个数据消费者的需求，出现了一些新的趋势，包括去中心化数据团队、自助数据平台以及在数据仓库以外存储数据的方法（如数据湖、数据湖仓或上文提到的数据网格）。

尽管人们对组织层面的这种变化还莫衷一是，专家们对于哪种方式最好也还有不同的意见，我们看到的一个趋势是，让领域专家拥有他们使用的数据，而不是由一个中心团队负责“真相来源”。因此，现在许多数据工程师都归属于中心平台团队，负责优化数据栈的不同方面，而不拥有数据。

上面提到的架构和组织层面的转变面临的主要挑战是保持对数据的共同理解。这就是人们采用语义层等概念的原因。语义层将复杂的数据映射到熟悉的业务术语，跨系统整合数据，提供统一的数据视图。

那么，该如何定义当今的数据工程角色呢？让我们看下《数据工程基础》一书的定义，这是迄今为止最新、最完整的定义之一：“数据工程是开发、实现和维护一些系统和流程，而这些系统和流程会接收原始数据，生成一致的、高质量的信息，为像分析和机器学习这样的下游用例提供支持。数据工程涉及安全、数据管理、数据操作、数据架构、编排和软件工程。”

数据工程生命周期，受《数据工程基础》一书启发

如今，数据工程师负责监视整个数据工程流程，从收集各种来源的数据到提供给下游流程使用。该角色需要熟悉数据工程生命周期的各个阶段，并具备从多个维度（包括价格、速度、灵活性、可扩展性、简单性、可重用性和互操作性）评估数据工具以获得最佳性能的能力。

未来：数据工程师将何去何从？

似乎大多数（如果不是全部的话）数据工程都趋向于通过采用软件工程 最佳实践 来提升该领域的 抽象水平 、 简洁性 和成熟度。这对于未来意味着什么？我认为主要有如下四个趋势：

数据工具的复杂度降低，而功能和特性增加。 专业化程度增加，从而催生新的数据工程角色。 数据生产者和消费者之间的差距缩小。 采用了 DataOps，改进数据管理。

下面我们将稍微深入地探讨下以上趋势。

退一步看，通过复杂的管道建立和维护数据源和目标之间的连接，一直是数据工程师的主要关注点之一。在这方面，有一个值得注意的发展，可以完美说明“工具易于使用和简洁性”这一趋势，那就是托管 数据连接器 。

在回答关于使用数据连接器的问题时，Alex Gronemeyer 提到：“从业务系统引入数据真的很有趣，只需几分钟就可以设置好一个新的连接器并让数据流进来，我以前从未经历过这样的事情。然后，当我开始为一个要在下游报表中使用的新数据集建模时，我的大部分工作集中在 数据建模 、 清理 和将数据 连接 在一起。我不需要再花一周的时间去获取数据，看看它是什么样子。这个问题已经解决了。”

Airbyte 是一个开源工具，它提供了数百个现成的数据连接器。例如，你可以创建一个从 Postgres 到 Snowflake 的数据管道，而无需编写任何代码。这个新一代的数据工具非常令人兴奋，甚至对技术能力很强的专业人员也很有吸引力，因为不需要另外创建一个ELT脚本，所以他们就可以把这块时间和精力用于其他对公司而言更重要的事情上。这一趋势未来似乎也不会放缓。

工具的简化使得任何数据从业者（如数据分析师和数据科学家）都可以在几分钟内设置好数据管道，其直接结果是，数据工程师不再是瓶颈。未来，自助式分析可能会继续为下游数据消费者赋能。

前面已经提到，数据世界可能会出现新的角色，就像 分析工程师 角色在 21 世纪 20 年代初出现那样。分析工程师是最可能从业务/数据分析师开启职业生涯的专业人士；因此，他们精通 SQL 和仪表板构建。自助式平台和像 dbt 这样的转换工具让他们可以从数据工程师那里获得更大的自主权。未来，我们可能会看到更多这样的专门角色出现。

企业获取的数据比以往任何时候都要多，这要归功于改进后的数据工具提供了更多的功能。随着在数据生命周期中与数据交互并基于数据做出决策的利益相关方越来越多，数据可信变得至关重要。正因为如此，数据质量仍然是数据团队的首要任务。

近来，对数据质量的日益关注催生了一个新的角色： 数据可靠性工程师 。这是一个专门致力于数据质量和可用性的数据工程角色。我相信，这个角色会继续发展。数据可靠性工程师将 DevOps 最佳实践应用于数据系统，如 CI/CD、服务水平协议（SLA）、监控和可观察性。

另一方面，软件工程和数据工程的岗位和职责也会交汇。这种转变可能是由结合了软件和分析的数据应用推动的。未来，软件工程师可能需要精通数据工程。随着流式架构和事件驱动架构的出现，上游后端系统和下游分析系统之间的界限将逐渐消失。

数据生产者会越来越关注分析和数据科学用例，这一趋势会继续发展。采用数据契约的人已经越来越多：源系统的所有者和负责将数据输入数据管道的团队之间达成的协议。这意味着，未来生产者和消费者之间的耦合将更加紧密。

宏观上看——除了技术或工具之外——数据生态系统正朝着利益相关方之间加强合作的方向发展。这催生了新的思维模式，如 DataOps。正如Gartner所定义的那样：“DataOps 是一种协作式数据管理实践，致力于改善组织内数据管理者和数据消费者之间的沟通、集成和数据流自动化。”

归根结底，新数据工具和实践的爆炸式增长都是为了解决了一个一直存在的问题： 数据管理 、更好地协同工作及提供价值。未来几年，这一领域将得到显著改善。

有人会质疑，上述情况是否会导致未来 数据工程师消失 。我认为不会。工具的日益成熟，生产者和消费者之间差距的逐步缩小，以及 DataOps 的实现，意味着数据工程师将专注于更具 战略性的任务 ，不是作为中间人，而是作为自动化顾问和推动者。

岗位和职责也将发生变化，“数据工程师”一词可能会被 更专业、更具体的头衔 所取代。但数据工程不可或缺，因为企业越来越依赖数据，而且要开发新的数据驱动的基础设施和流程。

未来，为了适应不断变化的需求，数据工程师将负责设计灵活的数据架构，其中包括针对为业务提供最大价值的工具和流程做决策。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：

https://airbyte.com/blog/data-engineering-past-present-and-future

关键词： 数据仓库 软件工程