一、异构数据源归集的本质挑战与内核迭代方向

在企业内部，销售板块的数据存于 A 类关系数据库，日志板块的数据落在对象存储的 JSON 文件中，生产板块的实时指标通过消息队列写入。当需要做一个跨板块的报表——例如“近一小时高价值订单对应的服务日志与设备状态”——传统做法是：先用 ETL 工具将各类数据抽取、清洗、加载到一个中间库，再执行分析。这个过程中的问题非常突出：第一，数据冗余严重，同一份数据可能在多个系统中存在副本；第二，实时性受损，ETL 周期往往是小时级或天级；第三，算力无法统一调度，分析逻辑分散在不同的处理框架中。

解决这些问题的根本路径，不是再引入一个更复杂的集成，而是迭代数据库内核架构，让数据库本身具备“理解并直接访问外部异构数据”的能力。这意味着数据库不再假设所有数据都存储在自己的本地存储引擎中，而是将外部数据源视为一种逻辑上的远程表。为了实现这一点，内核需要在三个层面进行深度改造：接入层需要支持多格式自动识别与解析；计算层需要具备跨源算子下推能力；元数据层需要统一描述不同数据源的格式、分布与统计信息。

这一迭代方向的核心价值在于：数据库从“数据的容器”演变为“数据的统一调度控制中心”，各个业务板块的数据可以保留在原处，但通过统一的查询与计算入口被归集和加工。

二、多格式数据接入通道：插件化格式解析与自动识别

打通多格式数据接入通道的第一步，是让数据库能够“读懂”存放在外部系统中的各类文件格式。许多方案要求用户在创建外部表时手动指定格式和分隔符，但在真实场景中，同一路径下的文件可能混合了 JSON 和 Parquet，或者 CSV 的版本差异导致列分隔符变化。手动指定既繁琐又容易出错。

