Kudu 概览
为什么需要 Kudu 在 Hadoop 生态中结构化的数据通常使用两种方式进行存储：一是通过 Apache Parquet 等二进制数据格式，将静态数据集存储在 HDFS 上，二是将可变数据以半结构化的方式存储在 HBase 中。这里面临的问题是存储在 HDFS 上的数据无法提供单个记录的随机访问，HBase 中存储的数据尽管允许低延迟的读取和写入，但是基于 SQL 分析的应用中顺序读取的吞吐方面要远远落后于静态文件格式。 当需要在一个系统中需要这两种访问模式的时候，HDFS 上的静态数据集提供的分析性能力与 HBase 的低延迟行级随机访问能力之间的差距就需要复杂的架构设计，一种可以想到的方式就是采用类似于 Lambda 架构的方案：架构中通过 HBase 构建一个实时层，通过 HDFS 构建一个批处理层。数据流式的进入实时层，然后定期将数据导入到 Parquet 批处理层，以提供历史分析。这一架构看似能够解决这个差异性的问题，但是却有这样几个缺点： 由于要管理两个层的数据流之间的同步，这样应用层的架构会变得复杂； 需要跨两个系统管理一致性备份、安全和监控； 新数据达到数据在实时层和可用于分析的批处理层之间会表现出滞后； 现实世界中，系统需要容纳后到达的数据、还需要对迁移到不可变存储中数据进行删除，这一过程会设计到昂贵的分区重写以及手动干预。 为了解决上面的问题，Kudu 被设计以一种折中的方式解决这些问题。Kudu 是一种全新设计和实现的新存储系统，旨在填补 HDFS 等高吞吐量顺序访问存储系统与 HBase 或 Cassandra 等低延迟随机访问系统之间的空白。特别是，Kudu 为行级插入、更新和删除提供了一个简单的 API，同时以类似于 Parquet的吞吐量提供表扫描。 用户视角下的 Kudu 表与模式 在用户视角下，Kudu 是一个结构化数据表的存储系统，可以有任意数量的表，每个表都有一个由有限数量的列组成的明确定义的模式。每列具有列名和类型。对于列设置类型有这样两个好处： 特定的类型在进行列式存储的时候可以进行充分的压缩； 显式类型允许我们将类似 SQL 的元数据公开给其他系统。 Kudu 表有主键，主键负责唯一性约束，并充当更新和删除行的唯一索引。同样与关系型数据库类似的是，用户在创建表的时候需要定义表的架构，插入不存在的列或者违反主键唯一性约束都会引起错误，用户可以添加删除列但是不能删除主键列。 与关系型数据库不同的是 Kudu 表不提供二级索引。 写操作 创建表之后的写操作必须指定主键，Kudu 提供了多种语言的客户端。这些 API 允许精确控制批处理和异步错误处理，以在执行批量数据操作（例如数据加载或大型更新）时分摊往返成本。Kudu 不提供跨行事务。 读操作 Kudu 提供 Scan 操作从表中检索数据，扫描时，用户可以添加谓词进行过滤，支持列和常量值之间的比较以及主键范围，谓词操作会下推到 Kudu 后台，减少数据扫描传递时的磁盘和网络开销。 ...