《Architecting Data and Machine Learning Platforms》第二章：创新数据的战略步骤

您的领导之所以为您建立数据平台提供资金，很可能是因为他们希望组织进行创新。他们希望组织能够发现经营的新领域，创造更好的业务运作方式，或为更多客户提供更高质量的产品。这种形式的创新通常通过更好地了解客户、产品或市场来实现。无论您的组织是想要减少用户流失、获取新用户、预测产品的维修周期，还是确定低成本替代品是否会受欢迎，任务始于数据收集和分析。数据是分析业务当前状态、识别缺陷或机会、实施改进现状的方式以及衡量这些变化影响的必需品。通常，必须将业务单元特定的数据与其他数据（来自整个组织以及来自供应商和市场的数据）一起进行分析。在构建数据平台时，重要的是要有意识地将最终的"为什么"（促进创新）牢记在心。

在本章中，您将了解构建促进创新的平台时应采取的七个战略步骤，为什么这些步骤是必不可少的，以及如何使用现代云技术实现它们。将这些步骤视为构建金字塔的基石（如图2-1所示），其中每个步骤都作为随后步骤的基础。

在本章中，我们将明晰说明所有步骤背后的概念，但将其实现的详细信息推迟到后续章节。例如，虽然我们将在本章描述打破信息孤岛的概念，但我们将在第5、6和7章中描述实现这一目标的分析中心或数据网格方法的架构。

步骤1：战略规划

为了使最后的六个步骤成功，首先需要制定一项战略计划，其中需要识别三个主要组成部分：

1. 目标

   • 组织在充分利用数据方面的雄心是什么？重要的是要深入挖掘，确定超越成本节约的目标。具体而言，重要的是要确定将使用数据做出的决策以及可以通过哪些指标了解转变是否成功。

2. 利益相关方

   • 在组织中，谁有权力赞助和推动更深层次的变革？确保将所有这些利益相关方聚集在一起------根据我们的经验，IT 项目往往资源不足，常常面临失败的风险，而业务驱动的项目则有更长期的高层支持和资金支持。业务项目还具有更高的投资回报率。

3. 变革管理流程

   • 如何有效地将方法层层传递并传达给整个组织，以获取最终用户的支持？

这种战略规划需要定期审视。目标是否仍然相同？是否有新的利益相关方需要了解情况？是否在队伍中酝酿着不满？让我们逐一看看这三个组成部分。

战略目标

在构建数据和AI/ML平台时，您应该明确自己的目标。很多时候，利益相关者会以当前平台的局限性为目标，例如，如果您当前最令人头痛的问题是报告工作负载导致级联宕机，目标可能会表述为"我们希望能够在三小时内为我们的三百万客户创建月度对账单"。然而，在构建平台的目标不应该被一个单一的用例狭隘地定义。相反，您希望从对您想要实现的战略目标的清晰理解开始。

基于业务的战略方向来设计系统。对于新购买提供信息的期望周转时间是多少？客户数量的预期增长是多少？通过手机还是通过经纪人到达的客户比例会随时间而变化吗？IT团队的预期人数是多少？业务是否希望让现场人员做出更多决策？您是希望发送月度对账单，还是希望根据需求动态生成历史活动报告？我们计划通过这些报告赚取钱？我们是否会根据这些结果改变业务做法？报告需要提供什么样的支持来支持我们当前的业务？当前平台无法支持这些需求将自然从这些战略关注中产生，但这使您能够全面地构建系统的要求，而不是被单一用例和老旧思维所束缚。这还有助于您向非技术高管传达对系统的需求。

如果可能的话，获取未来两三年内这些战略业务目标的数值估算，以帮助您做出具有成本效益的决策。例如，简单地说"查询应尽可能快地运行"可能很诱人，但这是建造一个过度工程化和昂贵系统的方法。相反，如果您知道在高峰时期会有1,500个并发查询，每个查询处理100GB的数据，需要在10秒内运行，您可以选择实现目标而不破坏银行的技术。这也可以反向运作。了解业务以60%的年同比速度获取客户，可能清楚地显示点击流数据集有望达到每天1TB的量级。这将阻止您做出短视的决策，需要撤销。

这通常受到您可以预见业务增长的时间范围的限制。它还受到现实世界事件的影响。例如，2020年的COVID-19大流行颠覆了许多企业的计划，加速了转向数字和全渠道体验的步伐。有时，您构建的系统必须被废弃并重新构建，但通过全面考虑应急情况，可以最大限度地减少这种情况发生的频率。

尽管细节可能有所不同，但我们发现大多数组织确定的战略目标最终需要他们的数据平台具备以下特点：

1. 降低运营数据和AI平台的成本。尤其是随着数据集大小的增长，线性增长的IT成本可能难以持续。
2. 加速新项目产生价值的时间，从而增加创新速度。对新想法进行实验不应该面临几个月的延迟，如采购机器、安装软件、获取数据集访问权限等。
3. 民主化从数据中获得的见解。使领域专家和现场人员能够直接与数据交互并获得见解。
4. 在决策中纳入预测分析，而不仅仅是描绘性分析。例如，不仅要测量上周使用的材料量，还要基于最近过去的使用量来预测下周所需的材料量。

这些因素的相对优先级在企业之间会有所不同（这也是应该的）。许多初创公司和数字原生公司强调创新速度和灵活性的增长，而许多成熟企业强调成本而不是灵活性。例如，初创公司可能会使用PB级的DWH，即使其数据规模较小，因为它预计将看到10倍的年度增长。与此相反，更成熟的企业可能选择使用批处理，因为它比流处理更便宜。这些不同的起点影响可能的创新和增长类型 - PB级的DWH可能使初创公司能够基于每次交易的每次付款推荐，而更成熟的企业可能仅每天发送一次推荐电子邮件，而且只向进行大额订单的客户发送。

确定利益相关者

确立战略的基础是正确的需求收集。为了成功做到这一点，非常重要的是要确定组织内能够理解需求并在所有不同业务单元之间有效协作的正确人员，以降低选择错误方法和解决方案的风险。但是，谁是正确的人呢？

