在做spark开发过程中,时不时的就有可能遇到租户的hive库目录下的文件个数超出了最大限制问题. 一般情况下通过hive的参数设置: val conf = new SparkConf().setAppName("MySparkJob") //.setMaster("local[1]").setMaster("spark://172.21.7.10:7077").setJars(List("xxx.jar")).set(&qu

针对hive on mapreduce 1:我们可以通过一些配置项来使Hive在执行结束后对结果文件进行合并: 参数详细内容可参考官网:https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties hive.merge.mapfiles 在 map-only job后合并文件,默认true hive.merge.mapredfiles 在map-reduce job后合并文件,默认false hive.merg

Hive的后端存储是HDFS,它对大文件的处理是非常高效的,如果合理配置文件系统的块大小,NameNode可以支持很大的数据量.但是在数据仓库中,越是上层的表其汇总程度就越高,数据量也就越小.而且这些表通常会按日期进行分区,随着时间的推移,HDFS的文件数目就会逐渐增加.   小文件带来的问题   关于这个问题的阐述可以读一读Cloudera的这篇文章.简单来说,HDFS的文件元信息,包括位置.大小.分块信息等,都是保存在NameNode的内存中的.每个对象大约占用150个字节,因此一千万个文件

本文首发于公众号:五分钟学大数据 小文件产生原因 hive 中的小文件肯定是向 hive 表中导入数据时产生,所以先看下向 hive 中导入数据的几种方式 直接向表中插入数据 insert into table A values (1,'zhangsan',88),(2,'lisi',61); 这种方式每次插入时都会产生一个文件,多次插入少量数据就会出现多个小文件,但是这种方式生产环境很少使用,可以说基本没有使用的 通过load方式加载数据 load data local inpath '/ex

最近发现离线任务对一个增量Hive表的查询越来越慢,这引起了我的注意,我在cmd窗口手动执行count操作查询发现,速度确实很慢,才不到五千万的数据,居然需要300s,这显然是有问题的,我推测可能是有小文件. 我去hdfs目录查看了一下该目录: 发现确实有很多小文件,有480个小文件,我觉得我找到了问题所在,那么合并一下小文件吧: insert into test select * from table distribute by floor (rand()*5); 这里使用distribute

小文件是如何产生的: 动态分区插入数据的时候,会产生大量的小文件,从而导致map数量的暴增 数据源本身就包含有大量的小文件 reduce个数越多,生成的小文件也越多 小文件的危害: 从HIVE角度来看的话呢,小文件越多,map的个数也会越多,每一个map都会开启一个JVM虚拟机,每个虚拟机都要创建任务,执行任务,这些流程都会造成大量的资源浪费,严重影响性能 在HDFS中,每个小文件约占150byte,如果小文件过多则会占用大量的内存.这样namenode内存容量严重制约了集群的发展 小文件的解决

我们知道,大部分Spark计算都是在内存中完成的,所以Spark的瓶颈一般来自于集群(standalone, yarn, mesos, k8s)的资源紧张,CPU,网络带宽,内存.Spark的性能,想要它快,就得充分利用好系统资源,尤其是内存和CPU.有时候我们也需要做一些优化调整来减少内存占用,例如将小文件进行合并的操作. 一.问题现象 我们有一个15万条总数据量133MB的表,使用SELECT * FROM bi.dwd_tbl_conf_info全表查询耗时3min,另外一个500万条总数

