下载掌阅APP，畅读海量书库
立即打开
就像一直在跟踪分析数据一样，技术团队也一直在跟踪数据质量，并寻求对其进行改善的方法。但直到21世纪20年代，数据质量才成为许多企业的首要任务。对于许多组织来说，数据不仅是一种产出，更是一种金融商品，所以这些信息的可信度非常重要。
所以，公司越来越像对待代码一样来对待数据，将软件工程团队中的框架和范例长期标准应用于其数据组织和架构中。DevOps是一个致力于缩短系统开发生命周期的技术领域，催生了业界领先的最佳实践，如站点可靠性工程、持续集成/持续部署（CI/CD）和基于微服务的架构。简而言之，DevOps的目标是通过自动化来发布更可靠、性能更好的软件。
在过去的几年里，越来越多的公司以“数据运营”（DataOps）的形式将这些概念应用于数据。数据运营指的是通过自动化来减少数据孤岛并促进更快、更容错的分析，以提高数据可靠性和性能的过程。
自2019年以来，Intuit（ https://oreil.ly/NhMtB ）、Airbnb（ https://oreil.ly/fbHlY ）、Uber（ https://oreil.ly/0GhQC ）和Netflix（ https://oreil.ly/Ai2zC ）等公司撰写了大量关于它们承诺通过应用数据运营最佳实践来确保为整个企业的利益相关方提供可靠、高可用性数据的文章。除了推动基于分析的决策（例如，产品战略、财务模型、成长型营销等）外，这些公司产生的数据还为其应用程序和数字服务提供了动力。不准确、缺失或错误的数据会耗费公司的时间、金钱以及客户的信任。
随着这些科技巨头越来越清楚地认识到实现高数据质量的重要性和挑战，其他各种规模和各行各业的公司也开始察觉并通过从实施更稳健的测试到投资包括监控和数据可观测性在内的数据运营最佳实践，来不断复制这些努力。
但究竟是什么导致了对更高数据质量的需求呢？为了促进DataOps的兴起，数据环境又发生了哪些变化，从而促进了数据质量的提高呢？接下来，我们将深入研究这些问题。
随着对数据货币化的更多关注以及对提高数据准确性的不断渴望，我们需要更好地了解可能导致数据宕机的一些因素。接下来，我们将进一步研究可能影响数据的变量。
迁移到云端
20年前，你的数据仓库（转换和存储结构化数据的地方）可能位于办公室的地下室内，而不是在亚马逊云计算服务（Amazon Web Services，AWS）或微软的Azure云计算服务上。现在，随着数据驱动分析、跨职能数据团队以及云计算的兴起，诸如Amazon Redshift、Snowflake和Google BigQuery等云数据仓库解决方案已经成为那些看好数据的公司越来越受欢迎的选择。在许多方面，云都让数据变得更易管理，更容易被广泛的用户所访问，并且能以更快的速度进行处理。
在数据仓库迁移到云端后不久，数据湖也迁移到了云端，这为数据团队在管理数据资产方面提供了更大的灵活性。随着公司及其数据迁移到云端，基于分析的决策（以及对高质量数据的需求）成为企业更加优先考虑的问题。
更多的数据源
现在的公司会使用数十到数百个内部与外部数据源来生成分析和机器学习模型。其中任何一个来源都可能以意想不到的方式在没有事先通知的情况下发生变化，从而影响到公司用于决策的数据。
例如，工程团队可能会更改公司的网站，从而修改了对营销分析至关重要的数据集的输出。结果，关键的营销指标可能因此出错，从而导致公司在广告活动、销售目标和其他收入驱动的重要项目上做出错误的决策。
日益复杂的数据管道
由于更先进的工具、更多的数据源以及高管层对数据的日益重视，数据管道正变得越来越复杂：有多个处理阶段且各种数据资产之间存在重要的依赖关系。然而，如果不了解这些依赖关系，对一个数据集所做的任何更改都可能会产生意想不到的后果，从而影响相关数据资产的正确性。
简而言之，数据管道中有很多工作要做。源数据的提取、接收、转换、加载、存储、处理和交付，以及其他可能的步骤，其中包含了在管道不同阶段的许多API和集成。在每个节点上都有数据宕机的可能，就像在代码合并时存在应用程序无法响应的可能一样。此外，即使数据不在关键节点（例如，数据在数据仓库之间迁移或手动输入源系统时），也可能会出现问题。
更专业的数据团队
随着公司越来越依赖数据来推动智能决策，公司正在招聘越来越多的数据分析师、数据科学家和数据工程师构建并维护数据管道、分析和机器学习模型，以支持其服务、产品以及业务运营。
当数据分析师主要负责收集、清洗和查询数据集，以帮助各职能利益相关方对业务产生丰富、可操作的见解时，数据工程师则负责确保支持这些分析的底层技术和系统是高性能、快速且可靠的。在工业界，数据科学家通常会收集、整理、扩充和理解非结构化数据以改进业务。数据分析师和数据科学家之间的区别可能有点模糊，而且头衔和职责通常会根据公司的需求而有所不同。例如，在20世纪10年代末，Uber在重组组织架构后，将所有数据分析师的头衔都改为数据科学家。
随着数据越来越成为业务的基石，数据团队也在不断壮大。事实上，更大型的公司可能会支持额外的角色，包括数据管理员、数据治理负责人、运营分析师，甚至分析工程师（这是一个数据工程师和分析师的混合角色，在可能还没有资源支持大型数据团队的创业公司和中型公司中很受欢迎）。
由于这些不同的用户都会接触到数据，因此不可避免会出现沟通不畅或协调不足的情况，并且这还会导致这些复杂的系统在进行更改时崩溃。例如，一个团队添加到数据表中的新字段可能会导致另一个团队的管道故障，从而导致数据全部或部分丢失。在下游，这些坏数据可能导致数百万美元的收入损失、客户信任受损，甚至合规性风险。
去中心化的数据团队
随着数据成为业务运营的中心，公司中越来越多的职能团队介入数据的管理和分析，以简化并加快洞察收集的过程。因此，越来越多的数据团队正在采用一种分布式、去中心化的模型，该模型模拟了整个行业从单体架构到微服务架构的迁移，这种迁移在20世纪10年代中期席卷了软件工程界。
什么是去中心化的数据架构？不要把它与数据网格（ https://oreil.ly/Vga7I ）混淆，因为它是一种利用分布式的、面向域的设计的组织范式，去中心化的数据架构由一个集中式数据平台团队管理，而分析和数据科学团队则分布在整个业务中。我们发现越来越多倾向于嵌入式数据分析模型的团队正在依赖这种类型的架构。
例如，一家200人的公司可能支持一个由3名数据工程师和10名数据分析师组成的团队，分析师分布在各个职能团队中，以更好地支持业务需求。这些分析师将向运营团队或集中式数据团队报告，但他们拥有特定的数据集和报告功能。多个域将生成并利用数据，这将不可避免地导致多个团队所使用的数据集会随着时间的推移而重复、丢失或过时。正在读这本书的你可能对使用不再相关、未知的数据集的经历并不陌生！
除了上述经常导致数据宕机的因素外，由于技术创新正在推动数据格局的转变，一些行业也正在发生转变。这些转变都促成了对数据质量的高度关注。
数据网格
正如软件工程团队从单体应用程序过渡到微服务架构一样，数据网格在许多方面都是微服务的数据平台版本。值得注意的是，数据网格的概念还处于萌芽阶段，数据社区中有很多关于如何（或是否有意义）在文化和技术层面上执行数据网格的讨论。
正如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功能和模式。今天，数据仓库和数据湖之间的历史差异正在缩小，因此你可以在一个包中获得两全其美的体验。
这种向湖仓一体模型的迁移表明管道正变得越来越复杂，虽然有些公司可能会选择一个专门的供应商来解决这两个问题，但其他公司正在将数据迁移到多个存储和处理层，而这也为管道数据带来更多即使经过充分测试但仍会损坏的潜在风险。