kudu从0到1

2024-06-10 09:18
文章标签 kudu

本文主要是介绍kudu从0到1,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

背景:

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

  • 静态数据:以HDFS引擎作为存储引擎,适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。

  • 动态数据:以HBase、Cassandra作为存储引擎,适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如HDFS,不适用于批量数据分析的场景。

从上面分析可知,这两种数据再存储方式上完全不同,进而导致使用场景完全不同,但在真实场景中,边界可能没有那么清晰,面对既需要随机读写、又需要批量分析的大数据场景。该如何选择呢?一个常见的方案是:

 

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

 

数据模型

KUDU的数据模型与传统的关系型数据库类似,一个KUDU集群由多个表组成,每个表由多个字段组成,一个表必须指定一个由若干个(>=1)字段组成的主键

 

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

 

核心API

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

(数据库中有read和scan操作。read:从数据库中读一条记录。 scan:在数据库中执行范围查询,结果返回一个记录集。)

 

一致性模型

跟大多数关系型数据库一样,KUDU也是通过MVCC(Multi-Version Concurrency Control)来实现内部的事务隔离。

 

整体架构

KUDU中存在两个角色

Master Server: 负责集群管理、元数据管理等功能

Tablet Server: 负责数据存储,并提供数据读写服务。

为了实现分区容错性,跟其他大数据产品一样,对于每个角色,在KUDU中都可以设置特定数据(3-5)的副本。各副本间通过Raft协议保证数据一致性。

 

KUDU Client与服务端交互时,先从Master Server获取元数据信息,然后去Tablet Server读写数据:

 

 

存储实现:

与其他大数据存储引擎类似,KUDU 的存储也是通过 LSM 树(Log-Structured Merge Tree)来实现的。KUDU 的最小存储单元是 RowSets,KUDU 中存在两种 RowSets:MemRowSetsDiskRowSets,数据先写内存中的 MemRowSetMemRowSet 满了后刷到磁盘成为一个 DiskRowSetDiskRowSet 一经写入,就无法修改了。见下图:

 

 

 

  • 如何应对数据变更?

  • 如何优化读写性能以满足 OLAP 场景?

     

    应对数据变更

    首先上面我们讲了,DiskRowSet 是不可修改了,那么 KUDU 要如何应对数据的更新呢?在 KUDU 中,把 DiskRowSet 分为了两部分:*base data**delta stores*。base data 负责存储基础数据,delta stores负责存储 base data 中的变更数据。整个数据更新方案如下:

  •  

    如上图所示,数据从MeMRowSet刷到磁盘后就形成了一份DiskRowSet(只包含base data),每份DiskRowSet在内存中都会有一个对应的DeltaMemStore,负责记录此DiskRowSet后续的数据变更(更新、删除)。DeltaMemStore数据增长到一定程度后转化成为二进制文件存储到磁盘中,形成一个DeltaFile,随着base data对应数据的不断变更,DeltaFile逐渐增长。

     

    优化读写性能

    首先我们从KUDU的DiskRowSet数据结构上分析:

  •  

  • 从上图可知,在具体的数据(列数据、变更记录)上,KUDU都做了B-树索引,以提高随机读写的性能。

    • 主键范围索引:记录本DiskRowSet中主键的范围,用于粗粒度过滤一些主键范围。

    • 布隆过滤器:通过主键的布隆过滤器来实现不存在数据的过滤

    • 主键索引:要精确定位一个主键是否存在,以及具体在DiskRowSet中的位置(即:row_offset),通过以B-树为数据结构的主键索引来快速查找。

    随着时间的推移,KUDU中的小文件会越来越多,主要包括各个DiskRowSet中的base data, 还有每个base data对应的若干份DeltaFile。小文件的增多会影响KUDU的性能,特别是DeltaFile中还有很多重复的数据。为了提高性能,KUDU会进行定期Compaction,compaction主要包括两部分:

    • DeltaFile compaction: 过多的DeltaFile影响读性能,定期将DeltaFile合并回base data可以提升性能。

    • DiskRowSet compaction: 除了DeltaFile,定期将DiskRowSet合并也能提升性能,一个原因是合并时我们可以将被删除的数据彻底的删除,而且可以减少同样key范围内数据的文件数,提升索引的效率。

    当用户的查询存在列的过滤条件时,KUDU还可以在查询时进行 延迟物化来提升性能,举例说明:

  •  

    用户的SQL是这样的:

    select * from tb where sex=‘男’ and age >20

    KUDU中数据查询过程是这样的:

    1、扫描sex列,过滤出要查询的行[1,3]

    2、扫码age列,过滤出要查询的行[3,4]

    3、过滤条件相交,得到3

    4、真正读取id=3行所对应的列信息,组装

    数据写过程

  •  

  • 如上图,当 Client 请求写数据时,先根据主键从 Mater Server 中获取要访问的目标 Tablets,然后到依次对应的 Tablet 获取数据。因为 KUDU 表存在主键约束,所以需要进行主键是否已经存在的判断,这里就涉及到之前说的索引结构对读写的优化了。一个 Tablet 中存在很多个 RowSets,为了提升性能,我们要尽可能地减少要扫描的 RowSets 数量。首先,我们先通过每个 RowSet 中记录的主键的(最大最小)范围,过滤掉一批不存在目标主键的 RowSets,然后在根据 RowSet 中的布隆过滤器,过滤掉确定不存在目标主键的 RowSets,最后再通过 RowSets 中的 B-树索引,精确定位目标主键是否存在。如果主键已经存在,则报错(主键重复),否则就进行写数据(写 MemRowSet)。

    数据更新过程

     

     

  •  

  • 数据更新的核心是定位到待更新数据的位置,这块与写入的时候类似,就不展开了,等定位到具体位置后,然后将变更写到对应的 delta store 中。

     

    数据读过程

  • 如上图, 数据读取过程大致如下:先根据要扫描数据的主键范围,定位到目标的Tablets,然后读取Tablets中的RowSets。在读取每个RowSet时,先根据主键过滤要scan范围,然后加载范围内的base data,再找到对应的delta stores, 应用所有变更,最后union上MemRowSet中的内容,返回数据给Client。

  •  

    应用案例

    在使用KUDU前,小米的架构是这样的:

  •  

  •  

    一部分源系统数据是通过Scribe(日志聚合系统)吧数据写到HDFS,另一部分源系统数据直接写入HBase。然后通过Hive/MR/Spark作业把两部分数据合并,给离线数仓和OLAP分析。

    在使用KUDU后,架构简化成了:

  •  

    从上图我们可以看到,所有的数据存储都集中到KUDU一个上,减少了整体的架构复杂度,同时,也大大提升了实时性。

     

    参考:

    https://kudu.apache.org/

    https://www.jianshu.com/p/93c602b637a4

