Kudu的架构原理、底层数据模型和读写流程详解

目录

一、Apache Kudu 介绍 

1. 背景介绍 

2. kudu 是什么 

3. kudu 应用场景 

二、Apache Kudu 架构 

1. Table 

2. Tablet 

3. Tablet Server 

4. Master Server 

三、Apache Kudu 原理 

1. table 与 schema 

2. kudu 底层数据模型 

3. tablet 发现过程 

4. kudu 写流程 

5. kudu 读流程 

6. kudu 更新流程 

---

一、Apache Kudu 介绍 

1. 背景介绍 

在 KUDU 之前，大数据主要以两种方式存储；   
（1）静态数据： 
  以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。 这类存储的局限性是数据无法进行随机的读写。  
（2）动态数据： 
以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。 局限性是批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景。 从上面分析可知，这两种数据在存储方式上完全不同，进而导致使用场景完全不同，但在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，又需要批量分析的大数据场景，该如何选择呢？ 这个场景中，单种存储引擎无法满足业务需求，我们需要通过多种大数据工具组合来满足这一需求，如下图所示：

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

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

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

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

为了解决上述架构的这些问题，KUDU 应运而生。KUDU 的定位是 Fast Analytics on Fast Data，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。 

从上图可以看出，KUDU 是一个折中的产品，在 HDFS 和 HBase 这两个偏科生中平衡了随机读写和批量分析的性能。从 KUDU 的诞生可以说明一个观点：底层的技术发展很多时候都是上层的业务推动的，脱离业务的技术很可能是空中楼阁。

2. kudu 是什么 

Apache Kudu 是由 Cloudera开源的存储引擎，可以同时提供低延迟的随机读写和高效的数据分析能力。它是一个融合HDFS 和HBase的功能的新组件，具备介于两者之间的新存储组件。 Kudu 支持水平扩展，并且与 Cloudera Impala 和Apache Spark等当前流行的大数据查询和分析工具结合紧密。

3. kudu 应用场景 

适用于那些既有随机访问，也有批量数据扫描的复合场景 

高计算量的场景 

使用了高性能的存储设备，包括使用更多的内存 

支持数据更新ÿ