Spark SQL repartition 为啥生成的文件变大了?
记录一个客户问题
客户用Spark SQL的repartition接口来解决Hive ORC表小文件的问题,发现文件膨胀的很厉害
比如原来有1000个小文件,总大小是500MB
repartition(10) 再 insert overwrite之后
10个文件 总大小是2~3GB
但是检查了一下最终的两个分区的 row count是一致的
调查结论
先说一下这两接口不同
repartition 把record完全打乱最终随机插入到10个文件 有Shuffle
coalesce 把相邻的分区的数据捏在一起,没有Shuffle
为啥shuffle打乱数据会让最终的表输出文件变大
其实就是 ORC 数据编码问题
原来的源分区其实是通过HashPartition的方式分布的,这样的数据分布可以让ORC的编码压缩得更加极致,而repartition完全打乱后导致本来在一个文件的相同记录分布到10个文件,那就是每个文件都有该记录的编码索引,那么最终文件就变大了
所以推荐使用 coalesce 接口来做类似的事情
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【最佳实践】Filebeat实现MySQL日志轻量化发送至Elasticsearch
在今天的文章中,我们来详细地描述如果使用Filebeat把MySQL的日志信息传输到Elasticsearch中。 环境准备 1、准备centos7.4版本 ECS 环境,关闭 selinux、firewall。2、准备阿里云elasticsearch 6.7 版本环境,并使用创建的账号密码登录Kibana3、安装 Filebeat 版本为 6.7.04、安装 MySQL 版本为 5.6.48 安装 MySQL 我们需要通过以下命令,来对 MySQL 进行安装。 # yum install mysql-server # systemctl start mysqld # systemctl status mysqld ####通过mysqladmin设置root密码##### # mysqladmin -u root password "12
- 下一篇
服务阿里 9 个APP|揭秘新奥创升级的质量演变
作者|何霜霜(谢萱)出品|阿里巴巴新零售淘系技术部 背景 新奥创技术体系,是手机淘宝端搭载着星环中台的整个商业化研发体系,孵化出的面对无线电商领域的技术体系。过去一年在手淘完成了下单、详情、购物车三大业务域的改造,接下来还会在订单、手淘导购等领域进行技术升级。目前新奥创已经接入阿里内的9个 App,逐步成为阿里集团无线领域电商系的技术解决方案。 本文主要围绕新奥创技术体系的升级,剖析架构升级对测试保障带来的新的转变,也是新的机遇。 新奥创的升级 新奥创是在基于组件化协议产品的基础上诞生的,并且结合端侧动态化技术,整体架构上升级了5大能力: ▐ 端侧动态化能力引入(DinamicX) 新奥创在解决业务端侧发版和客户端单点资源问题上,引入了DinamicX动态化能力。DinamicX是一套纯native的解决方案,专注于UI模板渲染,优势是高性能
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Windows10,CentOS7,CentOS8安装Nodejs环境