1. 监控和异常检测
1.1. 在数据方面，所有明面上的测试和数据质量检查都不能完全保护你免受数据宕机的影响
1.1.1. 宕机可能由于各种原因而出现在管道内部和外部的各个阶段
1.1.2. 这些原因通常与数据本身无关
1.2. 要了解数据何时中断，最好的做法是依靠数据监控，特别是异常检测技术
- 1.2.1. 在容量、新鲜度、分布和其他值没有达到预期阈值时被及时识别
1.3. 在知道有一个好的分类（或者说分类模型）之前，你需要知道什么是好的分类
2. 异常检测
2.1. 指的是识别出偏离常态的事件或观察结果
2.2. 对于许多数据团队来说，异常检测都被认为是一种“有则更好”而不是“必须要有”的东西
2.3. 团队必须同时采取主动方式和被动方式来解决数据质量问题
2.4. 监控并发出关于数据可观测性支柱（新鲜度、容量、分布和模式）的警报
2.5. 要明白对于任何异常检测问题来说都没有完美的分类器
3. 已知的未知和未知的未知
3.1. 你可以预测的（已知的未知）和你无法预测的（未知的未知）
3.1.1. 测试和断路器可以处理许多已知的未知
3.1.2. 在涉及未知的未知时，监控和异常检测可以作为处理的基础
3.2. 已知的未知是你可以轻松预测的问题
3.2.1. 空值
3.2.2. 特有的新鲜度问题
3.2.3. 由定期更新的系统触发的模式变更
3.2.4. 可以在它们导致下游出现问题前把它们解决
3.3. 未知的未知指的是即使通过最全面的测试也无法解决的数据宕机
3.3.1. 是整个数据管道中出现的问题
3.3.2. 不仅仅是特定测试所涵盖的部分
3.3.3. 关键字段中的分布异常导致Tableau仪表板出现故障
3.3.4. 其他团队进行的JSON模式变更
3.3.5. 对ETL（或反向ETL）的意外更改导致测试无法运行而不良数据未被发现
3.3.6. 直到几周后才被注意到的不完整或陈旧数据，影响了关键营销指标
3.3.7. 代码变更导致API停止收集为重要新产品提供的数据
-
3.3.8. 随时间推移产生的数据漂移
- 3.3.8.1. ETL作业通常不考虑给定表中已经存在的数据
3.4. 利用监控和异常检测来识别并警告偏离给定数据管道历史预期的数据行为。通过了解“好”数据的样子，就会更容易主动识别出“坏”数据
4. 构建异常检测的算法
4.1. 语言和工具
4.1.1. SQLite和SQL
4.1.2. Jupyter Notebooks
4.1.3. Python
4.2. 新鲜度监控
4.2.1. 可以为我们提供一个强有力的指标来说明关键数据资产上次更新的时间
4.2.2. 如果一份按小时定期更新的报告突然看起来很陈旧，这类异常应该给我们提供了一个强烈的信号，表明某些地方是不准确的或者可能是错误的
-
4.2.3. SQL不存储元数据，所以为了在这种追溯环境中对新鲜度进行可视化，我们需要自己跟踪这些信息
- 4.2.3.1. 到底多少天未更新数据就算太久没更新了呢？
4.3. 分布
4.3.1. 评估数据的字段级分布健康状况
4.3.2. 分布会告诉我们数据的所有期望值，以及每个值出现的频率
4.3.3. 在许多情况下，一定程度的数据不完整是可以接受的，但如果10%的空值率变成了90%，那我们就必须要知道到底发生了什么
-
4.3.4. 假设观测值数据集来自符合数学规则的基准分布
4.3.4.1. 样本分布
4.3.4.2. 真实分布
-
4.3.5. 中心极限定理
4.3.5.1. 随着样本数量的增加，独立生成的随机样本的分布会接近于某个分布
4.3.5.2. 如果在一个均值为μ、标准差为σ的给定数据集中有一个足够随机的样本，则样本均值的分布将近似正态分布
-
4.3.5.3. 正态分布或高斯分布是统计课中大家都很熟悉的著名钟形曲线
4.3.5.3.1. 应用高斯分布可能会得到一种进行异常检测的初始方法
4.3.5.3.2. 中心极限定理陈述了许多人都会忽略的一个数据生成过程中的关键特征：独立、随机的观测值在极限情况下产生正态分布
4.3.5.3.3. 在商业智能数据中，观测值结果往往具有高度的相关性，并与其他变量相混淆
-
4.3.5.4. “异常”和“有趣”的观测值之间是有区别的，这不能完全用纯粹的统计思维来理解
4.3.5.4.1. 时间序列包含重要的前后背景信息
4.3.5.4.1.1. 季节性是指时间序列在一定时间间隔内观察到可预测的波动趋势
4.3.5.4.2. 并非所有的异常观测值都是有趣的，它们并不能帮助我们识别并纠正数据宕机
-
4.3.6. 如果空值率的“峰值”代表着比之前平均值的增加，则更应令人担忧
- 4.3.6.1. 当空值率突然下降时，可能不值得进行监控，而检测空值率是否增加的价值是显而易见的
4.4. 良好的异常检测肯定是数据可观测性难题的一部分，但这并不是全部
- 4.4.1. 同样重要的还有前后的背景信息
5. 构建监控器
5.1. 模式变更和沿袭的异常检测
5.1.1. 跟踪模式变更和沿袭可以让你前所未有地了解数据的健康状况和使用模式，提供有关何人、何事、何地、何因以及如何使用你数据的关键前后上下文信息
5.1.2. 其实在理解数据宕机对下游（通常也是现实世界）的影响时，模式和沿袭是两个最重要的数据可观测性支柱
5.2. 当对数据结构进行更改时，就会发生模式变更
-
5.2.1. 模式变更可以指关于数据的任何事
5.2.1.1. 添加新的API端点
5.2.1.2. 假定已弃用的字段尚未被弃用
5.2.1.3. 增加或减少列、行或整个表
-
5.2.2. 有版本历史
- 5.2.2.1. 模式变更很容易悄悄地突然降临到我们身上
-
5.2.3. 识别发出表明管道健康的信号的有用元数据
5.2.3.1. 跟踪它，同时构建检测器来提醒我们潜在的问题
5.2.3.2. 提供额外的表是跟踪模式的一种方法，但还有许多其他不同的方法
5.3. 对沿袭进行可视化
5.3.1. 沿袭是数据可观测性5个支柱中最全面的一个
5.3.2. 沿袭通过告诉我们哪些下游来源可能受到影响以及哪些上游来源可能是根本原因这两件事来贯穿整个事件
5.3.3. 沿袭信息可以帮助我们确定事件的根本原因并更快地解决它们
5.4. 调查数据异常
5.4.1. 解释仅使用发生了数据异常的事实
5.4.2. 解释使用了沿袭，根据表和字段之间的依赖关系，将事件置于整个前后上下文中并确定了问题的根本原因
