kudu教程（二）——产生背景

##kudu教程（二）——产生背景

1 功能上的空白
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等计算引擎进行查询，生成最终报表。
这样一条工具链繁琐而复杂，而且还存在很多问题，比如：

如何处理某一过程出现失败
从HBase将数据导出到文件，多久的频率比较合适
当生成最终报表时，最近的数据并无法体现在最终查询结果上
维护集群时，如何保证关键任务不失败
Parquet是immutable，因此当HBase中删改某些历史数据时，往往需要人工干预进行同步
这时候，用户就希望能够有一种优雅的存储解决方案，来应付不同类型的工作流，并保持高性能的计算能力。Cloudera很早就意识到这个问题，在2012年就开始计划开发Kudu这个存储系统，终于在2015年发布并开源出来。Kudu是对HDFS和HBase功能上的补充，能提供快速的分析和实时计算能力，并且充分利用CPU和I/O资源，支持数据原地修改，支持简单的、可扩展的数据模型

2. 新的硬件设备
   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的利用更充分了。

3. 设计初衷
   kudu设计的初衷为了解决如下问题：

对数据扫描(scan)和随机访问(random access)同时具有高性能，简化用户复杂的混合架构
高CPU效率，使用户购买的先进处理器的的花费得到最大回报
高IO性能，充分利用先进存储介质
支持数据的原地更新，避免额外的数据处理、数据移动
支持跨数据中心replication
Kudu的很多特性跟HBase很像，它支持索引键的查询和修改。Cloudera曾经想过基于Hbase进行修改，然而结论是对HBase的改动非常大，Kudu的数据模型和磁盘存储都与Hbase不同。HBase本身成功的适用于大量的其它场景，因此修改HBase很可能吃力不讨好。最后Cloudera决定开发一个全新的存储系统。

Kudu的定位是提供”fast analytics on fast data”，也就是在快速更新的数据上进行快速的查询。它定位OLAP和少量的OLTP工作流，如果有大量的random accesses，官方建议还是使用HBase最为合适。