1.1. 数据是新的石油

1.1.1. 当今的企业拥有丰富的数据，但缺乏数据洞察力

1.1.2. 目前，企业内部的结构化数据、半结构化数据以及非结构化数据的数据量呈指数级增长

1.1.3. 尽管在数据湖中收集了大量数据，但它们可能不一致、无法解释、不准确、不及时、未标准化或不充分

1.2. 工程师通常缺乏必要的业务背景

1.2.1. 工程的复杂性限制了数据分析师和科学家获取数据，导致数据无法在产品管理、营销、金融、工程等领域得到应用

1.3. 开发机器学习洞察的自助服务平台

1.3.1. 谷歌的TensorFlow Extended

1.3.2. Uber的Michelangelo

1.3.3. Facebook的FBLearner Flow

1.4. 没有普遍适用的银弹策略

1.4.1. 每个企业在现有技术构建块、数据集质量、支持的用例类型、流程和人员技能方面都是独一无二的

1.5. 自助服务数据平台计划在执行过程中要么失败，要么中途放弃的原因

1.5.1. 在沟通中迷失了数据用户真正的痛点

1.5.1.1. 数据用户和数据平台工程师的视角不同

1.5.1.2. 数据工程师不懂具体的业务问题且把握不到数据用户的痛点

1.5.1.3. 数据用户不了解大数据技术的局限性和现实情况

1.5.1.4. 导致团队之间相互指责，无法得出一个持久的解决方案

1.5.2. 为了技术而采用“闪亮”的新技术

1.5.2.1. 鉴于解决方案众多，团队经常采用下一个“闪亮”的技术，而不清楚减缓提取洞察的问题

1.5.2.2. 很多时候，企业最终是为了技术而投资技术，而没有减少提取洞察的总体时间

1.5.3. 在转型过程中处理过多的问题

1.5.3.1. 在转型过程中处理过多的问题

1.5.3.2. 团队的目标通常是处理所有方面的工作，这无异于煮沸大海

1.5.3.3. 开发自助服务数据平台应该像开发自动驾驶汽车（具有不同级别的自动驾驶能力）一样，在自动化程度和实现复杂性方面有所不同

2.1. 传统上，数据仓库聚合了来自事务性数据库的数据，并生成回顾性的批处理报告

2.2. 数据仓库解决方案通常由单一的供应商打包销售，集成了元数据编目、查询调度、接入连接器等功能

2.3. 在今天的大数据时代，数据平台是由不同的数据存储、框架和处理引擎组合而成的，支持多种数据属性和洞察类型

2.4. 大数据时代的口号是根据数据类型、用例需求、数据用户的复杂程度以及与已部署技术的互操作性，使用“合适的工具来完成合适的工作”

2.5. 提取洞察分为四个关键阶段：发现、准备、构建和实施

2.6. 在提取洞察的每个阶段，数据用户都把大量时间花在数据工程任务上，比如迁移数据、了解数据沿袭、搜索数据工件等。数据用户的理想“天堂”是一个数据自助服务平台，它可以简化和自动化日常工作中遇到的任务

3.1. 所有洞察项目都是从发现可用的数据集和工件，并收集提取洞察所需的任何额外数据开始的

3.2. 数据发现的复杂性源于企业内部知识扩展的困难性

3.3. 数据团队往往从小规模开始，团队知识容易获得且可靠

3.4. 随着数据量的增长和团队规模的扩大，会在各业务线之间形成孤岛，导致没有可信的单一数据源

3.5. 发现数据集的元数据细节

3.5.1. 第一步是理解元数据的属性，比如数据来自何处、数据属性是如何生成的等

3.5.2. 数据用户首先获取其他用户提供的团队知识，这些知识可能是过时的和不可靠的

3.5.3. 在数据集被收集和转换的过程中，没有标准化的格式来跟踪数据集的元数据

3.6. 搜索可用的数据集和工件

3.6.1. 具备理解数据集元数据细节的能力后，下一步就是找到所有相关的数据集和工件，包括视图、文件、流、事件、指标、仪表盘、ETL和即席查询等

3.6.2. 根据规模的不同，数据用户可能需要花费数天或数周的时间来确定相关细节

3.6.3. 可用的数据集和工件在不断地演进，需要不断地更新元数据

3.7. 为机器学习模型重用或创建特征

3.7.1. 作为机器学习模型输入的属性（如收入）称为特征

3.7.2. 如果历史数据可用，那么属性就可以作为特征使用

3.7.3. 重用现有特征可以从根本上减少机器模型的开发时间

3.8. 聚合缺失的数据

3.8.1. 为了访问横跨不同应用程序孤岛的数据集，通常需要将这些数据集汇总并迁移到一个集中式的中央存储库中，类似数据湖

