1.1.         让你能够从摄取数据到分析数据的整个过程中全面管理数据的技术组合

1.2.         数据平台的要求随着业务的变化而变化

1.3.         数据栈分为6层

1.3.1.           数据摄取

1.3.1.1.            从各种不同的来源中收集结构化数据和非结构化数据

1.3.1.2.            正是ETL和ELT中的提取阶段和加载阶段

1.3.1.2.1.             大多数ETL工具都会从外部数据源或内部系统中提取数据，在暂存区内将其转换为存储所能接受的（通常是关系型）格式，并将其加载到数据库中

1.3.1.2.2.             更新颖的ELT集成架构，即从数据源中提取原始数据，将其直接加载到数据仓库中，并在流程结束时对其进行转换

1.3.1.3.            数据编排和工作流自动化通常被整合到摄取层来获取孤立的数据，将它们与其他数据源进行合并，并用于分析

1.3.1.4.            在解决完存储、处理和商业智能层之后，数据编排能够且应该被编织到平台中

1.3.1.4.1.             数据编排需要一组有效的数据

1.3.1.5.            在数据管道中的每一步都对数据进行测试并做出正确的断言会非常棒，因为这种最佳实践可以帮助我们具体化每个步骤的数据质量

1.3.1.6.            在摄取时所测试的数据不一定在整个流程的演变过程中都一直可靠

1.3.2.           数据存储和处理

1.3.2.1.            存储层是数据栈的主力，它是你对刚摄取的数据进行存储和处理的地方

1.3.2.2.            数据仓库是完全托管的解决方案，需要根据特定模式对数据进行结构化处理，所以一般从数据摄取的那一刻起就必须严格注意数据的整洁

1.3.2.3.            数据湖通常是由数据团队结合开源和现成技术来定制的，支持原始非结构化数据和解耦的分布式计算

1.3.2.4.            湖仓一体则是一种新兴的混合体，它为数据湖添加了SQL功能和模式等仓库式特性，为传统的数据仓库提供了更大的灵活性

1.3.3.           数据转换和建模

1.3.3.1.            “数据转换”和“数据建模”这两个术语经常被混用，但它们其实是截然不同的过程

1.3.3.2.            数据转换包括准备用于分析和报告的原始数据

1.3.3.2.1.             探索性数据分析（剖析数据以了解其结构和特征）

1.3.3.2.2.             数据映射（定义各个字段的格式来生成最终的输出）

1.3.3.2.3.             代码生成（根据定义的规则或元数据生成可执行代码）

1.3.3.2.4.             代码执行（应用生成的代码来生成所需的输出）

1.3.3.2.5.             数据审查（确保转换后的数据符合要求）

1.3.3.3.            数据建模是识别封装业务逻辑的数据中的关键概念和关系的过程，然后用表的形式以及它们之间的关系对数据进行建模

1.3.3.4.            数据转换由专业的工程师使用Python、R或SQL等脚本语言，经过耗时的工作周期来执行

1.3.3.4.1.             现代的自助式服务方法允许那些精通SQL且最常与数据打交道的业务用户在设置需求方面更加可控，并缩短了实现可操作洞察所需的时间，而无代码或低代码方法让这种转换成为可能

1.3.3.4.2.             转换在很大程度上仍然是数据工程师所负责的过程，它合并了Python和除SQL之外的其他语言

1.3.3.5.            数据转换可以用批处理或实时流处理的方式进行，而后者是一种很有前景且越来越常见的实时对转换和建模进行处理的方法，在获取新鲜的数据比确保数据的准确性更重要时会非常适用

1.3.4.           商业智能和分析

1.3.4.1.            高度可见的数据栈层称为商业智能和分析层

1.3.4.2.            商业智能层让数据具有可操作性，如果没有它，你的数据就会缺乏意义

1.3.4.3.            分析工具通过仪表板和数据可视化来检索、分析和显示数据，使用户能够利用数据获得可操作的洞察

1.3.4.4.            通过可视化来体验数据，可以增强数据叙事的能力，即以人类可以理解的叙事方式来表达数据，从而让人采取行动

1.3.4.5.            数据叙事通过交流数据变化的前后背景并分享数据趋势背后的原因则更进了一步

1.3.4.5.1.             数据叙事的原则必须经过长时间的实践和磨炼，但如果没有自助式的商业智能和分析工具，团队就无法开始培养这些技能

1.3.5.           数据可观测性

1.3.5.1.            通过正确的流程和文化建立对数据的信任

1.3.5.1.1.             除非你所使用的数据可以被信任并且能为你的业务提供可靠的见解，否则即便是世界上最先进的数据栈也是没用的

1.3.5.2.            第一步是要了解数据在当前状态下的健康状况

1.3.5.3.            现代数据栈的第6层本身并不是最后一步，而是贯穿整个数据生命周期的一种互连手段，我们称之为数据可观测性

1.3.5.4.            数据可观测性是指组织在生命周期的各个阶段充分了解其系统中数据健康状况的能力

1.3.5.5.            端到端的数据可观测性对于确保数据质量来说至关重要

1.3.5.5.1.             有效的可观测性工具将连接到现有的数据栈，提供端到端的沿袭，使你能够发现下游依赖关系并在静止状态下自动监控数据，而不会从数据存储中提取数据，并冒着安全或合规的风险

1.3.6.           数据发现和治理

1.3.6.1.            数据团队需要一种可扩展的方式来记录和理解关键数据资产

1.3.6.1.1.             通过数据目录来实现的

