KUDU(一)kudu概述

文章目录

概述
使用场景
对比其他存储
Kudu基本架构
Kudu中的相关概念和机制

概述

Kudu是一个分布式列式存储引擎/系统，由Cloudera开源后捐献给Apache基金会很快成为顶级项目。用于对大规模数据快速读写的同时进行快速分析

官网
https://kudu.apache.org/

Kudu运行在一般的商用硬件上，支持水平扩展和高可用，集HDFS的顺序读和HBase的随机读于一身，同时具备高性能的随机写，以及很强大的可用性（单行事务，一致性协议），支持与Impala/spark计算引擎。

数据形态	存储	场景	局限性
静态数据	HDFS(Parquet)+Hive/Impala	高吞吐离线大数据分析	数据无法实现随机读写
动态数据	HBase/Cassandra 作为存储	大数据随机读写	不适合高吞吐大数据离线分析

造成问题
1.数据过度冗余,数据需要存储多份以支撑多个应用，这样造成了存储等资源的浪费
2.架构复杂导致开发、运维、测试成本高,同时维护多套存储系统，架构复杂，开发、运维、测试成本相对较高
3. 数据不一致容易误解,多套数据由于程序bug或者其他原因很容易出现数据不一致的情况，往往会造成业务方的误解
为了解决上述问题业界做了很多尝试，例如HBase+Hive整合

Kudu 是一个折中的产品，它平衡了随机读写和批量分析的性能,当然Kudu身上还有很多概念或者标签，有分布式文件系统（好比HDFS），有一致性算法（好比Zookeeper），有Table（好比Hive Table），有Tablet（好比Hive Table Partition），有列式存储（好比Parquet），有顺序和随机读取（好比HBase），所以看起来kudu是一个轻量级的 HDFS +Zookeeper + Hive + Parquet + HBase，除此之外，kudu还有自己的特点，快速写入+读取，使得
kudu+impala非常适合OLAP场景，尤其是Time-series场景

使用场景

1.实时数据更新
2.时间序列相关的应用(例如APM),海量历史数据查询(数据顺序扫描),必须非常快地返回关于单个实体的细粒度查询(随机读)。
3.实时预测模型的应用(机器学习),支持根据所有历史数据周期地更新模型。

对比其他存储

HTAP:类比OLAP,kudu可以与hive,impala,sparkSQL等OLAP SQL查询引擎结合
类比OLTP,kudu可以根据主键快速检索,实现对表分析查询连续不断写入数据

存储	大规模数据扫描(分析场景)	随机读写
HDFS	全表扫描	不擅长随机读,不支持随机写
HBase	可以支持,性能差	随机读写,列式存储
Kudu	比hbase更擅长大规模数据扫描.接近HDFS上Parquet性能	擅长随机读写

Kudu基本架构

Kudu是典型的主从架构。一个Kudu集群由主节点即Master和若干个从节点即
Tablet Server组成。Master负责管理集群的元数据（类似于HBase Master），Tablet Server负责数据存储（类似HBase的RegionServer）。在生产环境，一般部署多个Master实现高可用（奇数个、典型的是3个），Tablet Server一般也是奇数个。

基本术语
Table(表)

Kudu中Table（表）的概念跟其他关系型数据库一样，table是数据存储在 Kudu 的位置。表具有schema（表结构）和全局有序的primary key（主键）。table被水平分成很多段，每个段称为Tablet。

Tablet

一个tablet 是一张表table 连续的segment（片段），类似于HBase的region 或关系型数据库
partition（分区）。每个tablet存储着一定连续range的数据（key），且tablet两两间的range不会重叠。一张表的所有tablet包含了这张表的所有key空间。tablet 会冗余存储。放置到多个 tablet server上，并且在任何给定的时间点，其中一个副本被认为是leader tablet,其余的被认之为follower tablet。每个tablet都可以进行数据的读请求，但只有Leader tablet负责写数据请求

Tablet Server

Tablet server是Kudu集群中的从节点，负责数据存储，并提供数据读写服务。一个 Tablet server 存储了table表的tablet，向kudu client 提供读取数据服务。对于给定的tablet，一个tablet server 充当 leader，其他 tablet server 充当该 tablet 的 follower 副本。只有 leader服务写请求，然而 leader 或 followers 为每个服务提供读请求。一个 tablet server可以服务多个 tablets ，并且一个 tablet 可以被多个 tablet servers 服务着。

Master

集群中的主节点，负责集群管理、元数据管理等功能,保持跟踪所有的tablets、tablet servers、catalog tables（目录表）和其它与集群相关的,metadata。在给定的时间点，只能有一个起作用的master（也就是 leader）
如果当前的leader消失，则选举出一个新的master，使用Raft协议来进行选举。master还协调客户端的metadata operations（元数据操作）,例如，当创建新表时，客户端内部将请求发送给master。 master将新表的元数据写入catalog
table（目录表，元数据表），并协调在tablet server上创建tablet的过程。所有master的元数据都存储在一个tablet中，可以复制到所有其他候选的master。tablet server以设定的间隔向master发出心跳（默认值为每秒一次）。

Raft Consensus Algorithm

Kudu 使用 Raft consensus algorithm 作为确保常规 tablet 和 master 数据的容错性和一致性的手段。通过 Raft协议，tablet 的多个副本选举出 leader，它负责接受请求和复制数据写入到其他
follower副本。一旦写入的数据在大多数副本中持久化后，就会向客户确认。给定的一组N副本（通常为 3 或 5 个）能够接受最多(N - 1)/2 错误的副本的写入。

Catalog Table(目录表)

catalog table是Kudu 的元数据表。它存储有关tables和tablets的信息.catalog table（目录表）不能被直接读写，它只能通过客户端 API中公开的元数据操作访问。
catalog table存储以下两类元数据：
1、Tables：table schemas 表结构，locations 位置，states 状态
2、Tablets：现有tablet 的列表，每个 tablet 的副本所在哪些tablet server，tablet的当前状态以及开始和结束的keys（键）。

Kudu中的相关概念和机制

主键

类比关系型数据库的主键,Kudu基于主键重组和索引数据,没有二级键,没有二级索引,影响到数据存储在哪台服务器上,因此主键设计不好影响查询性能,通常还会导致热点问题,即大多数读或者写请求落在一台服务器上

分区

范围分区
哈希分区
多级分区(范围+哈希)