Cloudera Kudu是什么？

　　不多说，直接上干货！

Cloudera Kudu是什么？

　　kudu是cloudera在2012开始秘密研发的一款介于hdfs和hbase之间的高速分布式列式存储数据库。兼具了hbase的实时性、hdfs的高吞吐，以及传统数据库的sql支持。作为一款实时、离线之间的存储系统。定位和spark在计算系统中的地位非常相似。如果把mr+hdfs作为离线计算标配，storm+hbase作为实时计算标配。spark+kudu有可能成为未来最有竞争力的一种架构。

也就是kafka -> spark -> kudu这种架构，未来此架构是否会风靡，暂且不言论。让我们拭目以待吧！

　　Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的新成员之一（incubating），专门为了对快速变化的数据进行快速的分析，填补了以往Hadoop存储层的空缺。

　　Kudu是Todd Lipcon@Cloudera带头开发的存储系统，其整体应用模式和HBase比较接近，即支持行级别的随机读写，并支持批量顺序检索功能。

Kudu 是一个针对 Apache Hadoop 平台而开发的列式存储管理器。Kudu 共享 Hadoop 生态系统应用的常见技术特性:它在commodity hardware（商品硬件）上运行，horizontally scalable（水平可扩展），并支持 highly available（高可用）性操作。

　 Kudu的目标是：提供快速的全量数据分析与实时处理功能；充分利用先进CPU与IO资源；支持数据更新；简单、可扩展的数据模型。

Kudu的官网

 http://kudu.apache.org/

A new addition to the open source Apache Hadoop ecosystem, Apache Kudu completes Hadoop's storage layer to enablefast analytics on fast data.

背景——功能上的空白

　　 Hadoop 生态系统有很多组件，每一个组件有不同的功能。在现实场景中，用户往往需要同时部署很多 Hadoop 工具来解决同一个问题，这种架构称为 混合架构 (hybrid architecture) 。比如，用户需要利用 Hbase 的快速插入、快读 random access 的特性来导入数据， HBase 也允许用户对数据进行修改， HBase 对于大量小规模查询也非常迅速。同时，用户使用 HDFS/Parquet + Impala/Hive 来对超大的数据集进行查询分析，对于这类场景， Parquet 这种列式存储文件格式具有极大的优势。

　　很多公司都成功地部署了 HDFS/Parquet + HBase 混合架构，然而这种架构较为复杂，而且在维护上也十分困难。首先，用户用 Flume 或 Kafka 等数据 Ingest 工具将数据导入 HBase ，用户可能在 HBase 上对数据做一些修改。然后每隔一段时间 ( 每天或每周 ) 将数据从 Hbase 中导入到 Parquet 文件，作为一个新的 partition 放在 HDFS 上，最后使用 Impala 等计算引擎进行查询，生成最终报表。

这样一条工具链繁琐而复杂，而且还存在很多问题，比如：

　　（1）如何处理某一过程出现失败？　　

　　（2）从 HBase 将数据导出到文件，多久的频率比较合适？

　　（3）当生成最终报表时，最近的数据并无法体现在最终查询结果上。

　　（4）维护集群时，如何保证关键任务不失败？

　　（5）Parquet 是 immutable ，因此当 HBase 中删改某些历史数据时，往往需要人工干预进行同步。

这时候，用户就希望能够有一种优雅的存储解决方案，来应付不同类型的工作流，并保持高性能的计算能力。 Cloudera 很早就意识到这个问题，在 2012 年就开始计划开发 Kudu 这个存储系统，终于在 2015 年发布并开源出来。 Kudu 是对 HDFS 和 HBase 功能上的补充，能提供快速的分析和实时计算能力，并且充分利用 CPU 和 I/O 资源，支持数据原地修改，支持简单的、可扩展的数据模型。

背景——新的硬件设备

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 的利用更充分了。

1. Kudu的简介

Kudu 设计之初，是为了解决一下问题：

对数据扫描 (scan) 和随机访问 (random access) 同时具有高性能，简化用户复杂的混合架构；
高 CPU 效率，使用户购买的先进处理器的的花费得到最大回报；
高 IO 性能，充分利用先进存储介质；
支持数据的原地更新，避免额外的数据处理、数据移动。

2. Kudu支持跨数据中心 replication

Kudu 的很多特性跟 HBase 很像，它支持索引键的查询和修改。 Cloudera 曾经想过基于 Hbase 进行修改，然而结论是对 HBase 的改动非常大， Kudu 的数据模型和磁盘存储都与 Hbase 不同。 HBase 本身成功的适用于大量的其它场景，因此修改 HBase 很可能吃力不讨好。最后 Cloudera 决定开发一个全新的存储系统。

3. Kudu的对外接口

Kudu 提供 C++ 和 JAVA API ，可以进行单条或批量的数据读写， schema 的创建修改。除此之外， Kudu 还将与 hadoop 生态圈的其它工具进行整合。目前， kudu beta 版本对 Impala 支持较为完善，支持用 Impala 进行创建表、删改数据等大部分操作。 Kudu 还实现了 KuduTableInputFormat 和 KuduTableOutputFormat ，从而支持 Mapreduce 的读写操作。同时支持数据的 locality（本地性）。目前对 spark 的支持还不够完善， spark 只能进行数据的读操作。

4. 节点

　　Kudu-master：主节点，维护存储表元数据，跟踪协调所有的tserver的状态和数据，安装奇数节点(最少三个)。

　　Kudu-tserver：从节点，存储具体表数据的节点，一个表数据可以有多个副本，但只有一个leader才能负责写请求，leader和follower都可以负责读请求。安装最少三个节点。

　使用案例——小米

　　为什么这里用小米来作为案例，是因为小米在Kudu走在前列。

　　小米是Hbase的重度用户，他们每天有约50亿条用户记录。小米目前使用的也是HDFS + HBase这样的混合架构。可见该流水线相对比较复杂，其数据存储分为SequenceFile，Hbase和Parquet。

　　在使用Kudu以后，Kudu作为统一的数据仓库，可以同时支持离线分析和实时交互分析。如下：