技术文章

第一次接触 Kudu 和 Impala，最容易产生两个误解：把 Kudu 当成“另一个 HDFS”，或者把 Impala 当成“装在 Kudu 上面的数据库”。两种说法都没有抓住边界。

Kudu 是分布式存储引擎。 它负责把表切成 Tablet，保存每一行、处理主键、更新、删除、快照和多副本。

Impala 是分布式 SQL 查询引擎。 它负责理解 SQL、选择执行计划、安排并行任务、扫描数据、执行 Join、聚合和排序，再把结果返回客户端。

两者组合后，Impala 可以查询和修改 Kudu 表，但数据最终仍由 Kudu 保存；Kudu 不负责解析 GROUP BY 或规...

Kudu 最值得研究的地方，不是“支持 UPDATE 的列式存储”这句话，而是它如何把两种冲突的访问模式放进同一个 Tablet：新数据要低延迟写入，分析查询又希望读取紧凑、按列编码的数据；更新不能重写整列文件，历史版本还必须对快照读可见。

解决办法不是某一种神奇数据结构，而是一组分层结构：MemRowSet 接住新行，DiskRowSet 提供列式基线，Delta Store 承载更新，WAL 与 Raft 负责持久性和复制，MVCC 决定每个快照能看到什么。

本文基于 Kudu 1.18.1 源码，文件路径均相对于 src/kudu/。

Tablet 才是存储与一致性

Impala 查询快，不是因为它省略了 SQL 优化，也不是简单地“绕过 MapReduce”。真正的区别在执行形态：Daemon 常驻、元数据常驻、查询被切成并行 Fragment，数据通过 Exchange 在节点间流动，Scan、Join 和 Aggregate 尽可能组成流水线，并由 Runtime Filter 在运行期缩小扫描范围。

本文以 Impala 4.5.0 为基线，从一条 SQL 进入 impalad 开始，追到 RowBatch 穿过执行树并回到客户端。源码路径均相对于 Impala 仓库。

先建立进程视图

Impala 集群的核心角色不是传统意义上...