1.1. 数据是你的CEO的首要任务

1.2. 下游数据消费者（包括产品分析师、营销领导者和销售团队）则依赖于数据驱动的工具

1.3. 数据宕机

1.3.1. 指数据丢失、不准确或出现错误的情况，它表现为过时的仪表板、不准确的报告，甚至是糟糕的决策

1.3.2. 数据宕机的根源是不可靠的数据

1.3.3. 受数据宕机影响的不仅仅是公司的利润

1.3.3.1. 数据宕机每年都可能使公司损失数百万美元，更不用说丢掉客户信任了

1.3.3.2. 处理数据质量问题将消耗数据团队40%以上的时间，这些时间本可以用于更有趣的项目或进行真正的业务创新

1.3.4. 数据宕机是软件工程和开发人员运营的必然结果，在这个世界中，应用程序的正常运行时间或宕机时间[即你的软件或服务可用（正常运行）或不可用（停机）的频率]都被仔细度量，以确保软件的可访问性和性能

1.4. 虚假信息还是技术错误造成的糟糕数据质量和不可靠的数据，一直都是组织所面临的重要问题

1.5. “坏数据”(bad data)和糟糕的数据质量这两个概念几乎与人类存在的时间一样长，尽管形式各有不同

1.6. 分析管道在过程的任何阶段都极易受到最无害变化的影响

1.7. 生产中的数据

1.7.1. 来自源系统（如CRM、CMS和前面提到的其他类似系统的数据库）的数据

1.7.2. 这些数据已经被数据仓库(data warehouse)、数据湖(data lake)或其他数据存储和处理解决方案接收，并通过数据管道流动（提取-转换-加载，即ETL），以便分析层将其呈现给业务用户

1.8. 数据管道既可以处理批数据，也可以处理流数据，并且在较高的层次上，度量这两种类型数据质量的方法都大致相同

1.8.1. 为构建决策仪表板、数据产品、机器学习模型和其他数据科学输出的数据分析数据管道提供动力

2.1. “数据质量”自从人类开始收集数据以来就已经存在了

2.1.1. 数据质量也是一种了解数据是否符合业务需求的有效方法

2.2. 在过去的几十年里，数据质量的定义已经开始具体化为度量数据可靠性、完整性和准确性的功能，因为它与报告时的状态相关

2.3. 高数据质量是所有强大分析程序的第一步

2.4. 数据质量定义为数据在其生命周期中任何阶段的健康状况

2.4.1. 数据质量可能在数据管道的任何阶段受到影响，无论是接收数据前、生产过程中，还是在分析过程中

2.5. 数据质量常常是一个糟糕的代表，数据团队知道他们需要优先考虑它，但它并没有像“机器学习”“数据科学”甚至“分析”那样一蹴而就，许多团队没有足够的带宽或资源来找人全职管理它

2.6. “没数据总比坏数据好”这句话是该领域专业人士经常抛出的一句话，虽然它确实有道理，但这往往不是现实

3.1. 数据不仅是一种产出，更是一种金融商品，所以这些信息的可信度非常重要

3.2. DevOps是一个致力于缩短系统开发生命周期的技术领域，催生了业界领先的最佳实践

3.2.1. DevOps的目标是通过自动化来发布更可靠、性能更好的软件

3.3. “数据运营”(DataOps)的形式将这些概念应用于数据

3.3.1. 数据运营指的是通过自动化来减少数据孤岛并促进更快、更容错的分析，以提高数据可靠性和性能的过程

3.4. 不准确、缺失或错误的数据会耗费公司的时间、金钱以及客户的信任

3.5. 实施更稳健的测试到投资包括监控和数据可观测性在内的数据运营最佳实践，来不断复制这些努力

3.6. 影响数据的变量

3.6.1. 迁移到云端

3.6.1.1. 20年前，你的数据仓库（转换和存储结构化数据的地方）可能位于办公室的地下室内，而不是在亚马逊云计算服务(Amazon Web Services，AWS)或微软的Azure云计算服务上

3.6.1.2. 在许多方面，云都让数据变得更易管理，更容易被广泛的用户所访问，并且能以更快的速度进行处理

3.6.1.3. 在数据仓库迁移到云端后不久，数据湖也迁移到了云端，这为数据团队在管理数据资产方面提供了更大的灵活性

3.6.2. 更多的数据源

