1.1　从原始数据到洞察

传统上，数据仓库聚合了来自事务性数据库的数据，并生成回顾性的批处理报告。数据仓库解决方案通常由单一的供应商打包销售，集成了元数据编目、查询调度、接入连接器等功能。查询引擎和数据存储耦合在一起，互操作性选择有限。在今天的大数据时代，数据平台是由不同的数据存储、框架和处理引擎组合而成的，支持多种数据属性和洞察类型。在内部部署、云部署或混合部署中，有许多技术可供选择，存储和计算的解耦使得数据存储、处理引擎和管理框架的混合和匹配成为可能。大数据时代的口号是根据数据类型、用例需求、数据用户的复杂程度以及与已部署技术的互操作性，使用“合适的工具来完成合适的工作”。表1-1对比了传统数据仓库时代和大数据时代的关键区别。

编辑注1：有的文献写作Value（价值性）。

提取洞察分为四个关键阶段：发现、准备、构建和实施（如图1-2所示）。我们以构建一个实时业务洞察仪表盘为例来详细说明，该仪表盘可以跟踪收入、营销活动绩效、显示客户注册和流失情况等。仪表盘还包括一个机器学习预测模型，用于预测不同地区的收入。

1.1.1　发现

所有洞察项目都是从发现可用的数据集和工件，并收集提取洞察所需的任何额外数据开始的。通常，数据发现的复杂性源于企业内部知识扩展的困难性。数据团队往往从小规模开始，团队知识容易获得且可靠。但随着数据量的增长和团队规模的扩大，会在各业务线之间形成孤岛，导致没有可信的单一数据源。今天的数据用户，需要在质量、复杂性、相关性和可信度各不相同的数据资源海洋中前行。以实时业务仪表盘和收入预测模型为例，数据用户的出发点是了解常用数据集的元数据，即客户资料、登录日志、计费数据集、定价和促销活动等。

发现数据集的元数据细节

第一步是理解元数据的属性，比如数据来自何处、数据属性是如何生成的等。元数据在决定数据的质量和可靠性方面也发挥着关键作用。例如，如果模型是使用未正确填充的表，或者其数据管道中存在错误的表构建的，那么该模型是不正确和不可靠的。数据用户首先获取其他用户提供的团队知识，这些知识可能是过时的和不可靠的。收集和关联元数据需要访问数据存储、接入框架、调度器、元数据目录、合规框架等。在数据集被收集和转换的过程中，没有标准化的格式来跟踪数据集的元数据。理解元数据的属性所需的时间需要通过度量“解释耗时”来追踪。

搜索可用的数据集和工件

具备理解数据集元数据细节的能力后，下一步就是找到所有相关的数据集和工件，包括视图、文件、流、事件、指标、仪表盘、ETL和即席查询等。在一个典型的企业中，数据集往往非常多。作为一个极端的例子，谷歌有260亿个数据集（https://oreil.ly/Feume）。根据规模的不同，数据用户可能需要花费数天或数周的时间来确定相关细节。如今，搜索主要依赖于数据用户的团队知识和应用程序开发人员。可用的数据集和工件在不断地演进，需要不断地更新元数据。完成这一步所需的时间需要通过度量“搜索耗时”来追踪。

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

继续这个示例，开发收入预测模型需要使用市场、产品线等历史收入数据进行训练。作为机器学习模型输入的属性（如收入）称为特征。如果历史数据可用，那么属性就可以作为特征使用。在构建机器学习模型的过程中，数据科学家对特征组合进行迭代，以生成最准确的模型。数据科学家需要花费60%的工作时间来创建训练数据集，为机器学习模型生成特征。重用现有特征可以从根本上减少机器模型的开发时间。完成这一步所需的时间需要通过度量“特征处理耗时”来追踪。

聚合缺失的数据

为了创建业务仪表盘，需要将已识别的数据集（如客户活动和账单记录）关联起来，以生成留存风险的洞察。为了访问横跨不同应用程序孤岛的数据集，通常需要将这些数据集汇总并迁移到一个集中式的中央存储库中，类似数据湖。迁移数据涉及协调异构系统间的数据移动、验证数据正确性，以及适应数据源上发生的任何模式或配置更改。一旦将洞察部署到生产环境中，数据迁移就是一个持续的任务，需要作为管道的一部分进行管理。完成这一步所需的时间需要通过度量“数据可用性耗时”来追踪。

管理点击流事件

