创建kudu表_Kudu概念和架构

前言

---

Apache Kudu是专门为Hadoop平台开发的列式存储管理器(不依赖于Hadoop组件)。 

Kudu具有Hadoop生态系统应用程序的共同技术特性：

    运行在商用硬件上

    易于水平扩展

    支持高可用

Apache Kudu是Apache Software Foundation(Apache软件基金会)中的顶级项目。

https://kudu.apache.org/

Kudu为我们带来哪些好处

---

Kudu能够对OLAP任务进行快速分析处理。

Kudu能够与MapReduce，Spark，Flume和其他Hadoop生态系统组件集成。

    Kudu与Spark的集成非常成熟：

    https://kudu.apache.org/docs/developing.html#_kudu_integration_with_spark

Kudu与Apache Impala的紧密集成，使其成为可以替换(HDFS+Apache Parquet)的一个可选的好选择。

Kudu拥有强大而灵活的一致性模型，允许用户针对每个请求选择一致性要求，包括用于严格序列化一致性的选项。

Kudu具备同时运行顺序型和随机型任务的强大性能。

Kudu可以通过Cloudera Manager进行管理。

高可用性，Tablet Server和Master使用Raft共识算法，只要可用副本多于不可用副本，它就可以确保可用性。

即使leader Tablet出现故障，也可以通过只读的follower Tablet提供数据读取(查询)服务。

Kudu支持结构化数据模型、insert update upsert。

结合上面的所有这些特性，Kudu可以支持难以或无法在当前可用的Hadoop存储技术上实现的应用场景。 Kudu作为可行的分布式存储和快速分析解决方案，适用的应用场景包括：

新数据到达后必须立即提供给最终用户使用 的实时数据报表。

支持跨大量历史数据查询的时间序列应用，同时需要返回有关单个实体的明细数据。

使用预测模型做出实时决策的应用，基于所有历史数据定期刷新预测模型。

Kudu概念

---

列式数据存储

Kudu是一个列式数据存储系统。 

列式数据存储 将数据存储在强类型的列中。 

出于以下两点考虑，通过适当的设计，列式存储可以胜任分析型或数据仓库的任务：

读取效率

对于分析型查询，用户可以只查询单个列或该列的一部分，而忽略其他的列。 

这意味着可以在读取磁盘上最少数量的块的同时能够满足查询需求。 

对于基于行的存储，即使只从几列中返回值，也需要读取整行数据(连根拔起带出泥)。

数据压缩

由于给定的一个列仅包含一种类型的数据，所以基于 模式的压缩 比基于 行的解决方案中压缩混合数据类型的 效率要高好几个数量级。结合从列读取数据的效率，压缩可以在从磁盘读取更少的块的同时完成快速查询。

Raft共识算法

Raft共识算法提供了一种从潜在leader池(所有参与leader选举的候选者节点)中为分布式集群选举leader的方法。 

如果follower无法找到当前的leader，它就成为candidate(候选者)。 

在选举节点达到设定数量的情况下，一个candidate当选为leader，其他节点自然成为follower。 

Raft是一种可靠的算法。

https://raft.github.io/

Kudu使用Raft共识算法实现master集群节点和tablets leader选举，还用来确定一个写操作是成功或者失败。

Table-表

表就是表格，和”传统“关系数据库表概念一致，由行和列组织而成。

Table代表数据在Kudu中的存储位置，它有schema(列定义)和完全有序的主键。 

一个table会根据主键切分成多个segments(段)，称为tablet。

Tablet

一个Tablet是由表里面相邻的连续的segment组成，类似于其他数据存储引擎或关系数据库中的分区。

一个给定的Tablet会被复制到多台Tablet Server服务节点上-从而形成多个副本，在任意给定的时间点，这些副本中的其中一个会被选举为leader tablet。

任意Tablet副本都可以提供数据读取服务，写数据需要在一组tablet服务器之间达成共识。

Tablet Server

Tablet Server为客户端提供Tablet的存储查询等服务。

对于一个给定的tablet，其中一个Tablet Server作为leader，其他Tablet Server为该tablet的follower副本提供服务。

只有leader Tablet Server负责处理写请求，leader和follower都可以处理读请求。

Leader是通过Raft共识算法选举产生的。

一个Tablet Server上面可以处理(服务)多个Tablet，一个Tablet也可以由多个Tablet Server来提供(读写)服务(通过副本)。

Master

Master用来跟踪所有的Tablet、Tablet Server和Catalog(目录)以及其他与群集相关的元数据。

在任意给定的时间点，Master集群中只有一个Leader Master。

如果当前Leader找不到了，将会根据Raft共识算法重新选举产生一个新的Leader。

Master还会协调客户端的元数据操作。

例如，在创建新表时，客户端会在内部将请求发送给Master。

Master将新表的元数据写入目录表(Catalog)，并协调在Tablet Server上面创建Tablet的处理流程。

Master的数据会存到Master tablet上面，且可以复制到其他的非Leader的Master节点上。

默认每秒钟Tablet Server会向Master发送一次心跳。

Catalog Table - 目录表

目录表是Kudu元数据中最重要的部分。

它存储有关Table和Tablet的信息。

用户可以调用Kudu客户端API通过Master访问Catalog Table。

Catalog Table不能被直接读写，只能通过客户端API中公开的元数据操作对其进行访问。

目录表存储两类元数据：

Tables：Table schemas, locations, and states

Tablets：The list of existing tablets, which tablet servers have replicas of each tablet, the tablet's current state, and start and end keys.

逻辑复制

Kudu并不是在硬盘上对数据做物理复制，而是采取了逻辑复制的办法，这有以下优点：

insert和update需要通过网络传输数据，delete操作不需要移动任何数据。

delete操作的请求会发送到每一个tablet server上，在本地做删除操作。

普通的物理操作，比如数据压缩，并不需要通过网络传输数据，这与使用HDFS的存储系统不同，在HDFS中，需要通过网络传输数据块以实现所需数量的副本。

tablet不需要在相同时间或相同任务里执行compactions(压缩、紧凑排列)，甚至不需要在物理存储层面保持同步，避免了compactions和繁重的写数据造成的高延时。

下图展示了具有三个Master节点(A B C)和n个Tablet Server的Kudu群集，每个服务器都服务于多个Tablet。 Raft共识算法从三个Master节点中选出了Master tablet Leader，以及从Tablet1的多个副本中选出了Tablet1 Leader，还有Tablet2 Leader...Tabletn Leader...Leader之外的是follower。

【END】