大数据-144 Apache Kudu 根本概述 数据模子 利用场景

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

目前已经更新到了：

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

章节内容

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

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

官方网站

1. 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的技术会逐渐的成熟。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。