人们对数据产品的含义都有不同的看法。我认为，如果数据产品要取得成功，就必须清楚、明确地了解它是什么，同样重要的是，必须了解它不是什么。

ChatGPT 因其像人一样地回答我们的问题以及为用户提供的出色体验而席卷了世界。在某种程度上，由于对话式人工智能的简单界面，我们不再需要搜索和接收多个链接，然后尝试制定答案，因为聊天机器人会为我们提供答案。鉴于生成的结果，ChatGPT 是否可以被视为数据产品?

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

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

我们来看看这个答案有多少水分。

首先，ChatGPT 可供所有人轻松访问(在撰写本文时)，尽管随着它从开源转向闭源，这一点可能会发生变化。它提供了出色的用户体验，记住前面问题的意图，然后形成答案。这样，它才真正具有产品的味道。基于大型语言模型的聊天机器人具有改变数字世界许多方面的巨大潜力。但是，我们必须面对现实，答案并不总是可信的。ChatGPT 不符合信任(准确性)属性。那么，基于此，让我们来定义数据产品的基本特征。

定义数据产品

我们学到的一个教训是坚持问题陈述，不要卷入“定义”的事情。任何两个人都无法达成一致，它会分散解决问题的注意力。例如，怀疑论者经常问的第一个问题是，什么是数据产品?我们是否会“清洗数据”保证数据产品输出，这听起来很复杂。对于某些人来说，数据产品并不是什么新鲜事。对于某些人来说，数据产品不那么关乎有形的结果，而更多地关乎如何构建和部署它。事实上，应用产品管理最 佳实践是数据产品的一个非常关键的决定因素。

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

数据产品是以下各项的组合：

• 数据集可能位于表、视图、ML 模型或流中。数据可以是原始数据或从多个数据源集成的整理数据。数据产品必须发布其数据模型。

• 添加语义层的领域模型。该层抽象了存储层的技术布局，并向最终用户公开易于理解的业务术语。该层还存储各种计算、指标和业务转换逻辑。

• 通过 API 和其他可视化选项访问数据，并强制执行访问控制策略。

数据产品目录也很重要，因为它用于使数据产品可被发现并记录所有必要的属性。该目录可能不是独立的产品，而是现有数据目录的扩展。

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

一个常见的误区就是快速跳到技术上寻找答案。数据产品通常是为业务用户构建的。因此，在深入讨论技术方面之前，更合适的做法是首先关注业务需求。

业务视角

老实说，业务用户并不真正关心 IT 人员如何对技术进行标记和分类，因为他们专注于解决组织所需的问题。因此，如果IT人员必须向业务部门解释数据产品，那么就必须避免使用技术术语。

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

为了将实际的数据产品与商业术语区分开来，让我们从产品的物理世界中获得一些帮助。想象一盒你最喜欢的麦片，盒子里有商品(比如肉桂吐司脆片)，以及其成分、营养成分、有效期等的描述，以及价格。麦片是可以在便利店指定通道找到并购买的产品。

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

首先，它无法提供体验。如果我们对内容的新鲜度有疑问，无法知道内容何时会变质，我们也无法向品牌生产商要求退款。我们不知道制造商是谁，在这种形式下，它不再提供有关谷物品牌的信息，也不再在其包装内容中宣传“信任”和“体验”。

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

如今，文档、业务逻辑、指标等都存在，但不是表的一部分。它们是事后才想到的，并且是附加的，就像在 SharePoint 网站或各种不同的 BI 工具中一样。结果是随着模式的发展，该文档很快就会变得不同步。此外，如果个人使用不同的数据访问工具，则逻辑可能不可用。这在传统方法中很常见，会导致重复工作并增加出错的机会。

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

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

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

技术视角

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

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

如果没有记录业务所需的非功能属性(例如可重复的体验、可靠性、并发性、响应时间、正常运行时间等)，技术定义是不完整的。

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

• 表、架构或视图

• 数据仓库、数据集市

• 报告或仪表板

• ML 模型、高级分析

表、架构、视图

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

如果我们按照定义将其与语义层结合起来，就可以实现这一点。为什么这很重要?请记住，数据产品为其用户提供卓越的自助用户体验，而无需了解物理细节。此外，它还使用户免受源模式更改的影响。当架构更改时，数据产品所有者会创建数据产品的新版本并使其在数据产品目录中可用。换句话说，产品管理方面对于数据产品而言至关重要。

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

数据仓库、数据集市

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

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

报告、仪表板

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

机器学习模型，高级分析

ML 模型(例如客户流失或情绪分析)遵循与上面为报告和仪表板定义的相同标准。它是数据产品的一个组件。

小结

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

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

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

想要推动创新并提高竞争优势的组织有一种紧迫感。当前的数据处理方法使数据团队受到限制，无法以业务团队设计新方法从数据资产中获取智能的速度提供服务。数据团队需要停止沉迷于新的云数据仓库或新的 Lakehouse，而是重新思考如何支持他们的业务伙伴，也就是他们的客户。这就是数据产品概念发生变革的原因。正确定义数据产品至关重要，这样我们才真正生产出数据产品，发挥数据资产的价值。