在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的诞生可以说明一个观点:底层的技术发展很多时候都是上业务推动,脱离业务的技术很可能是空中楼阁。
Apache Kudu是由Cloudera开源的存储引擎,可以同时提供低延迟的随机读写和高效的数据分析能力 。它是一个融合 HDFS 和 HBase 的功能新组件,具备介于两者之间的新存储组件。 Kudu 支持水平扩展,并且与Cloudera Impala和Apache Spark等当前流 行的大数据查询和分析工具结合紧密。
- 适用于那些既有随机访问,也批量数据扫描的复合场景
- 高计算量的场景
- 使用了高性能的存储设备,包括更多内
- 支持数据更新,避免反复迁移
- 支持跨地域的实时数据备份和查询