多源异构数据联邦查询平台
公开说明
本文是经过脱敏处理的项目介绍，仅保留通用的数据平台问题、公开技术方案和个人工作，不涉及具体应用单位、业务对象、真实数据、资源规模、内部地址、权限策略内容或部署参数。
项目总览
下面完整呈现原演示文稿的第 4 页。点击演示区域后，可按 F 进入全屏、按 Esc 查看总览。
项目背景
不同业务系统会根据数据特点选择关系型数据库、缓存、文档数据库、时序数据库、文件存储或图数据库。单个系统能够完成自己的查询，但当分析任务需要同时关联多种数据时，应用往往必须分别访问多个数据源，再在业务代码中手工完成转换、过滤和聚合。
这种方式容易形成数据孤岛：查询入口和数据模型不统一，跨源关联依赖定制代码；每增加一种数据源都要重复开发连接、分页、异常和类型转换逻辑；权限、审计、超时和资源限制也分散在各个系统中。
项目因此建设了一套多源异构数据联邦查询平台。在不强制搬迁原始数据的前提下，通过统一查询引擎连接不同类型的数据源，为上层应用提供统一 SQL、跨源关联、权限治理和查询加速能力。
系统解决的问题
- 对多种异构数据源提供统一查询入口；
- 保留各存储系统原有优势，避免重复建设新的数据副本；
- 支持跨数据源过滤、聚合和关联分析；
- 将查询接入、权限校验与审计能力集中治理；
- 尽可能把过滤和投影下推到数据源，减少无效数据传输；
- 为重复访问的文件型数据提供可控缓存；
- 保护底层数据源，避免大范围查询影响原有业务。
整体设计
应用、分析工具和可视化页面
↓
统一 SQL 查询入口
↓
联邦查询、权限和资源治理
↓
关系数据 / 缓存 / 文档 / 时序 / 文件 / 图数据Presto 负责 SQL 解析、执行计划、分布式调度和跨源计算；Connector 负责把不同数据源映射为统一的 Catalog、Schema、Table 和 Column；权限组件负责访问控制和审计；缓存层用于降低热点文件的重复远程读取。
平台不会替代底层数据库的专业能力。实时缓存、时序写入、复杂图遍历和文件归档仍由相应系统完成，联邦查询层专注于统一访问和跨源分析。
我的主要工作
1. 技术方案与平台集成
参与梳理不同数据源的数据模型、查询方式和权限边界，完成联邦查询引擎、文件缓存和权限组件的方案验证、搭建集成、现场部署及故障排查。
2. 多层级访问控制
参与查询入口与权限系统的集成，使权限校验覆盖数据目录、命名空间、表、字段以及必要的数据过滤范围。围绕策略数量增加后的匹配成本，对策略进行预分类和快速预判，减少明显不可能命中的无效遍历。
权限实现始终以最终策略校验为准，快速预判只用于缩小候选范围，不能直接产生授权结果；对外也不暴露完整策略内容，避免权限规则反向泄露数据边界。
3. 图数据库 Connector
基于 Connector SPI 开发图数据库连接器，完成元数据、字段类型和结果数据之间的映射，打通图数据与统一 SQL 查询入口。
针对普通属性查询，支持字段选择、过滤和数量限制等安全下推，降低不必要的数据回传；针对多跳关系、路径分析等图数据库特有能力，保留原生图查询入口，由图数据库完成遍历后再把结果交回查询引擎参与跨源关联。
下推优化遵循“正确性优先于下推率”：只下推能够证明语义一致的条件，无法保证类型、空值或边界语义一致的部分继续由查询引擎处理。
4. 文件数据缓存与链路隔离
参与在查询引擎和分布式文件存储之间接入 Alluxio 缓存层，减少热点文件的重复远程读取。为了不影响共享元数据的其他计算引擎，缓存路由只在查询引擎内部生效，不修改公共元数据中的原始文件地址。
5. 缓存准入与污染控制
单纯把所有访问过的数据写入缓存，会导致一次大范围历史查询挤出真正的热点数据。项目通过“数据集准入 + 时间范围”控制哪些文件有资格进入缓存，超出范围的数据仍可正常查询，但直接访问事实数据源，不污染热点空间。
缓存恢复时也不能只看进程是否启动，还要综合命中率、回源压力和任务积压判断是否具备服务能力，再逐步恢复查询流量。
6. 部署与运行支持
参与平台现场部署、跨组件链路验证、问题排查、技术文档整理和交付后的运行支持。排查时从查询计划、任务与节点状态、过滤下推、源库压力、缓存命中和文件读取链路分层定位问题。
关键技术思考
为什么采用联邦查询
联邦查询的目标不是把所有数据集中搬迁，而是在数据仍由原系统管理的情况下提供统一访问。这样既保留各类存储的专业能力，也减少数据复制、同步和生命周期管理成本。
如何平衡性能与正确性
过滤下推和复杂查询改写能够减少传输与计算，但任何优化都不能改变查询语义。实现时优先使用结构化条件和参数化查询，覆盖空值、数值边界、字符串转义和类型冲突等测试；不能证明等价的表达式不进行下推。
如何保护底层系统
统一查询入口不代表可以无限扫描底层数据。平台需要结合并发、超时、扫描范围、查询规范、只读链路和数据分层保护源系统；适合长期分析的数据应尽量进入文件或分析型存储，避免持续冲击在线业务库。
缓存为什么需要治理
缓存层本身也可能放大压力。冷启动、批量回源和冷数据污染都会让请求集中落到底层存储，因此需要准入规则、分批预热、并发限制、降级和就绪状态判断，而不是把“进程存活”等同于“缓存可服务”。
项目结果
- 建立面向多种数据类型的统一 SQL 查询入口；
- 支持跨源查询、关联分析和统一权限治理；
- 完成图数据库连接器并接入联邦查询链路；
- 通过安全下推减少不必要的数据回传与计算；
- 建立文件数据缓存、准入控制和动态路由机制；
- 降低热点文件的重复远程读取和底层存储压力；
- 完成实际环境部署、联调、问题排查和运行支持。
项目让我积累了分布式查询、Connector 扩展、谓词下推、细粒度权限、图数据接入、缓存治理和跨组件运维等实践经验。