在业务仪表盘中，假设我们要分析应用程序中最耗时的工作流。这需要根据点击、浏览和相关上下文来分析客户的活动，比如之前的应用程序页面、访问者的设备类型等。为了跟踪活动，数据用户可以利用产品中现有的记录活动的工具，或者添加额外的工具来记录特定小组件（如按钮）的点击。点击流数据在用于生成洞察之前，需要经过聚合、过滤和丰富。例如，需要从原始事件中过滤由机器人产生的流量。处理大量的流事件非常具有挑战性，特别是在近实时的应用场景中，例如定向个性化。完成收集、分析和聚合行为数据这一步所需的时间需要通过度量“点击指标耗时”来追踪。

1.1.2　准备

准备阶段致力于为构建实际业务逻辑以提取洞察做好数据准备。准备工作是一项反复的、耗时的任务，包括数据聚合、清理、标准化、转换和反规范化。这个阶段涉及多种工具和框架。另外，准备阶段还需要进行数据治理，以满足监管合规性需求。

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

继续这个例子，业务仪表盘和预测模型所需的数据现在聚合在一个中央存储库（通常称为数据湖）中。业务仪表盘需要结合历史批处理数据和流式行为数据事件。根据数据模型和存储在磁盘上的格式，需要有效地对数据进行持久化。与传统的数据管理类似，数据用户需要确保访问控制、备份、版本控制、并发数据更新的ACID属性等。完成这一步所需的时间需要通过度量“数据湖管理耗时”来追踪。

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

现在数据已经聚集在湖中，我们需要确保数据的格式是正确的。例如，假设在计费数据集中，试用客户的账单记录有一个空值。作为结构化的一部分，空值将被显式地转换为零。同样，在使用选定客户时可能存在异常值，需要排除它们以防止影响整体参与度分析。这些活动被称为数据整理。应用整理转换需要用Python、Perl和R等编程语言编写特殊的脚本，或者进行烦琐的手工编辑。鉴于数据的数量、速度和多样性不断增长，数据用户使用低级编码技能以高效、可靠和重复的方式大规模地应用转换。并且，这些转换不是一次性的，而是需要以可靠的方式持续应用。完成这一步所需的时间需要通过度量“整理耗时”来追踪。

确保数据权限合规

假设客户不同意使用他们的行为数据来产生洞察，则数据用户需要了解哪些客户的数据可以用于哪些用例。合规性是在给客户提供更好的洞察体验和确保数据的使用符合客户的意图之间的平衡。目前没有简单的方法可以解决这个问题。数据用户希望有一种简单的方法可以定位给定用例的所有可用数据，且不必担心违反合规性。没有单一标识符可用于跨孤岛数据集来跟踪客户数据。完成这一步所需的时间需要通过度量“合规耗时”来追踪。

1.1.3　构建

构建阶段的重点是编写提取洞察所需的实际逻辑。以下是这个阶段的关键步骤。

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

构建阶段的起点是确定编写和执行洞察逻辑的策略。数据湖中的数据可以持久化为对象，也可以存储在专门的服务层中，即键-值存储、图数据库、文档存储等。数据用户需要决定是否利用数据存储的原生API和关键字，并确定处理逻辑的查询引擎。例如，在Presto集群上运行短时的交互式查询，而在Hive或Spark上运行长时的批处理查询。理想情况下，转换逻辑应该是不可知的，并且在将数据迁移到不同的聚类存储时，或部署了不同的查询引擎时，转换逻辑不应该改变。完成这一步所需的时间需要通过度量“虚拟化耗时”来追踪。

编写转换逻辑

业务仪表盘或模型洞察的实际逻辑通常是以提取-转换-加载（ETL）、提取-加载-转换（ELT）或流式分析模式编写的。业务逻辑需要被翻译成高性能、可扩展性良好且易于管理更改的代码。需要监控逻辑的可用性、质量和变更管理。完成这一步所需的时间需要通过度量“转换耗时”来追踪。

训练模型

在收入预测示例中需要训练一个机器学习模型。我们使用历史收入数据来训练模型。随着数据集和深度学习模型的规模不断增长，训练可能需要几天甚至几周的时间。训练在由CPU和GPU等专用硬件组成的服务器群上运行。并且，训练是迭代的，有数百种模型参数和超参数值的排列组合，用于寻找最佳模型。模型训练不是一次性的，需要针对数据属性的变化重新训练。完成这一步所需的时间需要通过度量“训练耗时”来追踪。

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

假设在业务仪表盘示例中，计算活跃用户的定义发生了变化。机器学习模型管道随着源模式、特征逻辑、依赖数据集、数据处理配置和模型算法的变化而不断演进。与传统的软件工程类似，机器学习模型也在不断更新，各团队每天都会进行多次更改。为了集成这些变化，需要跟踪与机器学习管道相关的数据、代码和配置。通过在测试环境中部署并使用生产数据来验证更改。完成这一步所需的时间需要通过度量“集成耗时”来追踪。