我们是指来自业务方面的人（例如，首席执行官或首席财务官[CFO]），还是更好地依赖于IT团队（例如，首席信息官[CIO]、首席技术官[CTO]、首席数据官[CDO]等）？嗯，这实际上取决于组织。我们见过许多不同的方法，但一个共同的主题是，当直接由业务支持时，这种转型过程通常具有最高的成功率。为什么呢？很多时候，IT组织可能只被授权保持运营并在年复一年中降低成本。如果您的利益相关者仅在IT中，他们的激励与如果您的利益相关者包括需要开发新产品、触及更多客户或从根本上改变业务的BU中的人是非常不同的。

通过使新数据平台的定义不仅仅是纯粹的IT活动，您可以提高转型的可见性，并确保新平台允许组织解决以前无法解决的许多业务问题（例如，实时分析）。

即使在支持该倡议的公司领域内，也要确保所有参与其中的人都全力以赴是至关重要的。但是，这些人可能非常忙碌，没有足够的时间和专业知识来投入到这个转型项目中。因此，另一个关键问题是：公司是否有足够的内部人员（具有正确的技能和经验）来支持该倡议？或者您是否需要在公司外找到某人来引导项目朝着正确的方向发展？这不仅仅涉及技术知识，还涉及领导和管理，以确保数据平台的设计和实施成功，并且业务结果是积极的。

变更管理

一旦确定了目标和应该引导实现目标的人员，接下来必须为变更管理定义一个策略。组织可能拥有最雄心勃勃的目标，由最有影响力的人支持，但如果没有明确的任务来有效地将信息传达到组织内部，实施项目将变得非常困难。 在接受像以数据为驱动的变革这样的项目时，我们看到很多公司忽视了将变革的文化方面放在重要位置，将其视为一项纯粹的技术项目。业务用户和一般将利用数据平台的员工应准备好接受变革，而这只能通过适当的流程和正确的技能来实现。 如图2-2所示，变更管理是人、技术和流程之间的交集：

• 人和技术 开发全面的培训计划是至关重要的，以使员工能够利用组织内为他们提供的新资源。这可以由公司自己（内部提供）或由合作伙伴（外部提供）完成。组织越强调提升员工技能，就越能成功地实现其整体业务目标。
• 人和流程 这总是领导层的问题。公司内部的领导必须促使整体信息传达；当人们受到领导层的激励时（这也是利益相关者非常重要的另一个方面！），采用水平就会提高。我们看到很多项目因为缺乏来自发起倡议的同一人员的适当支持而失败。领导者有必要通过几次内部宣传活动，适当地在公司内传播信息，帮助人们拥抱变革。一些建议的问题是：团队结构如何？它们是否得到了高管的支持？云项目的预算、治理和评估是如何进行的？
• 流程和技术 这与组织利用云原生服务进行扩展的能力有关。一些建议的问题包括：组织在多大程度上使用托管和无服务器云服务抽象基础设施？自动化流程和运行通过其的可编程基础架构的实施水平如何？自动化是成功的关键因素，因为它一方面减少了人力投入，另一方面有助于进行低风险和频繁的变更，这是创新的关键要素。

成功需要这三个元素协同工作。许多组织通过建立一个名为卓越中心（CoE）的专门小组来实现这一点，其目标是确定方向并推动公司朝着人-流程-技术的和谐方向发展。我们将在第12章中通过一个具体的示例重新审视这一概念。

步骤2：通过采用云方法降低总体拥有成本（TCO）

对于大多数企业来说，在制定战略之后的第一步是制定（并找到）预算。将企业数据仓库（DWH）和数据湖迁移到云端可以大大节省传统实施的成本。让我们看看为什么会这样以及如何为实现最大节省做好准备。

云端为何成本更低

将数据迁移到云端可以因为多种因素为您节省资金：

1. 运营成本降低 在本地，贵公司需承担整个系统的运营成本，并且很多维护工作都是手动进行的。云服务提供商（我们将其称为超大规模提供商）则通过构建非常高效的方式来管理大型机群。例如，亚马逊通过在低利润业务中运行世界上最大、最可靠的网站之一，将这方面的专业知识带到云基础设施中，并提供非常低的成本。同样，谷歌运行着九个服务，必须以非常高效的方式运行，因为每个服务（如搜索、Gmail 和 YouTube）有超过十亿的免费用户使用。公共云的用户由于云服务运营中内置的高度自动化而受益，绝大多数云服务不需要维护，因为大多数活动（如硬件维护、安全检查、软件包更新等）在幕后自动管理。
2. 计算和存储的适度规模 与购买与预期峰值使用量相匹配的设备不同，云提供商允许您根据需求和使用情况调整计算资源的规模。例如，您可以从小规模开始，随着需要创建的报告数量随时间增长而增加机器的数量。这个好处既适用于云提供商的服务（如Amazon EMR、Google Cloud Dataproc 和Azure HDInsight），也适用于在云基础设施上运行的第三方工具，如Databricks 或Teradata Vantage。
3. 工作负载的自动缩放 许多云服务（例如Azure Cosmos DB、AWS Aurora、Google Cloud Composer、Snowflake 和Actian Avalanche）允许您在高峰时段分配更多机器，在低峰时段分配更少机器。请注意，我们说的是更少的机器，而不是零机器。尽管在非工作时间完全关闭服务可能很诱人，但请考虑是否真的希望保留那种实体店的模式。您公司的网站希望在晚上不关闭。您的后端系统也不应该关闭。在晚上保留服务紧急请求的能力通常会取得戏剧性的效果。
4. 无服务器工作负载 一些现代云服务（例如Google Cloud Platform 上的BigQuery、AWS 上的Athena、Azure Functions）是无服务器的 - 您可以提交代码，系统会帮您执行。将无服务器系统视为在所有超大规模提供商的客户之间共享的自动缩放集群。因此，无服务器系统将云基础设施操作的成本优势提升到整个堆栈。由于劳动力往往是IT预算中最昂贵的项目，无服务器云服务将带来成本效益最高的解决方案。请注意，许多供应商将其自动缩放服务定位为"无服务器"，因此您应验证所涉服务是否真正是无服务器 - 只有在是多租户的情况下，您才能获得无服务器解决方案的劳动力成本优势。如果群集属于您，您将需要管理该群集（例如，找出谁在群集上运行什么作业以及何时运行），因此您将无法获得无服务器解决方案的劳动力成本优势。

既然您对为何云可能成本较低有了更好的理解，那么让我们来看看如何估算您可能实现的节省金额。

节省多少成本呢？

