在建设 BI 平台时，数据架构经常从一个问题开始：报表应该直接查询业务数据库，还是先把数据抽取到分析库？
这个问题没有“永远正确”的答案。直连强调时效和链路短，抽取强调稳定和可治理；再配合缓存与跨源建模，才能覆盖企业真实的分析场景。合理的做法不是二选一，而是根据数据时效、查询复杂度、并发规模和安全要求进行组合。
先看两种模式的边界
1、实时直连：数据就在源头查询
直连模式不复制数据，报表或大屏的分析请求到达时，由 BI 引擎向业务数据库发起查询。它的优势是数据实时、链路简单，适合库存余额、订单状态、生产进度、客服工单等分钟级甚至秒级变化的场景。
直连的代价也很明确：查询性能受源库资源、网络延迟和 SQL 复杂度影响；当多个用户同时进行多维筛选、钻取或导出时，可能与交易业务争抢 CPU、IO 和连接数。
采用直连前，至少要确认三件事：源库是否有只读副本或分析库；是否能为常用过滤字段建立索引；慢查询和并发是否有监控、超时与限流机制。对核心交易库直接放开任意 SQL，通常不是一个可持续的方案。
2、抽取：在时效和性能之间取一个平衡
缓存不是独立的数据架构，而是把数据抽取到内存。对相同参数、相同时间范围的查询，可以直接复用结果，减少数据库压力。
缓存适合访问频率高、变化频率低的内容，例如管理驾驶舱首页、组织维度字典和最近一天的汇总指标。设计缓存时要明确失效策略：按时间过期、按数据任务刷新，还是由业务事件主动清理。缓存时间过长会造成“看起来很快，但数据已经过时”；缓存粒度过细又会降低命中率并增加内存占用。
用四个指标做技术选型
1. 数据时效
先定义业务真正需要的时效，而不是笼统地追求“实时”。实时监控可能要求秒级，经营分析通常接受小时级，财务结算则更重视数据冻结和可追溯。时效要求越高，越倾向直连或实时增量；时效要求越低，越适合抽取和预聚合。
2. 查询复杂度
单表查询、少量筛选和固定指标适合直连。跨表关联、复杂计算、历史拉链和多层汇总更适合在抽取阶段完成。把复杂逻辑留到用户每次打开报表时计算，容易造成响应抖动。
3. 并发与数据规模
低并发、低数据量时，直连的工程成本较低；当用户数、报表数量或导出任务增加，抽取、缓存、汇总表和只读副本可以把分析负载隔离出来。性能评估应使用真实筛选条件、峰值并发和导出数据量，不能只看单用户打开页面的耗时。
4. 治理与安全
需要统一指标、行列级权限、审计和多租户隔离时，数据模型比连接方式更重要。无论直连还是抽取，用户权限都必须在查询、缓存、导出和分享环节保持一致，不能因为命中缓存就绕过数据过滤。
Wyn 中的组合式实践
Wyn 商业智能提供直连模型和抽取模型，可以在同一平台中按业务场景组合使用。
一种常见做法是：生产订单和库存状态使用直连模型，保证业务人员看到最新状态；销售、采购、财务等多系统数据通过抽取和可视化建模整合，统一维度、度量和指标；管理驾驶舱对高频汇总结果启用缓存；复杂报表和 AI 分析则复用同一套语义模型。
这样做的关键，是让报表、大屏、自助分析和 AI 使用一致的数据定义，而不是为每种展示方式单独维护一套 SQL。数据源可以来自关系型数据库、国产数据库、Excel、CSV、JSON、Web API、大数据平台、NoSQL、时序数据库和实时推送数据，再根据时效与治理要求选择直连或抽取。
结语
直连和抽取不是互相替代的技术路线。直连解决“现在发生了什么”，抽取解决“跨系统和历史数据如何稳定分析”，缓存解决“高频访问如何更快”，跨源建模解决“不同系统如何形成同一个业务事实”。
BI 架构的成熟标志，不是所有数据都实时，也不是所有数据都进入数仓，而是每类数据都选择了与业务目标匹配的访问方式。通过 Wyn 商业智能的直连模型、抽取模型和多源数据接入能力，企业可以在保留数据时效性的同时，逐步建立可治理、可扩展的数据分析底座。
