Kudu简介4_kudu 修改leader-CSDN博客

Kudu概述

Kudu和Impala均是Cloudera贡献给Apache基金会的顶级项目。Kudu作为底层存储，在支持高并发低延迟kv查询的同时，还保持良好的Scan性能，该特性使得其理论上能够同时兼顾OLTP类和OLAP类查询。Impala作为老牌的SQL解析引擎，其面对即席查询(Ad-Hoc Query)类请求的稳定性和速度在工业界得到过广泛的验证，Impala并没有自己的存储引擎，其负责解析SQL，并连接其底层的存储引擎。在发布之初Impala主要支持HDFS，Kudu发布之后，Impala和Kudu更是做了深度集成。

Kudu 是一个基于 Raft 的分布式存储系统，致力于融合低延迟写入和高性能分析这两种场景。

在众多大数据框架中，Impala定位类似Hive，不过Impala更关注即席查询SQL的快速解析，对于执行时间过长的SQL，仍旧是Hive更合适。对于GroupBy等SQL查询，Impala进行的是内存计算，因而Impala对机器配置要求较高，官方建议内存128G以上，此类问题Hive底层对应的是传统的MapReduce计算框架，虽然执行效率低，但是稳定性好，对机器配置要求也低。

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

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

Kudu是围绕Hadoop生态圈建立存储引擎，Kudu拥有和Hadoop生态圈共同的设计理念，它运行在普通的服务器上、可分布式规模化部署、并且满足工业界的高可用要求。其设计理念为fast analytics on fast data.。Kudu的大部分场景和Hbase类似，其设计降低了随机读写性能，提高了扫描性能，在大部分场景下，Kudu在拥有接近Hbase的随机读写性能的同时，还有远超Hbase的扫描性能。

kudu使用方法

可通过Java client、C++ client、Python client操作kudu表，但要构建client并编写应用程序；
可通过kudu-spark包集成kudu与spark，并编写spark应用程序来操作kudu表；
可通过impala的shell对kudu表进行交互式的操作，因为impala2.8及以上的版本已经集成了对kudu的操作。下面主要讲述基于impala的使用方法。

Kudu有如下优势

快速的OLAP类查询处理速度
与MapReduce、Spark等Hadoop生态圈常见系统高度兼容，其连接驱动由官方支持维护
与Impala深度集成，相比HDFS+Parquet+Impala的传统架构，Kudu+Impala在绝大多数场景下拥有更好的性能。
强大而灵活的一致性模型，允许用户对每个请求单独定义一致性模型，甚至包括强序列一致性。
能够同时支持OLTP和OLAP请求，并且拥有良好的性能。
Kudu集成在ClouderaManager之中，对运维友好。
高可用。采用Raft Consensus算法来作为master失败后选举模型，即使选举失败，数据仍然是可读的。
支持结构化的数据，纯粹的列式存储，省空间的同时，提供更高效的查询速度。

其它劣势见: Kudu在使用过程中的各种限制

Kudu有如下劣势

只有主键可以设置range分区，且只能由一个主键，也就是一个表只能有一个字段range分区，且该字段必须是主键。
如果是pyspark连接kudu，则不能对kudu进行额外的操作；而scala的spark可以调用kudu本身的库，支持kudu的各种语法。
kudu的shell客户端不提供表schema查看。如果你不通过imapla连接kudu，且想要查看表的元数据信息，需要用spark加载数据为dataframe，通过查看dataframe的schema查看表的元数据信息。
kudu的shell客户端不提供表内容查看。如果你想要表的据信息，要么自己写脚本，要么通过spark、imapla查看。
如果使用range 分区需要手动添加分区。假设id为分区字段，需要手动设置第一个分区为1-30.第二个分区为30-60等等
时间格式是utc类型，需要将时间戳转化为utc类型，注意8个小时时差

Kudu的典型使用场景

流式实时计算场景

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

时间序列存储引擎(TSDB)

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

机器学习&数据挖掘

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