在图2-3中，我们展示了我们在一个真实的数据湖上进行的概念验证（PoC）的结果。我们首先将工作负载不加修改地转移到了云上，然后将其放到了可伸缩的基础设施上，最后进行了现代化改造。我们测量了云成本会是多少。由于这是一个PoC，系统在这些配置下运行的时间不足以测量运行这些系统的人员成本。

实际节省的金额当然会根据您平台和工作负载的具体细节而异。作为一个粗略的估计，将工作负载不加修改地转移到云上通常会提供约10%的节省。添加合适大小通常会额外增加5%。自动伸缩通常会增加40%的节省，而无服务器通常会额外增加30%。如果您充分利用所有这些节省，例如通过将在本地使用Hive的工作负载更改为在云上使用无服务器解决方案，成本节省可高达95%。在将工作负载迁移到云上之前，分析源工作负载是至关重要的。在某些情况下，纯粹的搬迁可能不会有益，因为工作负载是为利用本地环境的特定硬件功能而开发的。在这些情况下，评估更新代码（如果可能）以使工作负载现代化，并使其能够利用自动伸缩和无服务器功能是很重要的。

云计算何时有助于？

在所有这些背后的是基本的云经济学。忽略价格折扣的影响，用 10 台机器运行一个任务 10 小时的成本与用 100 台机器运行一个小时的任务的成本相同，或者与在 1,000 台机器上运行任务 6 分钟的成本相同。能够在多租户集群中为您提供 1,000 个"热"实例的能力是使无服务器成本效益如此高效的原因。当然，这不仅仅是成本问题------如果一个操作在今天需要花费 10 小时，而现在可以在 6 分钟内得到结果，这样更及时的决策可能带来的业务价值远远超过了计算成本的增加。

有哪些工作负载不适合完全迁移到云？从一般的角度来看，任何类型的工作负载都可能成为云环境获取前述所有好处的潜在目标。可能有一些情况，混合方法（例如，在本地环境中的工作负载的一部分以及云中的其余部分），我们将在第 9 章深入探讨，可能更适合一些情况：比如一个稳定的工作负载（即，不需要增长且没有峰值），规模大，非常特定，比如全球尺度的数值天气预报模型。在这种情况下，有一部分工作负载需要专业硬件（例如，共享内存，高速互连），这消除了云的即时硬件成本优势，以及需要了解天气模型的专业运维人员，并且它几乎每天都经历相同的负载。这一部分可以保留在本地，同时拥有其他可以立即从云采纳中受益的相关元素（例如，数据备份）。 短暂且峰值的工作负载往往最能从云迁移中受益，主要是通过减少花费宝贵时间进行资源配置的需要。短暂和峰值工作负载还将受益于自动缩放和按使用量付费的云经济学。因此，在基于成本的优先考虑云迁移时，请从短暂和峰值工作负载开始。

此外，与云计算相比，与员工流失相关的风险降低了，因为技术栈是众所周知的，企业支持是可用的。另一方面，使用定制数据中心，你的 IT 部门可能会受到许多限制！

第3步：打破信息孤岛

在将所有数据迁移到云端后，您可以开始思考如何更好地从中获取价值。开始从数据中获取价值的最佳方法之一是打破数据孤岛。换句话说，避免拥有多个不相关、分离且有时不可见的数据集。我们现在处于图2-1金字塔的第三层。

打破数据孤岛涉及在分散和价值之间找到合适的平衡。分散是好的，因为数据距离领域专家越远，数据质量就降低。因此，您必须让领域专家对数据负责。不要将数据集中在IT中。同时，请记住，通过结合组织内的数据甚至是合作伙伴共享的数据，您可以获得最大的AI/ML价值。打破组织不同部分之间的隔离是关键。

如何解决这个问题？如何让组织的不同部分保持对其数据的控制，同时为任何有权访问数据的人提供访问权限？我们将在以下部分探讨如何做到这一点。

统一数据访问

在云上实现数据的统一存储位置并不意味着要采用中央所有权结构。例如，数据可以存储在Azure Blob Storage上，但每个部门都可以将"他们的"数据放在"他们的"存储桶中。

对数据的访问应该通过云服务提供商的身份和访问管理（IAM）进行管理。避免将本地身份验证机制（如LDAP或Kerberos）带到云上。如果需要维护混合基础架构，在本地的Kerberos角色可以映射到云上的IAM。如果使用需要自己的身份验证机制（例如MySQL）的软件，请使用身份验证代理以避免登录机制的多样化。避免使用既不提供IAM也不提供IAM代理的软件。将数据和见解锁定将在长期内给你带来很多困扰，无论该软件在近期有什么好处。

如果使用多云，请确保在SaaS单点登录（SSO）身份验证机制上进行标准化，例如Okta，然后将Okta身份验证映射到各个云的IAM。另一种方法是，如果您有一个"主"云，可以将该云的IAM与其他云进行联合：例如，如果Azure是您的主云，但您希望在Google Cloud上执行一些数据工作负载，则可以将Google Cloud Identity与Azure Active Directory进行联合。

确保基于实际发出请求的用户对数据进行审计，而不是通过破坏与个人用户的关联的服务账户。由于有关数据访问的隐私和政府法规继续变得更为严格，避免陷入任何以其自己的云项目中运行或以不透明方式读取数据的软件。

这意味着每个部门都将管理其数据并对其进行分类。例如，他们可以将数据仓库中的某些列标记为包含财务数据。数据治理政策可能是只有会计和副总裁以上级别的人员被允许查看财务数据。此政策由IT部门（而不是数据所有者）使用云IAM来强制执行。

不要陷入中央控制数据以打破数据隔离的诱惑。数据质量会随着距离领域专家的距离而降低。您希望确保领域专家创建数据集并拥有存储桶。这允许本地控制，但对这些数据集的访问将通过云IAM角色和权限进行控制。使用加密、访问透明性和遮蔽/动态技术可以帮助确保即使数据准确性的责任属于领域团队，也能实现全组织的安全性。

选择存储

存储数据的选择取决于数据的类型：

