最简单来说，数据网格就是一个由互相作用的数据产品组成的生态系统，如图2-1所示。和任何生态系统一样，数据网格中有许多独立运行的部分，它们通过共同的标准和通信骨干相互连接。理想情况下，数据网格中的数据产品具有统一的技术实现，并提供一致的一套接口。
数据网格的基础是一个概念框架，属于数据架构领域，强调去中心化的数据所有权和架构。它认识到在大型组织中，数据是庞大且多样的，每个业务领域对其自身数据具有很大的自主权（同时也拥有对其数据的本地知识和掌控力）。通过分散控制，数据网格赋予各个领域管理和决策其数据的权力，同时保持整体结构的一致性。这种自主权带来了更好、更本地化、更快速的决策，从而提升了速度和敏捷性。
在数据网格的背景下，数据产品是一个自包含、自描述并面向特定业务目的或功能的数据包。数据产品是根据组织内特定业务目标精心设计的数据包。它们不仅仅是数据的集合，而是包含数据本身以及必要的工具、文档和元数据的完整单元。这确保了数据不仅存在，而且是可理解和可用的。每个数据产品都是面向特定目的的，专为服务于某一业务需求或解决特定问题而定制，使它们远远超出单纯的信息存储库的范畴。
数据产品的结构是自包含的，意味着它包括有效利用所需的一切。它遵循严格的质量和治理标准，从而确保了可靠性、安全性以及与相关法规的合规性。这种全面的方法使得数据产品在组织内部成为值得信赖和依赖的资源。数据产品的设计考虑了用户的可访问性，提供了易于导航的接口和文档，适用于从数据专家到技术背景较少的用户。
此外，每个数据产品的生命周期都经过精心管理。每个数据产品都有指定的负责人，负责其维护、更新和整体管理。这种责任制确保了数据产品随着时间的推移保持相关性并持续提供价值。对这些数据产品的持续监督和改进是它们不断发展的基础，确保它们与组织的动态需求和目标保持一致。这种生命周期管理是数据产品的关键方面，区别于静态数据集，使其成为数据网格生态系统中的不断演变的资产。
关于数据网格生态系统，我们将在第4章详细讨论更多内容。
数据网格原则
如我们在第1章提到的，数据网格的核心是一系列指导原则，这些原则在框架的效能和可持续性中起着至关重要的作用。让我们在这里更详细地探讨它们。
数据即产品
这些原则中的第一条是将数据视为产品。在传统的产品管理中，产品满足某种需求，拥有一个负责人（这一点我们稍后会详细讨论），并且有一个长期的路线图（与有明确开始和结束时间的项目不同）。所有这些特征同样适用于数据产品。
这些特征为每个数据产品建立了清晰的边界。这种边界划分定义了一个领域，对于定义数据产品的含义、范围及其局限性至关重要。数据网格中的明确边界确保每个数据产品在更大的生态系统中都是一个定义清晰的实体。这种明确性使得人们清楚地理解数据产品的用途，有助于管理期望，并恰当地引导精力和资源，确保每个数据产品能够有效地履行其预定角色。
然而，这不仅仅是这些。Zhamak Dehghani 在她的书《数据网格》中描述了数据产品的特性，认为它们应当是可发现的、可定位的、易于理解的、值得信赖且真实的、可本地访问的、可互操作的和可组合的、自身有价值的且安全的。我们将在后续章节中更多讨论这些具体属性。
去中心化的领域所有权
数据网格框架中的另一个基本原则是去中心化的领域所有权，它为每个数据产品确立了一个授权的所有者（及其团队）。这一框架借鉴了“每个街区都有一个专职管理员”的理念，这个人对该区域的福祉高度负责。同样，在数据网格中，每个数据产品都有一个所有者，负责其性能、质量及其是否符合治理标准。
授权的数据产品负责人（DPO）的角色是多方面的。DPO 需要确保数据产品既符合具体的业务需求，也符合整体的治理框架。这种对齐对保持数据产品的完整性和有用性至关重要，确保它在组织的数据环境中始终是有价值的资产。
自助数据平台
第三个核心原则是为消费者和生产者提供自助服务能力。
对于数据消费者来说，“自助服务”意味着他们可以轻松找到、使用并信任数据，且无需第三方（或中央团队或工程组）的协助。这通常通过一个“市场”实现，该市场提供一个门户（网站/移动站点），将各种数据产品分组，供消费者使用。
现在，简要谈一下市场的概念：与数据目录相比，市场的独特之处在于它同时提供消费者和生产者功能。通常称之为“双边市场”，它不仅让消费者轻松找到数据，还让数据生产者能够轻松发布数据。从这个意义上说，市场的生产者功能也是自助式的。数据网格应使任何人（在遵守正常安全规定的前提下）都能轻松发布数据产品。
数据网格中的自助服务能力不仅赋予用户更多权力，还促进了创新和敏捷文化。它使个体能够根据自己的需求灵活使用数据，鼓励实验和个性化分析。这种能力减少了集中式数据系统中常见的瓶颈，在这种系统中，数据访问和分析的请求可能会减缓决策过程。
联邦计算治理
数据网格框架的最后一个指导原则是联邦计算治理，它指的是一种去中心化的方法，用于在组织内不同领域或团队之间管理和执行数据政策、标准和质量控制。
与其由一个中央数据治理团队制定规则和标准，联邦治理将这些责任分配给领域特定的团队。每个团队管理自己的数据，同时遵守组织层面设定的整体原则。联邦计算治理确保尽管数据所有权是去中心化的，仍有一个统一的框架来管理数据的使用和共享。
目前可以说，数据网格在改进数据治理方面的机会还处于初期阶段。因此，实施联邦计算治理需要找到一种微妙的平衡。它需要创建既能确保一致性和合规性，又足够灵活以适应不同数据产品的独特需求和背景的治理结构。这种平衡对于营造一个创新能够蓬勃发展的环境至关重要，同时又不会妥协于维护一个一致的数据生态系统所需的标准和协议。
定义“优质”数据产品
如前所述，数据网格是由数据产品组成的生态系统。从实际角度来看，数据产品是其基础构建块，实际上是数据网格中最小且不可分割的单位，可以视为一种“数据量子”。显然，数据产品至关重要，但“优质”数据产品的定义是什么呢？一个“优质”数据产品由许多属性组成，这些属性涵盖了技术、业务、易用性等多个方面，如图2-2所示。
定义合乎原则的数据产品
从哪里开始呢？让我们从一个简单且明显的声明开始：优质的数据产品应遵循数据网格的原则。让我们来看这些原则，并将它们应用于数据产品。
首先，优质的数据产品应符合去中心化领域所有权：它们应与一个领域（无论大小）保持一致，具有明确的边界，并有一个授权的所有者。其次，优质的数据产品应像其名字所暗示的那样——被视为产品而不是项目。与其他产品一样，优质的数据产品具有生命周期、明确的消费者和明确的价值主张。优质的数据产品是自助服务的，意味着用户无需过多依赖第三方就能获得所需数据。优质的数据产品拥有联邦治理机制，允许数据产品负责人（DPO）及其团队在数据产品层面拥有本地自主权和决策权。这也意味着DPO及其团队需负责确保其数据产品在必要时符合企业的指南和标准。
定义FAIR数据产品
优质的数据产品还应遵循FAIR原则，即数据应该是：
- Findable（可发现的）
- Accessible（可访问的）
- Interoperable（可互操作的）
- Reusable（可重用的）
根据FAIR原则，“这些原则强调机器可操作性（即计算系统能够在无需或极少人工干预的情况下找到、访问、互操作和重用数据的能力），因为随着数据量、复杂性和生成速度的增加，人类越来越依赖计算支持来处理数据。”
让我们进一步阐述这些原则并将其应用于数据产品。FAIR原则中的第一条是可发现性。要使数据产品有价值，它必须在组织的广泛数据环境中易于发现。
可访问性是另一个关键原则（这里我们使用的“可访问性”是指容易消费，而不是特定用户的可访问需求）。仅仅能够找到数据是不够的：一旦找到，数据产品也必须易于访问。可访问性包括提供详细的文档，解释如何使用数据，并确保数据能轻松集成到各种应用程序和工作流中。一个好的数据产品应像一个设计良好的软件应用一样易于使用，具有清晰的说明和支持。
互操作性是FAIR原则中的一个关键方面。它指的是数据产品能够一起工作并有效集成的能力。在实践中，这意味着数据产品应使用标准的数据格式和协议创建。例如，如果一个数据产品使用XML格式而另一个使用JSON格式，应该有工具或服务来使这些不同格式能够无缝协作。同样，互操作性还可能意味着使用通用标准（例如SQL或RESTful API）或通用标识符。互操作性对于结合和利用来自各种来源的数据至关重要。
第四个原则，重用性，侧重于数据能够在多个上下文中应用的能力。这一原则对于最大化数据的价值尤为重要。设计为模块化和可重用的数据产品可以在不同的项目和应用中使用。例如，包含客户人口统计信息的数据产品可以被市场团队用于活动策划，销售团队用于销售策略开发，产品开发团队用于市场分析。
除了这些技术方面，遵循FAIR原则还需要培养协作和数据共享的文化。这种文化转变对于打破数据孤岛并鼓励数据产品的重用至关重要。这意味着要在组织中推广一种将数据视为共享资源的心态，以便用于多种目的。
总之，数据网格中的“优质”数据产品应遵循FAIR原则：可发现、可访问、可互操作和可重用。这些原则确保数据不仅被存储，还能够被积极管理和使用，为组织带来价值。遵循FAIR原则的数据产品不仅是信息存储库，更是推动企业创新和决策的动态资产。
定义企业级数据产品
FAIR原则为理解“优质”数据产品提供了一个视角。那么，什么使数据产品在企业中是“优质”的呢？更具体地说，什么定义了“优质”的企业级数据产品？在企业级数据产品领域，有几个关键属性共同定义了其质量和效能。这些属性包括安全性、可靠性、可观测性、可操作性、可部署性和完整的文档，它们形成了一个连贯的结构，确保数据产品在组织中的价值。
实际上，企业级数据产品的强大之处在于其关键属性的无缝整合。安全性、可靠性、可观测性、可操作性、可部署性和完整的文档并非孤立的方面；它们是相互关联的，每个都在产品的整体功能和价值中扮演着重要角色。满足这些要求的数据产品不仅是数据的存储库，而是推动业务效率、创新和决策的动态资产。理解这些属性如何相互作用并相互支持，对于创建符合企业环境严格要求的数据产品至关重要。
安全性可能是这些企业级属性中的首要因素。企业级数据产品必须防范未经授权的访问和数据泄露，确保其持有数据的机密性和完整性。安全不仅仅是保护信息，还关乎维护用户信任和遵守如GDPR或HIPAA等法规标准。实施强有力的加密、访问控制和定期的安全审计是这一过程的核心，为潜在的网络威胁创建一个坚固的防线。
然而，单靠安全性是不够的。数据产品的可靠性同样重要。用户需要相信数据产品能够随时提供准确、一致的信息。确保可靠性涉及实施验证检查、错误检测算法以及保持高数据可用性。这里，可靠性和安全性交织在一起：一个安全的数据产品自然更可靠，因为它能够防止数据篡改和丢失。
可观测性扩展了可靠性的概念。它指的是能够监控数据产品的健康状况和性能。通过使用工具来跟踪响应时间和错误率等指标，组织可以主动管理数据产品的健康或数据质量。这种主动管理对于维持产品的可靠性至关重要，因为它允许在问题升级之前及早识别和解决潜在问题。
可操作性与可观测性密切相关。一个可操作性强的数据产品更易于管理和操作。这包括简化数据产品生命周期管理的功能，包括部署、扩展、更新和故障排除。高可操作性通过确保产品在其生命周期内始终保持功能和有效性，支持产品的可靠性，能够在变化的需求中保持最小的干扰。
可部署性是另一个关键属性，特别是在动态的业务环境中。一个高度可部署的数据产品能够轻松实施并集成到各种业务流程和技术环境中。这种灵活性对于跟上业务不断发展的需求至关重要，无论是扩展以适应增长还是与新系统和应用集成。
所有这些属性的基础是完整的文档。文档是数据产品的支柱，提供了关于其使用、管理和集成的清晰说明。文档包括从用户指南和API文档到操作程序和架构图的所有内容。优质的文档不仅有助于有效利用数据产品，还确保合规性，便于审计和合规检查。
这些属性的相互作用创造了一个整体的企业级数据产品。例如，完善的文档通过详细说明数据处理流程提升了安全性，而可观测性通过识别预测性维护需求来支持可靠性。同样，易于操作性往往由结构良好的文档所促进，提供了管理和更新数据产品的清晰指南。
定义有价值的数据产品
俗话说，"美在旁观者眼中"。然而，我们可以使用一些客观特征来明确且无歧义地界定数据产品的价值。首先，有价值的数据产品基本上是通过其相关性和实用性定义的。此类产品的主要目的是解决特定的业务需求或问题，成为做出明智决策和生成洞察的关键工具。其价值直接与解决现实业务问题或提高运营效率的实际应用相关。因此，数据产品的实用性通过其促进行动、支持决策或提供直接适用于用户需求的洞察能力来衡量。
质量和可靠性是有价值的数据产品不可或缺的属性。这些属性不仅包括数据的准确性、一致性和完整性，还包括其及时性和与当前业务场景的相关性。此外，可靠性还延伸到数据产品的技术性能方面，如处理速度和可用性。确保高质量和可靠性至关重要，因为这些因素直接影响数据产品在运营和决策过程中的可信度和依赖性。
可用性是决定数据产品价值的关键因素：如果产品复杂或不直观，其潜在的实用性将大打折扣，无论其数据质量多么优越。因此，数据产品的设计和界面应确保易于使用，以便其目标用户能够有效利用它。与此相关的是互操作性，换句话说，从操作角度来看，数据产品也是可用的。有价值的数据产品不仅应能单独运行，还应能无缝地与其他数据产品集成。互操作性对于综合分析和生成洞察至关重要，因为它允许跨不同领域结合和分析数据。此外，遵守法规要求和安全标准是不可协商的。确保数据隐私、遵守如GDPR或HIPAA等法规，并保持强有力的安全协议，对于数据产品的完整性和价值至关重要。
最后，扩展性和可维护性是有价值的数据产品的关键方面。它应能够处理不断增长的数据量或用户需求，而无需进行重大重设计或重新工作。除了扩展性之外，可维护性——即数据产品能够轻松更新、修改或修复的能力——对于其长期实用性至关重要。这包括产品根据用户反馈和不断变化的业务需求进行演变的能力，确保它随着时间推移仍然保持相关性和价值。与组织的战略目标保持一致，并通过成本降低、收入增长或风险管理为业务目标做出贡献，进一步巩固了数据产品在组织生态系统中的价值。
定义平衡的数据产品
传统上，IT组织——尤其是那些高度集中的组织——往往倾向于优化成本控制。当IT与业务结果没有紧密关联时，成本控制——即注重效率——是常见的做法。这种做法虽然在财务上明智，但常常与企业日益增长的对速度和敏捷性的需求发生冲突，而速度和敏捷性在当今快速变化的市场环境中变得至关重要。有价值的数据产品的一个关键属性就是在成本和效率与速度和敏捷性之间实现平衡。
然而，转变视角会揭示出一种有趣的动态。事实上，经验表明，优先考虑速度和敏捷性并不一定会牺牲成本效益，专注于这些方面实际上能够实现更高效的产品交付，进而在长远上带来成本节约。这种效率来自于快速适应市场变化、客户需求和新技术进步的能力，从而减少了在冗长项目周期上花费的时间和资源。
这意味着一种涉及增量开发的方法，即将数据产品或其组成能力分解为较小的、可管理的交付单元。这允许根据反馈和变化的需求进行快速迭代和适应。原型和最小可行产品（MVPs）的使用是这种方法的核心，它使团队能够在不投入大量资源进行全面开发的情况下测试想法和概念。显然，对于新接触数据网格的组织来说，这种方法值得考虑。
增量方法有几个好处。首先，它允许更快地响应市场需求和客户反馈，因为可以在较短的周期内实施和测试更改。其次，它降低了与较大数据产品相关的风险，因为可以在过程中进行调整，避免完全承诺于单一、僵化的交付计划所带来的高昂代价。
定义现代数据产品——不仅仅是“常规”数据
数据网格中的数据产品通常被认为仅围绕“传统”数据展开，如数据库、表格等。然而，这种观点在某种程度上是有限的，甚至是过时的。虽然此类数据确实是基础元素，但数据产品包含的内容远不止如此。
在此背景下，数据产品的“工件”是指DPO决定向数据产品的用户或更广泛的受众提供的任何对象、实体或项目，如图2-3所示。
这些工件是数据产品的“内部构成”，可能包括：
- “常规”数据，如数据库、表或文件。我们称其为“常规”数据，因为这是目前数据产品中最常见的工件类型。数据产品可能仍然会优先整合和管理传统的数据形式，如数据库、表和文件，因为这些结构化数据类型是大多数分析和操作过程的基础。
- 图像、视频和音频，这些数据形式在我们现代的多模态数据环境中变得越来越普遍。这些数据形式提供了丰富的上下文信息，能够显著增强分析、机器学习模型和决策过程。随着组织旨在获取更全面的洞察，能够无缝处理和分析结构化和非结构化数据（如视觉内容）的能力变得越来越关键。
- 文档，如PDF或其他以文本为主的非结构化数据。
- 指南，帮助消费者理解或使用数据产品。不言而喻，清晰且全面的文档可以帮助用户有效地利用每个工件。当然，这些文档应易于访问和理解，满足不同技术水平用户的需求。
- 模型，包括旧的AI/ML模型以及新的生成式AI大型语言模型。在许多现代数据产品中，数据用于训练或微调机器学习或AI模型。这些模型作为工件提供消费时，可以为数据产品中的数据提供独特的洞察。
- 经过审核的查询（安全、高效等），简化了数据产品的使用。这些查询可以包括预先编写的SQL查询或其他访问方法，提供给用户现成的洞察。对于技术背景较少但需要从数据产品中获取有意义信息的用户来说，这些查询尤为有价值。
- 流数据，代表数据产品的动态方面，用户可以订阅数据产品中的特定主题，当数据发生变化或更新时收到通知。
- 报告，提供来自数据产品的预格式化输出。
- 笔记本和程序，展示如何有效利用数据产品中的数据，或展示数据产品中的处理逻辑。这些程序可能包含“入门套件”，帮助数据产品用户了解如何与数据交互并从中获取价值。这些程序可能展示从数据中得出的关键洞察，帮助用户在探索时抢占先机。
- 元数据，即关于数据产品、其内容、字段和格式的数据。
- 转换，包括管道和其他工作流工具，将数据导入并转化为适合消费者使用的形式。
选择哪些工件包含在数据产品中是一个重要的决策。这反映了数据产品负责人（DPO）对目标受众需求和偏好的理解。通过仔细策划这些工件，所有者可以显著提高数据产品的可用性和吸引力。这通常需要对工件的技术方面以及用户在数据产品中的旅程有深刻的理解。
那么，什么是现代数据产品？它不仅仅局限于“常规”数据，还认识到不断变化的数据格局和我们生活中的多模态数据世界。现代数据产品包含了一整套数据和工具，使复杂的数据洞察成为可能，包括AI模型、笔记本或程序。它展示了数据管理从静态存储向动态、交互式平台的演变，赋予用户从数据中获取更大价值和洞察的能力。
定义实用的数据产品生命周期
当你考虑一个产品时，你实际上也在考虑它的生命周期。想想你的汽车（如果你没有汽车，你可能认识某个有车的人）。汽车制造商需要一些时间来设计、开发和测试它，直到你购买它。当某个型号在售时，制造商会继续开发它的新版本。一个很好的例子是丰田凯美瑞，它于1979年作为Celica Camry推出，至今已有超过45年的历史。让我们在接下来的例子中以凯美瑞为例。
在传统数据工程中，通常由一个集中团队负责构建数据集。该团队交付数据集后，可能继续支持它，或者将其移交给运营团队，直到它被淘汰，如图2-4所示。实际上，大多数数据项目看起来都是这样的：在开发期之后，项目进入生产并持续运行，直到被淘汰。淘汰通常是不可能的，因为没有替代数据集。回想我们的凯美瑞，就像我们仍在驾驶1990年代的汽车一样。
如果构建了一个新的数据集来替代第一个版本，过渡通常会非常困难。如果没有足够的时间来推动过渡，消费团队将面临巨大的负担，如图2-5所示，其中数据集从版本1演变到版本2。这个过渡可能非常困难，尤其是出现破坏性变更时。
为了缓解两个数据集版本之间的过渡，团队可以在过渡期间提供支持或逐步淘汰期，在此期间两个数据集可以同时使用。如图2-6所示，数据集正在从版本1演变到版本2。
这些设计非常适合有中央团队的组织。在交付数据集之后，开发团队可能会切换到另一个项目。其缺点在于，这并不能保证处理v2的团队与处理v1的团队相同，因此无法利用在v1项目期间积累的专业知识。
想象一下，你可以通过迭代改进产品，并逐步交付增量价值，而不是一次性的大幅度变化。回到凯美瑞的例子，2014年和2015年款之间的变化是渐进的，并非重大改款（如2016年和2017年款之间的变化）。使用语义版本控制，2014年款凯美瑞可以是v50.14.0，2015年款则是v50.15.0；而2017年款则为v70.0.0，表示一次重大改变。
如图2-7所示，这种方法并不排除需要进行重大（且破坏性的）更改。但你仍然可以让开发团队专注于任务，逐步积累领域专业知识。开发团队不需要特别庞大，但更重要的是，你可以从持续的专注、不断积累的领域专业知识以及为消费者提供的一致体验中受益。这个过程与所有现代（敏捷）软件开发策略高度一致。
随着你构建和扩展数据集，它们会保持与同一领域的对齐，提供类似的用户体验，如图2-8所示。再次强调，数据契约（将在第5章详细说明）将为你公开的数据集提供大量信息。
定义实用的数据网格路线图
我们已经解释了数据产品的技术方面——它们遵循数据网格和FAIR原则，并具备被认为是企业级的属性。数据产品应具备价值、平衡性，并能适应不断演变的数据格局。但它们还必须具有实用性：不仅需要策略和愿景，还需要路线图和实施计划。它们需要支持和资金，否则数据产品甚至无法启动。它们还需要一支与数据产品的技术和数据足迹相匹配的专业团队，团队的运营方式和与组织其他部分的协作必须成为数据产品团队运作的核心。
首先，让我们将数据产品的策略和愿景转化为实用的路线图。数据产品的策略和愿景应当雄心勃勃但可实现，需在有抱负的目标和实际可行性之间找到平衡。目标状态应当挑战现状，但仍需基于当前技术能力和组织背景所能切实实现的范围内。实用的数据产品应有一个明确的目标状态或最终目标，并与其预期为组织带来的贡献保持一致。这部分内容将在后续章节中深入讨论。
与目标状态密切相关的是需要一条路线图：如图2-9所示，这条路线图是通往目标状态的路径。
路线图是一个详细说明从当前数据产品状态到期望未来状态的发展计划，涵盖技术（“技术流”）、流程（“工厂流”）、资源和运营模型（“运营模型流”）以及沟通计划（“社交化流”），当然，还包括时间表。这显然是一个大主题，更多的细节将在第16章中提供。
接下来，让我们讨论支持和资金。来自高层管理者的高度参与至关重要，他们必须认识到数据产品的长期性，这就是我们所说的支持者的作用。支持者通常是组织内的高层管理人员或决策者，他们为数据产品提供支持。他们的支持对于将数据产品与组织的更广泛目标和战略保持一致至关重要。支持者的角色不仅仅是背书。他们在克服组织障碍和在各个部门推广数据产品方面起着关键作用。他们的影响力对于确保组织内不同利益相关者的认同至关重要，从而确保数据产品能够被有效整合和利用。
拥有具有足够影响力的支持者对于确保数据产品不会被边缘化或淹没在其他组织优先事项中至关重要。支持者的角色不仅仅在于确保资金，还包括在数据产品的开发和部署过程中提供持续的支持。通常，随着支持者的加入，还会带来一个可持续的资金机制，以及创建和运营可行且实用的数据产品所需的激励机制。这在我们的运营模型章节（第15章）中也有讨论。
“优质”数据产品应有一个有权力的数据产品负责人（DPO）
一个有权力的DPO对数据产品的成功和效力至关重要。虽然这并不是有价值数据产品的一个具体属性，但却是交付有价值数据产品的必要条件。实际上，DPO负责决定什么被视为有价值。他们决定成本/效率与速度/敏捷性之间的平衡。他们的本地自主权是其决策权力的基础，使其能够影响和引导数据产品从构想到生产的全过程。显而易见：没有一个有权力的DPO，数据产品就无法生存。
尽管这一内容在第14章中有广泛讨论，这里仍值得更深入探讨。DPO承担着重大的责任和权力，监督数据产品的开发、整体健康状况、性能以及数据产品与业务需求的战略一致性。DPO的角色是多方面的，涵盖了数据产品管理的各个方面，从概念化到实施以及持续的维护。
问责制是DPO角色的一个关键方面。他们要对数据产品产生的结果负责。这意味着要确保产品满足所有质量和合规标准，并交付预期的结果。DPO的问责范围包括所有利益相关者，包括技术团队、业务用户和高层管理人员，要求他们保持透明并对产品的进展和性能进行公开沟通。
DPO被赋予的关键权力之一是决策权。他们拥有就数据产品的开发、部署和演变做出关键决策的权力。这包括对功能、特性以及产品整体方向的决策。这种决策权对于在快速变化的商业环境中保持产品的相关性和有效性至关重要。
通过这些决策权，一个有权力的DPO具有高度的自主权。这种自主权允许他们在数据产品的定义边界内独立运作，做出决策并实施促进创新和敏捷的策略。赋予他们的自主权并非完全不受限制，而是与广泛的组织目标和战略保持一致的需要相平衡。
让我们更具体一些。一个常见的场景展示了明确决策权的重要性，涉及数据产品技术工具和平台的选择。企业通常会有一套首选的工具和平台，要求在其运营中广泛应用。然而，DPO（或数据产品工程师）可能会识别到其他工具，他们认为这些工具对他们的具体数据产品更为有效。
在这种情况下，如果遵循数据网格的原则，决策权在于DPO。他们有权选择最适合其数据产品需求的工具和技术。这种自主权对于确保数据产品使用最合适、最有效的技术至关重要。
然而，这种决策自主权并不意味着与企业的孤立。企业应专注于使其推荐的工具变得高效、用户友好。目标应是创造一个DPO愿意使用企业推荐工具的环境，不是因为强制性规定，而是因为这些工具真正满足了他们的需求。
识别数据产品
你需要回答的第一个重要问题可能是：“如何开始构建数据产品？”我们希望能给你一个非常简单的答案。但即使我们已经构建了许多数据产品，依然没有一个保证成功设计的神奇配方。不过，我们可以分享一些基本的指导方针（第16章也会补充一些信息）。
与客户交谈至关重要。你可能已经在这样做了，但你需要确保向他们询问他们的优先事项，哪怕他们自己可能还不熟悉这些优先事项。你应确定他们在某个日期之前希望获得什么数据，是否可以分批交付：v1.0、v1.1、v1.2等等。考虑让多个客户参与进来，以扩大用例范围。
考虑使用领域驱动设计（DDD）。这是软件设计中的一种流行方法，重点是根据领域专家的输入，将软件建模以符合领域需求。在DDD的框架下，软件代码的结构、语言（类名、类方法、类变量）和数据工件应与业务领域保持一致。如果你对DDD感兴趣，可以查阅Vlad Khononov的《Learning Domain-Driven Design》（O'Reilly）。
你还需要确定将要担任DPO（数据产品负责人）的人选（你将在第14章了解更多关于DPO的角色）。在这个阶段，他们的职责包括以下任务：
- 定义并优先考虑数据产品的功能
DPO将功能与业务目标和用户需求保持一致；采用敏捷方法进行增量开发，从MVP（最小可行产品）开始；并根据持续的用户反馈和性能指标保持灵活性，确保产品有效演变，以为利益相关者提供最大价值。 - 创建并管理产品路线图
DPO定义清晰的愿景和战略目标，然后将这些转化为时间表，按照其价值、技术可行性和与业务目标的对齐程度优先安排功能和里程碑。 - 优先排序并管理产品待办事项
DPO根据项目的价值、可行性和战略目标的对齐情况，持续优化和排列待办事项。 - 验证并接受产品增量
DPO严格测试和审核每个已完成的功能或增强功能，确保其符合预定义的验收标准，达到质量标准和用户要求。
不要试图面面俱到。目标是快速带来价值，并准备好进行迭代。正如你在数据产品生命周期中所见，数据产品是为演进而设计的，你将能够修改你最初的几个数据产品。
总结
至此，我们已经了解了什么是“优质”数据产品：它遵循数据网格原则并符合FAIR原则，达到企业级标准，交付实际的、有形的价值。它在成本、敏捷性和速度方面达到了平衡，它远不止是数据本身。它有一个有权力的所有者，并且拥有一个能够定义和实现数据产品承诺的生命周期。
接下来显然的问题是：“如何构建具备所有这些属性的‘优质’数据产品？”接下来的两章将启动这个过程。我们将首先介绍一个贯穿全书的场景，展示如何将这些原则和特性付诸实践，然后深入探讨数据网格及其组成数据产品的架构组件。
