1. 项目背景与技术选型
chDB这个开源项目最早源于我们对OLAP场景下高性能查询引擎的深度需求。在2018年初期评估现有方案时，我们发现ClickHouse虽然性能出色，但其架构设计更偏向于分布式场景，在嵌入式应用和轻量级部署中存在明显短板。当时团队内部有个大胆的想法：能否基于ClickHouse的核心引擎，打造一个专为嵌入式场景优化的OLAP解决方案？
技术选型阶段我们重点考虑了三个方向：
- 从头开发全新引擎（开发周期预估18个月+）
- 基于DuckDB等轻量级方案改造（功能扩展性有限）
- 基于ClickHouse内核进行深度定制（6-8个月周期）
最终选择第三条路线主要基于以下考量：
- ClickHouse的列式存储引擎在OLAP场景有天然优势
- 其向量化执行引擎代码质量极高（C++17实现）
- 社区活跃度保证长期可维护性
- 团队已有2年ClickHouse深度使用经验
关键决策点：在保持85%以上ClickHouse性能的前提下，将二进制体积控制在15MB以内，内存占用减少60%
2. 核心架构改造
2.1 模块化裁剪
原始ClickHouse代码库包含120+个功能模块，我们通过依赖关系分析工具（包括自定义的C++ AST解析器）识别出核心依赖链。最终保留的关键组件包括：
| 模块名称 | 保留原因 | 体积占比 |
|---|---|---|
| Core | 基础类型系统与内存管理 | 35% |
| Common | 公共算法与数据结构 | 22% |
| Parsers | SQL语法解析前端 | 18% |
| Interpreters | 查询执行计划生成 | 15% |
| Storages | 表引擎抽象层 | 10% |
裁剪过程中最大的挑战是处理模块间的隐式依赖。例如，原始代码中多个模块通过全局配置管理器间接耦合，我们不得不重构为显式依赖注入模式。
2.2 内存管理优化
针对嵌入式场景特别改进了内存分配策略：
- 引入Arena-based内存池替代部分std::allocator
- 实现LRU缓存感知的预分配机制
- 对查询中间结果实施严格的内存限额
// 典型的内存池使用示例 chdb::MemoryPool pool(1024 * 1024); // 1MB初始池 auto block = pool.allocAligned(256, 64); // 256字节，64位对齐实测显示这些改动使得内存峰值使用量降低57%，特别是在处理大型JOIN操作时效果显著。
3. 性能调优实战
3.1 向量化执行加速
保留ClickHouse向量化引擎的同时，我们针对嵌入式CPU特性做了指令级优化：
- 使用CPUID检测AVX-512支持
- 为ARMv8实现NEON加速版本
- 关键路径循环展开策略调整
// AVX-512优化的列过滤代码片段 vpcmpeqd zmm0, zmm1, [rdi] ; 比较操作 vpmovmskb eax, zmm0 ; 生成掩码 kmovw [rsi], k1 ; 存储结果在Intel i7-1185G7上测试，过滤操作的吞吐量提升达3.2倍。
3.2 存储引擎改造
开发了新的轻量级存储格式CHLite，主要改进：
- 列块大小从1MB调整为128KB（更适合SSD随机读）
- 移除冗余的校验和计算
- 使用Zstd替换LZ4压缩（权衡压缩率与速度）
格式对比测试结果：
| 格式 | 压缩率 | 读取速度 | 写入速度 |
|---|---|---|---|
| 原始CH | 3.2x | 1.2GB/s | 800MB/s |
| CHLite | 3.8x | 950MB/s | 1.1GB/s |
4. 关键问题与解决方案
4.1 线程模型冲突
原始ClickHouse的线程池设计与嵌入式环境存在根本性冲突。我们的解决方案：
- 将全局线程池改为每查询独立线程组
- 实现协程友好的任务调度器
- 引入优先级感知的任务队列
struct QueryContext { chdb::ThreadPool local_pool{4}; // 每个查询独立4线程 chdb::FiberScheduler fiber_sched; };4.2 依赖库膨胀
通过以下措施将第三方依赖从28个减少到9个：
- 用libc++替代部分Boost功能
- 自实现HTTP服务器（原依赖Poco）
- 移除未使用的编码转换库
5. 实测性能数据
在标准SSB（Star Schema Benchmark）测试中：
| 查询类型 | ClickHouse | chDB | 差异 |
|---|---|---|---|
| Q1.1 | 0.12s | 0.15s | +25% |
| Q2.1 | 0.28s | 0.31s | +11% |
| Q3.1 | 1.05s | 1.12s | +7% |
| Q4.3 | 3.21s | 3.45s | +7.5% |
内存占用对比：
| 指标 | ClickHouse | chDB | 缩减 |
|---|---|---|---|
| 启动内存 | 480MB | 85MB | -82% |
| 查询峰值内存 | 2.1GB | 760MB | -64% |
| 二进制大小 | 98MB | 14MB | -86% |
6. 典型应用场景
6.1 边缘计算数据分析
在工业物联网网关中的实际部署案例：
- 每设备日均处理230万条传感器数据
- 直接在网关完成聚合计算
- 网络传输量减少92%
6.2 嵌入式BI工具
某商业智能软件的集成方案：
- 查询延迟<50ms（千万级数据集）
- 支持同时运行5个并发查询
- 整体内存占用<300MB
7. 开发经验总结
- 性能取舍的艺术：
- 在过滤操作中牺牲5%性能换取30%内存节省
- 预处理常见查询模式的内存访问模式
- 为热点代码保留手动SIMD优化路径
- 架构设计教训：
- 过早优化是万恶之源（我们曾浪费2周优化非热点代码）
- 模块边界要预留扩展槽（后续添加UDF支持时深有体会）
- 内存布局对缓存命中率的影响超乎预期
- 调试技巧：
- 使用perf定位L3缓存未命中热点
- 定制化的内存分配追踪器
- 查询计划可视化工具开发
这个项目给团队带来的最大收获是：在保持核心优势的同时，通过精准裁剪和深度优化，完全可以在专用场景中超越通用方案的性价比。现在回看，如果当初选择从头开发，可能现在还在实现基础功能阶段。
