企业数据流通与敏捷API交付实战（三）：数据湖、中间库与联邦查询对比

在实际的业务开发中经常会遇到跨异构数据库取数的需求。例如前端的大屏看板需要同时展示“生产MES系统存储于 MySQL”的当日产量以及“ERP系统存储于 Oracle”的实时库存状态。由于这些数据分布在不同的物理实例和不同的数据库引擎中无法直接使用标准的JOIN语句进行关联。为了向前端提供聚合后的数据接口业界通常会采用三种架构方案建立中间库、引入数据湖/数仓以及使用联邦查询Federated Query。一、 中间库方案数据物理搬运中间库方案是最容易想到、也是历史最悠久的解法。它的核心逻辑是通过数据同步工具如 DataX、Canal、Kettle 等将 Oracle 和 MySQL 中需要的表定时或准实时地同步到一个独立的“中间数据库”中通常是一个容量较大的 MySQL 或 PostgreSQL 实例。后端应用程序直接连接这个中间库就可以像操作单库一样使用标准的 SQL 语句进行多表JOIN和聚合查询。工程特点查询性能高数据已经物理落地到同一个库中可以充分利用索引和底层数据库的查询优化器。源库隔离大屏的并发查询压力全部由中间库承担不会影响 Oracle 和 MySQL 原有业务系统的稳定性。数据冗余与一致性成本数据被复制了一份。如果采用定时同步数据存在明显的延迟T1 或小时级如果采用 CDC 实时同步运维链路的复杂度会显著增加且需要处理主备延迟导致的数据不一致问题。实施成本中等。需要额外的数据库服务器资源以及数据同步组件的运维投入。二、 数据湖/数仓方案大规模 OLAP 架构当跨库聚合的需求不仅限于几张表而是涉及整个企业的数十个业务系统且需要进行海量历史数据的复杂分析时企业通常会引入数据湖Data Lake或数据仓库架构。异构数据源的数据会被全量或增量抽取到 HDFS、S3 等分布式文件系统中或者存入 ClickHouse、Doris 等 OLAP 引擎。工程特点海量数据处理能力采用分布式计算模型能够处理 PB 级别的数据关联与聚合。Schema-on-Read读时建模数据湖允许以极其灵活的格式存储数据在读取时再应用表结构。极高的基础设施门槛引入 Hadoop 生态或大型 MPP 数据库组件繁多HDFS、Spark、Hive 等集群搭建和日常调优需要专业的大数据开发团队。时效性较差数据湖主要面向离线分析和宏观报表虽然现在有流批一体架构如 Hudi、Iceberg但从源库到数据湖再到对外提供服务整条链路的时延依然很难满足应用层的绝对实时要求。实施成本极高。无论是硬件资源消耗还是人才储备要求都属于重量级投资。三、 联邦查询方案Federated Query联邦查询的核心理念是“计算与存储分离”即数据不移动由查询引擎去贴近数据。在这种架构下会引入一个计算引擎节点如 Trino/Presto或者应用层的跨源代理网关。开发人员向引擎发送一条包含跨库JOIN的逻辑 SQL。引擎内部会将其解析、拆分为针对 MySQL 和 Oracle 的两部分子查询分别下发到对应的物理源库执行最后将两边的返回结果在计算节点的内存中进行聚合拼接并返回给客户端。工程特点零数据冗余绝对实时不需要进行任何物理数据的搬运查询触发时直接从源库读取当前最新状态。架构轻量接入极快仅需配置网络连通性和数据库账号即可完成异构数据源的接入无需编写数据同步脚本。受制于网络与源库算力每次查询都需要通过网络拉取底层数据对于涉及几千万行级别的大表跨库JOIN大量数据在网络中传输会导致性能急剧下降。计算下推Pushdown优化优秀的联邦查询引擎具备计算下推能力会尽量把WHERE过滤和局部聚合操作推到源库执行减少传输回网关的数据量。实施成本较低。通常只需部署轻量级的无状态计算节点维护成本远低于中间库和数据湖方案。四、 方案选型对比对比维度中间库方案数据湖/数仓方案联邦查询方案数据冗余是部分数据是全量或海量数据否内存计算即用即焚数据时效性准实时 / 延迟延迟T1 或分钟级绝对实时基础设施成本中数据库实例同步工具高大型集群组件低轻量级计算网关适用场景高频固定报表、源库不可承受额外查询压力宏观指标分析、长周期历史数据挖掘实时大屏展示、轻量级敏捷数据接口对于大量临时性、轻量级的前端大屏取数需求如果要让开发人员为了几张表的关联就去搭建数据同步链路无疑是用牛刀杀鸡。在现代敏捷数据交付架构中利用联邦查询机制在网关层直接进行轻量的异构数据聚合已经成为提升接口开发效率的重要技术路线。