"每位分支机构经理只能看到本单元的数据；管理层则能看到全部。"这是一个常见的需求——而第一反应往往是"那我们就需要付费版"。其实未必。用Metabase 开源版配合数据架构就能解决，本文将说明如何实现（以及什么时候 OSS 确实不够用）。
问题所在：多位管理者、一个面板、不能混在一起的数据
在多单元运营中，同一个仪表盘需要向不同的人展示不同的现实。如果库里蒂巴分支机构的经理打开面板却看到了圣保罗的数据，你就有了一个信任问题——有时甚至是合同问题。
OSS 的思路：在数据层隔离，而非在过滤层
在开源版中，稳固的隔离发生在 Metabase 之前，即在数据仓库层面。每个分支机构成为一个独立连接——拥有自己的 schema（或自己的数据库），其中只包含属于自己的数据。Metabase 将每个都作为独立数据源接入。
- 每个单元一个 schema，在加载时仅填充该分支机构的数据切片。
- Metabase 中为每个 schema 建立一个连接（Database）。
- 按连接镜像仪表盘，或为有权查看全部的人建立一个合并视图。
用户组与按集合设置的权限
连接隔离之后，Metabase 通过用户组和按集合设置的权限将人员与数据绑定："库里蒂巴分支机构"组只能访问库里蒂巴的连接和集合；"管理层"组访问合并视图。这是一种简单、可审计、且为 OSS 原生支持的访问管理方式。
OSS 何时不够用：data sandboxing
要如实面对局限。如果你需要同一个查询能根据登录用户自动过滤行——无需复制仪表盘、也无需拆分连接——那就是 data sandboxing，它只存在于 Metabase Pro/Enterprise 中。对于拥有数十个使用相同仪表盘的分支机构而言，sandboxing 物有所值。而对于少数几个数据在加载时就能拆分的单元，OSS 就绰绰有余。
治理检查清单
- 敏感数据是否在进入 Metabase 之前就已隔离（按单元划分 schema/连接）？
- 每个用户组是否只能访问属于自己的连接和集合？
- 是否存在一个受限的合并组供管理层使用？
- 当有人变更职务时，权限是否会得到复审？
常见问题
在 Metabase 开源版中能实现行级安全吗？
原生上不能——根据登录用户按行自动过滤（data sandboxing）是 Metabase Pro/Enterprise 的功能。在开源版中，你可以通过按 schema/连接隔离数据、并将用户组和集合分别绑定到每一个，来获得相同的实际效果。当单元数量可控时，这种方式效果非常好。
Metabase 能支撑多少个连接？
远多于大多数运营所需。瓶颈很少在于连接数量，而在于背后的数据库；因此，在一个索引良好的单一数据仓库中按 schema 隔离，通常比运维数十个独立数据库更简单。