代码如下: dataFrame.createOrReplaceTempView("view_page_utm") val sql = s""" |insert overwrite table data_lake_v1.urchin_tracking_module PARTITION(cd='$date', tag ='ads') | select p_id, platform, utm_campaign, utm_source, utm_term, utm

#!/bin/bash #set -x DB=$1 #获取hive表定义 ret=$(hive -e "use ${DB};show tables;"|grep -v _es|grep -v _hb|grep -v importinfo) for tem in $ret; do echo ${tem}_tmp hive -e "use ${DB};drop table ${tem}_tmp" hive -e "use ${DB};create table

#!/bin/bash #需要指定hive中的库名 #set -x set -e DB=$1 if [ -z $1 ];then echo "Usage:$0 DbName" exit 1 fi #注释掉cron对应的计划任务 row=$(sed -n '/sjob_exec.sh/=' /etc/crontab) sed -i "$row s/^/#/" /etc/crontab #获取hive表定义 ret=$(sudo -u hdfs hive -e &quo

磁盘: heads/sectors/cylinders,分别就是磁头/扇区/柱面,每个扇区512byte(现在新的硬盘每个扇区有4K) 文件系统: 文件系统不是一个扇区一个扇区的来读数据,太慢了,所以有了block(块)的概念,它是一个块一个块的读取的,block才是文件存取的最小单位. 文件系统中1个块是由连续的8个扇区组成. HDFS: 默认文件大小64M(或者是128M) hive小文件问题解决 问题描述 HDFS的文件元信息,包括位置.大小.分块信息等,都是保存在NameNode的内存中

1.hive.merge.mapfiles,True时会合并map输出.2.hive.merge.mapredfiles,True时会合并reduce输出.3.hive.merge.size.per.task,合并操作后的单个文件大小.4.hive.merge.size.smallfiles.avgsize,当输出文件平均大小小于设定值时,启动合并操作.这一设定只有当hive.merge.mapfiles或hive.merge.mapredfiles设定为true时,才会对相应的操作有效.5.m

原文地址:https://www.cnblogs.com/ballwql/p/8944025.html HDFS总体架构 在介绍文件存储方案之前,我觉得有必要先介绍下关于HDFS存储架构方面的一些知识,在对架构有初步了解后,才会明白为什么要单独针对小文件展开介绍,小文件存储和其它文件存储区别在什么地方. 这里我只是就Hadoop生态中的存储层展开介绍,对于其它部分本文暂未描述.众所周知,HDFS是目前非常流行的分布式文件存储系统,其逻辑架构如下图所示: HDFS也是典型的Master/Slave

在生产中,无论是通过SQL语句或者Scala/Java等代码的方式使用Spark SQL处理数据,在Spark SQL写数据时,往往会遇到生成的小文件过多的问题,而管理这些大量的小文件,是一件非常头疼的事情. 大量的小文件会影响Hadoop集群管理或者Spark在处理数据时的稳定性: 1. Spark SQL写Hive或者直接写入HDFS,过多的小文件会对NameNode内存管理等产生巨大的压力,会影响整个集群的稳定运行 2. 容易导致task数过多,如果超过参数spark.driver.max

一.小文件是如何产生的 1.动态分区插入数据,产生大量的小文件,从而导致map数量剧增. 2.reduce数量越多,小文件也越多(reduce的个数和输出文件是对应的). 3.数据源本身就包含大量的小文件. 二.小文件问题的影响 1.从Hive的角度看,小文件会开很多map,一个map开一个JVM去执行,所以这些任务的初始化,启动,执行会浪费大量的资源,严重影响性能. 2.在HDFS中,每个小文件对象约占150byte,如果小文件过多会占用大量内存.这样NameNode内存容量严重制约了集群的扩

当Hive的输入由非常多个小文件组成时.假设不涉及文件合并的话.那么每一个小文件都会启动一个map task. 假设文件过小.以至于map任务启动和初始化的时间大于逻辑处理的时间,会造成资源浪费.甚至发生OutOfMemoryError错误. 因此,当我们启动一个任务时,假设发现输入数据量小但任务数量多时.须要注意在Map前端进行输入小文件合并操作. 同理.向一个表写数据时,注意观察reduce数量.注意输出文件大小. 1. Map输入小文件合并 #每一个Map处理的最大输入文件大小(256MB

场景:推送过来的数据文件数量很多,并且每个只有10-30M的大小 spark读取hdfs一般都是用textfile(),但是对于这种情况,如果使用textFile默认产生的分区数将与文件数目一致,产生大量的任务. 对应这种小文件,spark提供了一个特殊的api, wholeTextFiles(), wholeTextFiles主要用于处理大量的小文件,源码如下: /** * Read a directory of text files from HDFS, a local file syste

原文网址:http://www.cnblogs.com/wenjiang/p/3140055.html 最近几天真的是各种意义上的忙,忙着考试,还要忙着课程设计,手上又有外包的项目,另一边学校的项目还要搞,自己的东西还在文档阶段,真的是让人想死啊!! 近半个月来,C#这方面的编码比较多,android和java这里完全搁置了,于是抽空写个小例子. 这个例子非常小,就是一个读取android根目录下的文件夹或文件,当做热一下身. @Override public void onCreate(Bun

目前平台使用Kafka + Flume的方式进行实时数据接入,Kafka中的数据由业务方负责写入,这些数据一部分由Spark Streaming进行流式计算:另一部分数据则经由Flume存储至HDFS,用于数据挖掘或机器学习.HDFS存储数据时目录的最小逻辑单位为“小时”,为了保证数据计算过程中的数据完整性(计算某个小时目录中的数据时,该目录的数据全部写入完毕,且不再变化),我们在Flume中加入了如下策略:   每五分钟关闭一次正在写入的文件,即新创建文件进行数据写入.   这样的方式可以保证

1.先在hive-site.xml中设置小文件的标准. <property> <name>hive.merge.smallfiles.avgsize</name> <value>536870912</value> <description>When the average output file size of a job is less than this number, Hive will start an additional