大数据-144 Apache Kudu 基本概述数据模型使用场景

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （已更完）
Kafka（已更完）
Spark（已更完）
Flink（已更完）
ClickHouse（已更完）
Kudu（正在更新…）

章节内容

上节我们完成了如下的内容：

ClickHouse SQL 学习
ClickHouse SQL 案例测试
完结 ClickHouse

请添加图片描述

官方网站

https://kudu.apache.org/

基本介绍

Apache Kudu 是由Cloudera开源的存储引擎，可以同时提供低延迟的随机读写和高效的分析能力。
Kudu支持水平扩展，使用Raft协议进行一致性的保证，并且Cloudera和ApacheSpark等流行的大数据查询框架和分析工具紧密结合。
现在提起大数据存储，我们能想到的HDFS、ApacheParquet（在HDFS上做列式存储）、Apache ORC，还有KV形式存储半结构化数据的Apache HBase 和 Apache Cassandra 等等。
它是一个为大数据分析设计的分布式列式存储引擎，特别适用于需要同时支持快速随机读写操作和高效批量分析的工作负载。Kudu 主要定位于需要低延迟查询和频繁数据更新的场景，并与大数据生态系统中的其他组件（如 Apache Hadoop 和 Apache Spark）无缝集成。

背景和设计目标

传统的大数据存储解决方案（如 HDFS 和 HBase）通常在读写性能、查询延迟和数据模型等方面有所取舍。Kudu 则试图平衡这些需求，结合了 HDFS 的高吞吐量和 HBase 的快速随机读写能力，支持如下需求：

快速随机读写：支持近实时的数据写入与更新，适用于时间序列数据、传感器数据、交易数据等场景。
高效批量查询：通过列式存储设计，提升大规模数据的分析性能。
低延迟查询：支持低延迟的 OLAP（在线分析处理）查询，适用于实时分析场景。

架构和数据模型

Kudu 是一个分布式系统，采用主从架构：

Master节点：负责全局元数据的管理，如表的创建、删除、分区等元数据操作。它还负责协调数据副本的分配。
Tablet Server节点：负责表格数据的存储和查询。每个 Tablet Server 管理多个数据片（Tablet），这些数据片是数据分区后的单元。

数据模型

Kudu 的数据模型类似于传统的关系数据库，支持表、行、列的结构：

表：每个表有一个或多个列，可以定义主键。
行：每一行由一组列组成，每一行在插入时通过主键唯一标识。
列：Kudu 中的列可以支持多种数据类型，包括整数、浮点数、字符串等。

Kudu 表支持分区和副本，分区策略可以基于范围（Range）或哈希（Hash）进行配置，而副本机制确保了数据的高可用性和容错能力。

列式存储和压缩

Kudu 采用列式存储格式，这意味着表中的数据按列存储，而非按行。这种设计在大规模数据分析中极具优势，因为它可以减少磁盘 I/O 并提高查询性能。例如，在分析数据时，如果只查询特定列，Kudu 只需要读取这些列的数据，而不必读取整行。

Kudu 支持多种压缩算法，如 LZ4、Snappy 和 Zlib，用户可以根据需要选择合适的压缩方式来优化存储空间和性能。

与 Hadoop 和 Spark 集成

Kudu 与大数据生态系统中的其他组件有很好的集成能力：

与 Apache Hadoop：Kudu 可以与 Hadoop 的 HDFS、YARN 等组件集成。Kudu 的数据可以通过 MapReduce 和其他 Hadoop 工具进行处理。
与 Apache Spark：Kudu 提供了 Spark 连接器，允许用户在 Spark 中直接读写 Kudu 表。用户可以利用 Spark 进行复杂的实时数据处理和分析。

此外，Kudu 还可以与 Apache Impala 集成，提供类似 SQL 的低延迟查询接口，使得用户能够对存储在 Kudu 中的数据执行高性能的 SQL 查询。

使用场景

由于 Kudu 同时支持快速随机读写和高效批量分析，适合以下几类应用场景：

实时分析：如点击流分析、物联网传感器数据分析等需要近实时数据处理的场景。
时间序列数据存储：Kudu 对时间序列数据的存储和查询有很好的支持，可以为金融、监控、日志等领域提供解决方案。
混合工作负载：一些需要同时支持 OLTP（在线事务处理）和 OLAP（在线分析处理）的应用，可以利用 Kudu 实现既快速更新数据，又能进行高效批量查询。

优点

