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，两表的列数也相差不大。

1. CREATE TABLE IF NOT EXISTS  `bi`.`dwd_tbl_conf_info`  ( 
2.   `corp_id` STRING COMMENT '', 
3.   `dept_uuid` STRING COMMENT '', 
4.   `user_id` STRING COMMENT '', 
5.   `user_name` STRING COMMENT '', 
6.   `uuid` STRING COMMENT '', 
7.   `dtime` DATE COMMENT '', 
8.   `slice_number` INT COMMENT '', 
9.   `attendee_count` INT COMMENT '', 
10.   `mr_id` STRING COMMENT '', 
11.   `mr_pkg_id` STRING COMMENT '', 
12.   `mr_parties` INT COMMENT '', 
13.   `is_mr` TINYINT COMMENT 'R', 
14.   `is_live_conf` TINYINT COMMENT '' 
15. ) 

1. CREATE TABLE IF NOT EXISTS `bi`.`ods_tbl_conf_detail` ( 
2.     `id` string, 
3.     `conf_uuid` string, 
4.     `conf_id` string, 
5.     `name` string, 
6.     `number` string, 
7.     `device_type` string, 
8.     `j_time` bigint, 
9.     `l_time` bigint, 
10.     `media_type` string, 
11.     `dept_name` string, 
12.     `UPDATETIME` bigint, 
13.     `CREATETIME` bigint, 
14.     `user_id` string, 
15.     `USERAGENT` string, 
16.     `corp_id` string, 
17.     `account` string 
18.   ) 

因为两张表均为很简单的SELECT查询操作，无任何复杂的聚合join操作，也无UDF相关的操作，所以基本确认查询慢的应该发生的读表的时候，我们将怀疑的点放到了读表操作上。通过查询两个查询语句的DAG和任务分布，我们发现了不一样的地方。

（编辑：我爱制作网_潮州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!