1. 结构化和半结构化数据应存储在专为SQL分析进行优化的位置。Google BigQuery、AWS Redshift、Azure Synapse、Actian Avalanche、Snowflake 等是不错的选择。这些工具允许您集中数据，同时由不同团队管理不同的数据集，但作为同一大型数据仓库的一部分。
2. 另一种选择是将结构化或半结构化数据存储在开放格式中，比如使用分布式表格格式（如Apache Iceberg或Databricks Delta Lake）在云块存储（如AWS S3）之上，例如Parquet。虽然在使用这些开放格式（而不是BigQuery中的原生存储机制，比如Capacitor）存储数据时可能在SQL分析中稍微降低性能，但存储成本更低并且支持非SQL分析（如机器学习）的灵活性可能是值得权衡的。
3. 无结构数据应存储在为从各种计算引擎读取进行优化的格式和位置。使用标准的云友好格式，如Parquet、Avro、TensorFlow Records 和 Zarr，并将文件存储在Google Cloud Storage、Azure Blob Storage 或 AWS S3上。逗号分隔值（CSV）和JavaScript对象表示法（JSON）是人类可读且相对易于处理的格式，因此也有其用武之地。

通常，每个分析数据集或存储桶将位于单个云区域（或多个区域，如欧盟或美国）。我们将这样的存储层称为分布式数据层，以避免陷入数据湖与数据仓库的争论。

鼓励团队提供对其数据集的广泛访问（"默认开放"）。数据所有者控制访问权限，并负责对受组织范围数据治理政策约束的数据进行分类。专业团队还可能有能力标记数据集（用于隐私等）。对其数据集的权限由数据所有者管理。培养您的团队，使他们能够发现和标记数据集，并构建集成流水线，不断增加分布式数据层的广度和覆盖范围。

语义层

在构建民主化数据文化时可能出现的一个附带效应是可能会看到分析孤立。同一变量可能在组织的不同部分以不同的列名被称为。每次计算关键绩效指标（KPI）都是计算它的一次机会，有可能以错误或不一致的方式计算。因此，鼓励数据分析团队构建一个语义层（以便可以标准化词汇表并可以在其他所有地方计算一次并重复使用KPI），并通过它应用治理------见图 2-4。

类似 Looker、Informatica、Collibra、AtScale 和 Cube 的工具可以帮助定义和标准化语义层。使用这些工具的优势是它们是多云的，并且可以跨足在场地和云之间。因此，您可以在所有环境中标准化数据治理。在云上，实际的查询是由底层的数据仓库执行的，因此在使用这些工具创建仪表板时不会发生数据复制。

不要制作数据副本。提取和复制会增加安全风险，使数据依赖关系难以追踪，并降低分析的及时性。建立一个轻量级的语义层，并将计算带到单一数据源。

还有一种趋势是在不同环境中提供一致的控制界面。例如，Google 的 BigQuery Omni 允许您在 BigQuery 界面中处理 AWS S3 存储桶、Azure Blob 存储和 MySQL 中的数据。Informatica、Collibra、Looker 等工具提供了对不同云和本地环境中数据的一致界面。

正如您所见，消除数据孤岛是释放数据潜力的关键步骤，因为它实现了团队之间更好的可见性和更好的协作。现在让我们看看如何进入下一步，以更快地利用您手头的这些数据。

第四步：更快地在上下文中做决策

商业决策的价值随着延迟和距离的增加而降低。例如，假设你能够在一分钟内或一天内批准一笔贷款。一分钟的批准时间比一天的批准时间要更有价值得多。同样，如果你能够做出一个考虑到空间上下文（无论是基于用户当前居住地还是当前访问地点）的决策，那么这个决策就比不考虑空间上下文的决策更有价值。因此，你的平台现代化的一个重要目标应该是，在不复制数据的情况下，可以在数据上执行地理信息系统（GIS）、流处理和机器学习（ML）操作。前一节的原则，即将计算带到数据所在地，也应适用于GIS、流处理和ML。

批处理到流处理

在我们与许多组织合作的情况下，数据规模每年增长在30%到100%之间。由于复利的力量，这意味着在未来五年需要为数据增长规划4倍到32倍的容量。

大规模增加数据量的一个反直觉方面是，随着数据量的增加，更频繁地处理数据变得更有意义。例如，假设一个业务根据其网站流量创建每日报告，而这份报告需要两个小时才能生成。如果网站流量增长了4倍，报告生成时间将增加到八个小时，除非业务投入四倍数量的机器来完成工作。与此不同的方法是，通过每天计算四次六小时的数据统计信息，并将这些报告汇总，以创建每天更新四次的每日报告，如图2-5所示。这两种方法的计算成本几乎相同，然而第二种方法可以带来相当大的业务利益。将这种方法推广开来，将批处理数据处理更改为流处理变得有意义，尤其是随着数据量的增加，许多企业开始进行这种转变。

上下文信息

另一个加快决策的关键因素是自动化。随着数据质量的提高，或者企业将焦点转向其长尾客户，有必要减少用户体验中的摩擦。对于你产品的频繁、熟练的用户来说，他们能够忍受的问题要比偶尔、不那么复杂的用户多得多。能够捕捉到沮丧的用户并为他们提供上下文的帮助变得至关重要。

实时的、基于位置的可视化越来越成为决策的方式。在许多情况下，这些可视化是内嵌到用户使用的应用程序中的。例如，Shopify为商家提供了图形和图表，展示他们的店铺表现如何。为了以规模做到这一点，这些图形实际上被嵌入到网站中，而不是作为独立的仪表板产品。确保位置信息是你的数据模式的一部分是最佳实践，无论是店铺的位置还是交货卡车的位置。因此，如果你的模式包括地址，请确保该模式要求对地址进行地理编码并使其成为规范形式。事后向数据集添加干净的地理信息是非常困难的。

成本管理

尽管很少有技术高管会对前述观点提出异议，但流处理有着在实施、监控和长期维护方面成本高昂的声誉。2 如何在不超出预算的情况下实现实时决策呢？

首先，不要构建两个系统，一个用于批处理，另一个用于流处理。相反，将批处理视为流处理的一种特殊情况。诸如Apache Flink和Apache Beam（甚至Spark结构化流）之类的软件工具使这成为可能。其次，不要自定义构建监控、可观测性、延迟到达、扩展等功能。Flink和Beam是开源技术，但为了执行它们，利用完全托管的服务，如AWS上的Kinesis Data Analytics或GCP上的Cloud Dataflow------这是因为管理和排除故障流处理基础架构的技能相当罕见。

另一种方法是将流处理视为批处理的一种特殊情况（或者根据Flink的理念相反）。采用这种方法的人尝试进行微批处理，通过尽可能快地处理小量数据。当需要非常新鲜但不一定是实时的数据时，这种方法可以奏效。这意味着等待一小时或一天才能运行批处理是不可接受的，但与此同时，了解过去几秒发生了什么并不重要。

