kuda 了解片

本来上个月想去了解一下kuda的，结果一直没有抽出时间去搞，现在大致先开个头，方便后面深入！

 

Apache Kudu是开源Apache Hadoop生态系统的新成员，它完善了Hadoop的存储层，可以 快速分析快速数据。

Kudu提供快速插入/更新和高效柱状扫描的组合，以在单个存储层上实现多个实时分析工作负载。作为HDFS和Apache HBase的新补充，Kudu使架构师能够灵活地处理各种用例，而无需异乎寻常的解决方法。

Kudu专为需要快速（快速变化）数据快速分析的用例而设计。Kudu专为利用下一代硬件和内存处理而设计，可显着降低Apache Impala（孵化）和Apache Spark（最初与其他执行引擎）的查询延迟。

 

Kudu和Impala均是Cloudera贡献给Apache基金会的顶级项目。

 

之前一直是 hdfs+Parquet+hive+impala

现在很多厂有用kuda+impala(或其他), 

去百度一番，快速了解一下。

 

kuda大致了解 

Kudu作为底层存储，在支持高并发低延迟kv查询的同时，还保持良好的Scan性能，该特性使得其理论上能够同时兼顾OLTP类和OLAP类查询。

Impala作为老牌的SQL解析引擎，其面对即时快速查询(Ad-Hoc Query)类请求的稳定性和速度在工业界得到过广泛的验证，Impala并没有自己的存储引擎，其负责解析SQL，并连接其底层的存储引擎。在发布之初Impala主要支持HDFS，Kudu发布之后，Impala和Kudu更是做了深度集成。

在众多大数据框架中，Impala定位类似Hive，不过Impala更关注即席查询SQL的快速解析，对于执行时间过长的SQL，仍旧是Hive更合适。

对于GroupBy等SQL查询，Impala进行的是内存计算，因而Impala对机器配置要求较高，官方建议内存128G以上，此类问题Hive底层对应的是传统的MapReduce计算框架，虽然执行效率低，但是稳定性好，对机器配置要求也低。

执行效率是Impala的最大优势，对于存储在HDFS中的数据，Impala的解析速度本来就远快于Hive，有了Kudu加成之后，会是如虎添翼，部分查询执行速度差别可达百倍。

值得注意的是，Kudu和Impala的英文原意是来自非洲的两个不同品种的羚羊，Cloudera这个公司非常喜欢用跑的快的动物来作为其产品的命名。

 

Kudu的典型使用场景

流式实时计算场景

流式计算场景通常有持续不断地大量写入，与此同时这些数据还要支持近乎实时的读、写以及更新操作。Kudu的设计能够很好的处理此场景。

时间序列存储引擎(TSDB)

Kudu的hash分片设计能够很好地避免TSDB类请求的局部热点问题。同时高效的Scan性能让Kudu能够比Hbase更好的支持查询操作。

机器学习&数据挖掘

机器学习和数据挖掘的中间结果往往需要高吞吐量的批量写入和读取，同时会有少量的随机读写操作。Kudu的设计可以很好地满足这些中间结果的存储需求。

与历史遗产数据共存

在工业界实际生产环境中，往往有大量的历史遗产数据。Impala可以同时支持HDFS、Kudu等多个底层存储引擎，这个特性使得在使用的Kudu的同时，不必把所有的数据都迁移到Kudu。

 

Kudu中的重要概念

列式存储

毫无疑问，Kudu是一个纯粹的列式存储引擎，相比Hbase只是按列存放数据，Kudu的列式存储更接近于Parquet，在支持更高效Scan操作的同时，还占用更小的存储空间。列式存储有如此优势，主要因为两点：1. 通常意义下的OLAP查询只访问部分列数据，列存储引擎在这种情况下支持按需访问，而行存储引擎则必须检索一行中的所有数据。2. 数据按列放一起一般意义来讲会拥有更高的压缩比，这是因为列相同的数据往往拥有更高的相似性。

Table

Kudu中所有的数据均存储在Table之中，每张表有其对应的表结构和主键，数据按主键有序存储。因为Kudu设计为支持超大规模数据量，Table之中的数据会被分割成为片段，称之为Tablet。

Tablet

一个Tablet把相邻的数据放在一起，跟其他分布式存储服务类似，一个Tablet会有多个副本放置在不同的服务器上面，在同一时刻，仅有一个Tablet作为leader存在，每个副本均可单独提供读操作，写操作则需要一致性同步写入。

Tablet Server

Tablet服务顾名思义，对Tablet的读写操作会通过该服务完成。对于一个给定的tablet，有一个作为leader，其他的作为follower，leader选举和灾备原则遵循Raft一致性算法，该算法在后文中有介绍。需要注意的是一个Tablet服务所能承载的Tablet数量有限，这也要求的Kudu表结构的设计需要合理的设置Partition数量，太少会导致性能降低，太多会造成过多的Tablet,给Tablet服务造成压力。

Master

master存储了其他服务的所有元信息，在同一时刻，最多有一个master作为leader提供服务，leader宕机之后会按照Raft一致性算法进行重新选举。

master会协调client传来的元信息读写操作。比如当创建一个新表的时候，client发送请求给master，master会转发请求给catelog、 tablet等服务。

master本身并不存储数据，数据存储在一个tablet之中，并且会按照正常的tablet进行副本备份。

Tablet服务会每秒钟跟master进行心跳连接。