前言   

在Kudu出现前，由于传统存储系统的局限性，对于数据的快速输入和分析还没有一个完美的解决方案，要么以缓慢的数据输入为代价实现快速分析，要么以缓慢的分析为代价实现数据快速输入。随着快速输入和分析场景越来越多，传统存储层的局限性越来越明显，Kudu应运而生，它的定位介于HDFS和HBase之间，将低延迟随机访问，逐行插入、更新和快速分析扫描融合到一个存储层中，是一个既支持随机读写又支持OLAP分析的存储引擎。本篇文章研究一下Kudu，对其应用场景，架构原理及基本使用做一个总结。

Kudu介绍

在Kudu出现前，无法对实时变化的数据做快速分析：

以上设计方案的缺陷：

1.数据存储多份造成冗余，存储资源浪费。

2.架构复杂，运维成本高，排查问题困难。

而Kudu就融合了动态数据与静态数据的处理，同时支持随机读写和OLAP分析。

Kudu与HDFS,HBase的对比：

适用场景

• 既有随机读写随机访问，又有批量扫描分析的场景(OLAP)
• HTAP（Hybrid Transactional Analytical Processing）混合事务分析处理场景
• 要求分析结果实时性高（如实时决策，实时更新）的场景
• 实时数仓
• 支持数据逐行插入、更新操作
• 同时高效运行顺序读写和随机读写任务的场景
• Kudu作为持久层与Impala紧密集成的场景
• 解决HBase(Phoenix)大批量数据SQL分析性能不佳的场景
• 跨大量历史数据的查询分析场景（Time-series场景）

特点及缺点

特点

• 基于列式存储
• 快速顺序读写
• 使用 LSM树 以支持高效随机读写
• 查询性能和耗时较稳定
• 不依赖Zookeeper 有表结构，需要定义Schema，需要定义唯一键，支持SQL分析（依赖Impala，Spark等引擎）
• 支持增删列,单行级ACID（不支持多行事务-不满足原子性）
• 查询时先查询内存再查询磁盘
• 数据存储在Linux文件系统，不依赖HDFS存储

缺点

• 暂不支持除PK外的二级索引和唯一性限制
• 不支持多行事务 不支持BloomFilter优化join
• 不支持数据回滚
• 不能修改PK，不支持AUTO INCREMENT PK
• 每表最多不能有300列，每个TServer数据压缩后不超8TB
• 数据类型少，不支持Map，ARRAY，Struct等复杂类型

与相似类型存储引擎对比   

本文重点说Kudu，但我们也需要了解其他类似组件，了解它们各自擅长的地方，才能更好地做技术选型。这里简单对比一下Kudu，Hudi和DeltaLake这三种存储方案，因为它们都具有相似的特性，能解决类似的问题。

选择建议：考虑实时数仓方案以及SQL支持方面可选Kudu，数据湖方案及可回滚可选DeltaLake和Hudi，考虑兼容性高且应对读多写少读少写多都有很好的方案选Hudi，考虑并发写能力读多写少且与Spark紧密结合选DeltaLake。

原文链接：https://shmily-qjj.top/5f26355/