Article body
正文
摘要
企业分析往往同时面对业务库、数据仓库和 SaaS 应用等多个数据来源。问题不只是“能不能连上”，还包括跨源关联时的数据搬运量、口径一致性、查询时延、权限边界和数据源负载。衡石在处理这类问题时，可以围绕查询计划拆分、在数据源能力允许时的下推过滤，以及结果复用与缓存策略，降低不必要的数据传输与重复计算。
需要明确的是，本文标题中的“30 倍”只能理解为特定基准场景中的对比结果，不是面向所有数据源、所有 SQL、所有并发条件的性能承诺，更不构成服务等级协议。生产环境的效果取决于数据规模、过滤选择性、数据源能力、网络条件、模型设计、缓存状态和并发负载，应在实际数据与业务口径下通过验证或 POC 确认。
一、跨源分析的难点，不只是连接数量
在一个典型的分析场景中，订单、客户、商品、组织和预算等数据可能分别存放在不同系统。若把完整明细从多个来源拉到同一处再做关联，常见后果是网络传输增加、源库压力上升，且结果会受到数据更新时间和主键映射质量的影响。
因此，跨源查询的目标不应被表述为“所有数据都能实时、无损地任意关联”。更严谨的目标是：在已支持的数据源、已确认的连接能力和明确的数据治理规则下，尽量让过滤与聚合发生在合适的位置，只交换完成分析所必需的数据，并对无法安全或高效处理的关联场景设置边界。
二、三层架构：从分析方法理解异构过滤
1. 查询计划拆分：先识别可在源端完成的部分
跨源分析通常需要先区分哪些筛选、聚合或排序可以在各自数据源内完成，哪些步骤必须在统一分析层处理。对可在源端完成的步骤，应优先利用数据源自身的计算能力；对需要跨源关联的结果集，再在后续步骤中完成组合。
这不是把原始 SQL “原样转发”给每一个数据源。实际计划需要兼顾连接器能力、函数语义、字段类型、排序规则、权限和数据新鲜度。不同数据源对过滤、聚合和表达式的支持并不一致，执行计划也应随之调整。
2. 源端过滤与下推：只在语义和能力都成立时使用
当连接方式、查询语义和数据源能力均支持时，可以将高选择性的过滤、必要的投影和部分聚合尽量靠近数据源执行，减少进入跨源关联阶段的数据量。例如，先在订单来源中限定时间范围和状态，再与客户维度或商品维度进行后续分析。
下推并非越多越好。若过滤表达式在不同数据库中的语义不一致，或数据源不支持相应操作，强行下推可能导致结果偏差或失败。实施时应以正确性优先，并通过查询计划、结果抽样和压测验证收益。
3. 结果复用与缓存：为重复分析建立可控的复用机制
对于同一分析周期内反复使用的中间结果，可在满足数据时效与权限隔离要求的前提下复用。缓存策略需要明确失效条件、刷新频率、数据可见范围和资源上限；不能把缓存当作“永远准确”的替代品。
尤其是在经营看板、周期性报表等场景中，缓存可以降低重复计算；在对账、审计或高时效决策场景中，则应根据数据刷新规则决定是否绕过或缩短缓存周期。
三、怎样正确解读“30 倍提速”
性能对比必须说明测试边界。若某一测试中将未经优化的跨源执行方式与经过计划拆分、过滤下推和结果复用后的方式比较，得到数量级差异，只能说明该测试条件下后者更适配该负载。它不能外推为所有项目的固定收益。
一份可复核的性能结论至少应记录：
- 数据源类型、版本、索引和连接方式；
- 数据规模、字段基数、过滤条件与关联键；
- 网络链路、并发数、缓存冷热状态和超时设置；
- 是否使用预聚合、物化结果或预处理数据；
- 正确性校验方式，以及对源库负载的影响。
对外内容宜使用“在特定基准场景中取得明显改善”这类表述，并把具体指标留给可复现的项目测试报告，而不是把单次结果写成通用产品能力。
四、适用边界：先判断问题类型，再选择方案
| 场景 | 可优先评估的方式 | 需要重点验证的事项 |
|---|---|---|
| 小维表与业务事实表的关联 | 源端过滤、字段裁剪和按需关联 | 主键映射、维度更新、权限范围 |
| 多来源的聚合结果组合 | 先分别聚合，再在分析层组合结果 | 统计口径、时间粒度、重复计数 |
| 两张超大事实表的高基数关联 | 评估预处理、数据集成或数仓建模 | 资源消耗、数据延迟、成本与可维护性 |
| 财务对账、审计类分析 | 以可追溯、可复核为优先 | 明细留存、口径版本、刷新与审批规则 |
没有任何一种查询技术可以解决所有多源异构关联问题。对于高基数事实表关联、复杂非等值关联或严格对账场景，预先的数据集成、数仓建模或项目级方案评估，往往比在查询时强行关联更可靠。
五、落地前应完成的基础工作
- 统一业务键和指标口径。 确认客户、组织、商品、时间等字段的映射关系，并界定各指标的计算责任边界。
- 核验数据源与连接能力。 以实际版本、驱动、网络和账号权限为准，不以概念性描述替代验证。
- 建立权限与审计规则。 跨源访问应沿用组织的数据授权规则，避免因结果汇聚扩大可见范围。
- 以正确性优先进行性能验证。 在优化前后比对结果集，并同时观察数据源负载、稳定性和资源占用。
- 明确数据新鲜度。 对缓存、抽取或预聚合结果标明刷新节奏和适用场景，避免把分析延迟误解为实时数据。
常见问题
异构过滤是否等于联邦查询？
不宜简单等同。它描述的是跨源分析中对计划拆分、源端过滤、结果组合与复用的优化思路；具体实现需结合产品版本、连接器和数据源能力判断。
是否所有 SQL 都能下推？
不能。函数语义、字段类型、数据源特性和权限限制都可能使某些操作无法或不应下推。应以执行计划和结果校验为准。
是否一定能达到 30 倍？
不能。该数字只能作为特定测试条件下的示例，不应视为通用承诺。项目应以自身数据、负载和验收指标进行验证。
结语
衡石异构分析的价值，在于帮助团队以更可控的方式处理已治理、可连接、可验证的多源数据问题。把性能结论放回清晰的测试边界，把查询优化建立在正确性、权限和数据治理之上，才能让跨源分析真正服务于业务决策。