KUDU学习笔记（一）

开发背景

传统的大数据处理方式存在的无非是一个问题：
能进行灵活查询与分析的方式不能达到真正的事实更新，而能随数据实时更新的方式却不能灵活的查询和分析。
HDFS+HBase+Impala ：数据往往会有天或小时级的延迟；
Hbase ：不能进行灵活的查询分析
而kudu的出现刚好解决了这个问题。

特点

存储结构化数据，有良好的Schema；
与其他分布式存储系统相似，多副本存储，保证数据安全性；
raft协议保证数据一致性（不太懂，感觉很屌的样子。。。）
真正的列式存储，可以提供快速的随机更新和列式查询；
可以性能不差的批量读写；
c++开发，解决GC痛点；
完美集成MR，Spark，Impala；
提供JAVA，c++ API。

整体架构

主从架构，一个Master多个TabletServer

Master：
Kudu支持多个Master，但是只有一个活跃的Mater（leader）提供服务，Client在进行操作时leader Master 会将指令发送给follower Master ，当多数的follower Master 写入成功时，leader Master会认为写入成功，告知Client。
Master上是不存放Table中的数据的，但是Kudu的元数据 catalog会以tablet的形式存在Master上，在集群启动时Master会将元数据加载到缓存中。
Client会在本地缓存一份元数据，避免没次操作都要通过Master，使的Master的性能成为整个Kudu集群的瓶颈。当tablet的位置发生变化时，client会收到通知，再重新从Master拉去一份新的缓存信息。

元数据：
元数据即为catalog+其他集群信息（TabletServer状态等）
catalog是一张我们无法直接访问，只能通过API进行查询的表。他存储着Tables（表结构，位置，状态等）和Tablets的元数据信息（现有的Tablet的列表，每个列表存放于哪个TabletServer，各个Tablet的状态，和各Tablet的开始和结束的key）。

作用：
管理元数据；
负载均衡；
监听TabletServer状态

TabletServer：
是kudu存储真正数据的服务器

作用：
存储tablet（Tablet即为一个表的一个数据段，每个Table由一个或多个Tablet组成，取决于创建Table时分多少个区，一个区对应一个Tablet，Tablet内部结构后面再细讲）；
根据client的指令完成tablet的读写操作；
监控各Tablet的状态反馈给Master。