一、Apache Kudu的介绍

1.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的诞生可以说明一个观点：底层的技术发展很多时候都是上业务推动，脱离业务的技术很可能是空中楼阁。

1.2、kudu是什么

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

1.3、kudu应用场景

• 适用于那些既有随机访问，也批量数据扫描的复合场景
• 高计算量的场景
• 使用了高性能的存储设备，包括更多内
• 支持数据更新，避免反复迁移
• 支持跨地域的实时数据备份和查询