数据产品到底是什么？

这篇博客的写作时间比我预期的要长得多。我圈子里读过初版的每个人都对数据产品有不同的看法。我认为，如果数据产品要成功，我们必须对数据产品是什么有一个清晰明确的理解，同样重要的是，它不是什么。经过深思熟虑，我向你们介绍了我对数据产品（不断发展的）观点。

那么，让我们开始吧。

ChatGPT 风靡全球，因为它能很好地回答我们的问题，并为用户提供出色的体验。在一定程度上，得益于对话式人工智能工具的简单界面，我们不再需要搜索和接收多个链接，然后尝试制定答案，因为聊天机器人会为我们提供答案。考虑到生成的结果，ChatGPT 可以被视为数据产品吗？

为了得到答案，我们询问了聊天机器人本身。它的回答是这样的：

ChatGPT 可以被视为一种数据产品，因为它依赖于大量数据，特别是文本数据，来生成对用户查询的响应。该模型是在大量文本数据上训练的，它使用这些数据来理解上下文并生成相关响应。然而，ChatGPT 不仅仅是一个数据产品，它是一个复杂的系统，结合了机器学习算法、自然语言处理技术和复杂的软件工程，以创造无缝的用户体验。

让我们看看这个答案有多大说服力。

首先，ChatGPT 很容易被所有人访问（在撰写本文时），尽管随着它从开源转向闭源，这种情况可能会发生变化。它提供了出色的用户体验，记住了前面问题的意图，然后形成了一系列答案。这样，它就真正表现得像一个产品。

基于大型语言模型的聊天机器人具有改变数字世界许多方面的巨大潜力。但是，让我们面对现实吧。答案并不总是可信的。 ChatGPT 未能达到信任（准确性）属性。稍后我会详细介绍，因为我将在未来的博客中分享我对数据产品关键属性的看法，但首先，让我们定义数据产品的基本特征。

1、定义数据产品

我们学到的一个教训是坚持问题陈述，不要卷入“定义”的事情。定义是一个滑坡，没有两个人能够达成一致，它会将重点从解决问题上转移开。

例如，怀疑论者经常问的第一个问题是，什么是数据产品？我们是否因为听起来很复杂而“用数据产品清洗”任何数据输出？对于某些人来说，数据产品并不是什么新鲜事。对于其他人来说，数据产品与有形结果无关，而与如何构建和部署它有关。事实上，应用产品管理最佳实践是数据产品的一个非常关键的决定因素。

除了产品管理方面，数据产品还提供卓越、一致和可靠的数据访问，使消费者能够获得问题（或一系列问题）的答案，以支持业务决策或结果。数据产品有两个重要特征：用户体验和信任。它还有一个对其质量和可靠性负责的所有者。它是一个独立的界面，可以获取各种业务问题的答案，并且在大多数情况下，通过自助服务界面使用。大多数数据产品都是只读的。

下图总结了数据产品的组成部分：

数据产品是以下内容的组合：

• 数据集可能位于表、视图、ML 模型或流中。数据可能是原始数据，也可能是从多个数据源集成的精选数据。数据产品必须发布其数据模型。
• 领域模型，它添加了一个语义层。此层抽象了存储层的技术布局，而是向最终用户公开了业务友好的术语。此层还存储各种计算、指标和转换业务逻辑。
• 通过 API 和其他可视化选项访问数据，并强制执行访问控制策略。

数据产品目录也很重要，因为它用于使数据产品可发现，并记录所有必要的属性。有关更多详细信息，请参阅我最近的《福布斯》文章。此目录可能不是独立产品，而是现有数据目录的扩展。它充当数据产品的市场。

简而言之，数据产品传达了信任和旨在解决业务问题的产品功能。数据产品具有可衡量的价值。它有一个所有者，负责在产品从设计到退役的整个生命周期中提供价值。

本文档的其余部分将进一步详细介绍。但我们已经犯了一个常见的错误，那就是快速跳到技术上寻找答案。数据产品通常是为业务用户构建的。因此，在深入研究技术方面之前，先查看业务视图更为合适。

