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和使命漫衍，我们发明白纷歧样的处所。 三、营业调优 那此刻摆在我们眼前就存在此刻题目： 为什么小表会发生这么小文件 已经发生的这么小文件怎样归并 带着这两个题目，我们和营业的开拓职员聊了一个发明小表是营业开拓职员从原始数据表中，凭证差异的时刻切片查询并做数据洗濯后插入到小表中的，而因为时刻切片切的较量小，导致这样的插入次数出格多，从而发生了大量的小文件。 那么我们必要办理的题目就是2个，怎样才气把这些汗青的小文件举办归并以及怎样才气担保后续的营业流程中不再发生小文件，我们指导营业开拓职员做了以下优化： 行使INSERT OVERWRITE bi.dwd_tbl_conf_info SELECT * FROM bi.dwd_tbl_conf_info归并下汗青的数据。因为DLI做了数据同等性掩护，OVERWRITE时代不影响原稀有据的读取和查询，OVERWRITE之后就会行使新的归并后的数据。归并后全表查询由原本的3min收缩到9s内完成。 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
