kudu介绍：为什么要使用?

前言

近两年，KUDU 在大数据平台的应用越来越广泛。在阿里、小米、网易等公司的大数据架构中，KUDU 都有着不可替代的地位。本文通过分析 KUDU 的设计， 试图解释为什么 KUDU 会被广泛应用于大数据领域，因为还没有研究过 KUDU 的代码，下面的介绍是根据 KUDU 的论文和网上的一些资料学习自己理解所得，如有不实之处，劳请指正。

背景

在 KUDU 之前，大数据主要以两种方式存储：

• 静态数据：以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。
• 动态数据：以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景。

从上面分析可知，这两种数据在存储方式上完全不同，进而导致使用场景完全不同，但在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，又需要批量分析的大数据场景，该如何选择呢？这个场景中，单种存储引擎无法满足业务需求，我们需要通过多种大数据工具组合来满足这一需求，一个常见的方案是：

满足数据更新+批量分析的大数据架构

如上图所示，数据实时写入 HBase，实时的数据更新也在 HBase 完成，为了应对 OLAP 需求，我们定时（通常是 T+1 或者 T+H）将 HBase 数据写成静态的文件（如：Parquet）导入到 OLAP 引擎（如：HDFS）。这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景，但他有如下缺点：

• 架构复杂。从架构上看，数据在 HBase、消息队列、HDFS 间流转，涉及环节太多，运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。
• 时效性低。数据从 HBase 导出成静态文件是周期性的，一般这个周期是一天（或一小时），在时效性上不是很高。
• 难以应对后续的更新。真实场景中，总会有数据是「延迟」到达的。如果这些数据之前已经从 HBase 导出到 HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。

为了解决上述架构的这些问题，KUDU 应运而生。KUDU 的定位是 「Fast Analytics on Fast Data」，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。

KUDU 定位

从上图可以看出，KUDU 是一个「折中」的产品，在 HDFS 和 HBase 这两个偏科生中平衡了随机读写和批量分析的性能。从 KUDU 的诞生可以说明一个观点：底层的技术发展很多时候都是上层的业务推动的，脱离业务的技术很可能是「空中楼阁」。

概览

数据模型

KUDU 的数据模型与传统的关系型数据库类似，一个 KUDU 集群由多个表组成，每个表由多个字段组成，一个表必须指定一个由若干个（>=1）字段组成的主键，如下图：

KUDU 数据模型

KUDU 表中的每个字段是强类型的，而不是 HBase 那样所有字段都认为是 bytes。这样做的好处是可以对不同类型数据进行不同的编码，节省空间。同时，因为 KUDU 的使用场景是 OLAP 分析，有一个数据类型对下游的分析工具也更加友好。

核心 API

KUDU 的对外 API 主要分为写跟读两部分。其中写包括：Insert、Update、Delete，所有写操作都必须指定主键；读 KUDU 对外只提供了 Scan 操作，Scan 时用户可以指定一个或多个过滤器，用于过滤数据。

一致性模型

跟大多数关系型数据库一样，KUDU 也是通过 MVCC（Multi-Version Concurrency Control）来实现内部的事务隔离。KUDU 默认的一致性模型是 Snapshot Consistency，即客户端可以一致的访问到某个时间点的一个快照。

如果有更高的外部一致性（external consistency）需求，KUDU 目前还没有实现，不过 KUDU 提供了一些设计方案。这里先介绍下外部一致性，它是指：多个事务并发执行达到串行效果，并且保证修改时间戳严格按照事务发生先后顺序，即如果有先后两个事务 A、B， A 发生在 B 之前&#x