1.1 什么是数据工程

尽管数据工程目前很流行，但是人们对数据工程的含义和数据工程师的工作有很多困惑。自从公司开始使用数据做事，数据工程就以某种形式存在了，比如预测性分析、描述性分析和报告，并在21世纪10年代随着数据科学的兴起而逐渐成为焦点。就本书而言，定义 数据工程 和 数据工程师 的含义至关重要。

首先，让我们看一下数据工程的描述方式，并开发一些我们可以在本书中使用的术语。 数据工程 的定义是无穷无尽的。2022年初，在谷歌上精确匹配搜索：“什么是数据工程？”会得到超过91000个独特的结果。在我们给出定义之前，这里有几个说明该领域的一些专家如何定义数据工程的例子：

数据工程是一组操作，旨在为信息的流动和访问创建接口和机制。它需要专门的专家——数据工程师——来维护数据，以便其他人可以使用它。简而言之，数据工程师建立并运营组织的数据基础设施，为数据分析师和科学家的进一步分析做好准备。

——“Data Engineering and Its Main Concepts”，作者AlexSoft ^[1]

第一种类型的数据工程是以SQL为中心的。数据的工作和主要存储位于关系数据库中。所有数据处理都是使用SQL或基于SQL的语言完成的。有时，这种数据处理是使用ETL工具 完成的。第二种类型的数据工程是以大数据为中心的。数据的工作和主要存储位于Hadoop、Cassandra和HBase等大数据技术中。所有数据处理都在MapReduce、Spark和Flink等大数据框架中完成。在使用SQL时，主要处理是使用Java、Scala和Python等编程语言完成的。

——Jesse Anderson ^[2]

相对于以前存在的角色，数据工程领域可以被认为是商业智能和数据仓库的超集，它从软件工程中引入了更多的元素。该学科还集成了围绕所谓的“大数据”分布式系统操作的专业化，以及围绕扩展Hadoop生态系统、流处理和大规模计算的概念。

——Maxime Beauchemin ^[3]

数据工程就是关于数据的移动、操作和管理。

——Lewis Gavin ^[4]

如果你对数据工程感到困惑，那是完全可以理解的。这只是少数几个定义，它们包含关于数据工程含义的大量观点。

1.1.1 数据工程定义

当我们解开不同人如何定义数据工程的共同线索时，一个明显的模式出现了：数据工程师获取数据、存储数据，并准备数据供数据科学家、分析师和其他人使用。我们定义数据工程和数据工程师如下：

数据工程 是系统和流程的开发、实施和维护，这些系统和流程接收原始数据并生成支持下游用例（例如分析和机器学习）的高质量、一致的信息。数据工程是安全、数据管理、数据运维（DataOps）、数据架构、编排和软件工程的交集。 数据工程师 管理数据工程生命周期，从源系统获取数据开始，到为用例（例如分析或机器学习）提供数据结束。

1.1.2 数据工程生命周期

人们很容易只关注技术而短视地错过大局。本书围绕一个 数据工程生命周期 （如图1—1所示）的重要思想展开，我们相信它为数据工程师提供了一个看待其角色的整体背景。

数据工程生命周期将对话从技术转移到数据本身及其必须服务的最终目标。数据工程生命周期的各个阶段如下：

· 生成

· 存储

· 获取

· 转换

· 服务

数据工程的生命周期也有一个 底层设计 的概念——贯穿整个生命周期的关键思想。这些包括安全、数据管理、数据运维、数据架构、编排和软件工程。我们将在第2章中更广泛地介绍数据工程的生命周期及其底层设计。不过，我们之所以在这里介绍它是因为它对我们定义数据工程和本章后面的讨论至关重要。

现在你已经有了对数据工程的可行定义和对其生命周期的介绍，下面让我们退后一步，回顾一下历史。

1.1.3 数据工程师的演变

历史不会重演，但会押韵。

——一句著名的格言，常被认为是马克·吐温的名言