接下来，将流式数据落入提供最新信息给读取者（并且能够大规模处理它们）的DWH或存储层。换句话说，只要您能够实时落地数据，对数据的所有分析都将反映最新信息，而无需采取进一步的努力。

既然您已经了解了如何利用最新和与上下文相关的信息，让我们看看如何注入AI/ML以更好地理解数据。

步骤5：利用打包的人工智能解决方案实现飞跃

2010年代技术领域最令人振奋的发展之一是深度学习的崛起，这是人工智能（AI）的一个分支。AI涵盖了计算机作为决策工具的问题类别。通常情况下，AI系统是通过编写计算机以思考或行动像人类一样来构建的。为了做到这一点，专家的思考过程必须被精心编码成计算机可以遵循的规则。由于人类通常无法精确解释他们的判断，这种专家系统很少表现得很好。 机器学习（ML）是一类AI技术，与其捕获人类逻辑不同，ML"模型"显示大量正确的决策，预期该模型将来能够推断如何做出正确的决策。由于收集数据比捕获逻辑更容易，ML能够解决各种问题。然而，数据通常必须是结构化数据，类似于关系数据库中保存的数据。在2010年代中期，一组称为深度学习的技术开始崭露头角。这些技术使用"深度神经网络"，能够理解图像、语音、视频、自然语言文本等非结构化数据。这反过来导致了像Google Photos（即使用自然语言查询搜索图片的能力）或Alexa（即通过自然语言处理进行交互）这样的技术的发展。在企业中，深度学习也使组织能够从非结构化数据（如产品目录和用户评论）中提取信息。为企业用例提供了预构建的生成式AI解决方案，例如内容创作、客户体验、编码协助以及其他工作流助手。 由于AI变得越来越成熟，不再需要在组织中投入大量工程时间来构建AI能力。相反，您可以通过许多可购买或定制的AI解决方案来利用AI的好处。这些解决方案可以分为几类：预测性分析、理解和生成数据、个性化和打包解决方案。

预测分析

机器学习模型是通过正确决策的示例进行训练的。企业数据仓库（DWH）通常是这类训练示例的重要来源。例如，假设你的业务是购买二手车、维修并销售。你想要创建一个系统来估计在拍卖会上购买的车辆的维修成本。很明显，你企业的历史数据是你购买和整修车辆的实际维修成本的良好来源。换句话说，历史数据中的正确答案存在于你的数据仓库中（见图2-6），可以用来训练机器学习模型。然后，训练好的机器学习模型可以用于预测随后在拍卖会上出现的车辆的维修成本。

检测欺诈交易、估计机器故障时间、广告是否会被点击、销售多少商品、客户是否会购买等问题都是预测性分析问题的示例。通过教模型根据已捕获的其他因素预测历史记录中的一个值，可以解决这些问题。了解影响维修成本等事物的因素，将组织中与此估算有关的所有数据纳入数据仓库是成功进行预测性分析的先决条件。构建企业数据仓库后，有许多预建的预测性解决方案可用于创建必要的模型。事实上，像AWS Redshift和Google BigQuery这样的数据仓库提供了在不移出数据仓库的情况下连接到AWS SageMaker和Google Cloud Vertex AI等服务，从而能够训练自定义机器学习模型。

理解和生成非结构化数据

ML模型也可以经过训练以理解和生成非结构化数据。 例如，自眼底图像中识别眼病、从交通摄像头检测非法左转、从视频中转录文本以及在评论中识别辱骂性语言的问题，都是使用ML模型来解释非结构化数据（图像、视频或自然语言）的例子。

深度学习已经彻底改变了对非结构化数据的理解，每一代模型都将错误率降低到产品如Google Home中的问答系统、Gmail中的智能回复以及Google Photos中的图像检索极其准确的程度。

与预测性分析不同，很少需要创建和训练模型来理解非结构化数据。相反，可以直接使用像Azure Vision API、Google Video Intelligence API和AWS Comprehend这样的预构建模型。使用这些API来丰富您的数据。例如，即使没有ML知识，开发人员也可以使用Google的NLP API提取评论的情感，并将情感作为附加列添加到您的DWH中。

如果这些预构建模型提供的标签不足以满足您的用例怎么办？也许图像识别API返回一个响应，指示图像包含一个螺丝，但您希望API返回一个值，即它是您目录中的Item #BD-342-AC。即使在这种情况下，也无需从头开始训练模型。AutoML模型（即用于问题领域（如图像识别）的标准ML模型，可以使用自定义数据进行训练）如来自Google Cloud、Azure、H2O.ai、DataRobot等的模型可以通过简单地在自己的数据上进行微调来定制。通常，每种类型的示例可能只需十几个。AutoML模型适用于图像、视频和自然语言。使用它们来获取适用于您问题的高质量定制API。

除了解释非结构化数据外，AI技术还存在用于生成此类数据的技术。被称为生成式AI（我们将在第10章进一步讨论）的技术可用于生成文本、图像、语音、音乐和视频。在这方面，也存在预构建（"基础"）模型，它们已经能够解决各种各样的问题（称为零样本学习）。这些模型可通过云供应商（Azure OpenAI、Vertex AI）和独立供应商（如OpenAI、Anthropic、Midjourney、Cohere等）的API获得。

在许多企业用例中，有必要将数据和ML平台与生成式AI模型集成以将模型"植根"于现实中。例如，可以通过传递一些示例（称为少样本学习）和制定适当的输入（称为提示）来自定义基础生成式AI模型的行为。这些示例可以从数据平台获取。像Hugging Face和LangChain这样的框架提供了特定问题的开源解决方案，比如基于企业文档的问答。这涉及从数据平台通过矢量相似性搜索检索适当的文档，并在ML平台上运行链。有时，这些解决方案在云上以全托管方式提供（例如Google Enterprise Search）。最后，可以针对特定任务微调这些基础模型（称为监督微调），云提供商通过其ML平台提供此功能。

个性化

与为所有用户提供完全相同的产品相比，机器学习提供了提供更为个性化体验的机会。客户分割、定向和产品推荐等问题属于个性化的范畴。

