Spark优化之小文件是否需要合并?
我们知道,大部分Spark计算都是在内存中完成的,所以Spark的瓶颈一般来自于集群(standalone, yarn, mesos, k8s)的资源紧张,CPU,网络带宽,内存。Spark的性能,想要它快,就得充分利用好系统资源,尤其是内存和CPU。有时候我们也需要做一些优化调整来减少内存占用,例如将小文件进行合并的操作。
一、问题现象
我们有一个15万条总数据量133MB的表,使用SELECT * FROM bi.dwd_tbl_conf_info全表查询耗时3min,另外一个500万条总数据量6.3G的表ods_tbl_conf_detail,查询耗时23秒。两张表均为列式存储的表。
大表查询快,而小表反而查询慢了,为什么会产生如此奇怪的现象呢?
二、问题探询
数据量6.3G的表查询耗时23秒,反而数据量133MB的小表查询耗时3min,这非常奇怪。我们收集了对应的建表语句,发现两者没有太大的差异,大部分为String,两表的列数也相差不大。
CREATE TABLE IF NOT EXISTS `bi`.`dwd_tbl_conf_info` (`corp_id` STRING COMMENT '',`dept_uuid` STRING COMMENT '',`user_id` STRING COMMENT '',`user_name` STRING COMMENT '',`uuid` STRING COMMENT '',`dtime` DATE COMMENT '',`slice_number` INT COMMENT '',`attendee_count` INT COMMENT '',`mr_id` STRING COMMENT '',`mr_pkg_id` STRING COMMENT '',`mr_parties` INT COMMENT '',`is_mr` TINYINT COMMENT 'R',`is_live_conf` TINYINT COMMENT '')
CREATE TABLE IF NOT EXISTS `bi`.`ods_tbl_conf_detail` (`id` string,`conf_uuid` string,`conf_id` string,`name` string,`number` string,`device_type` string,`j_time` bigint,`l_time` bigint,`media_type` string,`dept_name` string,`UPDATETIME` bigint,`CREATETIME` bigint,`user_id` string,`USERAGENT` string,`corp_id` string,`account` string)
因为两张表均为很简单的SELECT查询操作,无任何复杂的聚合join操作,也无UDF相关的操作,所以基本确认查询慢的应该发生的读表的时候,我们将怀疑的点放到了读表操作上。通过查询两个查询语句的DAG和任务分布,我们发现了不一样的地方。
查询快的表,查询时总共有68个任务,任务分配比如均匀,平均7~9s左右,而查询慢的表,查询时总共1160个任务,平均也是9s左右。如下图所示:
至此,我们基本发现了猫腻所在。大表6.3G但文件个数小,只有68个,所以很快跑完了。而小表虽然只有133MB,但文件个数特别多,导致产生的任务特别多,而由于单个任务本身比较快,大部分时间花费在任务调度上,导致任务耗时较长。
那如何才能解决小表查询慢的问题呢?
三、业务调优
那现在摆在我们面前就存在现在问题:
1、为什么小表会产生这么小文件
2、已经产生的这么小文件如何合并
带着这两个问题,我们和业务的开发人员聊了一个发现小表是业务开发人员从原始数据表中,按照不同的时间切片查询并做数据清洗后插入到小表中的,而由于时间切片切的比较小,导致这样的插入次数特别多,从而产生了大量的小文件。
那么我们需要解决的问题就是2个,如何才能把这些历史的小文件进行合并以及如何才能保证后续的业务流程中不再产生小文件,我们指导业务开发人员做了以下优化:
1、使用INSERT OVERWRITE bi.dwd_tbl_conf_info SELECT * FROM bi.dwd_tbl_conf_info合并下历史的数据。由于DLI做了数据一致性保护,OVERWRITE期间不影响原有数据的读取和查询,OVERWRITE之后就会使用新的合并后的数据。合并后全表查询由原来的3min缩短到9s内完成。
2,原有表修改为分区表,插入时不同时间放入到不同分区,查询时只查询需要的时间段内的分区数据,进一步减小读取数据量。
点击这里→了解更多精彩内容
Spark优化之小文件是否需要合并?相关推荐
- spark 实现HDFS小文件合并
一.首先使用sparksql读取需要合并的数据.当然有两种情况, 一种是读取全部数据,即需要合并所有小文件. 第二种是合并部分数据,比如只查询某一天的数据,只合并某一个天分区下的小文件. val df ...
- HIVE优化系列(1)-- 自动合并输出的小文件
小文件的缺陷我们就不说了,直接进入到正题. HIVE自动合并输出的小文件的主要优化手段为: set hive.merge.mapfiles = true:在只有map的作业结束时合并小文件, set ...
- Hive合并小文件参数总结
hive merge小文件 一:为什么要合并小文件 当Hive输入由很多个小文件组成,由于每个小文件都会启动一个map任务,如果文件过小,以至于map任务启动和初始化的时间大于逻辑处理的时间,会造成资 ...
- Hive Archive合并文件归档,减少小文件数量(推荐)
我们在使用Hive存储时,有时会遇到Hive表的文件大小不大,但是文件数量众多:这是可能会遇到HDFS的储存空间没到阈值,但文件数量超过阈值.如果小文件太多,容易影响整个集群的性能. 那么对于小文件多 ...
- 代达罗斯之殇-大数据领域小文件问题解决攻略
: 点击上方蓝色字体,选择"设为星标" 回复"资源"获取更多惊喜 大数据技术与架构 点击右侧关注,大数据开发领域最强公众号! 大数据真好玩 点击右侧关注,大数据 ...
- HDFS小文件治理总结
目录 背景 第一部分 回本溯源 第二部分 HDFS大量小文件的危害 第三部分 小文件治理方案总结 第四部分 总结 参考文献及资料 背景 企业级Hadoop大数据平台在实际使用过程中,可能大部分会遭遇小 ...
- 海量小文件存储与Ceph实践
海量小文件存储(简称LOSF,lots of small files)出现后,就一直是业界的难题,众多博文(如[1])对此问题进行了阐述与分析,许多互联网公司也针对自己的具体场景研发了自己的存储方案( ...
- 蚂蚁绊倒大象?不起眼的小文件竟拖了Hadoop大佬的后腿
在使用Hadoop过程中,小文件是一种比较常见的挑战,如果不小心处理,可能会带来一系列的问题.HDFS是为了存储和处理大数据集(M以上)而开发的,大量小文件会导致Namenode内存利用率和RPC调用 ...
- HIVE 生成过多小文件的问题
HIVE 生成大量小文件 小文件的危害 为什么会生成多个小文件 不同的数据加载方式生成文件的区别 解决小文件过多的问题 今天运维人员突然发来了告警,有一张表生成的小文件太多,很疑惑,然后排查记录了下 ...
最新文章
- 基于JWT的Token认证机制实现
- python 自动化微信小程序_appium+python 微信小程序的自动化
- 将字符串的部分保存,剩余删去,或只保留指定一段子字符串
- Windows Phone开发(4):框架和页
- C++/C中定义与声明的区别
- python漏洞利用脚本_利用Python脚本实现漏洞情报监控与通知的经验分享
- Eclipse代码自动提示设置
- VM ware 12安装教程
- The essense of the software atchitecture
- 竹子买车商学院,知名汽车人钟志,销售实战培训
- 一、jsp和Servlet基础理论及jstl和EL表达式用法
- table thead tr设置表头背景色未完全覆盖的问题
- 使用you-get工具下载MP4视频
- android 命名空间的使用
- HDU 3374 最小 / 大表示法
- return 的含义
- 人工智能:声纹相关基础概念介绍
- stagefright 架构分析(六) 创建一个 Soft Decoder
- [转帖]希捷硬盘的命名规范
- [转帖]生产环境(基于docker)故障排除? 有感于博客园三番五次翻车
热门文章
- uniapp 如何给搜索框设值_uni-app搜索功能前后端开发(页面)
- array用法 numpy_python--numpy(3)
- python简单代码需要写多久_python基本语法?初学Python要多久才能入门?
- 自考专科计算机信息管理专业好,计算机信息管理(专科)专业介绍
- php面向对象初始化一次,php单例模式实现(对象只被创建一次)
- net 架构师-数据库-sql server-003-T-SQL 基本语句
- Repeater内部排序
- 20181030-4 每周例行报告
- 第三章 熟悉常用的HDFS操作
- CAS 5.1.x 的搭建和使用(四)—— 配置使用HTTP协议访问的服务端