| 对比方面 | HBase | Kudu |
|---|---|---|
| 开发语言 | Java | Java、C++（核心） |
| 数据模型 | key-value系统，无模式 | 强类型的结构化表 |
| 软件架构 | 利用ZK进行Master选举，数据存储到HDFS实现容错 | 使用Raft协议实现高可用，底层数据存储使用Raft实现多副本 |
| 存储方式 | 列簇式存储 | 纯列式存储 |
| 数据分区 | 一致性哈希 | Hash或Range |
| 索引 | 支持 | 不支持 |
| 数据一致性 | 强一致 | Snashot和External Consisitency |
架构
HBase
- Master：管理与监控的RegionServer，管理HBase元数据；
- Zookeeper：分布式协调服务，存储Meta表位置、Master位置、RS当前工作状态；
- RegionServer：维护Master分配的Region（表一段区间的内容），接受客户端的读写请求；
- HDFS：提供多副本的数据存储（包括Storefile和HLOG），HBase作为HDFS的客户端，与HDFS低耦合；
- Java实现，内存的释放通过GC来完成，在内存比较紧张时可能引发full GC进而导致服务不稳定；
Kudu
- TServer：管理Tablet，接收其他TServer中Leader Tablet传来的同步消息；
- TMaster：管理Tablet的基本信息、表的基本信息，监听TServer状态，多个TMaster之间通过Raft协议实现数据同步、高可用；
- Tablet：负责表中某块内容的读写，类似Region；由一或多个Rowset组成；
- 相当于把HBase中ZK的功能放在TMaster，比HBase中Master的功能更重；
- 数据存储模块集成在自身结构（避免HDFS读取小文件时延太大的问题）；
- 核心模块用的C++来实现，没有full gc的风险。
存储
HBase
- K-V型的NoSQL数据库，建表时指定一或多个列蔟，列蔟下有任意个列，相同列蔟的列存放在一起（面向列蔟存储），比行式存储有更高的压缩比；
- 每行数据包括：rowkey:columnFamily:columnQulifier:timestamp，其中columnQulifier为数据行是否删除的标记、TimeStamp区分多版本数据；
- 建表时不需要指定列和类型（value字段转换成二进制的字节流），相当于可以动态该表表结构；
- 每个cell存放多个版本的数据，更新删除通过插入一条新版本的数据实现；
- 表设计时一般会用单个列蔟，此时与行式存储无太大区别；
Kudu
- 完全的列式存储；
- 数据分三个部分：BaseData（当前数据），UndoRecords（历史修改数据），RedoRecords（未merge到当前数据的更新操作）；
- 建表时要定义每列的类型（设置合适的编码方式），实现更高的数据压缩比，降低I/O压力；
- 主键唯一，不能把更新操作转换成插入一条新版本的数据。
读写过程
HBase
特点
- 写入缓存：Memstore，同时会将写入操作顺序写入HLOG（WAL）保证数据不丢失；
- 读出缓存：BlockCache，采用LRU策略；
- 采用了LSM-tree的多组件算法作为数据组织方式，一个Region存在多个Storefile；
- 采用了非原地更新的方式（插入新版本数据），能实现快速的更新和删除，导致满足指定rowkey，列族、列名要求的数据有多个，并且可能分布在不同的Storefile中；
- timestamp属性可以设置，按顺序写入Storefile的数据timestamp可能不是递增的；
- 可考虑读写中使用的优化技术如Bloomfilter、timestamp range；
写过程：
- 1、客户端通过缓存的RS信息或访问ZK取得Region所在的RS信息；
- 2、RS接受客户端写入请求，先将写入的操作写入WAL，然后写入Memstore，HBase向客户端确认写入成功；
- 一定情况下（Memstore达到一定阈值或region占用内存超过一定阈值或手动flush），HBase将Memstore中的数据flush成Storefile，存放到HDFS；
- HBase将Storefile根据一定策略合并。
读过程：
- 1、客户端通过缓存或访问ZK取得Region所在的RS信息；
- 2、RS 接收读请求，要准确的读到相应版本的数据，需要找到所有可能存储有该条数据的位置，包括在内存中未flush的Memstore，已经flush到HDFS上的storefile，所以需要在1 Memstore + N Storefile中查找；
- 3、在所有数据中通过timestamp中得到最终数据。
Kudu
特点
- Tablet负责表某块内容读写，由一或多个Rowset组成：
- MemRowset：处于内存的Rowset，负责新数据写入请求，只有一个；
- DiskRowSet：MemRowset达到一定程序刷入磁盘后生成，由一个CFile（Base Data）、多个DeltaFile（UNDO records & REDO records）和位于内存的DeltaMemStore（达到一定大小后会将数据刷入磁盘生成新的REDO records）组成。
- Kudu后台有一个类似HBase的compaction线程按照一定策略对tablet进行合并：
- 将多个DeltaFile（REDO records）合并成一个大的DeltaFile
- 将多个REDO reccords文件与Base data进行合并，并生成新的 UNDO records；
- 将多个DiskRowset之间进行合并，减少DiskRowset的数量。
- 最终数据存储在本地磁盘，每个tablet设置多个副本且由多个TServer负责维护，写入请求由Leader Tablet处理，副本之间通过Raft协议保证强一致性；
写过程（插入）：
- 连接TMaster获取表相关信息（分区、Tablet）；
- 找到负责读写请求Tablet的TServer，Kudu接收到请求后检查是否符合要求（表结构）；
- Kudu在TServer的所有rowset中（内存、磁盘）根据主键查找，存在相同的返回错误；
- Kudu在MemRowset中写入一行新数据，如达到阈值则将数据写入磁盘（DiskRowSet），并生成一个memrowset继续接收新数据的请求。
写过程（更新）：
- 前两步相同；
- 待更新数据可能位于MemRowset中，也可能位于DiskRowSet：
- 位于MemRowset：找到待更新数据所在行， 然后将更新操作记录在所在行中一个mutation链表中；在memrowset将数据落盘时，Kudu会将更新合并到base data，并生成UNDO records用于查看历史版本的数据和MVCC,UNDO records实际上也是以DeltaFile的形式存放；
- 位于DiskRowSet：找到待更新数据所在的DiskRowset ， 每个DiskRowset 都会在内存中设置一个DeltaMemStore，将更新操作记录在DeltaMemStore中，在DeltaMemStore达到一定大小时，flush在磁盘，形成Delta并存在方DeltaFile中。
- Kudu提交更新时通过Raft协议将同步到其他replica，如没有在MemRowset和DiskRowSet中找到这条数据则返回错误，deltafile太多时会采用一定策略对一组deltafile合并。
读过程：
- 连接TMaster获取表相关信息（分区、Tablet）；
- Client找到相应Tablet的Tserver，Kudu接收读请求并记录timestamp（默认当前时间）；
- Kudu找到待读数据的所有相关信息：
- 位于MemRowset：根据读取操作中包含的timestamp 信息将该timestamp前提交的更新操作合并到base data中，这个更新操作记录在该行数据对应的mutation链表中；
- 位于DiskRowSet：在所有DeltaFile中找到所有目标数据相关的UNDO record和REDO records，REDO records可能位于多个DeltaFile中，根据读操作中包含的timestamp信息判断是否需要将base data进行回滚或者利用REDO records将base data进行合并更新。
特点：
HBase写的时候，不管是新插入一条数据还是更新数据，都当作插入一条新数据来进行；而Kudu将插入新数据与更新操作分别看待；
Kudu表结构中必须设置一个唯一键，插入数据的时候必须判断一些该数据的主键是否唯一，所以插入的时候其实有一个读的过程；而HBase没有太多限制，待插入数据将直接写进memstore；
HBase实现数据可靠性是通过将落盘的数据写入HDFS来实现，而Kudu是通过将数据写入和更新操作同步在其他副本上实现 数据可靠性。
在HBase中，读取的数据可能有多个版本，所以需要结合多个storefile进行查询；Kudu数据只可能存在于一个DiskRowset或 者MemRowset中，但是因为可能存在还未合并进原数据的更新，所以Kudu也需要结合多个DeltaFile进行查询；
HBase写入或者更新时可以指定timestamp，导致storefile之间timestamp范围的规律性降低，增加了实际查询storefile的数量；Kudu不允许人为指定写入或者更新时的timestamp值，DeltaFile之间timestamp连续，可以更快的找到需要的DeltaFile；
HBase通过timestamp值可以直接取出数据；而Kudu实现多版本是通过保留UNDO records（已经合并过的操作）和REDO records（未合并过的操作）完成，在一些情况下Kudu需要将base data结合UNDO records进行回滚或者结合REDO records进行合并然后才能得到真正所需要的数据。
HBase和Kudu在读取一条数据时都需要从多个文件中搜寻相关信息。Kudu将插入和更新操作分开，一条数据只可能存在于一个DiskRowset或者MemRowset中，只需要搜寻到一个rowset中存在指定数据就不用继续往下找了，用户不能设置更新和插入时的timestamp值，减少了在rowset中DeltaFile的读取数量。这样在scan情况下可以结合列式存储的优点实现较高的读性能，特别是在更新数量较少的情况下能够有效提高scan性能。
