PAYATHON 2026

Snowflake Feature Store 如何按团队控制访问权限？

数据小许

结论

同一个 Feature Store 可以通过底层对象的 Snowflake RBAC 控制数据访问，无须仅因数据权限为不同团队拆库。目前官方 list_feature_views() 接口没有 group 参数，也没有文档化的团队分组授权参数，因此列表筛选和权限控制需要分别处理。

即使拆分 schema，独立的 Feature Stores 之间仍可共享特征。官方明确支持有权访问多个 Feature Stores 的用户组合其中的 Feature Views，生成训练和推理数据集。Feature Store 官方说明

为什么不能只根据列表结果判断权限失效？

Feature Store 对应一个 schema。常规 Feature View 的底层对象是 dynamic table 或 view，受 Snowflake 权限规则约束。排查时需要分别验证角色能否发现对象、读取元数据和查询特征数据：看到名称并不等于有权读取数据。底层对象模型

当前公开的 SDK 源码显示，发现常规 Feature Views 时会查询底层 dynamic tables 和 views。SHOW DYNAMIC TABLES 也有自身的权限可见性规则，因此不能一概认为 SDK 会向任何角色列出全部对象。拥有 MANAGE GRANTS 的角色尤其可能看到全部对象。SDK 源码、SHOW DYNAMIC TABLES 权限说明

先排查实际生效的角色与授权

在 SDK 使用的同一个 Snowpark Session 中检查角色。示例中的 TEAM_B_READER 是需要预先配置的测试角色：

session.sql("USE ROLE TEAM_B_READER").collect()
session.sql("USE SECONDARY ROLES NONE").collect()

session.sql("SELECT CURRENT_ROLE()").show()
session.sql("SHOW DYNAMIC TABLES IN SCHEMA ML_DB.SHARED_FS").show()
session.sql("SHOW VIEWS IN SCHEMA ML_DB.SHARED_FS").show()

fs.list_feature_views().show()

USE SECONDARY ROLES NONE 用于排除其他已激活角色的影响，但仍需检查主角色继承的权限。这只是诊断步骤，不能阻止用户之后重新启用自己已经获授的其他角色。Secondary roles 说明

重点核查以下配置：

  • 团队角色是否继承了覆盖整个 schema 的 consumer 或管理角色。
  • 是否存在针对 ALL 或 FUTURE 对象的广泛授权。
  • 敏感对象的访问权限是否仍通过其他角色或 PUBLIC 授予用户。
  • Python SDK 与 SQL 测试是否使用相同用户、Session 和角色。

官方 RBAC 示例包含对 schema 内全部现有及未来 dynamic tables、views 的授权。如果两个团队继承了这种共享 consumer 角色，逐对象追加授权无法缩小原有权限。Feature Store RBAC 配置

单个 schema 内如何配置选择性访问？

为团队配置独立的 account roles，只授予所需底层对象的访问权限。以下示例展示读取权限配置。角色和对象须事先存在，<实际对象名> 必须替换为确认后的物理名称，包括版本和大小写。

GRANT USAGE ON DATABASE ML_DB TO ROLE TEAM_B_READER;
GRANT USAGE ON SCHEMA ML_DB.SHARED_FS TO ROLE TEAM_B_READER;
GRANT USAGE ON WAREHOUSE ML_WH TO ROLE TEAM_B_READER;

-- 对允许共享的、由 dynamic table 支撑的 Feature View 授权
GRANT SELECT, MONITOR
  ON DYNAMIC TABLE ML_DB.SHARED_FS."<实际对象名>"
  TO ROLE TEAM_B_READER;

-- 若目标由普通 view 支撑，则使用下面这类授权
-- GRANT SELECT, REFERENCES
--   ON VIEW ML_DB.SHARED_FS."<实际对象名>"
--   TO ROLE TEAM_B_READER;

这些权限对应官方消费者权限模型。生成训练数据时，可能还需要目标 schema 的建表或 Dataset 权限；不要因此授予源 schema 内所有特征的读取权限。消费者权限要求

新版本注册或对象替换后的授权也应纳入发布流程。可以维护包含 Feature View、版本和消费角色的授权清单，由注册流程同步应用。命名前缀有助于组织对象，但不会自动建立权限边界。

SDK 能否按团队或业务域分组？

官方接口支持 entity_name 和 feature_view_name 筛选，例如：

fs.list_feature_views(
    feature_view_name="transaction_features_fv"
).show()

这些参数用于发现特征，不会授予或撤销访问权限，也不能代替 RBAC。Entity 表示特征所关联的业务实体，不宜仅为团队授权而改变其含义。FeatureStore API

当前文档中的 Feature groups 可将多个 Feature Views 组合成供训练和推理消费的版本化特征集合，但要求源 Feature Views 启用指定类型的在线服务。Feature groups 不能作为 list_feature_views(group=...) 的团队授权机制。Feature groups 说明

什么时候适合拆分 Feature Stores？

如果敏感特征的名称和元数据也需要严格隔离，或者逐对象授权难以维护，可以按安全边界划分 schema，例如 A 团队私有、B 团队私有和公共特征区。经过审核的非敏感特征可以放入公共区，也可以选择性授权另一团队读取所需对象。

独立的 Feature Stores 在权限允许的情况下仍可组合特征。跨 Feature Store 使用说明

验收时，需要同时检查未授权角色的 SQL 查询是否失败、SDK 是否暴露不应公开的元数据，以及已授权的共享特征能否正常使用。如果 SQL 与 SDK 使用同一 Session，收紧授权后两者的可见性仍不一致，应记录 snowflake-ml-python 版本、完整授权链和最小复现，交由 Snowflake 支持确认。现有材料不足以认定这是 SDK 缺陷。

备注：内容仅供参考。