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)原有表修改为分区表,插入时不同时间放入到不同分区,查询时只查询需要的时间段内的分区数据,进一步减小读取数据量。
相关文章
- 让“物”能说会道,揭晓华为云IOT黑科技
- 这个应用魔方厉害了,让软件开发者效率提升10倍
- 华为云如何赋能无人车飞驰?从这群AI热血少年谈起
- 为什么说容器的崛起预示着云原生时代到来?
- 【API进阶之路】研发需求突增3倍,测试团队集体闹离职
- 小熊派开发实践丨漫谈LiteOS之传感器移植
- 谁说AI看不懂视频?
- 数据安全无小事:揭秘华为云GaussDB(openGauss)全密态数据库
- 数据湖探索DLI新功能:基于openLooKeng的交互式分析
- 趣味科普丨一文读懂云服务器的那些事儿
- 华为云瑶光:打通云边端界限,为企业云上业务带来最优解
- 解锁华为云AI如何助力无人车飞驰“新姿势”,大赛冠军有话说
- 原来AI也可以如此简单!教你从0到1开发开源知识问答机器人
- 技术实操丨HBase 2.X版本的元数据修复及一种数据迁移方式
- 技术实践丨手把手教你使用MQTT方式对接华为IoT平台 华为云开发者社区
- 必须收藏:20个开发技巧教你开发高性能计算代码
- 详解GaussDB(DWS) explain分布式执行计划
- 诸多老牌数据仓库厂商当前,Snowflake如何创近12年最大IPO金额
- 技术实践丨GaussDB(DWS)运维管理功能“升级”的原理和使用
- 华为云数据安全中心正式公测,8大核心数据安全能力守护你的数据