Impala实践之十一:parquet性能测试

前言

之前一直考虑更换impala的文件存储格式为parquet,但是没有立即使用,最近又做了一些测试,看看parquet是否真的有用。在测试的时候顺便测了一下compute语句的效果,一起作为参考。下面抽出一个小业务的部分测试结果来展示。

测试准备

库名和表名当然不是真的。

测试范围:

  • 文件格式:parquet和text
  • compute语句的影响

测试用表:

表名 行数 字段数 物理存储大小
ain 34231137 11 1.4 G
a_in 395857172 11 4.4 G
in 62025197 6 2.5 G
c 4055068 144 708.3 M

测试用例1

这个记录是当时随手测的一个结果。

sql语句:

select count(*) from c;

测试结果:

文件格式 第1次执行耗时 第2次执行耗时
text 7.72s 0.74s
parquet 5.90s 0.53s

测试用例2

sql语句:

select count(uid) from c
where ***

测试结果:

文件格式 where字句数量 持续时间 读取hdfs字节数 累积内存使用峰值
text 1 826ms 3G 361.1M
parquet 1 623ms 17.1 M 6.9M
text 2 1.04s 3G 112.3 M
parquet 2 623ms 17.6 M 7.1 M
text 3 930ms 3G 112.3 M
parquet 3 631ms 18.4 M 7.6 M
text 6 961ms 3G 120.6 M
parquet 6 836ms 22.9 M 45.1 M
text 13 1.04s 3G 117 M
parquet 13 1.04s 33.2 M 19.5 M

测试用例3

sql语句:

dev表是另外一个表,不是parquet格式。

SELECT SUBSTR(a1.dt,1,7) dt, COUNT(DISTINCT a1.uid)
FROM (
SELECT userid uid , createtime dt
FROM dev) a1
LEFT JOIN (
SELECT uid, dt
FROM (
SELECT userid uid, time dt FROM a_in
UNION ALL
SELECT uid uid, stime dt FROM ain
WHERE atype=‘1‘
UNION ALL
SELECT uid, time dt
FROM c
WHERE state!=0 AND source=‘test‘) a1 ) a2
ON a1.uid = a2.uid AND SUBSTR(a1.dt,1,7)>SUBSTR(a2.dt,1,7)
LEFT JOIN (
SELECT uid, dt
FROM (SELECT userid uid, time dt FROM in
UNION ALL
SELECT uid, time dt FROM c
WHERE state!=0 AND source=‘pc‘) a1 ) a3
ON a1.uid = a3.uid AND SUBSTR(a1.dt,1,7)>SUBSTR(a3.dt,1,7)
WHERE a2.uid IS NULL AND a3.uid IS NOT NULL
GROUP BY dt
ORDER BY dt;

测试结果:

文件格式 持续时间 读取hdfs字节数 累积内存使用峰值
text 12分38秒 71.4G 27.5G
parquet 12分27秒 22.5G 27.6G

测试用例4

这个稍微复杂一些,用到了上面的三张表,有一些join操作。因为前段时间发现了compute语句的神奇,因此这次顺便带上它。

sql语句:

select SUBSTR(a1.dt,1,7) dt, COUNT(DISTINCT a1.uid)
FROM (
SELECT uid, createtime dt
FROM c
WHERE state!=0 AND source=‘app‘) a1
INNER JOIN (
SELECT uid, dt
FROM (
SELECT userid uid, logtime dt FROM a_in
UNION ALL
SELECT uid uid, stime dt FROM ain
WHERE atype=‘1‘) a1 ) a2
ON a1.uid = a2.uid AND SUBSTR(a1.dt,1,7) = SUBSTR(a2.dt,1,7)
GROUP BY dt
ORDER BY dt

测试结果:

文件格式 提前执行compute 持续时间 读取hdfs字节数 累积内存使用峰值
text N 5分16秒 46.7G 12.1G
parquet N 3分48秒 1.7G 27.3G
text Y 34.9秒 46.7G 1.5G
parquet Y 14.5秒 1.7G 1.1G


2016-04-27 14:55:00 hzct

时间: 2024-08-14 08:11:13

Impala实践之十一:parquet性能测试的相关文章

微软云计算介绍与实践(实践之三十一)

今天开始管理私有云中的应用实践了. 一.先决条件 小张将在实验室环境中的GUEST01服务器上部署销售应用.这将安装和配置agent用于(discover)发现  , (inventory)库存和(monitor)监控.        Guest01添加到Contoso域中        在混合模式下安装SQL Server 2012到Guest01中,启用sa帐户和配置密码         在Guest01安装IIS         启用.NETFramework下以下特点4.5特色> WCF