了解数据工程的前世今生，需要了解该领域演变发展的背景。本节不是历史课，但回顾过去对于理解我们今天所处的位置和未来的发展方向具有无可估量的价值。一个共同的主题不断出现：旧的又成了新的。

早期：1980年到2000年，从数据仓库到Web

数据工程师的诞生可以说起源于数据仓库，最早可以追溯到20世纪70年代， 商业数据仓库 在20世纪80年代初具规模，Bill Inmon于1989年正式创造了 数据仓库 一词。在IBM的工程师开发了关系数据库和结构化查询语言（Structured Query Language，SQL）之后，Oracle普及了该技术。随着新生数据系统的发展，企业需要用于报告和商业智能（Businesses Intelligence，BI）的专用工具和数据管道。为了帮助人们在数据仓库中正确地进行业务逻辑建模，Ralph Kimball和Inmon开发了他们各自同名的数据建模技术和方法，这些技术和方法至今仍在被广泛使用。

数据仓库开创了第一个可扩展分析的时代，新的大规模并行处理（Massively Parallel Processing，MPP）数据库使用多个处理器来处理市场上出现的大量数据并支持前所未有的数据量。BI工程师、ETL开发人员和数据仓库工程师等角色解决了数据仓库的各种需求。数据仓库和BI工程是当今数据工程的前身，并且仍然在该学科中发挥着核心作用。

互联网在20世纪90年代中期成为主流，创造了全新一代的网络有限公司，例如AOL、雅虎和亚马逊。互联网繁荣发展催生了大量网络应用程序和支持这些应用程序的后端系统——服务器、数据库和存储。许多基础设施是昂贵的、单一的并且需要大量许可。销售这些后端系统的供应商可能没有预见到Web应用程序将产生如此大规模的数据。

21世纪00年代初期：当代数据工程的诞生

快进到21世纪00年代初，20世纪90年代末的互联网热潮破灭了，留下了一小群幸存者。其中一些公司，如雅虎、谷歌和亚马逊，将成长为强大的科技公司。最初，这些公司继续依赖20世纪90年代传统的单机关系数据库和数据仓库，将这些系统推向了极限。随着这些系统的崩溃，需要更新的方法来处理数据增长。新一代系统必须具有成本效益、可扩展性、可用性和可靠性。

随着数据的爆炸式增长，商品硬件——例如服务器、RAM、磁盘和闪存驱动器，也变得廉价且无处不在。一些创新允许在大规模计算集群上进行大规模分布式计算和存储。这些创新开始分散和打破传统的单机服务。“大数据”时代已经开始。

《牛津英语词典》将大数据（ https://oreil.ly/8IaGH ）定义为：一种可以通过计算分析来揭示模式、趋势和关联的超大数据集，尤其是与人类行为和交互相关的数据集。对大数据的另一个著名而简洁的描述是数据的三个V：速度（velocity）、多样性（variety）和数量（volume）。

2003年，谷歌发表了一篇关于Google文件系统的论文，紧接着，在2004年发表了一篇关于MapReduce（一种超可扩展数据处理范式）的论文。事实上，大数据在MPP数据仓库和实验物理项目的数据管理方面有着更早的前身，但谷歌的出版物构成了数据技术的“大爆炸”和我们今天所知的数据工程的文化根基。第3章和第8章将分别介绍有关MPP系统和MapReduce的更多信息。

Google的论文启发了Yahoo的工程师开发并于2006年开源了Apache Hadoop ^[5] 。Hadoop的影响怎么强调都不为过。对大规模数据问题感兴趣的软件工程师被这个新的开源技术生态系统的可能性所吸引。随着各种规模和类型的公司看到他们的数据增长到数TB甚至PB，大数据工程师的时代诞生了。

