本文主要介绍Kudu的一些典型应用场景及其架构等。
概述
Kudu产生主要是为了填补Hadoop生态圈的功能空白,用户可能存在以下的应用场景:
- 需要利用HBase的快速写入和随机读取来导入数据,HBase也允许用户进行数据的修改。
- 使用HDFS/Parquet + hive/spark/impala来进行超大规模数据集的查询以及分析,在这种情况下Parquet列式存储有很大的优势。
Kudu可以同时支持以上两种不同场景,避免用户同时部署HDFS/Parquet以及HBase的集群,减少客户的运维的成本。
典型的应用场景
- 近实时计算场景
流式计算场景通常会有持续不断地、大量写入数据的操作,与此同时这些数据还要支持近乎实时的读、写以及更新的操作。Kudu的设计能够很好的处理此场景。
- 时间序列数据的场景
时间序列数据随着时间产生的,用户可以根据这些数据调查性能指标以及基于时间序列数据进行预测。例如用户以时间序列的方式存储客户的购买点击历史,用来预计未来的购买,或者这部分数据有客户代表使用分析用户的购买行为,在分析的同时,客户可能会产生更多的数据或者修改已有的数据,而这些数据可以很快为分析所用, Kudu可以用可扩展的和高效的方式同时处理这些数据访问模式。
- 预测建模
数据科学家经常需要通过大量数据建立预测模型,但是模型以及模型所依赖的数据处于经常的变化当中,如果数据或者模型存储在HDFS, 频繁的更新HDFS是非常耗时的, 而Kudu的设计可以很好满足这样的场景,数据科学家只要更改数据,重新运行查询,就可以在秒级或者分钟级别更新模型,而不是要花费几个小时或者一天的时间去得到更新的模型。
- 与存量数据共存
用户生产环境中往往有大量的存量数据。可能存储在HDFS,RDBMS或者Kudu,Impala可以同时支持HDFS、Kudu等多个底层存储引擎,这个特性使得在使用的Kudu的同时,不必把所有的数据都迁移到Kudu。
基本架构
Kudu有两种类型的组件,Master Server和Tablet Server。Master Server负责管理元数据,这些元数据包括Tablet Server的服务器的信息以及Tablet的信息,Master Server通过Raft协议提供高可用;Tablet Server用来存储tablets,每个tablet存在多个副本存放在不同的tablet server, 副本之间通过Raft协议提供高可用,下图为Kudu集群的基本架构的示意图:

创建集群
E-MapReduce从E-MapReduce-3.22.0版本开始支持Kudu集群的创建,主要作为Hadoop集群类型的一个服务组件,用户在创建Hadoop集群时勾选Kudu组件就会创建Kudu集群,默认情况下Kudu集群包含3个Kudu Master服务并提供HA支持。

Impala集成
Impala集成Kudu不需要做特别的配置,可以通过在Impala配置文件设置kudu_master_hosts= [master1][:port],[master2][:port],[master3][:port]
;或者通过SQL创建语句通过TBLPROPERTIES语句中指定kudu.master_addresses来指定Kudu集群。下面示例展示的在SQL 语句中添加kudu.master_addresses指定Kudu的地址。
CREATE TABLE my_first_table
(
id BIGINT,
name STRING,
PRIMARY KEY(id)
)
PARTITION BY HASH PARTITIONS 16
STORED AS KUDU
TBLPROPERTIES(
'kudu.master_addresses' = 'master1:7051,master2:7051,master3:7051');
常用命令
- 检查集群健康
kudu cluster ksck <master_addresses>
- 检查集群Metrics
kudu-tserver --dump_metrics_json kudu-master --dump_metrics_json
- 获取tables
kudu table list <master_addresses>
- Dump出cfile文件内容
kudu fs dump cfile <block_id>
- Dump出kudu文件系统的tree
kudu fs dump tree [-fs_wal_dir=<dir>] [-fs_data_dirs=<dirs>]
在文档使用中是否遇到以下问题
更多建议
匿名提交