既然有了HBase，为什么还需要Kudu呢？

 

 

　　不多说，直接上干货！

 

 

 

那既然有了HBase，为什么还需要Kudu呢？

　　简单的说，就是嫌弃HBase在OLAP（联机分析处理）场合，SQL／MR类的批量检索场景中，性能不够好。通常这种海量数据OLAP场景，要不走预处理的路，比如像EBAY麒麟这样走Cube管理的，或者像谷歌Mesa这样按业务需求走预定义聚合操作。再有就是自己构建数据通道，串接实时和批量处理两种系统，发挥各自的特长。

　　但是OLAP是个复杂的问题，场景众多，必然不可能有完美的通用解决方案，Kudu定位于应对快速变化数据的快速分析型数据仓库，希望靠系统自身能力，支撑起同时需要高吞吐率的顺序和随机读写的应用场景（可能的场景，比如时间序列数据分析，日志数据实时监控分析），提供一个介于HDFS和HBase的性能特点之间的一个系统，在随机读写和批量扫描之间找到一个平衡点，并保障稳定可预测的响应延迟。

 

 

 

 

结构化数据存储系统在 Hadoop 生态系统里面，通常分为两类：

• 静态数据，数据通常都是使用二进制格式存放到 HDFS 上面，譬如 Apache Avro，Apache Parquet。但无论是 HDFS 还是相关的系统，都是为高吞吐连续访问数据这些场景设计的，都没有很好的支持单独 record 的更新，或者是提供好的随机访问的能力。
• 动态数据，数据通常都是使用半结构化的方式存储，譬如 Apache HBase，Apache Cassandra。这些系统都能低延迟的读写单独的 record，但是对于一些像 SQL 分析这样需要连续大量读取数据的场景，显得有点捉紧见拙。

　　上面的两种系统，各有自己的侧重点，一类是低延迟的随机访问特定数据，而另一类就是高吞吐的分析大量数据。之前，我们并没有这样的系统可以融合上面两种情况，所以通常的做法就是使用 pipeline，譬如我们非常熟悉的 Kafka，通常我们会将数据快速写到 HBase 等系统里面，然后通过 pipeline，在导出给其它分析系统。虽然我们在一定层面上面，我们其实通过 pipeline 来对整个系统进行了解耦，但总归要维护多套系统。而且数据更新之后，并不能直接实时的进行分析处理，有延迟的开销。所以在某些层面上面，并不是一个很好的解决方案。

　　Kudu 致力于解决上面的问题，它提供了简单的来处理数据的插入，更新和删除，同时提供了 table scan 来处理数据分析。通常如果一个系统要融合两个特性，很有可能就会陷入两边都做，两边都没做好的窘境，但 Kudu 很好的在融合上面取得了平衡。

 

 

 

 

 

那为什么不能想办法改进HBase呢？

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