大约在同一时间，亚马逊必须跟上其自身爆炸式增长的数据需求，并创建了弹性计算环境（Amazon Elastic Compute Cloud，或EC2）、无限可扩展的存储系统（Amazon Simple Storage Service，或S3）、高度可扩展的NoSQL数据库（Amazon DynamoDB）和许多其他核心数据构建块 ^[6] 。亚马逊选择通过Amazon Web Services（AWS）为内部和外部消费提供这些服务，成为第一个流行的公有云。AWS通过虚拟化和转售巨大的商品硬件池创建了一个超灵活的即付即得资源市场。开发人员只需简单地从AWS租用计算和存储，无须为数据中心购买硬件。

随着AWS成为亚马逊的高利润增长引擎，其他公有云也将很快跟进，例如Google Cloud、微软Azure和DigitalOcean。公有云可以说是21世纪最重要的创新之一，它引发了软件和数据应用程序开发与部署方式的革命。

早期的大数据工具和公有云为今天的数据生态系统奠定了基础。如果没有这些创新，现代数据格局——以及我们现在所知道的数据工程——将不会存在。

21世纪00年代和21世纪10年代：大数据工程

Hadoop生态系统中的开源大数据工具迅速成熟，并从硅谷传播到全球高科技的公司。这是第一次，任何企业都可以使用顶级科技公司使用的相同的前沿数据工具。另一场革命发生在从批处理计算到事件流的转变，开创了大“实时”数据的新时代。你将在本书中了解批处理和事件流。

工程师可以选择最新、最好的技术——Hadoop、Apache Pig、Apache Hive、Dremel、Apache HBase、Apache Storm、Apache Cassandra、Apache Spark、Presto以及出现的许多其他新技术。传统的面向企业和基于GUI的数据工具突然变得过时了，并且随着MapReduce的兴起，代码优先的工程开始流行起来。我们在这段时间里，感觉旧教条在大数据的祭坛上突然死亡了。

21世纪00年代后期和21世纪10年代，数据工具的爆炸式增长迎来了 大数据工程师 的诞生。为了有效地使用这些工具和技术——包括Hadoop、YARN、Hadoop分布式文件系统（Hadoop Distributed File System，HDFS）和MapReduce在内的Hadoop生态系统——大数据工程师必须精通软件开发和底层基础设施黑客技术，但是重点有所转移。大数据工程师通常会维护大量的商业硬件集群以便大规模地交付数据。虽然他们偶尔会向Hadoop核心代码提交拉取请求，但他们将重点从核心技术开发转移到了数据交付上。

大数据很快成为其自身成功的牺牲品。作为一个流行语，大数据在21世纪00年代初期到21世纪10年代中期变得流行起来。大数据抓住了试图理解不断增长的数据量的公司的想象力，以及销售大数据工具和服务的公司无休止的营销。由于大肆宣传，我们经常看到公司使用大数据工具来解决小数据问题，有时建立一个Hadoop集群来处理仅几千兆字节的数据。似乎每个人都想参与大数据行动，但没有人真正知道该怎么做，每个人都认为其他人在做，所以每个人都声称自己也在做。

图1—2展示了搜索词“大数据”的Google Trends快照，可以了解大数据的兴衰。

尽管这个词很受欢迎，但大数据已经失去了活力。发生了什么？一个词：简化。尽管开源大数据工具功能强大且复杂，但管理它们需要大量工作并且需要持续关注。通常，公司会聘请整个大数据工程师团队，每年花费数百万美元来照看这些平台。大数据工程师经常花费过多的时间来维护复杂的工具，而没有足够的时间来提供业务的洞察力和价值。

开源开发人员、云计算和第三方开始寻找方法来抽象、简化大数据并使大数据可用，而无须管理集群以及安装、配置和升级其开源代码的高管理开销和成本。 大数据 一词本质上是描述处理大量数据的特定时间和方法的遗留物。

如今，数据的移动速度比以往任何时候都快，而且数据增长越来越大，但是大数据处理已经变得如此容易理解，以至于它不再是一个单独的术语。每家公司都旨在解决其数据问题而不用关心实际数据大小。大数据工程师现在只是 数据工程师 。

21世纪20年代：数据生命周期工程