低延迟的随机读写性能：Kudu 适用于需要频繁更新或插入数据的场景，并且支持快速的随机读取。
高效的批量查询：列式存储提升了批量查询的性能，尤其是大规模数据分析。
与 Spark、Impala 的良好集成：Kudu 与大数据生态系统集成紧密，用户可以方便地利用这些工具进行数据分析。
灵活的数据模型：Kudu 支持关系型数据模型，提供了与传统关系数据库相似的操作接口。

缺点

事务支持有限：Kudu 的事务支持较为简单，可能不适合复杂的事务场景。
不适合冷数据：由于 Kudu 主要针对快速读写的场景，因此对存储长期不访问的冷数据并不理想。
依赖内存较多：Kudu 在处理高并发写入时，对内存的依赖较大，系统需要较高的硬件配置以获得最佳性能。

基于HDFS

数据分析：Parquet，具有高吞吐量连续读取数据的能力
实时读写：HBase和Cassandra等技术适用于低延迟的随机读写场景

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

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

目前痛点

所以现在的企业中，经过会存储两套数据分别用于实时读写和数据分析。
先将数据写入HBase中，再定期ETL到Parquet进行数据同步。
在这里插入图片描述
但是这样做有很多缺点：

用户需要在两套系统间编写和维护复杂的ETL逻辑，结构复杂，维护成本高。
时效性差，因为ETL通常是1个小时、N个小时甚至一天，那么可供分析的数据就需要这么久才可以到达，存在一个明显的空档期。
更新需求难以满足，在实际情况中可能会有一些已经写入的数据有更新需求，这种情况需要对历史的数据进行更新，而Parquet这种静态数据更新操作，代价非常高。
存储资源浪费，两套系统意味着会有大量的占用，成本很高。

Kudu优势

我们知道，基于HDFS，比如Parquet，具有高吞吐量连续读取数据的能力，而HBase和Cassandra等技术适用于低延迟的随机读写场景，那么有没有一种技术，结合二者。
Kudu提供了一种 Happy Medium 的选择：
在这里插入图片描述

Kudu不但提供了行级的插入，更新，删除，同时也提供了接近Parquet性能的批量扫描操作。使用同一份存储，既能随机读写，也可以满足数据分析的需求。

数据模型

Kudu的数据模型与传统的关系型数据库类似，一个Kudu集群由多个表组成，每个表由多个字段组成，一个表必须指定若干个字段组成主键：
在这里插入图片描述
从用户角度看，Kudu是一种存储结构化数据的存储系统。在一个Kudu集群中可以定义任意数量的table，每个table都需要预先定义好Schema。
每个Table的列数是确定的，每一列都需要有名字和类型，每个表中可以把其中一列或者多列定义为主键。
这么看来，Kudu更像关系型数据库，而不是HBase、Cassandra、MongoDB这些NoSQL数据库，不过Kudu目前还不能像关系型数据库一样支持二级索引。
Kudu使用确定的列类型，字段是强类型的，而不是NoSQL那种 Everything is Byte。可以带来好处如下：

确定的列类型使Kudu可以进行类型特有的编码，节省空间。
可以提供SQL-like元数据给其他上层查询工具，比如BI工具。
Kudu的场景是OLAP分析，有一个数据类型对下游的分析工具也更加友好。

用户可以使用INSERT、UPDATE、DELETE等对表进行操作。不论使用那种API，都必须指定主键，但批量的删除和更新操作依赖更高层次的组件（比如Impala、Spark）。
Kudu目前不支持多行事务。在读操作方面，Kudu只提供了Scan操作来获取数据，用户可以通过指定过滤条件来获取自己想要读取的数据，但目前只提供了两种类型的过滤条件：主键范围和列值与常数比较。
由于Kudu在硬盘中的数据采用列式存储，所以只需要扫描的列将极大的提高读取性能。

一致性模型

Kudu为用户提供了两种一致性模型，默认的一致性模型是：snapshot consistency。
这种模型保证用户每次读取出来的都是一个可用的快照，但这种一致性模型只能保证单个Client可以看到最新的数据，但不能保证多个Client每次取出的都是最新的数据。

另一种一致性模型是external consistency可以在多个Client之间保证每次取到的都是最新数据，但是Kudu没有提供默认的实现，需要用户做一些额外的工作：

在Client之间传播Timestamp Token，在一个Client完成一次写入后，会得到一个TimestampToken，然后这个Client把这个Token传播到其他Client，这样其他的Client就可以通过Token取到最新的数据了，不过这个方式的复杂度很高。
通过commit-wait方式，这有类似于Google的Spanner，但是目前基于NTP的commit-wait方式延迟实在有点高，不过Kudu相信，随着Sapanner的出现，未来基于real-time lock的技术会逐渐的成熟。