CC00001.kudu——|Hadoop&OLAP_Kudu.V01|——|kudu.v01|概述背景|数据模型|

一、概述：背景

### --- 背景

~~~     Apache Kudu是由Cloudera开源的存储引擎，
~~~     可以同时提供低延迟的随机读写和高效的数据分析能力。
~~~     Kudu支持水平扩展，使用Raft协议进行一致性保证，
~~~     并且与Cloudera Impala和Apache Spark等当前流行的大数据查询和分析工具结合紧密。
~~~     近两年，KUDU 在大数据平台的应用越来越广泛。
~~~     在阿里、小米、网易等公司的大数据架构中，KUDU 都有着不可替代的地位。
~~~     现在提起大数据存储，我们能想到的技术有很多，
~~~     比如HDFS，以及在HDFS上的列式存储技术Apache Parquet，Apache ORC，
~~~     还有以KV形式存储半结构化数据的Apache HBase和Apache Cassandra等等。
~~~     既然有了如此多的存储技术，Cloudera公司为什么要开发出一款全新的存储引擎Kudu呢？

### --- 基于HDFS的存储技术：

~~~     数据分析：Parquet，具有高吞吐量连续读取数据的能力
~~~     实时读写：HBase和Cassandra等技术适用于低延迟的随机读写场景

### --- 在 KUDU 之前，大数据主要以两种方式存储：

~~~     # 静态数据：
~~~     以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。
~~~     这类存储的局限性是数据无法进行随机的读写。
~~~     # 动态数据：
~~~     以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。
~~~     这类存储的局限性是批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景。
~~~     # 所以现在的企业中，经常会存储两套数据分别用于实时读写与数据分析，

二、先将数据写入HBase中，再定期通过ETL到Parquet进行数据同步。

### --- 但是这样做有很多缺点：

~~~     用户需要在两套系统间编写和维护复杂的ETL逻辑。结构复杂，维护成本高。
~~~     时效性较差。因为ETL通常是一个小时、几个小时甚至是一天一次，
~~~     那么可供分析的数据就需要一个小时至一天的时间后才进入到可用状态，
~~~     也就是说从数据到达到可被分析之间是会存在一个较为明显的“空档期”的。
~~~     更新需求难以满足。在实际情况中可能会有一些对已经写入的数据的更新需求，
~~~     这种情况往往需要对历史数据进行更新，
~~~     而对Parquet这种静态数据集的更新操作，代价是非常昂贵的。
~~~     存储资源浪费。两套存储系统意味着占用的磁盘资源翻倍了，造成了成本的提升。
~~~     我们知道，基于HDFS的存储技术，比如Parquet，具有高吞吐量连续读取数据的能力；
~~~     而HBase和Cassandra等技术适用于低延迟的随机读写场景，
~~~     那么有没有一种技术可以同时具备这两种优点呢？Kudu提供了一种“happymedium”的选择：
~~~     Kudu不但提供了行级的插入、更新、删除API，同时也提供了接近Parquet性能的批量扫描操作。
~~~     使用同一份存储，既可以进行随机读写，也可以满足数据分析的要求。

三、数据模型

### --- kudu数据模型

~~~     KUDU 的数据模型与传统的关系型数据库类似，一个 KUDU 集群由多个表组成，
~~~     每个表由多个字段组成，一个表必须指定一个由若干个(>=1)字段组成的主键，如下图：

### --- 从用户角度来看，

~~~     Kudu是一种存储结构化数据表的存储系统。
~~~     在一个Kudu集群中可以定义任意数量的table，每个table都需要预先定义好schema。
~~~     每个table的列数是确定的，每一列都需要有名字和类型，
~~~     每个表中可以把其中一列或多列定义为主键。
~~~     这么看来，Kudu更像关系型数据库，而不是像HBase、Cassandra和MongoDB这些NoSQL数据库。
~~~     不过Kudu目前还不能像关系型数据一样支持二级索引。 
~~~     Kudu使用确定的列类型，字段是强类型的，而不是类似于NoSQL的“everything is byte”。
~~~     # 这可以带来两点好处：
~~~     确定的列类型使Kudu可以进行类型特有的编码，节省空间。
~~~     可以提供 SQL-like 元数据给其他上层查询工具，比如BI工具。
~~~     KUDU 的使用场景是 OLAP 分析，有一个数据类型对下游的分析工具也更加友好。
~~~     用户可以使用 Insert，Update和Delete API对表进行写操作。
~~~     不论使用哪种API，都必须指定主键。
~~~     但批量的删除和更新操作需要依赖更高层次的组件(比如Impala、Spark)。
~~~     Kudu目前还不支持多行事务。 而在读操作方面，Kudu只提供了Scan操作来获取数据。
~~~     用户可以通过指定过滤条件来获取自己想要读取的数据，
~~~     但目前只提供了两种类型的过滤条件：主键范围和列值与常数的比较。
~~~     由于Kudu在硬盘中的数据采用列式存储，所以只扫描需要的列将极大地提高读取性能。

### --- 一致性模型

~~~     # 内部事务隔离
~~~     Kudu为用户提供了两种一致性模型。默认的一致性模型是snapshot consistency。
~~~     这种一致性模型保证用户每次读取出来的都是一个可用的快照，
~~~     但这种一致性模型只能保证单个client可以看到最新的数据，
~~~     但不能保证多个client每次取出的都是最新的数据。
~~~     另一种一致性模型external consistency可以在多个client之间保证每次取到的都是最新数据，
~~~     但是Kudu没有提供默认的实现，需要用户做一些额外工作。

### --- 为了实现external consistency，Kudu提供了两种方式

~~~     在client之间传播timestamp token。
~~~     在一个client完成一次写入后，会得到一个timestamp token，
~~~     然后这个client把这个token传播到其他client，这样其他client就可以通过token取到最新数据了。
~~~     不过这个方式的复杂度很高。
~~~     通过commit-wait方式，这有些类似于Google的Spanner。
~~~     但是目前基于NTP的commit-wait方式延迟实在有点高。
~~~     不过Kudu相信，随着Spanner的出现，未来几年内基于real-time clock的技术将会逐渐成熟。