多源异构数据联邦查询平台

公开说明

本文是经过脱敏处理的项目介绍，仅保留通用的数据平台问题、公开技术方案和个人工作，不涉及具体应用单位、业务对象、真实数据、资源规模、内部地址、权限策略内容或部署参数。

项目背景

该项目面向多类业务数据的统一检索与分析场景。受项目安全要求限制，公开内容不展示应用单位、真实数据、系统规模、内部地址、具体权限策略和部署参数，仅介绍通用架构与个人承担的技术工作。

不同业务系统会按照数据特征分别使用关系型数据库、缓存、文档数据库、时序数据库、图数据库和分布式文件存储。单个系统查询自己的数据并不困难，真正的痛点出现在跨源分析：上层应用需要分别连接多个数据源，在业务代码中完成类型转换、过滤、聚合和结果拼接。

随着数据源增加，这种点对点集成不断复制连接、分页、异常处理和权限逻辑，跨源 JOIN 更依赖定制开发；文件型历史数据被重复远程读取时，还会形成较长的 I/O 链路并增加底层存储压力。

项目的目标不是把所有数据搬到一个新仓库，而是在保留原有存储体系的前提下，建立统一 SQL、跨源计算、访问控制和查询加速能力。

要解决的核心问题

1. 统一入口：让 MySQL、Redis、MongoDB、Neo4j、InfluxDB 与 HDFS / ORC 等不同数据源通过一致方式被查询。
2. 跨源关联：把原本散落在业务代码中的数据拼接交给分布式查询引擎执行。
3. 异构适配：解决元数据、字段类型、查询语义和结果格式不一致的问题，并支持新增数据源扩展。
4. 权限集中治理：让目录、命名空间、表、字段及必要的数据范围校验进入统一链路，同时保护权限策略本身。
5. 查询链路提速：尽量把过滤、投影和数量限制下推到源端，并降低热点文件的重复远程读取。
6. 保护底层系统：避免大范围历史查询、缓存冷启动和批量回源把压力集中传导到事实数据源。

技术途径

应用 / 分析工具 / 可视化页面
              ↓
       Presto 统一 SQL 入口
              ↓
执行计划 / 跨源计算 / 权限与资源治理
       ↙             ↓              ↘
标准 Connector   Neo4j Connector   HDFS / ORC + Alluxio

1. 用 Presto 建立联邦查询层

以 Presto Coordinator / Worker 作为统一查询与分布式计算引擎，通过 Connector 将不同数据源映射为 Catalog、Schema、Table 和 Column。平台负责 SQL 解析、执行计划、任务调度和跨源计算，底层系统仍保留各自擅长的写入、存储和专业查询能力。

这种方式避免为统一查询再复制一套完整数据，也减少了新增数据源时上层应用的重复接入工作。

2. 开发 Neo4j Connector 补齐图数据接入

基于 Connector SPI 开发 Neo4j Connector，完成元数据发现、字段类型映射、查询生成和结果转换，使图数据能够进入统一 SQL 与跨源关联链路。

普通属性查询支持过滤、字段选择和数量限制等安全下推，尽量减少数据回传；多跳关系和路径分析等图数据库特有能力保留原生查询入口，由 Neo4j 完成图遍历后，再将结果交给 Presto 参与后续计算。

3. 以“语义等价”为边界做查询下推

下推并非越多越好。实现中优先处理结构化、可证明等价的条件，关注空值、类型转换、数值边界和字符串转义；不能保证与 Presto 语义一致的表达式留在查询引擎侧执行。这样在降低扫描量和源库压力的同时，不以查询正确性换取表面上的下推率。

4. 集成细粒度访问控制

将查询入口与 Ranger 等权限组件集成，使校验覆盖数据目录、命名空间、表、字段和必要的数据过滤范围。针对策略数量增加后的匹配成本，先做预分类和快速预判以缩小候选集，再执行最终策略校验。

快速预判只负责排除明显不匹配项，不能直接产生授权结果；外部接口也不返回完整策略内容，避免权限规则反向暴露数据边界。

5. 建立可回退的文件缓存链路

在 Presto 与 HDFS / ORC 之间接入 Alluxio，并将 Presto Worker 与 Alluxio Worker 协同部署，使热点文件尽量在计算节点附近被重复利用。

缓存路由只在 Presto 查询链路内部生效，不修改共享元数据中的原始文件地址。查询满足缓存条件时动态路由到 Alluxio；缓存不可用或不满足条件时安全回源 HDFS，从而不影响依赖同一份元数据的其他计算引擎。

6. 用准入与时间范围治理缓存

如果所有读过的数据都进入缓存，一次大范围历史查询就可能挤出真正的热点数据。项目通过“数据集白名单 + 时间范围 / 分区条件”识别缓存资格：命中的热点数据进入缓存，超出范围的数据仍可查询，但直接读取事实数据源。

运行侧同时关注冷启动批量回源、Presto Worker 异常和缓存恢复问题。恢复服务不能只看进程存活，还要结合命中率、回源压力和任务积压判断是否就绪，再逐步恢复流量。

我的核心工作

• 参与多源异构查询平台的方案研究、搭建集成、实际环境部署和故障排查；
• 梳理不同数据源的数据模型、查询方式和权限边界，完成跨组件链路验证；
• 集成细粒度权限组件，参与策略匹配优化与权限信息保护；
• 基于 Connector SPI 开发 Neo4j Connector，完成元数据、类型与查询结果映射；
• 优化过滤、字段选择和数量限制下推，同时保留复杂图查询的原生能力；
• 参与 Presto、Alluxio 与文件存储的缓存加速链路设计；
• 通过数据集准入、时间范围和动态路径路由控制缓存范围，降低冷数据污染风险；
• 从执行计划、任务状态、源库压力、缓存命中和文件读取链路等层面定位现场问题，并整理交付文档和运行支持材料。

项目亮点

不迁移数据，也能形成统一分析能力

联邦查询把“统一使用”与“集中存储”解耦。数据继续由原系统管理，上层获得统一 SQL 和跨源 JOIN，降低数据复制、同步和生命周期管理成本。

Connector 不只是连接，还负责把计算推近数据

Neo4j Connector 除了完成协议与类型适配，还结合查询特征实施安全下推；对图数据库的复杂遍历则保留原生能力，在统一抽象和专业能力之间取得平衡。

缓存优化与共享元数据解耦

缓存路径改写限定在 Presto 内部，失败时可回源原始 HDFS 路径，不改变公共元数据，也不把其他引擎绑定到缓存层，降低了引入缓存后的系统耦合和故障影响面。

把缓存当作需要治理的系统，而不是无限空间

通过白名单、时间范围、动态路由和就绪判断控制“什么进入缓存、何时使用缓存、异常时如何回退”，重点解决冷数据污染、冷启动回源风暴和缓存失效后的可用性问题。

落地结果

• 建立多类数据源的统一 SQL 查询入口和跨源关联能力；
• 完成 Neo4j Connector 接入及过滤、投影、数量限制等查询下推；
• 形成细粒度访问控制与审计链路；
• 建立可控、可回退的文件缓存机制，减少热点文件重复远程读取；
• 在实际环境完成部署、联调、问题排查并投入使用。

这个项目的核心价值，是在不改变各类数据原有归属和专业能力的前提下，把分散的数据访问、权限治理和性能优化收敛为一条统一、可扩展、可运维的查询链路。