1.2.2 促成当前形势的其他行业趋势

除了上述经常导致数据宕机的因素外，由于技术创新正在推动数据格局的转变，一些行业也正在发生转变。这些转变都促成了对数据质量的高度关注。

数据网格

正如软件工程团队从单体应用程序过渡到微服务架构一样，数据网格在许多方面都是微服务的数据平台版本。值得注意的是，数据网格的概念还处于萌芽阶段，数据社区中有很多关于如何（或是否有意义）在文化和技术层面上执行数据网格的讨论。

正如Thoughtworks顾问兼该术语的原始架构师Zhamak Dehghani首次定义的那样（如图1-1所示），数据网格是一个社会技术范式，它识别了在复杂组织中人员与技术架构和解决方案之间的交互。数据网格通过利用面向域的自助设计来包含企业中无处不在的数据。它利用了Eric Evans的领域驱动设计理论，这是一种灵活、可扩展的软件开发范式，可以将代码的结构和语言与其相应的业务领域进行匹配。

与传统的整体数据基础设施（在一个集中式数据湖中处理数据的消耗、存储、转换和输出）不同，数据网格支持分布式、特定域的数据消费者且视“数据即产品”，在每个域中处理自己的数据管道，连接这些域及其相关数据资产的组织是应用相同语法和数据标准的通用互操作层。

数据网格联合了负责将数据作为产品提供的域数据所有者之间的数据所有权，同时也促进了跨不同位置的分布式数据之间的通信。

虽然数据基础设施负责为每个域提供用于处理数据的解决方案，但域的任务是管理数据的接收、清洗和聚合，以生成可供商业智能应用程序使用的资产。每个域负责拥有它们自己的管道，但所有域都应具有存储、编录和维护访问控制原始数据的能力。一旦数据被提供给一个指定的域并由其转换，该域的所有者就可以利用这些数据来满足其分析或运营需求。

只有当数据可靠且值得信赖，并且跨域应用此“通用互操作层”时，数据网格范式才能成功。而数据可靠和值得信赖的唯一方法是通过测试、监控和可观测性来密切关注数据质量。

图1-1：由Zhamak Dehghani开创的数据网格推动了一种去中心化、面向域的数据架构，该架构依赖于高质量的可靠数据和通用治理

许多公司正在采用数据网格范式，尤其是需要多个数据域的大型组织。例如，在Intuit的前数据工程副总裁Mammad Zadeh与Intuit的核心服务和体验高级副总裁Raji Arasu于2021年1月撰写的博客文章（https://oreil.ly/oxTyk）中，Intuit将自己定位为“由人工智能驱动的专家平台公司”，其平台“收集、处理并将稳定的数据流转换为高质量的数据网格”。另一个例子是摩根大通（https://oreil.ly/Tga4W），它构建了一个数据网格基础设施来帮助公司划分离散分析函数之间的数据所有权，并提高对整个企业数据共享的可见性。

无论你对数据网格的看法如何，它无疑席卷了数据社区，并引发了关于我们未来分布式数据架构和团队结构的精彩对话和博客文章（https://oreil.ly/rcFTp）。

流数据

流数据指的是将连续的数据流传输到管道中，从而快速生成实时洞察的过程。传统上，数据质量是通过批式数据进入生产管道前对其进行测试来强制执行的，但越来越多的企业正在寻求更为实时的分析。虽然这有可能提高洞察的速度，但也带来了与数据质量相关的更大问题和挑战，因为流数据是“处于动态中”的数据。

越来越多的组织同时采用批处理和流处理，这迫使数据团队重新思考测试和观察数据的方法。

湖仓一体（data lakehouse）的兴起

数据仓库还是数据湖？至少如果你去问数据工程师的话，这会是一个问题。数据仓库（结构化数据存储库）和数据湖（原始非结构化数据池）都依赖于高质量的数据来进行处理和转换。越来越多的数据团队选择同时使用数据仓库和数据湖来满足其业务不断增长的数据需求。而湖仓一体也就应运而生。

当云仓库供应商开始添加诸如Redshift Spectrum或Databricks Lakehouse等提供湖式好处（lake-style benefits）的功能时，湖仓一体首次出现在人们的目光中。同样，数据湖也添加了提供仓库式功能的技术，例如SQL功能和模式。今天，数据仓库和数据湖之间的历史差异正在缩小，因此你可以在一个包中获得两全其美的体验。

这种向湖仓一体模型的迁移表明管道正变得越来越复杂，虽然有些公司可能会选择一个专门的供应商来解决这两个问题，但其他公司正在将数据迁移到多个存储和处理层，而这也为管道数据带来更多即使经过充分测试但仍会损坏的潜在风险。