category
写这个博客的时间比我预想的要长得多。在我的圈子里，每个阅读过初始版本的人都对什么是数据产品有不同的看法。我觉得，如果数据产品要成功，我们必须清楚、毫不含糊地了解它是什么，同样重要的是，它不是什么。经过深思熟虑，我向您介绍我对数据产品的（不断发展的）观点。
所以，我们走吧。
ChatGPT已经席卷了世界，因为它雄辩地回答了我们的问题，并为用户提供了卓越的体验。部分归功于对话式人工智能工具的简单界面，我们不再需要搜索和接收多个链接，然后尝试制定答案，因为聊天机器人为我们提供了答案。考虑到生成的结果，ChatGPT可以被视为数据产品吗？
为了得到答案，我们询问了聊天机器人本身。它是这样回答的：
ChatGPT可以被视为一种数据产品，因为它依赖于大量数据，特别是文本数据，来生成对用户查询的响应。该模型是在大量文本数据的基础上训练的，用于理解上下文并生成相关响应。然而，ChatGPT也不仅仅是一种数据产品，因为它是一个复杂的系统，结合了机器学习算法、自然语言处理技术和复杂的软件工程，创造了无缝的用户体验。
让我们看看这个答案能支持多少。
首先，ChatGPT对所有人都很容易访问（在撰写本文时），尽管随着它从开源向闭源的转变，这种情况可能会发生变化。它提供了极好的用户体验，记住了前面问题的意图，然后形成了一系列答案。通过这种方式，它真的闻起来像一种产品。
基于大型语言模型的聊天机器人具有巨大的潜力，可以改变数字世界的许多方面。但是，让我们现实一点。答案不可能总是可信的。ChatGPT使信任（准确性）属性失败。稍后，我将在未来的博客中分享我对数据产品关键属性的看法，但首先，让我们定义数据产品的基本特征。
定义数据产品
我们学到的一个教训是坚持问题陈述，不要卷入“定义”的东西。定义是一个没有两个人能够达成一致的滑坡，它将焦点从解决问题上转移开。
例如，怀疑论者经常问的第一个问题是，什么是数据产品？我们“数据产品清洗”任何数据输出是因为它听起来，哦，太复杂了吗？对一些人来说，数据产品并不是什么新鲜事。对其他人来说，数据产品与其说是有形的结果，不如说是如何构建和部署它。事实上，应用产品管理最佳实践是数据产品的一个非常关键的定义因素。
除了产品管理方面，数据产品还提供卓越、一致和可靠的数据访问，使消费者能够获得他们的问题（或一系列问题）的答案，以支持商业决策或结果。数据产品突出了两个重要特征：用户体验和信任。它还有一个对其质量和可靠性负责的所有者。它是一个自包含的接口，可以获得各种业务问题的答案，在大多数情况下，还可以通过自助服务接口使用。大多数数据产品都是只读的。
下图总结了数据产品的组成部分。
数据产品除了技术特征之外，还包括语义层和访问层——所有这些都是使用产品管理原理构建的，并有一个指定的所有者。
数据产品是以下各项的组合：
- 数据集:可以在表、视图、ML模型或流中的数据集。数据可以是原始数据或从多个数据源集成的策划数据。数据产品必须发布其数据模型。
- 领域模型：添加语义层的领域模型。该层抽象了存储层的技术布局，而是向最终用户公开了业务友好的术语。该层还存储各种计算、度量和转换业务逻辑。
- 访问:通过API和其他可视化选项访问数据，并强制执行访问控制策略。
数据产品目录也很关键，因为它用于使数据产品可被发现，并记录所有必要的属性。有关更多详细信息，请参阅我最近在《福布斯》上发表的文章。此目录可能不是独立的产品，而是现有数据目录的扩展。它充当数据产品的市场。
简单地说，数据产品传达了信任和旨在解决业务问题的产品功能。数据产品具有可测量的价值。它的所有者负责在产品从设计到退役的整个生命周期中提供价值。
该文件的其余部分将进一步详细介绍。但我们已经犯了一个常见的失礼行为，那就是迅速转向技术寻找答案。数据产品通常是为业务用户构建的。因此，在回到技术方面之前，先看业务视图更合适。
业务特点
老实说，业务用户并不真正关心IT人员如何标记和分类技术，因为他们专注于解决组织需要的问题。因此，如果IT人员必须向业务部门解释数据产品，就必须去掉技术术语。
如今，用户必须使用仪表板获取分析答案，使用ML模型获取规范性答案，并使用搜索数据库进行诊断查询。数据产品提供了统一的独立访问，可以获得不同类型问题的答案——诊断、预测、规定、分析等。
要将实际的数据产品与业务术语区分开来，让我们从产品的物理世界中获得一些帮助。想象一下一盒你最喜欢的麦片。盒子里有商品（比如肉桂吐司），还有成分描述、营养细节、保质期等，还有价格。这种谷物绝对是你可以在杂货店的指定过道里找到并购买的产品。
现在，想象一下你可以在没有盒子的情况下以某种方式获得麦片。它还是一种产品吗？毕竟，谷物没有改变，但基于上述解释，它不再是一种产品。
首先，它不能给你经验。如果我们对内容的新鲜度有疑问，您无法知道内容何时会变质，我们也无法联系品牌制作人要求退款。我们不知道制造商是谁，在这种形式下，它不再提供谷物品牌的信息，也不在包装内容中推广“信任”和“体验”。
现在，让我们将这个类比应用于数字对象。就像实体产品有品牌一样，数字产品也必须有身份。该身份包括标签、标签、用户同意、目的以及信任和可靠性声明。对于数据产品，除了核心功能之外，它还可能包括输出表模式、数据字典、数据分布、语义层、度量、协议和合同以及其他遥测，包括中间快照，以帮助在运行时为产品提供服务。
如今，文档、业务逻辑、度量等都存在，但不是表的一部分。它们是事后才想到的，超出了范围，比如在SharePoint网站或各种不同的BI工具中。结果是，随着模式的发展，这些文档很快就不同步了。此外，如果个人使用不同的数据访问工具，则该逻辑可能不可用。这在传统方法中很常见，这会导致重复工作并增加出错的机会。
总之，简单地发布数据集并不能使其成为数据产品。它必须具有其他组件——产品管理流程、包含语义层的域包装器、业务逻辑和度量以及访问。
数据产品还应服务于广泛的领域用例。例如，营销团队可以从多个可用来源收集客户数据，如Salesforce、SAP、Marketo、Hubspot、网站日志、调查等，并生成“客户主数据”。然后，可以将此基础数据资产与前面讨论的其他组件相结合，并将其打包为营销团队的数据产品。其他领域，如销售和金融，可以信任其数据，并使用其得出自己的结果，甚至构建自己的数据产品。数据产品使数据生产者和消费者之间的数据协议更加透明和可操作。
既然我们已经从业务的角度定义了数据产品，那么让我们转向数据产品的技术定义。
技术特点
数据产品抽象了内容的物理存储位置，可以使用本地或多个云提供商中的数据源来构建。它还向数据消费者隐藏了数据管道的复杂性。该管道可能涉及数据移动、数据虚拟化、内存、缓存、lakehouse或结构。
这种抽象类似于消费者不必考虑他们的谷物是如何制造、包装和/或运输的。过去，我们期望企业了解技术是最有效的。在新的方法中，企业可以期待获得与每次购买一盒肉桂吐司Crunch时相同的一致结果，而无需了解任何细节。
技术定义是不完整的，没有记录业务所需的非功能属性，如可重复体验、可靠性、并发性、响应时间、正常运行时间等。稍后将在另一个博客中介绍构建数据产品的过程。
虽然业界对以下哪一项是数据产品几乎没有达成一致，但让我们来看看每一项：
- 表、架构或视图
- 数据仓库、数据集市
- 报表或仪表板
- ML模型，高级分析
表、架构、视图
表本身不是数据产品，因为它可能引用了其他表中的键。换句话说，它可能不是独立的。好吧。有些人不同意，因为通过对表进行扁平化或非规范化，可以很容易地使其独立。但这构成了数据产品吗？
如果我们将其与定义状态中的语义层相结合，则可能会出现这种情况。为什么这很重要？
请记住，数据产品为用户提供了卓越的自助服务用户体验，而无需了解物理细节。此外，它还将用户从源模式的更改中抽象出来。当架构更改时，数据产品所有者会创建数据产品的新版本，并使其在数据产品目录中可用。换句话说，产品管理方面对于数据产品的命名至关重要。
如果每个表及其度量都成为一个数据产品，我们很快就会陷入无法管理的混乱。此外，如果每个表都是一个表，那么数据产品的意义何在？
数据仓库、数据集市
数据产品应该遵循左移原则，由领域团队为一组无限制的用例创建。数据产品与业务域实体、事件及其交互和行为更加紧密地联系在一起。数据产品所有者负责提供数据产品的约定质量，尽管定义数据质量的责任由数据消费者根据其要求完成。
数据集市是为了回答非常具体的业务领域问题而构建的，所以它们肯定是一种数据产品，对吧？答案是否定的。数据集市、数据仓库、数据湖和湖屋是数据管理平台，而不是数据产品。传统上，数据集市是经过漫长而乏味的数据仓库构建后到达的IT可交付成果，此时业务需求可能已经发生了变化。如果产品管理方法要应用于数据集市，那么它可以用于开发数据产品。此外，数据集市产品应该是敏捷的，并支持各种可视化模式、高级分析和查询引擎。
报表，仪表板
报表或仪表板是数据产品的组成部分之一。它可以访问数据和指标。可以通过API或类似SQL的语言进行访问。它必须有一个指定的产品所有者，并使用产品管理原则构建。
ML模型，高级分析
ML模型，如客户流失或情绪分析，遵循与上面为报告和仪表板定义的标准相同的标准。它是数据产品的组成部分。
重述
让我们通过另一个例子来回顾我们对数据产品的业务和技术特征的理解。想象一下，如果一个商业用户的目标是能够用准确、最新的数据分析其SaaS产品的月活跃用户（MAU）。然后想象一下，如果他们希望能够与历史数据进行比较，并基于可配置参数预测MAU。
为了满足这一要求，他们需要对历史数据、流式事务数据和预测分析进行统一分析。数据生产者，在这种情况下是营销部门，不仅负责提供数据，还负责遵守相关法规遵从性和API或GUI的访问控制策略。这是一个数据产品的例子。它使用包含必要公式和计算的语义层从结构化数据库和半结构化日志文件中提取数据。API访问端点应支持各种选项，如HTTP/JSON、GraphQL、SQL等。
随着对数据需求的增加，故障线出现在我们当前的数据架构中。传统的体系结构是为一个时代构建的，在这个时代，一组表可以满足报告和仪表板的大多数要求。但是，随着数据源、用户和用例的数量呈指数级增长，集中数据之上的工具集和角色也变得支离破碎。如今的数据消费者很精明，期望值很高。他们希望数据具有响应性、高质量、可靠和可预测的成本，并且不再希望被数据团队视为测试版测试人员。信任和分析数据的用户体验至关重要。
想要推动创新和提高竞争优势的组织有一种紧迫感。目前的数据方法使数据团队受到限制，无法以业务团队设计新方法从其数据资产中驱动智能的速度交付。数据团队需要停止对新的云数据仓库或新的lakehouse的痴迷，而是重新思考如何取悦他们的业务伙伴，也就是他们的客户。这就是数据产品概念转变的原因。
正确的数据产品定义至关重要，这样我们才能有一个共同的理解。据维基百科报道，20世纪70年代，E.F.Codd开始定义关系数据库的12条规则，以“防止原始关系数据库的愿景被淡化，因为数据库供应商在20世纪80年代初争相用关系贴面重新包装现有产品。”正如他们所说，历史在重复。
