多租户SaaS场景：事务库缓存报表vs data warehouse选型考量

做选型决策前不用盲目追求技术先进性，先对着下面几个维度摸清楚实际情况，选匹配度最高的方案即可：

数据规模与查询需求预期 #

• 先算清未来1-2年的真实数据量级：如果单租户核心业务表年增量在千万级以下、总付费租户规模不超过几百个，方案二（租户库建专用表存JSON缓存）完全够用，不会触发性能瓶颈；如果单租户年数据增量破亿、或者租户规模很快要冲到上千级别，哪怕有专用表，分析查询的IO争抢也会拖垮核心事务库，到时候再拆数仓的迁移成本反而更高。
• 摸透看板的查询复杂度：如果只是固定的几个统计卡片、固定周期的趋势图，没有自定义维度筛选、多表下钻、跨业务域复合指标的需求，预计算好JSON结果直接返回是性价比最高的方案；如果后续要支持自定义看板、ad-hoc查询、多维度交叉分析，数仓的维度建模能力才能扛住，靠存JSON的方式根本没法快速响应需求变更。

成本与团队能力匹配度 #

• 算清楚基础设施账：方案二几乎不需要新增组件，用现有MySQL实例就能跑，额外的存储和计算成本可以忽略；方案一不管是自建开源数仓（ClickHouse、Doris等）还是采购云数仓服务，都要额外承担数据同步链路、数仓存储计算的成本，初期投入至少是方案二的5到10倍。
• 评估团队的运维能力：数仓不是搭完就能用，需要持续做ETL任务调度、数据质量校验、元数据管理、故障排查，如果团队没有专门的大数据/数仓开发岗位，全靠后端开发兼职维护，大概率会出现数据延迟、数值不准、出问题没人能快速定位的情况，实际用起来反而不如业务库缓存可靠。

多租户架构的合规与扩展要求 #

• 确认租户数据隔离的合规要求：如果做的是金融、医疗类强监管行业的SaaS，要求租户数据必须物理隔离、不能流出所属数据库实例，那集中式数仓的方案天然不符合合规要求，只能在各租户库内做专用表缓存；如果是通用类SaaS没有强物理隔离要求，才可以考虑集中数仓的方案。
• 评估租户定制化需求的占比：如果有大量付费租户需要自定义看板、自定义统计指标，方案二给每个租户单独维护表结构、更新缓存逻辑的成本会随着租户数量线性增长，反而数仓统一建模+租户ID维度隔离的方式扩展性更强；如果所有租户的看板都是标准化统一配置，方案二的开发上线速度要快很多。

数据可靠性要求 #

• 明确看板的数据延迟容忍度：如果要求看板数据延迟在秒级，方案二的后台任务直接刷新同库缓存表，链路短、延迟低，很容易满足；常规数仓的同步链路一般是分钟级甚至小时级延迟，要做到秒级实时需要额外搭实时数仓链路，成本会再上一个台阶。
• 评估数据一致性的校验成本：方案二的缓存数据和业务数据在同一个数据库实例，对账、排查数据不一致的问题非常方便，写几条SQL就能核对清楚；数仓的数据是跨组件同步过去的，一旦出现同步丢数、延迟，需要排查源库、同步任务、数仓表三层链路，排查成本要高很多。

内容的提问来源于stack exchange，提问作者karim kamal