2、业务特征

说实话，业务用户并不真正关心 IT 人员如何标记和分类技术，因为他们专注于解决组织需要的问题。因此，如果 IT 人员必须向企业解释数据产品，那么必须没有技术术语。

如今，用户必须转到仪表板获取分析答案，使用 ML 模型获取规范答案，并搜索数据库以进行诊断查询。数据产品提供统一的独立访问，以获取不同类型问题的答案——诊断、预测、规范、分析等。

为了将实际数据产品与业务术语区分开来，让我们从产品的物理世界中寻求一些帮助。想象一盒你最喜欢的麦片。盒子里有商品（例如，肉桂吐司脆片），以及其成分的描述、营养细节、保质期等，以及价格。麦片绝对是你可以在杂货店指定过道找到并购买的产品。

现在，想象一下，你可以在没有盒子的情况下以某种方式购买麦片。它还是产品吗？毕竟，麦片没有改变，但根据上述解释，它不再是产品。

首先，它不能给你体验。如果我们对内容的新鲜度有疑问，你无法知道内容何时会变质，我们也不能去找品牌生产商要求退款。我们不知道制造商是谁，而且在这种情况下，它不再提供有关麦片品牌的信息，也不会在包装内容中宣传“信任”和“体验”。

现在，让我们将这个类比应用到数字对象上。就像实体产品有品牌一样，数字产品必须有身份。这个身份包括标签、标记、用户同意、目的以及信任和可靠性声明。对于数据产品，除了核心功能之外，它可能包括输出表模式、数据字典、数据分布、语义层、指标、协议和合同以及其他遥测数据，包括中间快照，以帮助在运行时为产品提供服务。

如今，文档、业务逻辑、指标等虽然存在，但并非表格的一部分。它们是事后的想法，并且是带外的，例如在 SharePoint 站点或各种不同的 BI 工具中。结果是，随着模式的发展，这些文档很快就会不同步。此外，如果个人使用不同的数据访问工具，则逻辑可能不可用。这在传统方法中很常见，会导致重复劳动并增加出错的可能性。

总而言之，仅仅发布数据集并不能使其成为数据产品。它必须具有其他组件——产品管理流程、包含语义层的域包装器、业务逻辑和指标以及访问权限。

数据产品还应服务于广泛的领域用例。例如，营销团队可以从多个可用来源（如 Salesforce、SAP、Marketo、Hubspot、网站日志、调查等）收集客户数据，并生成“客户主数据”。然后可以将此基础数据资产与前面讨论的其他组件相结合，并打包为营销团队的数据产品。其他领域，如销售和金融，可以信任其数据并使用它来得出自己的结果，甚至构建自己的数据产品。数据产品使数据生产者和消费者之间的数据协议更加透明和可操作。

现在我们已经从业务角度定义了数据产品，让我们来看看数据产品的技术定义。

3、技术特征

数据产品抽象了内容的物理存储位置，可以使用本地或多个云提供商中的数据源构建。它还向数据消费者隐藏了数据管道的复杂性。该管道可能涉及数据移动、数据虚拟化、内存、缓存、Lakehouse 或结构。

这种抽象类似于消费者不必考虑他们的谷物是如何制造、包装和/或运输的。过去，我们期望企业了解最有效的技术。在新方法中，企业可以期望获得与他们每次购买一盒肉桂吐司脆片时相同的一致结果，而无需了解任何细节。

如果不记录企业所需的非功能性属性，如可重复体验、可靠性、并发性、响应时间、正常运行时间等，技术定义是不完整的。稍后将详细介绍这一点，因为将在另一篇博客中介绍构建数据产品的过程。

虽然业界对于以下哪些是数据产品几乎没有共识，但让我们逐一分析一下：

• 表、架构或视图
• 数据仓库、数据集市
• 报告或仪表板
• ML 模型、高级分析

3.1 表、模式、视图

表本身不是数据产品，因为它可能引用其他表中的键。换句话说，它可能不是自包含的。好吧。有些人不同意，因为表可以通过扁平化或非规范化轻松地自包含。但这构成数据产品吗？

