多租户 SaaS 系统的 BI 数据隔离方案：从逻辑隔离到物理隔离的实现路径

一、为什么 SaaS 产品的BI模块必须考虑数据隔离？

在 SaaS 模式下，一套软件服务着成百上千家客户（即"租户"）。对于集成了 BI 分析能力的 SaaS 产品来说，数据隔离不是可选项，而是生存底线------租户A的销售数据绝对不能出现在租户B的报表中。一旦出现数据越权访问，对 SaaS 厂商而言将是致命的合规灾难。

Wyn商业智能作为一款可嵌入 SaaS 应用的 BI 平台，原生支持多租户架构，能够灵活适配从逻辑隔离到物理隔离的不同数据安全策略。问题的关键不在于"要不要隔离"，而在于"隔离到什么程度"。

二、两种隔离模式的本质区别与适用场景

逻辑隔离（共享模式）

实现原理：所有租户共享同一个数据库实例，甚至共享同一张数据表，通过"租户ID"字段来区分数据归属。

适用场景：

租户数量庞大（数百至数千家）
大部分中小客户，数据敏感性一般
成本和运维效率是首要考量

优势：成本最低，扩展性最好，新增租户无需创建新数据库。挑战：依赖代码层严格过滤，误配置可能导致数据泄露。

物理隔离（独享模式）

实现原理：每个租户拥有独立的数据库，可以是同一服务器上的不同数据库，也可以是完全独立的数据库实例。

适用场景：

金融、医疗、政府等强监管行业
对数据安全有极致要求的大客户
客户明确要求数据物理分离

优势：安全性最高，即使数据库层面出现漏洞也不会导致跨租户泄露。挑战：成本高，管理复杂（每个租户需单独备份、监控）。

三、Wyn的两种隔离实现路径

路径一：基于组织上下文的逻辑隔离（数据源级路由+行级/语义模型过滤）

这是 Wyn商业智能实现多租户逻辑隔离的核心机制，通过"组织信息上下文"让租户在共享资源下只能看到自己的数据，组织上下文来源于系统管理员在组织管理中定义的组织模型属性，登录用户所属组织的属性值会在查询时被字段注入。

数据源连接串动态路由（适用于每个租户有独立数据库的场景）

Wyn商业智能允许在数据源的连接字符串中使用组织属性作为占位符。例如，为每个组织定义一个DBName属性，然后在连接字符串中写成Database=#{DBName}。

当不同租户的用户登录并访问该数据源时，Wyn 会自动将#{DBName}替换为该租户对应的数据库名称，实现"同一个数据源定义，访问不同物理库"的效果。这本质上是把各自独立的物理库通过同一个 Wyn 数据源定义来统一访问，既保留了物理隔离，又避免了为每个租户单独维护数据源带来的运维负担。

数据集/数据模型的行级过滤（适用于所有租户共享同一张表的场景）

如果所有租户的数据存储在同一个表的同一套表结构中，Wyn可以在数据集或数据模型层设置基于组织上下文的过滤条件。

操作方式是在数据集设计器中添加"组织信息上下文"类型的参数，并在查询过滤条件中使用该参数。系统会在 SQL 执行层自动注入类似WHERE TenantID = 当前租户ID的条件，对用户完全透明，无法绕过。数据模型中可使用安全过滤器，以用户信息上下文/组织上下文作为取值实现行级隔离，效果与数据集参数过滤一致。