Parquet性能测试调优及其优化建议

 Parquet性能测试调优及其优化建议 一.我们为什么选择parquet 1.选择parquet的外部因素 (1) 我们已经在使用spark集群,spark原本就支持parquet,并推荐其存储格式(默认存储为parquet): (2) hive支持parquet格式存储,使用HiveSql查询也是完全兼容的. 2.选择parquet的本身原因 (1) parquet由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O.CSV格式一般不进行压缩,通过pa

Redis进阶实践之十一 Redis的Cluster集群搭建

原文:Redis进阶实践之十一 Redis的Cluster集群搭建 一.引言 本文档只对Redis的Cluster集群做简单的介绍,并没有对分布式系统的所涉及到的概念做深入的探讨.本文只是针对如何设置集群.测试和操作集群做了简述,并且从用户的角度描述了系统的行为,并不涉及Redis集群规范中所包含的细节.但是,本教程试图从最终用户的角度来解释有关Redis的Cluster集群的可用性和一致性的特点,并以简单易懂的方式讲解. 请注意,本教程需要使用Redis 3.0版本或更高版本. 如果您打算部署

Impala实践之十二:impala压缩方式测试

前言 测一下parquet.snappy.gzip.textfile这些方式在hdfs中占用的存储大小. 在impala中直接建内部表. 测试 存储格式 压缩格式 文件大小 建表时间 textfile none 3.0 G 38.74s parquet none 1.5 G 32.33s parquet snappy 709.3 M 31.71s parquet gzip 471.5 M 48.23s snappy snappy的官方描述. Snappy is a compression/dec

Impala实践之十三:Impala建表时的关键字

前言 由于经常要帮数据分析抽表,因此自己写了个自动生成impala和sqoop脚本的工具,结果今天发现一个库中17张表,只成功导入了12张.仔细检查才发现是是由于impala建表时候字段使用了location关键字的原因. 分析 建表语句 impala-shell -i ip:25004 -q " DROP TABLE IF EXISTS database.table; CREATE EXTERNAL TABLE database.table( id string, location strin

软件工程——理论、方法与实践 第十一章

第十一章.软件演化      第十一章   主要讲 1.软件演化的特性,软件维护是一个必然的过程,软件的不断修改会导致软件的退化,软件系统的演化特性是在早期的开发阶段建立起来的,软件开发的效率与投入的资源无关,在软件系统中添加新的功能不可避免地会产生新的缺陷: 2.软件的维护,软件维护是指在软件运行或维护阶段对软件产品进行的修改:分为改正型维护.适应性维护.完善性维护:并介绍了维护的特点和过程: 3.软件再工程,软件再工程以系统理解为基础,结合逆向工程.重构和正向工程等方法,讲现有系统重新构造成

Impala实践之五:一次系统任务堵塞记录 + 思考

前言 前段时间,imppala资源告警,各种任务失败,查询堵塞,因此公司集群升级. 这次迁移的确必须,因为当时的集群规模很小,资源太紧张了. 迁移集群后,今天集群再次出问题,导致一个下午没什么事都没干,查了一下午的错误. 事件发展 1.阶段一:下午2点17分 数据组反映集群崩溃,HUE界面不能登录,登录之后刷不出来表,当然也不能提交数据. 查看各种log日志.任务信息,发现事件发生前后有两个现象: 有一个admin用户每隔一分钟提交一次insert任务,一次任务的数据量主要分两个个等级:500M

Impala实践之六:使用Rest Api

前言 上次的impala状况出现后,决定自己做一套impala的管理系统,那么首先面临的一个问题就是获取impala的各种状态,比如任务执行状态.经过一天多的尝试,总结一下. hue:可以使用hue的脚本,hue使用python编写,其中有一个beeswax模块,负责任务的执行等.缺点是没发现java的api. cloudera manager java api:java可以调用cm原生的api,需要导入jar包.跑是跑通了,但是资料太说,目前只能通过这个接口获取集群的基本情况,不想再折腾imp

Impala实践之七:添加负载均衡

前言 impala的负载均衡,使用haproxy来做,主要是比较简单.安装后做一个小配置就行. 主要用的就是haproxy四层交换机的特性,讲所有指向haproxy主机和端口的请求,转发到相应的主机:端口上. cdh官网里面的信息已经比较久了,有些配置需要改,因此做一个笔记. impala负载 安装haproxy yum install haproxy 配置文件 vim /etc/haproxy/haproxy.cfg 下面是一个实际的配置文件,主机信息已经隐藏. global # To hav