与历史遗产数据共存

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

Kudu特点

作为Hadoop生态圈的一部分，对接生态系统的其他组件方便，会有官方提供的接口
kudu自己存储数据不依赖与HDFS存储；不依赖于zookeeper，将它的功能集成进了自身的TMaster；
和HBase类似的LSM结构，用于支持数据的随机读写。
有表结构，需定义Schema信息

必须定义唯一键，这就造成了写数据时多了一个判断唯一的过程。

需在写入数据前定义好每一列的类型（方便做类似于parquet的列式存储）

可以像关系型数据库一样用Alter增删列，不具有HBase动态列的特性

支持行级别的ACID
目前不支持二级索引
目前不支持BloomFilter优化join
核心模块用的C++来实现，没有full gc的风险
开源（免费，ASL 2.0）；
这是一个融合HDFS和HBase的功能的新组件，具备介于两者之间的新存储组件

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进行心跳连接。

Raft Consensus Algorithm

Kudu 使用Raft一致性算法，该算法将节点分为follower、candidate、leader三种角色，当leader节点宕机时，follower会成为candidate并且通过多数选举原则成为一个新的leader，因为有多数选举原则，所以在任意时刻，最多有一个leader角色。leader接收client上传的数据修改指令并且分发给follower，当多数follower写入时，leader会认为写入成功并告知client。

Catalog Table

Catelog表存储了Kudu的一些元数据，包括Tables和Tablets。

Kudu架构概览

从下图可以看出有三台Master，其中一个是leader，另外两个是follower。

有四台Tablet server，n个tablets及其副本均匀分布在这四台机器上。每个tablet有一个leader，两个follower。每个表会按照分片的数量分成多个tablet。

Kudu的使用场景

Strong performance for both scan and randomaccess to help customers simplify complex hybrid architectures（适用于那些既有随机访问，也有批量数据扫描的复合场景）

High CPU efficiency in order to maximizethe return on investment that our customers are making in modern processors（高计算量的场景）

High IO efficiency in order to leveragemodern persistent storage（使用了高性能的存储设备，包括使用更多的内存）

The ability to update data in place, toavoid extraneous processing and data movement（支持数据更新，避免数据反复迁移）

The ability to support active-activereplicated clusters that span multiple data centers in geographically distantlocations（支持跨地域的实时数据备份和查询）

总结上述内容，可以归纳为两个亮点：1）将不同组件结合起来的异构生态圈打通，使得数据、操作在一个圈内进行；2）将CPU、磁盘IO统一考量，便于资源的最优分配，尤其是未来CPU的计算资源成为瓶颈后；

kudu解决了什么问题

HDFS和HBase是大数据最常用的两种存储方式，它们的优缺点非常明显：

HDFS，使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条记录级别的update操作，随机读写性能差。这个就不多说了，用过HDFS的同学应该都知道这个特点。

HBase，可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。

那为什么HBase不适合做分析呢？

因为分析需要批量获取数据，而HBase本身的设计并不适合批量获取数据

1）都说HBase是列式数据库，其实从底层存储的角度来说它并不是列式的，获取指定列数据时是会读到其他列数据的。看过我之前文章的同学应该比较清楚就不多说了。相对而言Parquet格式针对分析场景就做了很多优化。

2）HBase是LSM-Tree架构的数据库，这导致了HBase读取数据路径比较长，从内存到磁盘，可能还需要读多个HFile文件做版本合并。

LSM 的中心思想就是将随机写转换为顺序写来大幅提高写入操作的性能，但是牺牲了部分读的性能。

随机读写是指对任意一个位置的读和写，磁盘随机读写慢是因为需要寻道，倒带才可以访问到指定存储点，而内存不需要，可以任意指定存储点

为了让数据平台同时具备随机读写和批量分析能力，传统的做法是采用混合架构(hybrid architecture)，也就是我们常说的T+1的方式，数据实时更新在HBase，第二天凌晨同步到HDFS做离线分析。这样的缺点很明显，时效性差，数据链路长，过程复杂，开发成本高。

