spark partition和hdfs block的关系

背景：最近遇到了一个问题，一个程序利用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/51150278

2、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速度慢的原因还在查找中。