【KWDB 创作者计划】_技术解读（2）：查询引擎架构与跨模融合计算实现
在大多数传统数据库中，时序模型和关系模型通常需要分别部署和查询。而 KWDB 通过引入“融合查询引擎”，实现了多模数据在统一 SQL 语法下的无缝检索。本篇我们将深入讲解 KWDB 查询引擎的核心设计：从解析器、执行计划生成、跨模优化器、到多源执行器的协同工作机制，并附带部分源码路径指引，助你真正理解“时序 + 关系”的一体化查询背后的技术力量。
一、KWDB 查询架构概览
查询在 KWDB 中的生命周期如下：
flowchart LR
A[SQL 查询语句] --> B[Parser 语法解析]
B --> C[Query Planner 构建逻辑执行计划]
C --> D[Query Optimizer 查询优化]
D --> E[Execution Engine 执行器调度]
E --> F[数据读取器 + 存储引擎]
F --> G[结果聚合 + 返回客户端]
在执行过程中，KWDB 的查询引擎支持多模数据的联合处理，确保数据结构之间不需要预处理即可直接 JOIN 与聚合分析。
二、语法解析：支持标准 SQL + 拓展语法
KWDB 支持 ANSI SQL-92 基础语法，并对 时间窗口函数、嵌套子查询、标签过滤表达式 做了增强：
SELECT avg(temperature), device_info.model
FROM ts_metrics
JOIN device_info ON ts_metrics.device_id = device_info.id
WHERE time BETWEEN now() - interval '5m' AND now()
AND device_info.location = '北京'
GROUP BY time_bucket('1m'), model;
解析入口：
src/
└── parser/
├── sql_parser.cc // SQL token解析
├── sql_ast.cc // AST结构构建
└── sql_validator.cc // 语义校验
三、执行计划生成：逻辑层与物理层分离
KWDB 使用逻辑执行计划 + 物理执行计划的双层结构来规划查询执行路径。
逻辑计划构建
-
识别 SQL 中的子句与依赖关系
-
构建查询图（Query Tree）：扫描 → 过滤 → 聚合 → 投影
物理计划构建
-
结合数据分布（是否分区）、数据源类型（时序 or 关系）做调度
-
为每一步选择具体算子：如
TSScan,HashJoin,GroupByAggregate
源码入口：
engine/
├── planner/
│ ├── logical_plan.cc // 构建逻辑树
│ └── physical_plan.cc // 优化成物理计划
四、跨模执行调度：KWDB 的核心能力亮点
跨模执行是 KWDB 的核心特性之一，其技术本质体现在两个关键点：
1. 统一的数据访问抽象层
无论是 ts_metrics（时序表）还是 device_info（关系表），在执行器中都实现了统一的访问接口：
class DataSource {
public:
virtual RecordBatch NextBatch() = 0;
virtual Schema GetSchema() = 0;
};
所有物理算子（如 Filter、Project、Join）都面向抽象接口处理，解耦了表结构。
2. 混合执行计划：时序 + 关系混合节点调度
举例：
SELECT *
FROM ts_metrics
JOIN device_info ON ts_metrics.device_id = device_info.id
WHERE device_info.model = 'ABC'
AND time > now() - interval '10m';
执行计划会如下调度：
-
分别构建两个 Scan 节点
-
通过 HashJoin 节点 将两者关联
-
时间过滤被下推至
ts_metrics读取阶段，提升性能
示意图如下：
graph TD;
A[Scan(ts_metrics)] --> C[Join]
B[Scan(device_info)] --> C
C --> D[Filter by time]
D --> E[Project 输出]
五、查询优化：推理下推 + 多级缓存 + 并行执行
KWDB 的查询优化器在物理计划阶段会做多种优化：
| 优化类型 | 说明 |
|---|---|
| 谓词下推 | WHERE 条件尽可能提前应用 |
| 列裁剪 | 只加载 SELECT 中涉及的字段 |
| Lazy Evaluation | 按需计算，避免中间物化 |
| 并行调度 | 分区数据可并发扫描 |
源码位置：
engine/planner/optimizer/
├── predicate_pushdown.cc
├── column_prune.cc
├── plan_rewriter.cc
六、实战演示：一次真实查询过程
我们用一个真实数据进行演示：
SELECT d.model, avg(t.humidity)
FROM ts_metrics t
JOIN device_info d ON t.device_id = d.id
WHERE t.time > now() - interval '5m'
GROUP BY d.model;
查询结果如下（截图来自 Postgres 接口查询工具）：
model | avg
-----------|------
A-001 | 41.2
B-021 | 47.8
C-999 | 35.6
执行日志显示：
-
实际读取文件数：6 个 SST 文件
-
查询耗时：236ms
-
Join 后聚合条目：3 类设备型号
七、小结：统一查询引擎，释放开发者生产力
KWDB 的查询引擎设计实现了以下目标：
| 特性 | 开发者价值 |
|---|---|
| SQL 统一 | 降低多模查询门槛 |
| 跨模 JOIN | 实现结构 + 时序融合查询 |
| 查询优化器 | 提升响应速度与查询效率 |
| 可扩展执行器 | 便于自定义算子与函数注册 |
下一篇我们将进入源码解读实战篇，主题为：
【KWDB 创作者计划】_技术解读（3）：代码导读：带你从源码构建 KWDB
将从代码目录结构、模块依赖、开发与调试环境配置一步步展开。
如果你觉得这篇博文对你有帮助，请点赞、收藏、关注我，并且可以打赏支持我！
欢迎关注我的后续博文，我将分享更多关于人工智能、自然语言处理和计算机视觉的精彩内容。
谢谢大家的支持！