引言
大家好,我是ChinaManor,直译过来就是中国码农的意思,俺希望自己能成为国家复兴道路的铺路人,大数据领域的耕耘者,一个平凡而不平庸的人。
一文快速搞懂系列讲究快速入门掌握一个新的大数据组件,帮助新手了解大数据技术,以下是系列文章:
文章传送门:
一文快速搞懂系列__一文快速搞懂SuperSet[实战案例]
一文快速了解Elastic Search 开源搜索引擎（技术选型+启动命令）
一文快速了解ClickHouse 战斗民族的开源搜索引擎（超详细解读+快速入门）
这是一文快速搞懂系列的第二篇:一文快速搞懂Kudu到底是什么
Kudu 介绍
近两年， KUDU 在大数据平台的应用越来越广泛，在 阿里、小米、网易 等公司的大数据架构中，
KUDU 都有着不可替代的地位。
背景介绍
在 Kudu之前，大数据主要以两种方式存储：
静态数据：
以 HDFS 引擎作为存储引擎，适用于 高吞吐量的离线大数据分析 场景；
这类存储的局限性是 数据无法进行随机的读写；
动态数据：
以 HBase、 Cassandra 作为存储引擎，适用于 大数据随机读写 场景；
这类存储的局限性是 批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景 ；
从上面分析可知，两种数据在 存储方式上 完全不同，进而导致使用场景完全不同，但在真实的场景
中，边界可能没有那么清晰，面对 既需要随机读写，又需要批量分析的大数据场景，该如何选择呢？
这个场景中，单种存储引擎无法满足业务需求，需要通过多种大数据工具组合来满足这一需求。
如上图所示， 数据实时写入 HBase，实时的数据更新也在 HBase完成，为了应对 OLAP需求，
定时（通常是 T+1或者 T+H）将 HBase数据写成静态的文件（如： Parquet）导入到 OLAP引擎（如：
HDFS）。 这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景，但它有如下 缺点：
架构复杂 。从架构上看，数据在 HBase、消息队列、 HDFS 间流转，涉及环节太多，运维成本
很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后
数据在多个系统上，对数据安全策略、监控等都提出了挑战。
时效性低 。数据从 HBase导出成静态文件是周期性的，一般这个周期是一天（或一小时），在
时效性上不是很高。
难以应对后续的更新。 真实场景中，总会有数据是延迟到达的。如果这些数据之前已经从 HBase
导出到 HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写
一遍，但这代价又很高。
为了解决上述架构的这些问题， Kudu应运而生。 Kudu的定位是 Fast Analytics on Fast Data，
是一个 既支持随机读写、又支持 OLAP 分析的大数据存储引擎 。
从上图可以看出， KUDU 是一个 折中的产品 ，在 HDFS 和 HBase 这两个偏科生中平衡了随
机读写和批量分析的性能。从 KUDU 的诞生可以说明一 个观点： 底层的技术发展很多时候都是上
层的业务推动的，脱离业务的技术很可能是空中楼阁 。
新的硬件设备
内存（ RAM）的技术发展非常快，它变得越来越便宜，容量也越来越大。 Cloudera的客户数
据显示，他们的客户所部署的服务器， 2012年每个节点仅有 32GB RAM，现如今增长到每个节点有
128GB或 256GB RAM。存储设备上更新也非常快，在很多普通服务器中部署 SSD也是屡见不鲜。
HBase、 HDFS、以及其他的 Hadoop工具都在不断自我完善，从而适应硬件上的升级换代。然而，
从根本上， HDFS基于 03年 GFS， HBase基于 05年 BigTable，在当时系统瓶颈主要取决于底层磁盘速
度。 当磁盘速度较慢时， CPU利用率不足的根本原因是磁盘速度导致的瓶颈，当磁盘速度提高了之
后， CPU利用率提高，这时候 CPU往往成为系统的瓶颈。 HBase、 HDFS由于年代久远，已经很难
从基本架构上进行修改，而 Kudu是基于全新的设计，因此可以更充分地利用 RAM、 I/O资源，并优
化 CPU利用率。
可以理解为： Kudu相比与以往的系统， CPU使用降低了， I/O的使用提高了， RAM的利用更充分了 。
Kudu 是什么
Apache Kudu是由 Cloudera开源的 存储引擎 ，可以同时提供 低延迟的随机读写和高效的数据分
析能力 。它是一个融合 HDFS和 HBase的功能的新组件，具备介于两者之间的新存储组件。
Kudu支持水平扩展，并且与 Cloudera Impala和 Apache Spark等当前流行的大数据查询和分析
工具结合紧密。
Kudu 应用场景
Kudu的很多特性 跟 HBase很像，它支持索引键的查询和修改 。 Cloudera曾经想过基于 HBase
进行修改，然而结论是对 HBase的改动非常大， Kudu的数据模型和磁盘存储都与 Hbase不同。 HBase
本身成功的适用于大量的其它场景，因此修改 HBase很可能吃力不讨好。最后 Cloudera决定开发一
个全新的存储系统。
1．Strong performance for both scan and random access to help customers simplify complex
hybrid architectures（ 适用于那些既有随机访问，也有批量数据 扫描的复合场景 ）
2．High CPU efficiency in order to maximize the return on investment that our customers are
making in modern processors（ 高计算量的场景 ）
3．High IO efficiency in order to leverage modern persistent storage（ 使用了高性能的存储设
备，包括使用更多的内存 ）
4．The ability to upDATE data in place, to avoid extraneous processing and data movement
（ 支持数据更新，避免数据反复迁移 ）
5．The ability to support active-active replicated clusters that span multiple data centers
in geographically distant locations（ 支持跨地域的实时数据备份和查询 ）
Kudu 架构
与 HDFS和 HBase相似， Kudu使用单个的 Master节点，用来管理集群的元数据，并且使用任意
数量的 Tablet Server（可对比理解 HBase中的 RegionServer角色）节点用来存储实际数据。 可以 部
署多个 Master节点来提高容错性 。 一个 table表的数据，被分割成 1个或多个 Tablet， Tablet被部署
在 Tablet Server来提供数据读写服务 。
数据模型
KUDU 的数据模型与传统的 关系型数据库 类似， 一个 KUDU 集群由多个 表 组成，每个表由多
个 字段 组成，一个表必须指定一个由若干个（ >=1）字段组成的 主键 ，如下图：
KUDU 表中的每个字段是强类型的 ，而不是 HBase 那样所有字段都认为是 bytes。好处是可
以 对不同类型数据进行不同的编码，节省空间 。同时，因为 KUDU 的使用场景是 OLAP 分析，
有一个数据类型对下游的分析工具也更加友好。
Table（表） ： 一张表 table是数据存储在 Kudu的从节点 tablet server中。表具有 schema 和全
局有序的 primary key（主键）。 table 被分成称为 tablets 的 segments。
Tablet：
1）、一个 tablet 是一张 table连续的 segment， tablet是 Kudu表的水平分区，类似于 google
Bigtable的 tablet，或者 HBase的 region。
2）、每个 tablet存储着一定连续 range的数据（ key），且 tablet两两间的 range不会重叠。
一张表的所有 tablet包含了这张表的所有 key空间。与其它数据存储引擎或关系型数据库中
的 partition（分区）相似。
3）、给定的 tablet 冗余到多个 tablet server 服务器上，并且在任何给定的时间点，其中
一个副本是 leader tablet，其他的副本为 follower tablet。
4）、每个 Tablet同时只有一个 leader副本，这个副本对用户提供修改操作，然后将修改结
果同步给 follower。
5）、 Follower只提供读服务，不提供修改服务。副本之间使用 raft协议来实现 High
Availability，当 leader所在的节点发生故障时， followers会重新选举 leader。 Raft协议的另
一个作用是实现 Consistency。 Client对 leader的修改操作，需要同步到 N/2+1个节点上，
该 操作才算成功。
分区策略
与大多数大数据存储引擎类似， KUDU 对表进行横向分区， KUDU 表会被横向切分存储在多
个 tablets 中。不过相比与其他存储引擎， KUDU 提供了更加丰富灵活的数据分区策略。
Range Partitioning，按照字段值范围进行分区， HBase 就采用了这种方式。
Example 1：没有边界，用 20150101和 20160101分割数据，将数据分成了三块
Example 2：有边界 [(2014-01-01), (2017-01-01)]，在 2015-01-01 and 2016-01-01处分割
Range Partitioning的优势是 在数据进行批量读的时候，可以把大部分的读变成同一个 tablet
中的顺序读，能够提升数据读取的吞吐量 。并且按照范围进行分区，可以很方便的进行分区扩展。
其劣势是同一个范围内的数据写入都会落在单个 tablet 上，写的压力大，速度慢。
Hash Partitioning，按照字段的 Hash 值进行分区， Cassandra 采用了这个方式。
下 面的案例中， metric表按照 host， metric散列分区，把数据写入到四个 bucket中。
与 Range Partitioning 相反，由于是 Hash 分区，数据的写入会被均匀的分散到各个 tablet
中，写入速度快。但是对于顺序读的场景这一策略就不太适用了，因为数据分散，一次顺序读需要
将各个 tablet 中的数据分别读取并组合，吞吐量低，并且 Hash 分区无法应对分区扩展的情况。
KUDU 支持用户对一个表指定一个范围分区规则和多个 Hash 分区规则，如下图：
多级散列分区组合，如下图所示：
列式存储
KUDU 是一个列式存储的存储引擎 ，其数据存储方式如下：
列式存储的数据库很适合于 OLAP 场景，其特点如下：
优势： 查询少量列时 IO 少，速度快；数据压缩比高；便于查询引擎性能优化：延迟物化、直
接操作压缩数据、向量化执行。
劣势： 查询列太多时性能下降（ KUDU 建议列数不超过 300）；不适合 OLTP 场景
整体架构
KUDU 中存在两个角色：
Mater Server：负责集群管理、元数据管理等功能
Tablet Server：负责数据存储，并提供数据读写服务
为了实现分区容错性，跟其他大数据产品一样，对于每个角色， 在 KUDU 中都可以设置特定
数量（ 3 或 5）的副本。 各副本间通过 Raft 协议来保证数据一致性。 Raft 协议与 ZAB 类似，都
是 Paxos 协议的工程简化版本。
上图显示了一个具有 三个 master 和 多个 tablet server 的 Kudu 集群 ，每个服务器都支持多
个 tablet。它说明了如何使用 Raft 共识来 允许 master 和 tablet server 的 leader 和 follow。
文档： https://kudu.apache.org/docs/index.html#_architectural_overview
此外， tablet server 可以成为某些 tablet 的 leader，也可以是其他 tablet 的 follower。 leader 以
金色显示，而 follower 则显示为蓝色。下面是一些基本概念：
角色 作用
Master 集群中的老大，负责集群管理、元数据管理等功能
Tablet Server 集群中的小弟，负责数据存储，并提供数据读写服务
一个 tablet server 存储了 table表的 tablet 和为 tablet 向 client 提供服务。
对于给定的 tablet，一个 tablet server 充当 leader，其他 tablet server 充当
该 tablet 的 follower 副本。
只有 leader服务写请求，然而 leader 或 followers 为每个服务提供读请求 。
一个 tablet server 可以服务多个 tablets ，并且一个 tablet 可以被多个
tablet servers 服务着。
Table（表） 一张 table是数据存储在 Kudu的 tablet server中。表具有 schema 和全局有序
的 primary key（主键）。 table 被分成称为 tablets 的 segments。
Tablet 一个 tablet 是一张 table连续的 segment， tablet是 kudu表的水平分区，类似
于 google Bigtable的 tablet，或者 HBase的 region。每个 tablet存储着一定连续
range的数据（ key），且 tablet两两间的 range不会重叠。一张表的所有 tablet
包含了这张表的所有 key空间。与其它数据存储引擎或关系型数据库中的
partition（分区）相似。给定的 tablet 冗余到多个 tablet 服务器上，并且在任
何给定的时间点，其中一个副本被认为是 leader tablet。任何副本都 可以对读
取进行服务，并且写入时需要在为 tablet 服务的一组 tablet server之间达成
一致性。
Tablet server 的任务非常繁重 , 其负责和数据相关的所有操作 , 包括存储 , 访问 , 压缩 , 其还
负责将数据复制到其它机器。 因为 Tablet server`特殊的结构 , 其任务过于繁重 , 所以有如下限制：
Kudu 最多支持 300个服务器 , 建议 Tablet server最多不超过 100 个
建议每个 Tablet server 至多包含 2000 个 tablet(包含 Follower)
建议每个表在每个 Tablet server中至多包含 60个 tablet(包含 Follower)
每个 Tablet server至多管理 8TB数据
理想环境下 , 一个 tablet leader应该对应一个 CPU`核心 , 以保证最优的扫描性能
Kudu Client 交互
KUDU Client 在与服务端交互时，先从 Master Server 获取元数据信息，然后去 Tablet Server
读写数据，如下图：
Kudu 可视化工具
Kudu 使用方法 ： https://kudu.apache.org/docs/developing.html
方式一：可 通过 Java client、 C++ client、 Python client操作 Kudu表 ，但要构建 Client并编写应
用程序；
方式二：可 通过 Kudu-Spark包集成 Kudu与 Spark，并编写 Spark应用程序来操作 Kudu表；
KuduContext，集成 Kudu上下文实例对象，封装数 据为 RDD
SparkSession ，读取 Kudu表的数据，封装为 DataFrame
方式三：可 通过 Impala的 shell对 Kudu表进行交互式的操作 ，因为 Impala2.8及以上的版本已经
集成了对 Kudu的操作。
直 接定义 Impala表数据存储在 Kudu中，内部集成
Kudu 框架本身提供命令 kudu管理 Kudu集群，位于 $KUDU_HOME/bin目录
Kudu-Plus一款针对 Kudu可视化工具， GitHub地址： https://github.com/Xchunguang/kudu-plus
Kudu-plus是可视化管理 Kudu的工具，由于 Kudu虽然是列式数据库，但是可以表达成关系数
据库类似的表和字段等信息，某种情况下通过可视化管理更加轻松。 KuduPlus包括对表和数据的操
作约束，可以帮助更好的理解 Kudu。目前版本的功能如下所列：
下载地址： 链接： https://pan.baidu.com/s/1_VX0wwAIh60-Mnus8r8uqQ 提取码： 7ltk
总结
以上就是大数据框架Kudu的全部内容,如果对你有帮助,不妨点个关注~
