wsl-docs

关于采用 Snowflake Internal Marketplace 的最佳实践 ｜技术实践

发布日期：2026-02-27来源：InfoQ原文链接：https://www.infoq.cn/article/k3dDblNcrtKHEsNTVCOp?utm_source=rss&utm_medium=article19分钟阅读

摘要

一句话总结 本文探讨了企业采用 Snowflake Internal Marketplace 构建数据产品体系的最佳实践，涵盖组织协同、账户配置、产品管理、权限控制及监控等关键维度的技术与运营建议。

关键要点

  • 组织协同：需让数据产品所有者和消费方尽早参与，明确数据所有权及职责（文档、治理、质量等），从简单场景起步敏捷迭代。
  • 账户配置：支持单账户、多账户或混合部署，强烈建议创建 Snowflake Organization Account 以统一管理用户画像、自定义属性和监控面板。
  • 产品运营：数据产品负责人应采用传统产品管理原则，建立沟通渠道（如 Slack/Teams），并定义/跟踪数据质量与成功指标。
  • 技术实施：每个数据产品应独立上架并完善描述，底层对象可跨模式/数据库分布，建议将数据质量（DQ）指标纳入数据字典。
  • 合规与验证：可通过 DESCRIBE LISTING 命令和相关视图自动验证数据产品是否符合公司合规标准（如数据预览、共享权限等）。
  • 版本管理：数据产品定义以 YAML 文件形式管理，重大变更时应提前通知用户，并保留旧版本一段时间以供平滑迁移。
  • 非 Snowflake 资产：支持将第三方工具（如 Power BI、Tableau）的报表或外部资产发布至内部市场以提高可发现性，访问授权在外部管理。
  • 权限管理：提供两种主要模式：将用户角色直接加入列表的定向访问列表，或将已有访问权限的角色授予目标用户。
  • 数据监控：可通过组织账户中的 access_history 和 query_history 视图创建跨域仪表板，追踪数据产品的使用情况。

风险/缺口

  • 中央数据平台团队与目标用户群体之间可能出现目标偏差，导致落地失败。
  • 在多区域或多云环境中使用时，必须采用独立账户部署，否则无法有效运作。
  • 进行非向后兼容的重大变更（如移除视图或列）时，若未妥善管理版本和沟通，可能导致数据消费方业务中断。

正文

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

数据产品的概念已获得广泛关注，众多企业正纷纷构建门户或平台，以在内部共享数据与人工智能产品。过去一年中，我协助了数十家企业推进数据产品化进程，并推动其采用 Snowflake Internal Marketplace。

不出所料，不同组织在现有 IT 架构、治理要求及数据管理流程方面存在差异。这些特点影响着 Internal Marketplace 的采纳效果及其与现有流程的整合。尤其值得注意的是，面向数据与人工智能的 Internal Marketplace 是一个高度可见的组件，其涉及公司内部几乎所有与数据相关角色的参与。因此，引入 Internal Marketplace 将带来多方面的影响，并涉及众多利益相关方。为确保持续成功落地，必须对这些因素进行审慎考量。

我们建议根据实际需求对 Snowflake Internal Marketplace 进行定制化配置，并分享在实施过程中涉及人员与流程维度的组织级考量建议。

若您尚未熟悉 Snowflake Internal Marketplace，建议[观看此演示视频]以了解其核心功能特性。

组织层面的考量

建立 internal marketplace 与数据产品体系不仅是技术任务，人员与流程同样是关键要素，对于推动 internal marketplace 的顺利落地至关重要。

  • 避免引入 internal marketplace 的中央数据平台团队与目标用户群体之间出现目标偏差。在规划阶段应吸纳未来数据产品所有者及使用方的代表参与，尽早并持续获取所有相关方及用户的支持与认可；

  • 确保数据产品的所有权明确（即明确各项数据的归属主体）；

  • 部分数据的所有权界定可能较为清晰，可从易于确定归属的数据入手，逐步迭代并扩展范围；

  • 制定清晰的所有权职责定义，涵盖数据产品文档、治理、质量、沟通、标准、互操作性等方面。初期可设定基础职责，再随时间推移逐步完善；

  • 必须将业务数据负责人纳入数据文档、治理与质量管理的责任体系中；

  • 无需在初始阶段追求覆盖所有场景的完美方案。精细规划与分析停滞之间需把握平衡，应从“简单”场景起步，通过持续学习、迭代并渐进扩展，以敏捷方式推进 internal marketplace 的落地。