我们设计的方案是在内核中构建一个插件化格式解析框架。每一种文件格式（CSV、JSON、Parquet、Avro、ORC 等）被封装为一个独立的解析插件，遵循统一的读取接口——输入为字节流或文件分片，输出为内存储存的行/列式数据块。接入通道在读取数据时首先通过格式探测器进行快速判定：读取文件头部若干字节，匹配特征魔数（例如 Parquet 的 PAR1、Avro 的 Obj1）或基于统计启发式规则（如 JSON 的起始字符为 { 或 [）。一旦识别成功，内核动态加载对应的解析插件，并将后续读取委托给该插件。

为了适配不同量级的业务，解析插件支持两种运行模式：全量解析模式用于小文件或高频访问场景，将数据一次性解析并缓存于数据库内存页中；流式解析模式用于 TB 级以上大文件，以分片方式逐批读取并立即参与计算，避免内存溢出。此外，接入通道还维护了一个格式元数据缓存，记录最近访问的文件路径、格式类型与解析参数，从而避免重复识别开销。

通过这套插件化架构，数据库可以在不重启实例的情况下新增对新型文件格式的支持——只需部署一个新的解析插件。业务板块的数据无需提前转换格式，即可被数据库直接接入和归集。

三、跨业务板块数据归集：统一数据抽象与位置透明的访问协议

有了多格式解析能力，接下来要解决的是跨业务板块的数据组织问题。不同板块的数据往往分布在不同存储系统中，拥有各自的访问协议与路径表达方式。销售板块的数据可能在 jdbc:postgresql://sales-host/db，日志板块的数据在 s3://log-bucket/2026/，实时指标在 kafka://topic/metrics。如果数据库的访问语法强制要求用户区分这些协议，归集查询将变得异常复杂。

我们提出的方案是构建一个统一数据抽象层，称为外部数据引用（External Data Reference, EDR）。EDR 将任意数据源的访问信息封装为一个逻辑标识符，格式为 <板块名>.<数据集名>，同时在内核的元数据表中记录该标识符对应的实际协议、路径、格式以及访问凭证（经脱敏与权限控制）。用户在编写查询时，无需关心数据实际存储在哪里、是什么格式，只需像访问普通数据库表一样引用 sales.orders 或 logs.api_calls。

更关键的是，统一抽象层实现了位置透明的跨源归集。当一条查询同时涉及多个板块的数据时，数据库的优化器会生成一个跨源执行规划，分解为多个子查询分别下推到各自的数据源。例如，先从销售板块的关系库中通过 JDBC 协议拉取订单 ID 列表，再从日志板块的 JSON 文件中过滤出对应的记录。为了提高归集效率，内核支持谓词下推与投影下推——如果日志查询只需要 timestamp 和 user_id 两列，接入通道会在解析 JSON 时直接跳过其他字段，减少网络与内存开销。

对于需要频繁归集的跨板块数据集，系统允许管理员定义物化归集视图，由后台调度自动将多个异构数据源的结果预计算并存储于数据库本地存储引擎中，从而实现查询毫秒级响应与源系统解耦。

四、统一算力统筹调度：跨源算子下推与自适应执行

打通数据接入只是基础，真正的挑战在于算力调度。不同数据源的计算能力差异巨大——关系数据库支持 SQL 聚合，对象存储上的 Parquet 文件支持谓词过滤但无法执行 JOIN，消息队列只支持简单的偏移量读取。如果将所有数据拉取到数据库本地再进行计算，网络 I/O 和本地内存会成为瓶颈。

因此，我们设计了一套基于算子能力的跨源调度框架。数据库内核维护每个数据源的能力描述（Capability Description），包括支持的操作类型（过滤、投影、聚合、排序、LIMIT）、支持的下推表达式复杂度、以及是否支持并行分片读取。优化器在生成执行规划时，会遍历各个算子并尝试将其下推到对应的数据源执行。

具体来说，对于一份存于对象存储的 Parquet 文件，如果查询为 SELECT count(*) FROM logs.api_calls WHERE status >= 400，调度框架会将过滤条件 status >= 400 下推到解析插件，利用 Parquet 本身的行组统计信息和谓词下推特性，只读取符合条件的数据块并返回计数结果。对于存于关系数据库中的订单表，则可以将完整的聚合计算（如 SUM(amount) GROUP BY region）下推到远程库执行，只返回聚合后的少量结果。

当某个数据源不支持所需算子时，调度框架会自动拉取必要数据在数据库本地完成计算，同时记录下该执行路径的性能特征。多次执行后，系统会生成一个自适应调度策略表，优先选择总代价最低的执行方案，代价模型综合考虑网络延迟、数据源计算速度以及本地资源消耗。

更为重要的是，统一算力统筹调度支持跨源 JOIN 的智能路由。若 JOIN 左表来自关系库（10 万行），右表来自 JSON 文件（10 亿行），调度框架会选择将左表数据整体下推到 JSON 文件所在的解析端，在那里完成过滤和哈希构建，而非将巨大的右表拉回本地。这种“向数据移动计算”的调度思想，是整个架构的核心效率保障。

五、实际案例验证与不同量级业务的适配表现

上述架构在一个跨三个业务板块的真实场景中得到了验证。销售板块（约 500GB 订单数据存储于关系型数据库），日志板块（约 8TB 的 JSON 格式访问日志存放于对象存储），设备板块（实时指标流入消息队列，数据量每日新增约 200GB）。需求是实时归集“过去 1 小时内、订单金额超过 1000 元的用户对应的设备异常日志”。

在未采用本方案前，该需求需要运维人员编写复杂的 ETL 作业，每 30 分钟同步一次，延迟高且资源消耗大。采用统一接入通道与算力调度后，数据库通过 EDR 定义了三个外部数据集，优化器自动生成执行规划：从消息队列读取最近 1 小时的实时指标（流式解析），过滤出相关设备 ID；同时将订单表的过滤条件下推到关系库执行，仅返回符合条件的用户 ID；最后将两个中间结果与日志板块的 JSON 文件进行归集，利用谓词下推只扫描相关时间分区。

测试结果表明：数据归集的端到端延迟从 30 分钟降至 12 秒，数据库本地内存占用仅为全量搬运方案的 1/20，且三个源系统的原有业务未受明显影响。在适配不同量级业务方面，该架构支持配置降级策略——小规模业务可关闭自动下推，全量拉取简化运维；大规模业务则启用全部优化，并增加分布式协调机制应对 PB 级跨源归集。

结语

围绕异构数据源互通需求迭代数据库内核架构，并非简单的功能堆砌，而是从底层重塑数据接入、归集与调度的哲学。通过插件化格式解析通道、统一数据抽象层以及基于算子能力的跨源算力调度，我们让数据库不再是被动的数据容器，而是主动的跨业务板块数据融合枢纽。这一架构有效替代了繁重的传统 ETL 模式，在保障数据新鲜度的同时降低了冗余与运维成本。未来的演进方向包括增加对更多半结构化格式（如 Protobuf、Thrift）的自动解析支持，以及引入机器学习模型辅助的调度代价估计，进一步提升异构数据源场景下的统一算力调度效率。