在撰写本书时，数据工程角色正在迅速发展。我们预计在可预见的未来，这种演变将继续快速发展。虽然数据工程师过去倾向于关注Hadoop、Spark或Informatica等单体框架的低级细节，但趋势正在转向分散化、模块化、管理化和高度抽象的工具。

事实上，数据工具已经以惊人的速度激增（如图1—3所示）。21世纪20年代初期的流行趋势包括 现代数据栈 ，代表了一组现成的开源和第三方产品，这些产品组合起来可以让分析师的工作更轻松。与此同时，数据源和数据格式的种类和规模都在增长。数据工程越来越成为一门互操作的学科，并像乐高积木一样连接各种技术，以服务于最终的业务目标。

我们在本书中讨论的数据工程师可以更准确地被描述为 数据生命周期工程师 。随着更大的抽象和简化，数据生命周期工程师不再被昨天大数据框架的血淋淋的细节所困扰。虽然数据工程师保持低级数据编程技能并根据需要使用这些技能，但他们越来越多地发现自己的角色侧重于价值链中更高层次：安全、数据管理、DataOps、数据架构、编排和一般数据生命周期管理 ^[7] 。

随着工具和工作流的简化，我们已经看到数据工程师的态度发生了显著转变。开源项目和服务不再关注谁拥有“最大数据”，而是越来越关注管理和治理数据，使其更易于使用和发现，并提高其质量。数据工程师现在熟悉CCPA和GDPR ^[8] 等首字母缩略词，在他们设计管道时，他们关心隐私、匿名化、数据垃圾收集和法规遵从性。

旧的又成了新的。虽然数据管理（包括数据质量和治理）等“企业级”内容在前大数据时代的大型企业中很常见，但在小型公司中并未得到广泛采用。现在，过去数据系统的许多具有挑战性的问题都得到了解决，并被巧妙地产品化和包装，技术专家和企业家将注意力转移回“企业级”内容，但强调去中心化和敏捷性，这与传统的企业命令-控制型方法形成鲜明对比。

我们将现在视为数据生命周期管理的黄金时代。管理数据工程生命周期的数据工程师拥有比以往更好的工具和技术。我们将在第2章更详细地讨论数据工程生命周期及其底层设计。

1.1.4 数据工程与数据科学

数据工程与数据科学的关系是什么呢？有一些争论，有人认为数据工程是数据科学的一个分支学科。我们认为数据工程与数据科学和分析学是分开的。它们相互补充但又截然不同。数据工程位于数据科学的上游（如图1—4所示），这意味着数据工程师提供数据科学家使用的输入（数据工程的下游），数据科学家将这些输入转化为有用的东西。

考虑数据科学需求层次（如图1—5所示）。2017年，Monica Rogati在一篇文章（ https://oreil.ly/pGg9U ）中发布了这种层次结构，展示了人工智能（Artif icial Intelligence，AI）和机器学习（Machine Learning，ML）与更“平凡”的领域（如数据移动/存储、收集和基础设施）的关系。

尽管许多数据科学家渴望构建和调整ML模型，但现实情况是，估计他们70%～80%的时间都花在了层次结构最下面的三层（收集数据、清洗数据、处理数据）上，而只有很少的时间花在分析和ML上。Rogati认为，在处理AI和ML等领域之前，公司需要建立坚实的数据基础（层次结构中最下面的三层）。

数据科学家通常没有接受过设计生产级数据系统的培训，他们最终会随意地做这项工作，因为他们缺乏数据工程师的支持和资源。在理想情况下，数据科学家应该将90%以上的时间专注于金字塔的顶层：分析、实验和ML。当数据工程师专注于层次结构的这些底层部分时，他们为数据科学家的成功奠定了坚实的基础。

随着数据科学推动高级分析和ML，数据工程跨越了获取数据和从数据中获取价值之间的鸿沟（如图1—6所示）。我们认为数据工程与数据科学具有同等的重要性和可见性，数据工程师在使数据科学在生产中取得成功方面发挥着至关重要的作用。