3.8.2. 一旦将洞察部署到生产环境中，数据迁移就是一个持续的任务，需要作为管道的一部分进行管理

3.9. 管理点击流事件

3.9.1. 点击流数据在用于生成洞察之前，需要经过聚合、过滤和丰富

3.9.2. 处理大量的流事件非常具有挑战性，特别是在近实时的应用场景中，例如定向个性化

4.1. 准备阶段致力于为构建实际业务逻辑以提取洞察做好数据准备

4.2. 包括数据聚合、清理、标准化、转换和反规范化

4.3. 在中央存储库中管理聚合数据

4.3.1. 业务仪表盘和预测模型所需的数据现在聚合在一个中央存储库（通常称为数据湖）中

4.4. 结构化、清理、丰富和验证数据

4.4.1. 现在数据已经聚集在湖中，我们需要确保数据的格式是正确的

4.4.2. 转换不是一次性的，而是需要以可靠的方式持续应用

4.5. 确保数据权限合规

4.5.1. 假设客户不同意使用他们的行为数据来产生洞察，则数据用户需要了解哪些客户的数据可以用于哪些用例

4.5.2. 合规性是在给客户提供更好的洞察体验和确保数据的使用符合客户的意图之间的平衡

5.1. 构建阶段的重点是编写提取洞察所需的实际逻辑

5.2. 确定访问和分析数据的最佳方法

5.2.1. 构建阶段的起点是确定编写和执行洞察逻辑的策略

5.2.2. 数据湖中的数据可以持久化为对象，也可以存储在专门的服务层中，即键-值存储、图数据库、文档存储等

5.2.3. 数据用户需要决定是否利用数据存储的原生API和关键字，并确定处理逻辑的查询引擎

5.3. 编写转换逻辑

5.3.1. 业务仪表盘或模型洞察的实际逻辑通常是以提取-转换-加载（ETL）、提取-加载-转换（ELT）或流式分析模式编写的

5.3.2. 业务逻辑需要被翻译成高性能、可扩展性良好且易于管理更改的代码

5.3.3. 需要监控逻辑的可用性、质量和变更管理

5.4. 训练模型

5.4.1. 随着数据集和深度学习模型的规模不断增长，训练可能需要几天甚至几周的时间

5.4.2. 训练是迭代的，有数百种模型参数和超参数值的排列组合，用于寻找最佳模型

5.4.3. 模型训练不是一次性的，需要针对数据属性的变化重新训练

5.5. 持续集成机器学习模型变化

5.6. 洞察的A/B测试

5.6.1. A/B测试（也称为桶测试、拆分测试或控制实验）正在成为做出数据驱动决策的标准方法

5.6.2. 将A/B测试整合为数据平台的一部分，以确保在机器学习模型、业务报告和实验中应用一致的指标定义，这一点至关重要

5.6.3. 正确配置A/B测试实验非常重要，并且必须确保不存在不平衡，避免导致不同群体之间的兴趣度量在统计上出现显著差异

6.1. 在提取洞察的实施阶段，洞察模型已经部署到生产环境中

6.2. 此阶段一直持续到洞察模型在生产中被广泛使用为止

6.3. 验证和优化查询

6.3.1. 继续以业务仪表盘和收入预测模型为例，数据用户编写了数据转换逻辑，可以是SQL查询，也可以是用Python、Java、Scala等实现的大数据编程模型

6.3.2. 好的查询和不好的查询之间的差异非常明显

6.4. 编排管道

6.4.1. 编排是确保管道服务水平协议（SLA）和有效利用底层资源的一种平衡行为

6.4.2. 管道调用的服务横跨接入、准备、转换、训练和部署

6.4.3. 管道的编排是多租户的，支持多个团队和业务用例

6.5. 部署机器学习模型

6.5.1. 预测模型部署在生产环境中，以便不同的程序调用它以获得预测值

6.5.2. 部署模型不是一次性的任务—机器学习模型会根据重新训练定期更新

6.5.3. 数据用户使用非标准化、自主开发的脚本来部署需要定制的模型，以支持广泛的机器学习模型类型、机器学习库与工具、模型格式和部署终端（如物联网设备、移动设备、浏览器和Web API）

6.6. 监控洞察的质量

6.6.1. 不正确的值的原因

6.6.1.1. 不同步的源模式更改

6.6.1.2. 数据元素属性发生变化

6.6.1.3. 数据接入问题

6.6.1.4. 源系统和目标系统的数据不同步

6.6.1.5. 处理失败

6.6.1.6. 生成指标的业务定义不正确

6.7. 持续成本监控

6.7.1. 实施阶段的最后一部分是成本管理

6.7.2. 在云端，成本管理尤其关键，即付即用的付费模型会随着使用量的增加而线性增长（与传统的先买后用、固定成本模式不同）