这篇关于kudu从0到1的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1047763

相关文章

实时数仓链路分享:kafka =SparkStreaming=kudu集成kerberos

点击上方蓝色字体,选择“设为星标” 回复”资源“获取更多资源 大数据技术与架构 点击右侧关注,大数据开发领域最强公众号! 暴走大数据 点击右侧关注,暴走大数据! 本文档主要介绍在cdh集成kerberos情况下,sparkstreaming怎么消费kafka数据,并存储在kudu里面 假设kafka集成kerberos假设kudu集成kerberos假设用非root用户操作spark基

通过java程序对kudu表进行权限操作

对kudu表进行权限操作除了上述通过impala-shell和hue界面进行SQL操作外,还可以通过Java client、C++ client、Python client操作kudu表,这里介绍通过java程序对kudu表进行权限操作。 一、Impala jdbc连接hive和kudu准备工作 1.配置环境IDEA和JDK 此处不做说明,请自行完成。 2.IDEA搭建maven安装、下载

对kudu表进行权限管理

对kudu表操作之前,需要先安装impala并配置sentry服务,因为kudu表可以通过impala-shell的SQL操作。详情请参考https://blog.csdn.net/u013168084/article/details/99690353 Kudu是Cloudera开源的新型列式存储系统,是Apache Hadoop生态圈的新成员之一(incubating),专门为了对快速变化的数

Kudu元数据分析

获取Kudu元数据信息,目前直接查询Kudu表即可 原因如下:(官网文档)   Catalog Table The catalog table is the central location for metadata of Kudu. It stores information about tables and tablets. The catalog table may not be r

关于kudu使用的一些问题及解决办法

在client 1.5之前,由于kudu客户端链接的token有效时间是7天,当时间大于7天的时候token失效,客户端不会主动去刷新token,导致写入数据报错;  解决办法:kudu-client 版本使用1.5以上的版本  kudu数据flush的模式问题 AUTO_FLUSH_BACKGROUND:异步刷新可能会导致写入的时候乱序,因此有严格的顺序的写入操作可能要使用AUTO_

ubuntu 16.04部署安装kudu

由于ubuntu 16.04自带的源中没有kudu相关的包,需要配置系统的源 一、配置如下: 1、从 http://archive.cloudera.com/kudu/ubuntu/xenial/amd64/kudu/cloudera.list 下载源的配置,下载之后如下: 2、把下载的内容添加到/etc/apt/sources.list中 3、 添加公匙:     从http://cl

impala和kudu使用的小细节

之前入门的小错误总结,建表都会出错,真的好尴尬 还是要做好笔记 第一个错误: error:AnalysisException:Table property 'kudu.master_addresses' is required when the impalad startup flat -kudu_master_hosts is not used. answer:'kudu.maste

kudu表分区

kudu表的数据结构是列式存储,但也支持像mysql那样进行检索,而且与spark、impala等现有的应用完美契合,可以说是是大数据平台上支持快速sql查询的上佳选择了。它的好处这里不多说啦,公司的大数据查询有一部分是用到这个技术,这里就列几个其他博客里不常见的涉及kudu表分区的语句(其实官网里都有,只是中文博客里还没见到)。 分区有两种方式,hash 和range分区, hash分区

kudu-impala分区表(hash和range分区)

展开 1、分区表支持hash分区和range分区,根据主键列上的分区模式将table划分为 tablets 。每个 tablet 由至少一台 tablet server提供。理想情况下,一张table分成多个tablets分布在不同的tablet servers ,以最大化并行操作。  2、Kudu目前没有在创建表之后拆分或合并 tablets 的机制。  3、创建表时,必须为表提供分区模式。

KUDU的相关内容,KUDU的优劣势

KUDU的相关内容 kudu的简介kudu是什么那么怎么读取数据呢什么是IMPALA? kudu适用场景对比 kudu的简介 kudu是什么 kudu其实是一种引擎,是一种针对HIVE的引擎。 那么怎么读取数据呢 使用IMAPALA读取数据,IMPALA可以选择各种hive引擎,而KUDU就是其中之一 什么是IMPALA? 说得明白一点其实就相当于是mysql中得nav