Apache Kudu入门学习

最新推荐文章于 2024-09-23 09:19:25 发布

chimchim66

最新推荐文章于 2024-09-23 09:19:25 发布

阅读量702

点赞数

文章标签：学习

本文链接：https://blog.csdn.net/chimchim66/article/details/127060767

版权

1.范围分区Range Partitioning

2.哈希分区Hash Partitioning

3.多级分区Multilevel Partitioning

一、概念

官方概念：

Apache Kudu is an open source distributed data storage engine that makes fast analytics on fast and changing data easy.

Apache Kudu 是一个开源分布式数据存储引擎，可以轻松地对快速变化的数据进行快速分析。

官网地址：

Apache Kudu - Fast Analytics on Fast Data

二、背景

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

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

当面对既需要随机读写，又需要批量分析的大数据场景时，方案如下：

数据实时写入 HBase，HBase 完成实时的数据更新，定时（通常是 T+1 或者 T+H）将 HBase 数据写成静态的文件（如：Parquet）导入到 OLAP 引擎（如：HDFS）。

但是也有很多缺点：

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

基于HDFS的存储技术，比如Parquet，具有高吞吐量连续读取数据的能力；而HBase和Cassandra等技术适用于低延迟的随机读写场景。Kudu的设计，就是试图在实时分析与随机读写之间，寻求一个最佳的结合。在Cloudera发布的《Kudu: New Apache Hadoop Storage for Fast Analytics on Fast Data》一文中有提及，Kudu作为一个新的分布式存储系统也是为了进一步提升CPU的适用效率。

KUDU 的定位是「Fast Analytics on Fast Data」，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。

三、特点

快速处理 OLAP 工作负载。
强大但灵活的一致性模型，允许您基于每个请求选择一致性要求，包括严格序列化一致性的选项。
结构化数据模型。
同时运行顺序和随机工作负载的强大性能。
与 Apache Impala 紧密集成，使其成为将 HDFS 与 Apache Parquet 结合使用的良好、可变的替代方案。
与 Apache NiFi 和 Apache Spark 集成。
与 Hive Metastore (HMS) 和 Apache Ranger 集成以提供细粒度的授权和访问控制。
经过身份验证和加密的 RPC 通信。
高可用：Tablet Servers 和 Masters 使用Raft Consensus Algorithm，保证只要有超过一半的 tablet 副本可用，tablet 就可以读写。例如，如果 3 个副本中有 2 个（或 5 个副本中的 3 个等）可用，则平板电脑可用。即使在领导者副本发生故障的情况下，只读跟随者平板副本也可以为读取提供服务。
故障自动检测和自我修复：为了保持数据的高可用性，系统会检测故障的 Tablet 副本并从可用的副本中重新复制数据，因此当集群中有足够的 Tablet Server 可用时，会自动替换故障的副本。
位置感知（也称为机架感知）以在相关故障的情况下保持系统可用，并允许 Kudu 集群跨越多个可用区。
逻辑备份（完整和增量）和还原。
多行事务（仅适用于 Kudu 1.15 版本的 INSERT/INSERT_IGNORE 操作）。
易于管理和管理。

四、架构

KUDU 中存在两个角色

Mater Server：负责集群管理、元数据管理等功能。即tablet和表的基本信息，监听TServer的状态，TMaster之间通过raft协议进行数据同步。
Tablet Server：负责数据存储，并提供数据读写服务。tablet 负责这一张表的某块内容的读写，接受其他tablet leader 传来的同步信息。

Table（表）

一张talbe是数据存储在Kudu的tablet server中。表具有 schema 和全局有序的primary key（主键）。table 被分成称为 tablets 的 segments。

Tablet

一个 tablet 是一张 table连续的segment，tablet是kudu表的水平分区，类似于google Bigtable的tablet，或者HBase的region。每个tablet存储着一定连续range的数据（key），且tablet两两间的range不会重叠。一张表的所有tablet包含了这张表的所有key空间。与其它数据存储引擎或关系型数据库中的 partition（分区）相似。给定的tablet 冗余到多个 tablet 服务器上，并且在任何给定的时间点，其中一个副本被认为是leader tablet。任何副本都可以对读取进行服务，并且写入时需要在为 tablet 服务的一组 tablet server之间达成一致性。

KUDU 的核心对外 API 主要分为写跟读两部分

写：Insert、Update、Delete，所有写操作都必须指定主键。
读： Scan 操作，Scan 时用户可以指定一个或多个过滤器，用于过滤数据。

五、应用场景

Strong performance for both scan and random access to help customers simplify complex hybrid architectures（适用于那些既有随机访问，也有批量数据扫描的复合场景）
High CPU efficiency in order to maximize the return on investment that our customers are making in modern processors（高计算量的场景）
High IO efficiency in order to leverage modern persistent storage（使用了高性能的存储设备，包括使用更多的内存）
The ability to update data in place, to avoid extraneous processing and data movement（支持数据更新，避免数据反复迁移）
The ability to support active-active replicated clusters that span multiple data centers in geographically distant locations（支持跨地域的实时数据备份和查询）