如果我们将其与语义层相结合，则可以，正如我们的定义所述。为什么这很重要？

请记住，数据产品为其用户提供了卓越的自助式用户体验，而无需了解物理细节。此外，它将用户从源模式的变化中抽象出来。当模式发生变化时，数据产品所有者会创建数据产品的新版本并将其提供给数据产品目录。换句话说，产品管理方面对于数据产品被称为数据产品至关重要。

如果每个表及其指标都成为数据产品，我们很快就会陷入难以管理的混乱。此外，如果每个表都是一个数据产品，那么数据产品的意义何在？

3.2 数据仓库、数据集市

数据产品应遵循左移原则，由领域团队为无限的用例集创建。数据产品与业务领域实体、事件及其交互和行为更加紧密地结合在一起。数据产品所有者负责提供数据产品的约定质量，尽管定义数据质量的责任由数据消费者根据其要求完成。

数据集市是为了回答非常具体的业务领域问题而建立的，所以它们肯定是数据产品，对吗？答案是否定的。数据集市、数据仓库、数据湖和湖屋是数据管理平台，而不是数据产品。传统上，数据集市是经过漫长而繁琐的数据仓库构建后得出的 IT 可交付成果，此时业务需求可能已经发生了变化。如果将产品管理方法应用于数据集市，那么它可用于开发数据产品。此外，数据集市产品应该是敏捷的，并支持各种可视化模式、高级分析和查询引擎。

3.3 报告、仪表板

报告或仪表板是数据产品的组件之一。它可以访问数据和指标。访问可以通过 API 或 SQL 等语言进行。它必须有指定的产品所有者，并使用产品管理原则构建。

3.4 ML 模型、高级分析

ML 模型（如客户流失或情绪分析）遵循与上述报告和仪表板相同的标准。它是数据产品的组件。

4、结束语

让我们通过另一个示例来回顾一下我们对数据产品的业务和技术特征的理解。想象一下，如果业务用户的目标是能够使用准确且最新的数据分析其 SaaS 产品的月活跃用户 (MAU)。然后想象一下，如果他们希望能够与历史数据进行比较，并根据可配置参数预测 MAU。

为了满足这一要求，他们需要对历史数据、流式交易数据和预测分析进行统一分析。数据生产者（在本例中为营销部门）不仅负责提供数据，还负责提供符合相关法规遵从性以及 API 或 GUI 的访问控制策略。这是一个数据产品的示例。它使用包含必要公式和计算的语义层从结构化数据库和半结构化日志文件中提取数据。API 访问端点应支持各种选项，例如 HTTP/JSON、GraphQL、SQL 等。

随着对数据的需求不断增加，我们当前的数据架构中出现了断层线。传统架构是为一组表格可以满足大多数报告和仪表板要求的时代而构建的。但随着数据源、用户和用例的数量呈指数级增长，集中数据之上的工具集和角色都变得支离破碎。如今的数据消费者非常精明，期望很高。他们希望数据具有响应性、高质量、可靠性和可预测的成本，并且不再希望被数据团队视为 beta 测试人员。数据分析的信任和用户体验至关重要。

想要推动创新并提高竞争优势的组织有一种紧迫感。当前的数据处理方法使数据团队受到限制，无法以业务团队设计新方法从其数据资产中获取智能的速度交付数据。数据团队需要停止痴迷于新的云数据仓库或新的 Lakehouse，而是重新思考如何取悦他们的业务伙伴，也就是他们的客户。这就是数据产品概念变革的原因。

正确定义数据产品至关重要，这样我们才能达成共识。根据维基百科，在 20 世纪 70 年代，E.F. Codd 着手定义关系数据库的 12 条规则，以“防止原始关系数据库的愿景被淡化，因为数据库供应商在 20 世纪 80 年代初争先恐后地用关系表重新包装现有产品。”正如他们所说，历史会重演。

原文链接：What Exactly is a Data Product?

BimAnt翻译整理，转载请标明出处