spark partition和hdfs block的关系
2018-03-28 18:57
239 查看
背景:最近遇到了一个问题,一个程序利用hive sql 读取数据时出现了轻微的数据倾斜(每个task的输入data 大小类似,但是executor的数据大小有差距),我怀疑是每个partition的数据大小不同,导致的这个问题。(但我想的很明显是错的,如果使用的是textfile,每个task处理的就是一个partition的数据,而每个partition的数据应该是 每个block的数据)。而现在的程序使用的是spark.sql.shuffle.partitions控制最后的partition数量。1、如果使用textfile读取hdfs中的文件,block的数量和partition的数量应该是相同的。--上面的这句话现在看来是有问题的,对于数据读入阶段,例如sc.textFile,输入文件被划分为多少InputSplit就会需要多少初始Task。在Map阶段partition数目保持不变。在Reduce阶段,RDD的聚合会触发shuffle操作,聚合后的RDD的partition数目跟具体操作有关,例如repartition操作会聚合成指定分区数,还有一些算子是可配置的。partition的个数是split size决定的,spark的底层还是用的hadoop的fileformat,当你制定了一个可以切分的format,他就会按照splitsize去切partition,这个决定了任务会被分成多少份。
具体大小见https://blog.csdn.net/dr_guo/article/details/511502782、Multiple files are not stored in a single block. BTW, a single file can be stored in multiple blocks. The mapping between the file and the block-ids is persisted in the NameNode.一个block只能储存一个文件,但一个文件可以储存在多个block(文件太大)。但是如果文件太多,namenode就会因为储存太多的mapping而出问题(一个150b)。HDFS的namenode储存着3、小文件是指文件size小于HDFS上block大小的文件。这样的文件会给hadoop的扩展性和性能带来严重问题。首先,在HDFS中,任何block,文件或者目录在内存中均以对象的形式存储,每个对象约占150byte,如果有1000 0000个小文件,每个文件占用一个block,则namenode大约需要2G空间。如果存储1亿个文件,则namenode需要20G空间(见参考资料[1][4][5])。这样namenode内存容量严重制约了集群的扩展。 其次,访问大量小文件速度远远小于访问几个大文件。HDFS最初是为流式访问大文件开发的,如果访问大量小文件,需要不断的从一个datanode跳到另一个datanode,严重影响性能。最后,处理大量小文件速度远远小于处理同等大小的大文件的速度。每一个小文件要占用一个slot,而task启动将耗费大量时间甚至大部分时间都耗费在启动task和释放task上。4、上面的描述都是针对textfile的情况,但是我使用的是hive读取数据,参数spark.sql.shuffle.partitions控制最后的partition数量5、使用repartition分区很明显是毫无意义的,因为其使用的是hashcode。目前为什么输入数据差不多大,但是有部分task速度慢的原因还在查找中。
具体大小见https://blog.csdn.net/dr_guo/article/details/511502782、Multiple files are not stored in a single block. BTW, a single file can be stored in multiple blocks. The mapping between the file and the block-ids is persisted in the NameNode.一个block只能储存一个文件,但一个文件可以储存在多个block(文件太大)。但是如果文件太多,namenode就会因为储存太多的mapping而出问题(一个150b)。HDFS的namenode储存着3、小文件是指文件size小于HDFS上block大小的文件。这样的文件会给hadoop的扩展性和性能带来严重问题。首先,在HDFS中,任何block,文件或者目录在内存中均以对象的形式存储,每个对象约占150byte,如果有1000 0000个小文件,每个文件占用一个block,则namenode大约需要2G空间。如果存储1亿个文件,则namenode需要20G空间(见参考资料[1][4][5])。这样namenode内存容量严重制约了集群的扩展。 其次,访问大量小文件速度远远小于访问几个大文件。HDFS最初是为流式访问大文件开发的,如果访问大量小文件,需要不断的从一个datanode跳到另一个datanode,严重影响性能。最后,处理大量小文件速度远远小于处理同等大小的大文件的速度。每一个小文件要占用一个slot,而task启动将耗费大量时间甚至大部分时间都耗费在启动task和释放task上。4、上面的描述都是针对textfile的情况,但是我使用的是hive读取数据,参数spark.sql.shuffle.partitions控制最后的partition数量5、使用repartition分区很明显是毫无意义的,因为其使用的是hashcode。目前为什么输入数据差不多大,但是有部分task速度慢的原因还在查找中。
相关文章推荐
- HDFS------block,packet,chunk的关系
- hbase blocksize设置,与hdfs关系
- spark中的partition和block的关系
- display:inline-block和元素水平居中的关系
- 表空间(tableSpace) 段(segment) 盘区(extent) 块(block) 关系
- hdfs fsck命令查看HDFS文件对应的文件块信息(Block)和位置信息
- python spark中parquet文件写到hdfs,同时避免太多的小文件(block小文件合并)
- Hive学习之七《 Sqoop import 从关系数据库抽取到HDFS》
- hdfs fsck命令查看HDFS文件对应的文件块信息(Block)和位置信息
- CUDA中grid、block、thread、warp与SM、SP的关系
- 聊聊HDFS BlockManager的服务化改造
- INFO hdfs.DFSClient: Exception in createBlockOutputStream java.net.NoRouteToHostException: No route
- HDFS中的部分Datanode存在大量没有删除的Block磁盘被占满
- 修改SequenceFileInputFormat hdfs blocksize
- CUDA软件架构—网格(Grid)、线程块(Block)和线程(Thread)的组织关系以及线程索引的计算公式
- bug宝典hadoop篇 org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for Block pool <
- hdfs.DFSClient: Exception in createBlockOutputStre
- 智能客户端应用学习系列:SmartClient Software factory中的Composite UI Application Block(Cab)技术了解(十):异步调用,离线处理,队列管理的关系
- [转载]HDFS的'Block'和MapReduce的'Split'之间的关系和区别
- 自定义/指定 HDFS Block存放位置