Kudu学习总结

本文为Kudu学习总结

一、Kudu简介

Kudu是为快速数据的快速分析而生的存储，是专为下一代硬件设计的，可提高跨框架分析性能的，用于构建实时分析应用的原生存储引擎

二、Kudu概览

1）Kudu的特点

• Kudu的表定义采用类似于SQL的模式，支持类型: BOOL，INT8，INT16，INT32，INT64，FLOAT，DOUBLE，STRING，BINARY，TIMESTAMP
• 几个子列可以组成一个组合主键
• 快速修改表
• Kudu本身没有SQL引擎，它只是一个存储层 – “使用你自己的SQL” 例如 Impala或者Spark
• Kudu不是一个跑在HDFS上的应用，它是一个替代品，原生的Hadoop存储引擎，期望与HDFS协同工作
• Kudu不是要替代HDFS或者HBase，而是为用户提供一个新的选择，用户需为适合的用例选择正确的存储

2）为什么是Kudu

HDFS的强项：
高效的顺序扫描能力
支持高吞吐的数据追加

HBase的强项：
高效的按行随机存取能力
支持数据的修改

可以“鱼”和“熊掌”兼得吗？
如何实现对实时变化的数据集做高效的数据分析呢（Fast Analysis on Fast Data）？
这时候不妨考虑使用Kudu！

Kudu的设计目标：
1）扫描大数据量时吞吐率高

• 列式存储和多副本机制
• 目标：相对Parquet的扫描性能差距在2x之内

2）随机访问数据时延时低

• 主键索引和多数占优复制机制
• 目标：SSD上读写延时不超过1毫秒

3）通过高CPU性能发挥RAM和Flash潜力

• 单列扫描性能是HBase的10-100倍

4）IO效率高

• 列式存储，按需访问

5）类似的数据库语义（初期支持单行记录的ACID）
6）关系数据模型

• SQL查询
• “NoSQL”风格的扫描/插入/更新(Java客户端)

三、Kudu设计

1）Kudu基本设计

• 基本构成：表（Table）
• 表通过水平划分分区形成多个tablet，依据范围或者hash分区
• 每个tablet有多个备份（3个或者5个），通过Raft算法保持一致性
• 允许从任何备份中读取数据，并具有较低的平均恢复时间MTTR
• 使用Tablet服务器来存放tablet
• 在本地盘存储数据（不是HDFS）

2）Kudu的元数据管理

• 高可用的主节点，作为一个tablet的目录 (“META” table)，作为一个编目表 (table schemas，etc)，作为负载均衡器（跟踪服务器的监控状态，重新复制低于副本数的tablet）
• 为高性能，缓存所有的元数据到内存
• 客户端保存服务器端的地址，询问主节点得到需要的tablet地址并且缓存这些地址

3）Kudu故障恢复

• 随从节点短暂失败：领导节点不受影响；故障的随从节点在5分钟之内重启服务器，就可以透明重新加入
• 领导节点短暂失败：随从节点每1.5秒尝试和领导节点通信一次；3次失败之后，领导者选举，新的领导节点会在很短的时间内从剩余的节点中选出；故障的领导节点在5分钟之内重启，就可以作为随从节点加入
• N 个备份能接受(N-1)/2 的失败数
• 永久失败：领导者注意到一个随从节点已经死亡超过5分钟，便会删除这个跟随者，而后从Master节点选择一个新的Server做备份并拷贝数据到新的随从节点上

4）性能特点

• 非常好的CPU利用率：使用C++编码, 利用了特定的CPU指令集,利用LLVM工具进行即时编译
• 依赖存储硬件能力的低延迟：期望利用SSD或者新的硬件技术来实现亚毫秒的低延迟
• 没有垃圾回收机制，允许没有停顿的大的内存占用
• Bloom filters减少了大量的硬盘访问

5）权衡

• 随机更新会变慢：HBase可以不用扫描硬盘进行随机更新，而Kudu需要在更新之前进行关键值查找，在插入前进行Bloom查找
• 单行读取可能会变慢：列式存储设计是为了全表扫描做的优化，未来可能会为单行访问的应用引入“列组”的概念