Big Data

背景 Kudu 启动慢是长期以来饱受诟病的一个问题，部分数据量大的集群，单节点重启极端耗时需要 30 分钟以上，同时其部分参数并不能进行运行时调优，需要重启才能生效，这困扰着运维人员，影响升级和变更流程。 社区以及一些组织实现了一些优化方案，具体可以见 此文 tserver启动加速 一节，一些具体的 patch 包括： KUDU-2977 Sharding block map of

Block 抽象接口 操作系统把磁盘抽象成文件，Kudu 则在文件之上再加了一层抽象——Block。在 Kudu 中，一列数据、一个 BloomFilter、一份主键索引，最终都变成一个或多个 Block 写入磁盘。Block 是 Kudu 存储引擎与本地文件系统之间的分界线：上层组件只需面对 Block 接口的 Append / Read，不必关心底层是一个独立文

数据结构 MemRowSet 是 Kudu tablet 中用来暂存新写入数据的内存结构。它的底层存储是一棵并发 B-tree（CBTree），每个叶节点条目存放一个 key-value 对：key 是主键的编码形式（字典序 = 主键逻辑序），value 是一个 MRSRow。 为了支持快照一致性，MemRowSet 从不原地更新已插入的行数据——所有后续变更都以 Mutation 节点的形式挂在

序 本文记录 kudu 源码阅读笔记，记录了 kudu tserver 端非事务写入的完整流程。 写入流程总览 Kudu 的一次“非事务”写（普通单/批行 Insert/Upsert/Update/Delete，不带 txn_id）在 tserver 侧需要经历以下阶段： Client 组装 WriteRequestPB 并通过 RPC 发送 (tserver_service.proto:

为什么需要 Kudu 在 Hadoop 生态中结构化的数据通常使用两种方式进行存储：一是通过 Apache Parquet 等二进制数据格式，将静态数据集存储在 HDFS 上，二是将可变数据以半结构化的方式存储在 HBase 中。这里面临的问题是存储在 HDFS 上的数据无法提供单个记录的随机访问，HBase 中存储的数据尽管允许低延迟的读取和写入，但是基于 SQL 分析的应用中顺序读取的吞吐方面