1.2.1 了解“数据宕机的增加”

随着对数据货币化的更多关注以及对提高数据准确性的不断渴望，我们需要更好地了解可能导致数据宕机的一些因素。接下来，我们将进一步研究可能影响数据的变量。

迁移到云端

20年前，你的数据仓库（转换和存储结构化数据的地方）可能位于办公室的地下室内，而不是在亚马逊云计算服务（Amazon Web Services，AWS）或微软的Azure云计算服务上。现在，随着数据驱动分析、跨职能数据团队以及云计算的兴起，诸如Amazon Redshift、Snowflake和Google BigQuery等云数据仓库解决方案已经成为那些看好数据的公司越来越受欢迎的选择。在许多方面，云都让数据变得更易管理，更容易被广泛的用户所访问，并且能以更快的速度进行处理。

在数据仓库迁移到云端后不久，数据湖也迁移到了云端，这为数据团队在管理数据资产方面提供了更大的灵活性。随着公司及其数据迁移到云端，基于分析的决策（以及对高质量数据的需求）成为企业更加优先考虑的问题。

更多的数据源

现在的公司会使用数十到数百个内部与外部数据源来生成分析和机器学习模型。其中任何一个来源都可能以意想不到的方式在没有事先通知的情况下发生变化，从而影响到公司用于决策的数据。

例如，工程团队可能会更改公司的网站，从而修改了对营销分析至关重要的数据集的输出。结果，关键的营销指标可能因此出错，从而导致公司在广告活动、销售目标和其他收入驱动的重要项目上做出错误的决策。

日益复杂的数据管道

由于更先进的工具、更多的数据源以及高管层对数据的日益重视，数据管道正变得越来越复杂：有多个处理阶段且各种数据资产之间存在重要的依赖关系。然而，如果不了解这些依赖关系，对一个数据集所做的任何更改都可能会产生意想不到的后果，从而影响相关数据资产的正确性。

简而言之，数据管道中有很多工作要做。源数据的提取、接收、转换、加载、存储、处理和交付，以及其他可能的步骤，其中包含了在管道不同阶段的许多API和集成。在每个节点上都有数据宕机的可能，就像在代码合并时存在应用程序无法响应的可能一样。此外，即使数据不在关键节点（例如，数据在数据仓库之间迁移或手动输入源系统时），也可能会出现问题。

更专业的数据团队

随着公司越来越依赖数据来推动智能决策，公司正在招聘越来越多的数据分析师、数据科学家和数据工程师构建并维护数据管道、分析和机器学习模型，以支持其服务、产品以及业务运营。

当数据分析师主要负责收集、清洗和查询数据集，以帮助各职能利益相关方对业务产生丰富、可操作的见解时，数据工程师则负责确保支持这些分析的底层技术和系统是高性能、快速且可靠的。在工业界，数据科学家通常会收集、整理、扩充和理解非结构化数据以改进业务。数据分析师和数据科学家之间的区别可能有点模糊，而且头衔和职责通常会根据公司的需求而有所不同。例如，在20世纪10年代末，Uber在重组组织架构后，将所有数据分析师的头衔都改为数据科学家。

随着数据越来越成为业务的基石，数据团队也在不断壮大。事实上，更大型的公司可能会支持额外的角色，包括数据管理员、数据治理负责人、运营分析师，甚至分析工程师（这是一个数据工程师和分析师的混合角色，在可能还没有资源支持大型数据团队的创业公司和中型公司中很受欢迎）。

由于这些不同的用户都会接触到数据，因此不可避免会出现沟通不畅或协调不足的情况，并且这还会导致这些复杂的系统在进行更改时崩溃。例如，一个团队添加到数据表中的新字段可能会导致另一个团队的管道故障，从而导致数据全部或部分丢失。在下游，这些坏数据可能导致数百万美元的收入损失、客户信任受损，甚至合规性风险。

去中心化的数据团队

随着数据成为业务运营的中心，公司中越来越多的职能团队介入数据的管理和分析，以简化并加快洞察收集的过程。因此，越来越多的数据团队正在采用一种分布式、去中心化的模型，该模型模拟了整个行业从单体架构到微服务架构的迁移，这种迁移在20世纪10年代中期席卷了软件工程界。

什么是去中心化的数据架构？不要把它与数据网格（https://oreil.ly/Vga7I）混淆，因为它是一种利用分布式的、面向域的设计的组织范式，去中心化的数据架构由一个集中式数据平台团队管理，而分析和数据科学团队则分布在整个业务中。我们发现越来越多倾向于嵌入式数据分析模型的团队正在依赖这种类型的架构。

例如，一家200人的公司可能支持一个由3名数据工程师和10名数据分析师组成的团队，分析师分布在各个职能团队中，以更好地支持业务需求。这些分析师将向运营团队或集中式数据团队报告，但他们拥有特定的数据集和报告功能。多个域将生成并利用数据，这将不可避免地导致多个团队所使用的数据集会随着时间的推移而重复、丢失或过时。正在读这本书的你可能对使用不再相关、未知的数据集的经历并不陌生！