3.6.2.1. 数十到数百个内部与外部数据源来生成分析和机器学习模型

3.6.2.2. 任何一个来源都可能以意想不到的方式在没有事先通知的情况下发生变化，从而影响到公司用于决策的数据

3.6.3. 日益复杂的数据管道

3.6.3.1. 数据管道正变得越来越复杂：有多个处理阶段且各种数据资产之间存在重要的依赖关系

3.6.3.2. 如果不了解这些依赖关系，对一个数据集所做的任何更改都可能会产生意想不到的后果，从而影响相关数据资产的正确性

3.6.3.3. 源数据的提取、接收、转换、加载、存储、处理和交付，以及其他可能的步骤，其中包含了在管道不同阶段的许多API和集成

3.6.4. 更专业的数据团队

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

3.6.4.2. 当数据分析师主要负责收集、清洗和查询数据集，以帮助各职能利益相关方对业务产生丰富、可操作的见解时，数据工程师则负责确保支持这些分析的底层技术和系统是高性能、快速且可靠的

3.6.4.3. 在工业界，数据科学家通常会收集、整理、扩充和理解非结构化数据以改进业务

3.6.4.4. 更大型的公司可能会支持额外的角色，包括数据管理员、数据治理负责人、运营分析师，甚至分析工程师

3.6.4.4.1. 分析工程师是一个数据工程师和分析师的混合角色，在可能还没有资源支持大型数据团队的创业公司和中型公司中很受欢迎

3.6.4.5. 一个团队添加到数据表中的新字段可能会导致另一个团队的管道故障，从而导致数据全部或部分丢失

3.6.5. 去中心化的数据团队

3.6.5.1. 随着数据成为业务运营的中心，公司中越来越多的职能团队介入数据的管理和分析，以简化并加快洞察收集的过程

3.6.5.2. 越来越多的数据团队正在采用一种分布式、去中心化的模型，该模型模拟了整个行业从单体架构到微服务架构的迁移，这种迁移在20世纪10年代中期席卷了软件工程界

3.6.5.3. 不要把它与数据网格混淆，因为它是一种利用分布式的、面向域的设计的组织范式，去中心化的数据架构由一个集中式数据平台团队管理，而分析和数据科学团队则分布在整个业务中

3.6.5.4. 多个域将生成并利用数据，这将不可避免地导致多个团队所使用的数据集会随着时间的推移而重复、丢失或过时

4.1. 数据网格

4.1.1. 数据网格在许多方面都是微服务的数据平台版本

4.1.2. 数据网格的概念还处于萌芽阶段，数据社区中有很多关于如何（或是否有意义）在文化和技术层面上执行数据网格的讨论

4.1.3. 数据网格是一个社会技术范式，它识别了在复杂组织中人员与技术架构和解决方案之间的交互

4.1.4. 数据网格通过利用面向域的自助设计来包含企业中无处不在的数据

4.1.5. 数据网格支持分布式、特定域的数据消费者且视“数据即产品”，在每个域中处理自己的数据管道，连接这些域及其相关数据资产的组织是应用相同语法和数据标准的通用互操作层

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

4.1.7. 域的任务是管理数据的接收、清洗和聚合，以生成可供商业智能应用程序使用的资产

4.1.8. 只有当数据可靠且值得信赖，并且跨域应用此“通用互操作层”时，数据网格范式才能成功

4.1.9. 数据可靠和值得信赖的唯一方法是通过测试、监控和可观测性来密切关注数据质量

4.2. 流数据

4.2.1. 流数据指的是将连续的数据流传输到管道中，从而快速生成实时洞察的过程

4.2.2. 数据质量是通过批式数据进入生产管道前对其进行测试来强制执行的，但越来越多的企业正在寻求更为实时的分析

4.3. 湖仓一体(data lakehouse)的兴起

4.3.1. 数据仓库（结构化数据存储库）和数据湖（原始非结构化数据池）都依赖于高质量的数据来进行处理和转换

4.3.2. 越来越多的数据团队选择同时使用数据仓库和数据湖来满足其业务不断增长的数据需求

4.4. 云、分布式数据架构和团队的兴起，以及数据产品化的转变，使数据领导者有责任帮助其公司获得更值得信赖的数据（并因此得出更可靠的分析）

4.5. 实现可靠数据的过程是一场马拉松，而不是一场短跑，它会涉及数据管道的多个阶段