近来，我一直在思考过去几年当中我们在数据工程方面取得的进展，以及这个领域接下来的发展方向。大多数想法都孕育自我们几位团队成员在WePay项目中的心得，但我坚信接下来将要提到的这套框架将得到广泛应用，而且有必要与大家分享一番。

数据工程的工作内容，主要是帮助组织实现数据的移动与处理。从广义上讲，这通常需要两套不同的系统：数据管道与数据仓库。数据管理负责移动数据，数据仓库则负责处理数据。我承认这样的解释可能太过简单化，因为大家可以在批处理与流处理之间进行提取与加载转换，从而实现管道内处理。“数据仓库”包括目前大家所熟知的多种存储与处理系统（Flink、Spark、Presto、Hive、BigQuery、Redshift等），外加数据目录、作业调度程序等辅助系统。虽然种类繁多，但我认为其中的范式仍然存在。

整个行业正在努力改变这些系统的构建与管理方式。我个人最希望在未来几年能够看到以下四个方面的改进：

及时性：从批量到实时。
连通性：从一对一定制集成到多对多。
集中化：从集中托管到自助服务工具。
自动化：从手动管理到自动化工具。

从批量到实时

过去，数据管道与数据处理都基于批处理机制。数据以批量ETL快照的形式在不同系统之间传输，数据按定期方式接受处理，并由作业调度程序（Airflow、Oozie、Azkaban、Luigi等）负责管理。

如今，我们正一步步转向实时数据管道与实时数据处理系统。
Debezium等新型数据捕捉系统以及Kafka当中强大的连接器生态系统，使得实时数据管道成为可能。流处理在过去五年中亦经历了复兴，如今已经有更多实时数据处理系统涌现来。这些因素的组合，意味着入口（提取）、处理（转换）以及出口（加载）都能够实时发生。

现在的权衡焦点似乎落在了成本与复杂性上面。如果一家企业正着手建立一套数据仓库，那么整个构建周期大约需要4到6周，这时采用实时管道无疑会带来沉重的负担。相比之下，批量式解决方案的启动与运行要容易得多。但我预计，随着实时类工具的不断成熟，加上云主机的持续增长，这一切将在未来几年内发生变化。

连通性

以往，将上游数据源接入数据仓库，意味着为系统之间的各个一对一连接添加新的定制化集成方案。Jay Kreps在开创性的文章《日志：每位软件工程师都应该了解的实时数据统一抽象（The Log: What every software engineer should know about real-time data’s unifying abstraction）》当中，就说明了这一点：

这篇文章还详细介绍了数据集成的未来。虽然文章写于2013年，但其中提出的很多预期及设想直到今天才刚刚实现。如今，Confluent、Kafka Connect以及连接器生态系统的推出，意味着我们已经能够利用多种现成连接器方案接入Kafka数据管道。

我觉得这种架构方法可能会逐渐开始落地。具体来讲，将入口与出口分离，二者同时又与转换分离，这意味着数据管道能够充分发挥梅特卡夫定律的优势——向管道中添加新系统的成本将有所降低，但价值回报却进一步提升。

我知道，这里说的主要是Kafka，但我要强调一点：这种方法不一定是实时的（虽然我相信它会是）。例如，在Airflow中，目前的实现方法是一个GoogleCloudStorageHook、一个BigQueryHook，然后是一对一运算符：GoogleCloudStorageToBigQueryOperator。这完全分离了入口与出口，因此拥有通用格式的暂存区将得到大大改善，包括基于批量方式的ETL。

这种模式还将帮助我们获得细粒度数据系统。一旦能够以低成本方式将新系统添加至管道当中，那么生态系统内新增专用系统的价值就将超过相关支出。因此，我相信未来将有更多用户开始使用小众数据处理系统，例如图数据库、实时OLAP系统、搜索索引等。这种模式还鼓励进行更多实验，因为我们能够以远低于以往的成本，尝试将新系统添加至管道并观察其能否解决实际问题。