个性化是由客户的历史行为驱动的。例如，如果您是零售商，您可以基于其他人的行为（"购买此商品的用户还购买了..."）、基于用户自己的购买历史或基于商品相似性向用户推荐产品。所有这些信息都存在于您的企业数据仓库中（或至少可以存在）。因此，您可以使用存储引擎来支持推荐引擎。

事实上，Google BigQuery ML具有一个推荐模块，Google的推荐 AI 是基于 BigQuery 数据运行的。同样，Azure Machine Learning 中的推荐模块是基于 Azure Synapse 运行的。

在本节考虑的这三类 AI 中，很容易在几小时到几天内建立一个快速原型。这些模型都已存在；数据需求不繁重，您可以通过单击或单个 SQL 查询训练机器学习模型。

打包解决方案

除了在前面讨论的个别机器学习模型和技术之外，始终密切关注解决特定领域问题的打包解决方案，这些解决方案以即插即用的方式提供。

例如，通过自然语言进行交互的对话型人工智能能够准确处理常见的例行问题，比如了解商店的营业时间或请求餐厅预订。现在，对话式人工智能能够将建议的答案填充到呼叫中心支持代理的屏幕上，以回答客户的问题。这些解决方案可以轻松集成到企业的电话系统中。

像订单到现金、库存管理、货架缺货识别等解决方案已经准备好集成到您的业务中。毫无疑问，在您阅读本文时，将会有更多的打包和即插即用解决方案可用。我们鼓励您通过采用这些打包解决方案，跨越您当前技术堆栈实际可实现的局限性。

步骤 6：将以人工智能为驱动的工作流程投入运营

您数据平台战略的最后阶段是超越简单的预测和决策，实现端到端工作流程的自动化。您希望能够以完全自动和自治的方式解决业务问题。例如，您不仅希望预测机器何时会下次故障；您还希望在机器故障之前安排维护。实际上，您希望以最佳方式执行此操作，以降低运营成本、延长机器寿命并避免您的维修设施不堪重负。要实现所有这些，首先必须了解您在组织内希望实现的自动化水平（例如，完全自动还是仅提供协助？），然后需要专注于建立数据文化，为实现期望目标构建路径。最后但同样重要的是，需要强化数据科学团队，他们是实现您人工智能愿望的推动力。

确定自动化和辅助的正确平衡

根据我们的经验，许多组织在决策方面采用一次性的方式。如果它们采用数据驱动的方法并投资于使这些数据驱动的决策更加系统化，将会获得可观的回报。

这种系统化的自动化是打破信息孤岛、获取数据的综合视图和提供建议的逻辑终点，如图2-7所示。随着企业数据成熟度的提高，领导层需要鼓励企业从一个阶段迈向下一个阶段。

为了实现这种日益成熟，高管和员工都需要明确最终目标是什么。是决策的全自动化吗？是AI引导的决策制定吗？换句话说，人类是否完全不参与其中？还是他们在"掌握"整个过程？

例如，考虑一下谷歌地图和贵国空中交通管制系统生成导航指令的方式的差异。前者是人类不参与其中的例子，完全是自动化的。在空中交通管制的情况下，系统提供指导，但是是人类最终给予降落飞机最终的导航指令。当然，在这两种情况下，人类都会接收并执行导航指令。

自动化与协助的合适平衡通常是组织经过相当多的实验后确定的。它因行业而异，因组织而异。相对混合通常是同一行业中不同企业竞争的方式之一。因此，这通常是由产品管理主导的，而不是工程。

建立数据文化

组织将需要构建应用程序和系统，以实现最终目标，无论这个目标是全自动化还是为专家提供帮助。构建这样的系统将需要组织灌输一种数据文化。

仅仅建立一个分析型数据平台是不够的。同样需要改变组织的文化，使其变成一个以数据驱动的实验为常态，并且成功的实验能够被操作化和扩展的组织。 建立数据文化是解锁创新的关键，因为这将增强组织内的数据素养，传播读取和处理数据所需知识。仅仅因为你建立了一个能够打破数据孤岛的平台并不意味着它们就会消失。仅仅因为决策可以以数据驱动的方式进行并不意味着旧的启发式方法会轻易被抛弃。

成功的组织会进行一个转型计划，涉及向整个创意工作人员提供有关数据工具（如商业智能仪表板和嵌入式分析）的培训。他们试图改变员工被奖励的方式，以鼓励承担风险和创业精神。他们试图建立一种衡量业务中所有重要指标的方式。最后，他们致力于为他们的员工提供数据工具，以便他们能够推动变革。

填充你的数据科学团队

为了使你的组织从数据和人工智能投资中获得价值，你的数据平台需要启用几个角色：数据工程师、数据科学家、机器学习工程师、开发人员和领域专家。除非所有这些群体都在你的数据平台上积极合作，否则你不能说你已经建立了一个未来准备好的数据平台。

• 数据工程师：负责摄取、准备和转换数据。他们使用ETL工具将数据加载到数据仓库(DWH)中。他们监控数据管道，确保管道正常运行且不损坏数据源。
• 数据科学家：进行数据分析，帮助决策者了解业务的运行情况，回答假设问题，建模结果并创建创新模型。产品管理团队是此处的关键决策者。数据科学团队进行分析，帮助产品经理了解产品路线图上不同项目的投资回报率。例如，农业技术公司的数据科学家可能回答有关不同种子每英亩产量及其与土壤类型的关系的问题。他们可能回答假设问题，例如如果商店的产品组合更改为更多的某一种子而不是另一种子，预期的利润是多少。他们还可能对业务策略进行建模，例如创建个性化的收获计划，并将其分解为组件模型并构建它们。
• 机器学习工程师：将整个工作流封装到机器学习(Machine Learning, ML)管道中，并确保以可监视的方式执行。对模型进行常规运行监视，包括对韧性（模型是否正在运行？是否处理所有请求预测的用户？）和准确性（结果是否正确？）的监控。模型随时间漂移。这有时是因为环境本身发生变化（某种新型害虫开始影响某种类型的种子，因此其产量估计不再有效），有时是因为用户适应模型（农民开始根据相应种子品种的价格变化多种大豆而不是玉米，这改变了对某些类型的肥料的需求）。机器学习工程师寻找这种漂移并使用新数据对模型进行重新训练。这被称为MLOps。已部署的模型可作为API提供。开发人员调用模型，并在最终用户使用的应用程序中呈现其结果。
• 领域专家：也被称为业务分析师，利用预测性分析实现数据驱动的决策。数据科学家观察专家的决策，并探讨通过打破阻止这些数据被定期访问的数据孤岛来加速决策的方法。他们使用打包的人工智能解决方案来丰富数据，从而继续数据驱动的创新循环。