1.3.6.1.1.1.              数据目录充当元数据清单，并提供数据可访问性、健康状况和存储位置等信息

1.3.6.1.1.2.              数据目录可以很容易地跟踪个人身份信息的存储位置，以及组织中的哪些人有权跨管道来访问这些信息，从而让这些人成为数据治理和法规合规性的组成部分

1.3.6.2.            现代数据团队还是会遇到传统数据目录的局限性

1.3.6.3.            数据发现是一种越来越多地应用于数据编目的新方法，它根据一组特定消费者如何摄取、存储、聚合和使用数据，提供了数据在特定领域的动态解读

1.3.6.4.            通过数据发现，治理标准应当是跨领域联合的

1.3.6.5.            数据发现可以实时了解数据的当前状态，而不是其理想或“编目”状态

1.3.6.6.            数据发现使数据团队能够相信其对数据的假设与现实相匹配，从而能在数据基础设施中增强动态发现并实现高度可靠性

1.4.         流的数据团队会对每一层都进行投资，有时会利用相同的工具或技术一次解决2～3层

1.4.1.           层数也将根据数据团队的需求而增加

2.1.         评估数据质量的投资回报率

2.1.1.           不可靠的数据会导致时间浪费、收入损失、合规风险和客户信任的削弱

2.1.2.           在提升数据质量之前，你需要对低数据质量的影响进行评估并弄清哪些数据集对你的组织来说是最重要的

2.1.3.           不是所有的数据都同等重要，而了解业务中关键资产的数据宕机成本将会是和利益相关方沟通数据质量影响的基础

2.2.         计算数据宕机成本

2.2.1.           从DevOps从业者那里借鉴到的TTD和TTR这两个指标将为解决这一问题提供良好的开端

2.2.2.           TTD描述了数据团队发现任何类型的数据质量问题所需的时间，无论是新鲜度异常还是导致整个管道被破坏的模式变更

2.2.3.           TTD以天、周甚至月为单位，因为在大多数情况下，数据宕机会在仪表板或报告“不正常”时首先被下游用户检测到

2.2.4.           时间越长，通过重新处理或回填源数据来恢复数据就越困难

2.2.5.           TTR描述了团队在收到警报后能够以多快的速度来解决数据事件

2.2.6.           TTR指标让你能够了解数据问题的严重程度，并跟踪解决问题所需的时间

2.2.7.           （TTD小时数+TTR小时数）×宕机每小时成本=数据宕机成本

2.2.7.1.            宕机每小时成本是一个通用指标，用于表示宕机每小时花费的工程时间，以及数据宕机对数据消费者和业务决策的影响

2.2.7.2.            花费的工程时间可以计算为宕机时间的一个因素

2.2.7.3.            随着时间的推移和技术债务的累积，宕机成本只会不断增加

2.2.7.4.            根据宕机时间对业务的潜在影响不同，该成本会有非常大的差异

2.2.8.           数据质量和可靠性的影响通常会被忽视，当这些问题被发现时，往往为时已晚

2.3.         更新数据宕机成本以反映外部因素

2.3.1.           每年因数据损坏而产生的成本可以通过解决问题所需的工程或资源来进行估算

2.3.2.           劳动力成本+合规风险+机会成本=不良数据的年度成本

3.1.         站点可靠性工程师使用SLA、SLI和SLO等框架来减少应用程序宕机并确保其可靠性

3.1.1.           使用SLO来定义并度量内部团队或供应商将要交付的给定产品的SLA，以及如果不满足这些SLA则可能采取的补救措施

3.1.2.           软件团队开发了内部的SLO，以帮助工程、产品和业务团队在其应用程序最重要的事情上保持一致，并对传入的请求进行优先级排序

3.2.         如果不能容忍最小的宕机时间，就没有创新的空间

3.3.         有了可靠的SLA，一旦出现问题，工程师就确切地知道应该如何以及何时进行干预

3.4.         SLA可以帮助数据团队及其消费者在整个生命周期中定义、评估并跟踪数据可靠性

3.4.1.           设置数据可靠性的SLA可以在数据、数据团队和下游消费者之间建立信任

3.5.         如果没有一致认可的SLI，消费者可能会对数据的可靠性做出不准确的假设或者寻找有关数据可靠性的轶事证据

3.6.         有了SLO，组织就可以成为更好的“数据驱动型”组织

3.7.         通过对沟通和优先级流程进行规范化，数据可靠性SLA将有助于数据团队更清晰地掌握业务优先级，并更容易在事件发生时快速响应

3.8.         步骤

3.8.1.           通过SLA定义数据可靠性

3.8.1.1.            数据团队还应该从消费者那里收集反馈，了解他们对可靠性的看法

3.8.2.           通过SLI度量数据可靠性

3.8.3.           通过SLO跟踪数据可靠性

3.8.3.1.            在确定SLI后，你可以为数据设定目标或设置可接受的宕机范围

3.9.         为数据设置SLA、SLO和SLI只是难题的第一步

3.9.1.           请务必记住，设置SLO和度量SLI本身并不能改善任何事情

3.9.2.           成功的关键在于他的团队评估了什么是最重要的，设置了SLI来度量它，并设置了SLO来判断进度，然后能够正确地确定优先级，并评估所执行项目的成功程度，以改进这些度量指标

3.9.3.           数据团队经常忙于设置指标，但没有为实际执行这些指标而提供适当的价值，也没有确定环境中的哪些负面特征会导致缺失SLO的情况