账户与配置

Snowflake Internal Marketplace 在不同团队共享单个 Snowflake 账户、使用独立账户或混合部署场景下均能有效运作。您无需预先确定固定的账户拓扑结构，该拓扑可灵活调整并随时间演进。

  • 独立账户可为各业务单元提供更强的隔离性与独立性，但需额外考虑账户管理问题。Snowflake Organization Account 能够简化多账户的统一管理与监控；

  • 若要在多区域或多云环境中使用 internal marketplace，则必须采用独立账户部署；

  • 在单账户内通过独立数据库访问数据产品时，其细粒度访问策略的定义可能与多账户场景存在差异，相关内容将在后续文章中详细探讨。

无论采用单账户还是多账户模式，我们强烈建议创建 Snowflake Organization Account，该账户为定制组织的 Snowflake Internal Marketplace 提供关键能力：

  • 为通过 Internal Marketplace 共享数据产品的不同团队/领域/部门创建用户画像；

  • 创建自定义数据产品属性，用于定义描述任意数据产品的附加字段。可指定哪些属性为必填或选填、其允许取值范围及筛选条件（此功能目前处于私有预览阶段）；

  • 可创建 Snowsight Dashboard 以提供 Internal Marketplace 使用情况的概览视图，更多细节将在后文“数据产品监控”部分说明；

  • 可选创建组织级用户与用户组，以协助数据产品的管理与访问控制。

Image 1

使用组织账户定义并管理域团队

许多 Internal Marketplace 用户倾向于将其菜单项固定至菜单栏顶端作为快捷访问入口。

Image 2

将 Internal marketplace 菜单项置顶

数据产品管理

数据产品管理的最佳实践涵盖流程与运营原则，以及技术实施指导规范。

运营建议

数据产品负责人应运用传统的产品管理原则，重点关注“客户”需求、业务目标、路线图、生命周期管理、文档化及内部推广。

  • 尤其应基于潜在数据消费者的需求设计数据产品。如何使特定数据产品对典型数据消费者产生最大价值？

  • 定义并跟踪数据产品质量标准，不仅涵盖传统数据质量指标，还应包括元数据完整性、文档完备性、治理控制措施、标准遵循度等；

  • 定义并跟踪数据产品成功指标，可涵盖使用统计量、数据消费者数量、数据消费者用例类型，以及使用该数据产品的报表或 AI 智能体等。

技术实施建议

针对内部市场上数据产品的技术实施，建议遵循以下最佳实践：

  • 每个数据产品应在 Internal Marketplace 中作为独立条目上架；

  • 充分利用条目的所有可选字段，使数据产品的描述尽可能完整、清晰。必要时可添加自定义属性；

  • 确保所共享的表、视图等对象具备完整的对象描述与字段描述，系统将据此自动生成数据产品的数据字典；

  • 组成数据产品的对象可分布于不同模式乃至不同数据库（后者需使用 reference_usage 授权）。因此，无需根据待发布的数据产品重新调整数据对象在模式或数据库中的物理分组，可通过 Marketplace 的上架条目实现逻辑层面的灵活分组，独立于底层存储结构；

  • 如需展示数据质量，可在数据产品条目中添加包含相关 DQ 指标、质量期望及最新 DQ 评估结果的视图或表。建议将该视图或表加入条目，并设置为数据字典中首个或唯一一个推荐对象。

Image 3

数据质量指标可纳入数据产品的数据字典中

数据产品合规性与验证

在数据产品发布时或发布前，可能需要验证其是否符合一项或多项需强制执行的规定或标准。此类规则的示例如下：

  • 验证数据产品在应（或不应）显示数据预览时，是否确实（或未）显示数据预览；

  • 验证数据产品是否包含适当的归属和联系信息，例如通过引用预定义的域配置文件进行确认；

  • 验证数据产品未与不应拥有访问权限的账户或角色共享；

  • 根据需求验证数据产品是否允许（或禁止）重新共享；

  • 其他类似规则。

DESCRIBE LISTING 命令以及 information_schema.listings 视图（目前处于私密预览阶段）能够提供列表的所有元数据，以便自动验证此类规则。例如，存储过程可以根据公司标准验证列表配置，并在需要时采取相应措施。