第7步：数据的产品管理

为了最大程度地发挥数据的作用，请应用产品管理原则。几年前，许多高管所说的"将数据视为产品"实际上意味着他们想要直接从数据中获利，比如在数据市场上出售数据。然而，如今这样的市场大多数包含由专门从多个来源聚合数据的公司创建的数据（例如，零售流量、信用卡交易记录、产品评论）。很少有公司成功地从他们的第一方数据中获利。

那么，当今一家典型企业希望将数据视为产品时，这意味着什么呢？

将产品管理原则应用于数据

我们更倾向于将期望的结果与实现这一目标的过程结合起来。期望的结果是，通过将数据视为产品，您的组织将最大限度地发挥数据的作用，而以上定义中突出的特征（有用性、标准化、治理）对此至关重要。我们对数据产品有一个广义的看法，数据集当然属于其中，但数据管道、仪表板、依赖数据的应用程序和机器学习模型也同样在范围之内。

期望的结果只有在有达到这一目标的路径时才有价值。为了将数据视为产品，在构思和构建数据产品时应用产品管理原则。什么是产品管理原则呢？（1）制定产品战略，（2）以客户为中心，（3）进行轻量级的产品发现，以及（4）专注于找到市场适应性。我们建议采用与这些原则一致的10个数据实践（参见图2-8）。

1.了解并维护企业数据流的映射

产品经理的一个关键职责是简化。将数据视为产品意味着数据产品团队维护着业务中数据流的高层模型，以便轻松进行可发现性的沟通。您需要在多个粒度级别维护这个映射。

以电商网站为例，最高级别可能是：

• 网站流量
• 产品目录
• 网站内容
• 订单
• 库存
• 客户调查

在更详细的粒度级别，网站流量可能被细分为会话数据、页面数据等。捕捉每个数据集的收集方式、处理方式、哪些角色可以访问以及如何访问、是否包含个人身份信息（PII）或其他属性、所做的质量保证等信息。还要捕捉每个数据集的生产用例。随着粒度从较高级别逐渐降低，映射开始包含数据平台实现的细节，逐渐成为数据目录。

2.确定关键指标

一个数据目录仅仅是当前存在的记录。它并没有说明数据的重要性，或者数据是否符合目标（除非您利用临时标签来完成）。它不告诉您需要改进的内容。您的数据产品战略的重要部分是在企业内就关键指标达成一致------您将测量什么，如何测量以及指标的目标数值是多少（目标会随时间而变化）。您跟踪的指标范围应包括：

• 业务关键绩效指标

  • 数据需要支持哪些业务结果？

• SLA（服务水平协议）

  • 数据的可用性如何？数据质量如何？刷新频率如何？

• 使用情况

  • 数据在公司内部被广泛使用的频率是多少？

• 满意度

  • 客户（可能是内部客户）对可用数据及其易用性的满意程度如何？

对于前面介绍的假想的电商网站，业务结果可能涉及增加客户生命周期价值，提高免费套餐的转化率等。对于显示给内部采购人员（用于补货）的库存，SLA可能是它在99.99%的时间内可用，每小时刷新一次，并且保持在下周预测销售量的上方。您可能希望库存预测不仅被内部采购使用，还被物流团队使用，并被整合到仪表板中。您可能还有一个衡量预测库存量被多少次覆盖的指标。

3.同意的标准、承诺的路线图和有远见的待办事项

数据目录是当前存在的记录。度量标准捕捉你的目标是什么。然而，这两者都没有解释接下来的发展方向。

根据客户反馈、利益相关方意见和市场状况，随时间调整产品愿景是重要的。在此过程中，利益相关方会要求你提供功能和时间表，并期望你信守承诺。为了应对变化和用户反馈，你需要三样东西：

1. 优先级标准： 利益相关方事先同意的优先级标准，这有助于在产品路线图上实现透明度和全组织的认同。
2. 产品路线图： 由产品发现过程提供支持的产品路线图，以便团队能够在没有信息和原型的情况下同意时间表。
3. 待办事项清单： 认为重要但尚未在路线图上的事项将被记录在产品待办事项清单中。通常，产品待办事项清单包括需要解决的客户问题（而不是需要构建的功能）。在很多方面，待办事项清单（而不是路线图）构成了你的长期产品愿景。组织待办事项清单以讲述一个清晰的故事。

路线图需要具有高度的承诺度，你应该能够对路线图上的时间表和功能做出承诺。一个很好的方法是就优先级标准达成共识，进行产品发现，并维护一个产品待办事项清单。

回顾我们的一个假设性数据产品（参见前一步）是未来一周的库存预测，我们需要达成一致意见，以衡量预测的好坏。是很少出现缺货吗？是最小化采购和存储物品的成本吗？是在仓库级别发生缺货？还是在公司级别？这些形成了优先级标准。如果有人要求你定制易腐食品的库存模型，是否值得做？你最初会将其添加到产品待办事项清单中。然后，你将进行产品发现，以确定执行这个项目的投资回报率 - 这将包括增加/减少仓库冷藏的成本，例如。只有在了解价值后，你才会将其添加到产品路线图上。

4.面向你拥有的客户构建产品

往往，数据团队会陷入技术口号的泥淖：他们只提供API，或坚持让每个人将数据发布到他们的企业数据仓库，或期望符合一个统一的词典。

向产品管理学习，深入了解你的客户是谁。他们在构建什么？一个移动应用程序还是一个月度报告？他们了解什么？SQL 还是 Java？他们使用什么工具？仪表板还是 TensorFlow？他们是否需要在数据更改时收到警报？他们是否需要实时数据的移动平均值？他们是否关心测试覆盖率？

然后，以目标客户能够使用的方式提供数据。例如，你可以将数据提供给数据仓库（供数据分析师使用），通过API使其可访问（供开发人员使用），将其发布到特征存储中（供数据科学家使用），或在仪表板中可用的语义层（供业务用户使用）。

例如，我们作为示例使用的假设性库存预测数据产品，如果将被内部采购员（业务用户）利用，那么预测结果将需要在用于订购补给的应用程序中提供。因此，这些预测结果可能需要通过API提供给应用程序开发人员使用。

5.不要转嫁变更管理的负担