洞察的A/B测试

考虑一个为终端客户预测房价的机器学习模型。假设针对此洞察开发了两个同样准确的模型，哪一个更好？在大多数企业内部，普遍做法是部署多个模型，并将它们呈现给不同的客户集。基于客户使用的行为数据，从而选择一个更好的模型。A/B测试（也称为桶测试、拆分测试或控制实验）正在成为做出数据驱动决策的标准方法。将A/B测试整合为数据平台的一部分，以确保在机器学习模型、业务报告和实验中应用一致的指标定义，这一点至关重要。正确配置A/B测试实验非常重要，并且必须确保不存在不平衡，避免导致不同群体之间的兴趣度量在统计上出现显著差异。同时，在不同实验变体之间，客户不应该被交叉影响。完成这一步所需的时间需要通过度量“A/B测试耗时”来追踪。

1.1.4　实施

在提取洞察的实施阶段，洞察模型已经部署到生产环境中。此阶段一直持续到洞察模型在生产中被广泛使用为止。

验证和优化查询

继续以业务仪表盘和收入预测模型为例，数据用户编写了数据转换逻辑，可以是SQL查询，也可以是用Python、Java、Scala等实现的大数据编程模型（例如，Apache Spark或Beam）。好的查询和不好的查询之间的差异非常明显。根据实际经验，一个需要运行几个小时的查询可以通过调优在几分钟内完成。数据用户需要了解Hadoop、Spark和Presto等查询引擎中的众多旋钮及其功能。这需要深入了解查询引擎的内部工作原理，对于大多数数据用户而言挑战极大。没有什么通用方案——查询的最佳旋钮值根据数据模型、查询类型、集群大小、并发查询负载等的不同而有所不同。因此，查询优化是一项需要持续进行的活动。完成这一步所需的时间需要通过度量“优化耗时”来追踪。

编排管道

该过程需要调度与业务仪表盘和预测管道相关的查询。运行管道的最佳时间是什么时候？如何确保正确处理依赖关系？编排是确保管道服务水平协议（SLA）和有效利用底层资源的一种平衡行为。管道调用的服务横跨接入、准备、转换、训练和部署。数据用户需要监控和调试管道，以确保这些服务的正确性、健壮性和及时性（这很不容易）。管道的编排是多租户的，支持多个团队和业务用例。完成这一步所需的时间需要通过度量“编排耗时”来追踪。

部署机器学习模型

预测模型部署在生产环境中，以便不同的程序调用它以获得预测值。部署模型不是一次性的任务——机器学习模型会根据重新训练定期更新。数据用户使用非标准化、自主开发的脚本来部署需要定制的模型，以支持广泛的机器学习模型类型、机器学习库与工具、模型格式和部署终端（如物联网设备、移动设备、浏览器和Web API）。目前还没有标准的框架来监控模型的性能并根据负载自动扩展。完成这一步所需的时间需要通过度量“部署耗时”来追踪。

监控洞察的质量

业务仪表盘每天都在使用，假如它在某一天显示了一个不正确的值，原因可能如下：不同步的源模式更改、数据元素属性发生变化、数据接入问题、源系统和目标系统的数据不同步、处理失败、生成指标的业务定义不正确等。数据用户需要对数据属性进行异常分析，并对检测到的质量问题进行根因调试。数据用户依赖一次性检查，在大量数据流经多个系统的情况下，这种检查是不可扩展的。我们的目标不仅是检测数据质量问题，还要避免将低质量的数据记录与其他数据集分区混在一起。完成这一步所需的时间需要通过度量“洞察质量耗时”来追踪。

持续成本监控

我们现在已经在生产中部署了洞察模型，并进行了持续监控以确保质量。实施阶段的最后一部分是成本管理。在云端，成本管理尤其关键，即付即用的付费模型会随着使用量的增加而线性增长（与传统的先买后用、固定成本模式不同）。随着数据大众化，数据用户可以在日常工作中自助提取洞察，但这有可能出现大量资源浪费，导致成本无限高的情况。比如，在高配GPU上运行一个糟糕的查询可能在几个小时内花费数千美元，这通常会让数据用户感到惊讶。数据用户需要回答以下问题：

a. 每个应用程序花了多少钱？

b. 哪个团队的支出会超出预算？

c. 是否可以在不影响性能和可用性的情况下减少开销？

d. 分配的资源是否得到了适当的利用？

完成这一步所需的时间需要通过度量“优化成本耗时”来追踪。

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