数据产品版本管理

许多数据产品会随时间演进，您可能需要实施一套版本管理方案。

每个数据产品定义（Snowflake 产品清单）均以 YAML 文件形式呈现，支持对产品进行程序化管理。这些 YAML 文件可存储于 Git 仓库或 Snowflake 版本化阶段中。若采用后者，请熟悉 Snowflake 文档中的以下命令：

CREATE ORGANIZATION LISTING ... FROM <yaml_stage_location>;``SHOW VERSIONS IN LISTING <listing_name>;``ALTER LISTING <listing_name> ADD VERSION FROM <yaml_stage_location>;``DESCRIBE LISTING <listing_name>;

复制代码

当您对数据产品进行非向后兼容的重大变更（例如移除视图或列）时，建议遵循以下步骤：

  • 提前向数据产品用户充分告知即将进行的变更；

  • 发布数据产品 V2 版本，并在一段时间内（例如 6 周或 3 个月）继续维护 V1 版本，以便用户完成迁移；

  • 最终下线并废弃数据产品 V1 版本；

  • 充分利用与数据用户间的沟通渠道，确保信息传递到位。

非 Snowflake 数据产品在 Internal Marketplace 中的管理

用户可将非 Snowflake 数据产品发布于 Internal Marketplace 实现可发现性。此类产品可包含其他存储库中的数据资产，或第三方工具（如 Power BI、Tableau、Qlik、Microstrategy 等）中的报表与仪表板。

  • 创建产品列表时需填写描述、所有权信息及其他外部资产相关详情；

  • 建议定义自定义数据产品属性，以便列表所有者能以结构化、可筛选且统一的方式标注产品的类型、来源或其他关键属性；

  • 在列表描述中需包含一个或多个指向外部资产的 URL 链接；

  • 当前发布此类列表仍需创建一个空的“虚拟”共享单元作为技术前提；

  • 外部资产的访问授权将在 Snowflake 平台之外进行管理。

角色与权限管理

您需要为 Internal Marketplace 上的数据产品选定合适的访问与权限管理模式。目前主要有两种方案，请根据您的实际需求与流程选择最适配的方案。

**方案一：**当用户需要访问某个数据列表时，可将相应用户账户与角色添加至该列表的定向访问列表（即授权列表）中。

  • 例如，若某个列表原本仅允许角色 0 访问，现需为拥有角色 1 的用户开放访问权限，则可将角色 1 添加至该列表的可访问角色集中（如下图所示）；

  • 该方案通常适用于基于 Snowflake 平台内部的请求与审批流程。

**方案二：**当用户需要访问某个数据列表时，可为该用户授予已具备该列表访问权限的现有角色。

  • 例如，若某个列表已允许角色 0 访问，现需为拥有角色 1 的用户开放访问权限，则可将角色 0 授予角色 1。角色 0 可以是仅针对此单一列表的技术访问角色，也可涵盖多个列表的访问权限集合。

Image 4

向角色 1 授予数据产品访问权限的替代方案

数据产品监测

您可在组织账户中创建跨域仪表板以追踪所需指标。仪表板中的每个磁贴均显示一项查询结果。目前这些查询的源数据主要来源于以下视图：

Image 5

数据产品活动仪表板

总结

Snowflake 平台及其 Internal Marketplace 提供了全面的数据产品管理能力，包括：

  • 提供丰富的文档、服务等级目标（SLOs）及元数据，使数据产品易于理解且值得信赖；

  • 基于角色的权限设定，明确谁可发现或访问特定数据产品；

  • 具备审计追踪功能的访问请求与审批流程；

  • 可为数据产品添加广泛的数据治理策略；

  • 追踪与度量数据产品的使用情况；

  • 支持跨云区域和跨平台共享与使用数据产品的组织；

  • 支持高级数据产品载体，如笔记本、语义模型及 AI 智能体。

本文探讨的最佳实践可帮助您成功应用上述能力，并使其与现有 IT 架构和流程保持高度协调。.

原文地址：https://medium.com/snowflake/best-practices-for-adopting-the-snowflake-internal-marketplace-ba4440838d32

Image 6

点击链接立即报名注册：Ascent - Snowflake Platform Training - China，更多 Snowflake 精彩活动请关注专区。

关联主题

关系图谱

反向链接