这个时候Kudu出现了，它是介于HDFS和HBase两者之间的一个东西如下图所示，

它不及HDFS批处理快，也不及HBase随机读写能力强，但是反过来它比HBase批处理快（适用于OLAP的分析场景），而且比HDFS随机读写能力强（适用于实时写入或者更新的场景），这就是它能解决的问题。

传统大数据应用场景分析

在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，又需要批量分析的大数据场景，该如何选择呢？这个场景中，单种存储引擎无法满足业务需求，大部分公司经常通过多种大数据工具组合来满足这一需求，一个常见的方案是：

该方案可以满足数据更新+随机查询+批量分析的业务需求。

如上图所示，数据实时写入 HBase，实时的数据更新也在 HBase 完成，为了应对 OLAP 需求，我们定时（通常是 T+1 或者 T+H）将 HBase 数据写成静态的文件（如：Parquet）导入到 OLAP 引擎（如：HDFS）。这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景，但存在如下缺点：

(1)如何处理某一过程失败？

(2)从HBase将数据导出到文件，频率多少比较合适？

(3)当生产报表时，最近的数据如何体现在查询结果上？

(4)维护集群时，如何保证关键任务不失败？

(5)Parquet 是 immutable 的，因此当HBase 中数据变更时，往往需要人工干预同步。

(6)架构复杂。从架构上看，数据在 HBase、消息队列、HDFS 间流转，涉及环节太多，运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。

(7)时效性低。数据从HBase导出成静态文件是周期性的，一般这个周期是一天或一小时，在时效性上不是很高。

(8)难以应对后续的更新。真实场景中，总会有数据是「延迟」到达的。如果这些数据之前已经从 HBase 导出到 HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。

为了解决上述架构存在的问题，Cloudera公司开发了Kudu，kudu 的定位不是取代HBase，而是Fast Analytics on Fast Data，是一个既支持随机读写数据查询的业务、又支持批量扫描数据的实时分析的大数据存储引擎。

基于Apache Kudu 对频繁更新数据场景下的大数据实时分析

(1)为什么有了HBase还需要Kudu

首先，清楚以下几点是很重要的。
1)Kudu的定位绝不是取代HBase，而是以降低写的性能为代价，提高了批量扫描数据的性能，使其能够实现快速在线分析业务。

2)一个大数据存储引擎设计的初衷都是源于具体的业务场景，用来解决具体业务问题，没有能应对所有业务场景的大数据存储引擎。

3)HBase，可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。

4)HBase不适合做批量扫描数据分析的原因是:HBase本身的设计并不适合批量获取数据,都说HBase是列式数据库，其实从底层存储的角度来说它并不是列式的，获取指定列数据时是会读到其他列数据的。相对HBase而言,Parquet格式针对分析场景就做了很多优化。HBase是LSM-Tree架构的数据库，这导致了HBase读取数据路径比较长，从内存到磁盘，可能还需要读多个HFile文件做版本合并。LSM 的中心思想就是将随机写转换为顺序写来大幅提高写入操作的性能，但是牺牲了部分读的性能。

5)Kudu不及HDFS批处理快，也不及HBase随机读写能力强，但是反过来它比HBase批处理快（适用于OLAP的分析场景），而且比HDFS随机读写能力强（适用于实时写入或者更新的场景），这就是Kudu存在的根本意义。

(2)为什么不能想办法改进HBase呢

Kudu 的很多特性跟 HBase 很像，它支持索引键的查询和修改。 Cloudera公司也曾经想过基于 HBase 进行修改，将HBase修改成既合适随机访问数据的查询，又合适做批量数据扫描的数据分析平台，然而结论是对 HBase 的改动非常大， Kudu 的数据模型和磁盘存储都与 HBase 不同。 HBase 本身成功的适用于大量的其它场景，因此修改 HBase 很可能吃力不讨好。最后 Cloudera 决定开发一个全新的存储系统。