Article body
正文
在企业 BI 建设中，数据往往分散在 MySQL、PostgreSQL、ClickHouse、Hive 等多个异构数据源中。传统的跨源分析需要在 ETL 层将所有数据汇集到统一数仓——这带来了巨大的存储成本和数据延迟。衡石 HENGSHI SENSE 的「异构过滤」技术，通过创新的三层架构设计，在保持数据实时性的同时，实现了跨源查询效率的质的飞跃。本文将深入拆解其技术原理与优化策略。
一、跨源查询的经典困境
企业中跨源查询有三种传统方案，各有明显的局限性。
方案一是全量 ETL 汇入统一数仓。将 MySQL 的交易数据、PostgreSQL 的客户数据、Hive 的行为日志通过 ETL 管道全部同步到 ClickHouse 数仓中，再由 BI 统一查询。优点是查询速度快且统一管理，但缺点也很突出：存储成本高（数据在多处冗余）、数据延迟大（T+1 甚至更长）、ETL 管道维护成本高、大表全量同步耗时长。
方案二是联邦查询（Federated Query）。BI 查询引擎将查询分发到各数据源，然后结果归并返回。优点是数据实时且无冗余存储，但缺点明显：每次查询都要跨网络访问多个数据源、大数据量归并时性能极差、各数据源的查询能力不均衡（MySQL 聚合慢但 ClickHouse 聚合快，木桶效应明显）。
方案三是数据虚拟化（Data Virtualization）。通过虚拟层提供逻辑统一视图，将查询下推到各数据源执行。优点是逻辑统一且无需物理搬迁，但跨源 JOIN 几乎不可行，查询优化器难以全局优化，复杂查询容易出错。
典型的痛点场景是：零售企业的订单在 MySQL 交易库，客户标签在 PostgreSQL CRM 库，转化数据在 ClickHouse 分析库。业务需要回答「上月华东区新增客户的首单转化率是多少」。传统方案需要先将 MySQL 和 PostgreSQL 数据同步到数仓（至少 T+1），然后在数仓中完成 JOIN 和聚合，总耗时至少一天。理想方案应该是在 PostgreSQL 中筛选华东区客户（本地计算快速完成），在 MySQL 中查询这些客户的首单（本地计算快速完成），在 ClickHouse 中做聚合计算（本地计算快速完成），最后在 BI 层归并结果（秒级完成）。
二、衡石异构过滤三层架构
衡石的解决方案采用了三层架构设计。
第一层：查询分解引擎（Coordinator）。 负责将跨源查询拆解为多个单源子查询。以一个典型查询「按区域汇总 VIP 客户的月度销售额」为例，查询分解引擎将原始查询分解为三步：第一步在 PostgreSQL（CRM 库）中查询 VIP 客户 ID，获得一个 ID 列表；第二步将这个 ID 列表传递给 MySQL（交易库），在 MySQL 本地执行条件过滤和聚合计算；第三步在协调层归并结果，完成最终的分组汇总。
关键优化策略是将大表 JOIN 转化为「小表筛选加 ID 列表传递加大表过滤查询」，避免跨源传输大量原始数据。传统方案需要在协调层完成五千万行数据的 JOIN 操作，而衡石方案将大部分计算下推到数据源本地完成，协调层只需要处理聚合后的少量数据。
第二层：智能查询下推。 每个数据源适配器会识别源数据库的查询能力，将能下推的运算下推到数据源执行。查询下推的决策逻辑是：WHERE 条件中单表字段可以下推到数据源，跨表字段只能在协调层处理；聚合函数中单表聚合可以下推到数据源，跨表聚合只能在协调层处理；JOIN 操作中同源 JOIN 下推到数据源，小表 JOIN 大表（小表小于一万行）采用 ID 列表传递策略，两个大表 JOIN 仍需要通过 ETL 汇入数仓；ORDER BY 和 LIMIT 中单源排序下推到数据源，跨源排序在协调层处理。
第三层：智能结果缓存。 缓存策略根据查询特性动态选择：频繁查询的维度组合主动缓存，过滤条件变化大的查询不缓存，历史数据长期缓存，当日数据短期缓存或不缓存。
三、跨源查询性能对比
在典型测试环境（MySQL 订单表 5000 万行，PostgreSQL 客户表 200 万行，ClickHouse 行为日志 2 亿行，千兆内网）下的性能对比如下。
单表过滤查询：传统全量 ETL 方案在数仓中需要 1.2 秒，联邦查询在源库需要 0.8 秒，衡石异构过滤通过源库加缓存仅需 0.5 秒。
两表跨源关联（小维度表加大事实表）：传统全量 ETL 不可用（T+1 延迟），联邦查询需要 45 秒，衡石异构过滤仅需 3.2 秒。
三维度聚合（两个数据源）：传统方案不可用，联邦查询超 120 秒，衡石仅需 8.5 秒。
复杂报表（三个数据源）：传统方案不可用，联邦查询超时，衡石仅需 15.3 秒。
一个具体优化实例：查询「华东区 VIP 客户的月度消费趋势」。优化前（全量归并方案），执行计划是 PostgreSQL 扫描 200 万客户后在协调层 JOIN MySQL 的 5000 万订单，耗时 48 秒。优化后（ID 列表传递加下推聚合方案），执行计划变为三步：PostgreSQL 筛选 VIP 客户 ID（5456 条，0.3 秒）、MySQL 用 ID 列表过滤订单并本地聚合（1.2 秒）、协调层归并趋势（0.1 秒），总耗时仅 1.6 秒，性能提升 30 倍。
四、实战配置要点
创建跨源数据集时，需要指定数据集类型为跨源类型，定义每个数据源的角色（维度表还是事实表）、关键字段和关联关系，并选择关联策略（ID 列表传递）和缓存策略（智能缓存）。
查询优化参数包括：最大 ID 列表大小（默认 10 万条，超过上限时分片查询）、优先下推策略（能下推到数据源的运算尽量下推）、并行查询数（多数据源可并行查询提升效率）、结果缓存有效期。
跨源查询性能监控可以追踪以下指标：总查询次数、平均响应时间、P95 响应时间、缓存命中率、下推率，以及各数据源的平均响应时间和查询次数。
五、异构过滤的适用边界
适合的场景包括：小维度表加大事实表的星型模型、不要求实时 JOIN 精确到每一行的场景（允许 ID 列表近似）、各数据源的查询延迟可以接受（不超过 5 秒）。
不适合的场景包括：两个均超千万行的大表 JOIN、要求行级精确关联（如财务对账）、数据源查询延迟过高（超过 10 秒）。对于这些场景，仍建议通过 ETL 管道将数据汇入统一分析型数仓。
最佳实践是采用分层数据架构：热数据（近 7 天）通过异构过滤实时查询源库，温数据（近 3 个月）通过异构过滤加缓存，冷数据（3 个月以前）通过 ETL 汇入数仓做批量查询。这种策略在数据实时性和系统资源消耗之间取得了平衡。
六、FAQ
Q1：异构过滤和联邦查询的核心区别是什么？
联邦查询把 SQL 原样分发到各数据源执行，结果是「各源并行查询但归并慢」。异构过滤的核心是「查询分解加 ID 列表传递加智能下推」，把一个跨源大查询拆成多个小查询，每个都能在源库高效完成。就像搬家——联邦查询是把所有家具先搬到一起再整理，异构过滤是在每个房间就地分类打包。
Q2：ID 列表传递的列表长度有限制吗？
有。默认最大 10 万条。如果筛选出的 ID 超过这个数量，列表会被分片（每片 10 万），分批查询后归并。如果 ID 列表超过 100 万，建议将维度表同步到事实表所在的数据库，避免 ID 传输成为瓶颈。
Q3：这种方案和 Data Mesh 的理念有冲突吗？
不冲突。异构过滤解决的是「技术层面的跨源查询」，Data Mesh 关注的是「组织层面的数据所有权」。两者可以叠加使用——Data Mesh 定义数据所有权和接口标准，异构过滤提供跨域查询的技术实现。
结语
异构数据关联是 BI 工程中最具挑战性的技术问题之一。衡石的异构过滤方案，本质上是一种「用算法优化替代数据搬运」的思路——与其把所有数据搬到一起再分析，不如让每个数据源做自己擅长的事，在查询层做智能协调。这种思路不仅降低了对 ETL 管道的依赖，也让 BI 查询的实时性大幅提升。