变化和冲突是不可避免的。数据的供应商会更改格式；数据的使用者会有新的需求；数据的速度会发生变化；相同的数据可能会通过多个渠道提供；由于成本原因，您的客户可能会转向另一家供应商。这些问题不仅仅是进行更改的团队或使用数据的团队的问题。

将数据视为产品的重要部分是确保数据的用户不必负担变更管理的责任。尽量确保演进模式和服务，使变更对下游用户透明。

当不可向后兼容的更改不可避免地发生时，对更改进行版本化，并与利益相关方合作，将它们从旧版本的数据移动到新版本。这可能涉及创建一个迁移团队，其任务是将企业从一个版本迁移到下一个版本。

变更管理的原则也适用于安全性。确保为个人身份信息（PII）和合规性建立保护措施，而不是将负担转嫁给数据产品的用户。

假设我们的假设性库存预测数据产品被定制以包括易腐食品的预测。如果这涉及请求有关所售物品的额外信息，则必须负责确保所有现有物品的物品目录得到增强。这项数据工程工作是项目范围的一部分，它影响是否值得进行这项工作的投资回报率。

6.面试客户以发现他们的数据需求

你如何发展产品待办事项、确定需求的优先级并添加到路线图上？一个重要的纪律是确保你不断地与客户交流，发现他们在解决遇到的问题时需要什么样的数据。他们是如何绕过当前数据产品的不足之处的？这些问题会进入你的产品待办事项清单，供你优先考虑和解决。

在任何新的数据产品想法进入产品路线图之前，重要的是已经通过潜在的（内部或外部）客户对产品的需求进行了验证。按照规格构建（"构建它，他们会来"）是非常危险的。更安全的做法是构建已经通过与客户验证的想法的实现。你如何做到这一点呢？

7.广泛使用白板和原型制作

与需要该数据产品的客户一起使用白板设计。这确保了在数据平台上实现的内容能够满足他们在质量、完整性、延迟等方面的需求。在构建任何数据流或转换之前，与他们一起讨论数据的潜在用途。

在这里，其中一个最好的工具是原型。通过构建一个最小可行原型，可以验证数据的许多用例。我们是什么意思呢？如果销售团队认为构建一个客户数据平台将帮助他们实现产品交叉销售，可以通过手动匹配个别产品销售渠道的一组记录，尝试交叉销售生成的客户来验证这一点。

我们建议使用原型以及与最终产品的潜在用户进行的面试来界定问题，包括：

• 需要构建什么：确定项目成功所需的一切，从数据流到用户界面
• 预期的业务关键绩效指标（KPI）方面的预期投资回报率

在编写任何代码之前执行此操作。只有当你清楚知道需要构建什么以及预期的投资回报率时，你才应该将项目添加到路线图上。在那之前，将问题保留在待办事项清单中。

对于我们假设的库存预测数据产品的情况，您将与主要产品用户一起验证输入模式以及如何使用预测，并检查仓库可以容纳多少更多的冷藏设施等等。在编写任何代码之前，您将执行此操作，可能通过在电子表格中进行预测并对各种产品的整套情景进行游戏化。

8.只构建立即使用的内容

优先快速投产而不是构建所有必要的功能。这意味着你应该使用敏捷、迭代的过程，仅构建当前需要的数据集、数据管道、分析等。不要专注于开发太多没有显著影响的功能：你付出的努力可能得不偿失。使用产品待办事项清单记录未来需求。只有在确定将使用这些功能的客户并能在白板/原型会话中给出反馈后，才构建这些功能。

9.规范化常见实体和关键绩效指标（KPIs）

为业务中的常见实体和关键绩效指标（KPIs）提供规范化、丰富的数据集。通常，这些丰富的实体支持大量高回报投资的用例（例如，客户数据平台、内容管理平台），或者是出于监管/合规目的所需的（例如，计算税收的方式）。

通常，你只会有少数几个这样的标准化数据集和指标，因为这样的丰富需要跨业务单位的广泛协作，并降低了它们的发布速度。

10.在你的数据平台中提供自助服务功能

在组织中找到适合的方式来平衡灵活性和标准化。不要过分追求前一步（标准化）。不要构建拥有任何人可能需要的所有内容的中心化数据集。相反，要使团队能够自给自足。这是将微服务原则应用于数据的方法。

实现这种平衡的一种方式是提供小型的、自包含的数据集，客户可以通过与其他数据集以特定领域的方式连接来进行定制。通常，这被实现为数据网格，每个业务单元负责其发布到共享分析中心的数据集的质量。

总结

在本章中，您了解了组织应该采取的创新数据过程的更多信息。本章的主要要点如下：

通过确定关键业务目标、聚集合适的利益相关方并在整个企业中建立变革管理，创建战略计划。确保您的利益相关方集合中包括那些如果采用数据平台将最受益的业务单元。

通过转向云来降低总体拥有成本。在这样做时，不要试图复制您在本地所做的技术选择。相反，选择能够自动缩放、分离计算和存储、支持 NoOps 并允许您支持各种应用程序而无需数据移动的技术。

打破数据孤岛，以便将整个组织的数据连接在一起。确保每个部门都控制其数据并对其质量负责是很重要的。然而，所有数据都应该在统一平台上可用，以实现跨组织访问。

通过将数据实时流入数据仓库并确保数据访问始终反映最新数据，以更快地在上下文中做出决策。在相关的情况下，数据表应该包括上下文元数据，如位置信息。

利用可定制和适应性的 AI 模型，这样您就不必构建定制的 AI 模型。这些模型有助于无论您的需求是预测分析、理解非结构化数据还是个性化，都可以从您的数据平台推动。预测分析和个性化可以由数据平台驱动。非结构化数据可以通过使用预建的 AI 模型处理它并将其添加到数据平台中。

将重点从一次性 ML 模型扩展到自动化整个工作流。这一步通常由产品管理领导，此处的分析通常会为产品路线图提供信息。

通过聘用和配备由数据工程师、数据科学家、ML 工程师、开发人员和业务分析师组成的团队，建立创新文化。

使用产品管理原则制定您的数据产品战略：以客户为中心，通过白板和原型发现产品，并在标准化和灵活性之间找到正确的平衡。

在本章中，我们讨论了如何构建创新的数据组织的策略。在下一章中，我们将关注设计数据分析平台时必须考虑的关键方面：现有员工目前具备或将需要掌握的技能。