云服务的普及也为连接问题带来了有趣的影响。目前，我们还无法利用AWS控制台中的几个简单勾选框就搞定数据集成，而且我认为在短时间之内，各大云服务供应商的系统之间也很难实现完全集成。相比之下，我觉得建立一套点击式用户界面，并借此统一管理各家云服务供应商的产品倒还比较靠谱。最后，云与非云（或者第三方托管）系统之间的集成仍然需要大量努力。

出于上述原因，我认为基于云的第三方解决方案（例如Stitch）仍将具有价值。这也意味着对于有能力构建并加以运营的高水平用户而言，我在前文中提到的实时Kafka架构仍将是最成熟的解决方案。

自动化与权力下放

作为清单中的后两项，自动化与集中化可以说是齐头并进。大多数组织都拥有一支数据工程与/或数据仓库团队，专门负责管理数据管道与数据仓库。当上峰的指令下达至这些团队时，他们需要通过两项标准对请求做出评估：

我们能做什么（技术）
我们可以做什么（政策）

根据我的个人经验，集中式团队当中往往会包含部分自动化方法，但主要集中在技术自动化层面。这可以理解，毕竟它更像是工程团队的轮椅——这部分工作一般体现在利用自动化机制取代手动操作层面，例如添加新的连接器、设置监视或数据质量检查、创建新的数据库或表、授予权限等等。

然而，我认为第二种劳动力数据工程类型还没有实现自动化，即政策性负担。这类差事主要是管理谁有权访问哪些数据、数据应该保留多长时间、允许将哪种敏感数据保存在哪些数据系统当中，以及数据可能存在于哪些地理位置等等。数据工程通常不是最终回答这些问题的团队，但在寻找答案的过程中，他们一般需要扮演联络人或者领航员的角色。具体来讲，他们往往需要将请求一路引导通过组织内的其它部分（例如安全性、合规性以及合法性）。

随着GDPR及CCPA等监管要求的出台，这方面工作正变得愈发重要。把政府监管同远超传统软件企业的技术扩展速度结合起来，特别是在医疗与金融等敏感领域，可以想见自动化工作将成为政策流程中极为关键甚至不可或缺的一环。

政策自动化的实质，在于关注不太成熟的数据生态系统当中那些经常被忽视的领域。Lyft Amundsen、Apache Ranger以及谷歌Data Catalog等工具链将成为必要选项，帮助我们在审计、DLP、敏感数据检测、保留执行以及访问控制管理等政策的实施层面建立起全面的自动化体系。

随着自动化在技术与政策两大领域的逐步成熟，接下来需要回答的问题自然是：我们为什么需要一支单独的团队来管理这方面任务？如果说工具自己就能实施政策方针并自动操作数据管道，为什么不授权组织内的相关团队直接管理自己的数据管道与数据仓库？

在数据管道方面，权力下放意味着任何团队都可以自主决定如何调整现有数据管道——前提是符合自动实施的技术与政策指导原则。在数据仓库当中，团队可以根据需求创建数据库、数据集、数据市场以及数据存储库等（其中一些现在已经得到广泛应用）。这会带来大量复杂性、混乱且重复的元素。正因为如此，以上述工具为代表的管理方案才会成为权力下放的重要先决条件。

由于管理高复杂度数据生态系统会带来认知负担，因此我觉得唯一具备可扩展性的有效方法就是推动自动化加权力下放。在一定程度上，这可能更像是过去十年当中我们在应用层面所熟知的CI/CD以及从整体式到微服务架构的迁移。

总结

这种种趋势，都让我对数据工程的未来抱有乐观心态。其中有很多工作要做，也蕴藏着大量机会。我希望组织内的数据工程能够满足这些需求。开源社区将继续扩展，并建立起新的项目与初创企业。而所有这一切，都有望给组织整体带来巨大的效率提升，并建立起更严格的数据管理实践。

原文链接：
The Future of Data Engineering

创作场景

除了实时性，你还应该关注的三个数据科学改进方向