spark中的partition和block的关系

今天写代码写到用rdd.cartesion(RDD),就查看了下源码部分，涉及到了partition，就整理了这块的知识点，大家可做参考

hdfs中的block是分布式存储的最小单元，类似于盛放文件的盒子，一个文件可能要占多个盒子，但一个盒子里的内容只可能来自同一份文件。假设block设置为128M，文件是250M，那么这份文件占3个block（128+128+2）。这样的设计虽然会有一部分磁盘空间的浪费，但是整齐的block大小，便于快速找到、读取对应的内容。（p.s. 考虑到hdfs冗余设计，默认三份拷贝，实际上3*3=9个block的物理空间。）

spark中的partion是弹性分布式数据集RDD的最小单元，RDD是由分布在各个节点上的partion组成的。partion是指的spark在计算过程中，生成的数据在计算空间内最小单元，同一份数据（RDD）的partion大小不一，数量不定，是根据application里的算子和最初读入的数据分块数量决定的，这也是为什么叫“弹性分布式”数据集的原因之一。

总结：
block位于存储空间、partion位于计算空间，
block的大小是固定的、partion大小是不固定的，
block是有冗余的、不会轻易丢失，partion（RDD）没有冗余设计、丢失之后重新计算得到

另外补充几点：

1. partition也可以有冗余，通过storagelevel来配置；

2. local或者yarn模式和partition，block概念上没有半毛钱关系，local模式也能操作hdfs，yarn模式也能操作本地文件；

3. 存储上为什么要将空间抽象成块前面的兄台已经叙述了，而且之所以设计成这么大的理由还牵扯到大存储空间中的各种管理、容错等等。那么与之对应的，在并行计算里我们希望降低网络带宽的负荷，所以会对计算做一层计算本地性优化，那么怎样做到这点呢？最简单的逻辑，把计算代码发到数据所在的节点上执行就可以了。那么这样一来，怎样做到并行优化？很简单啦，把一个超大的文件切切切分成一个一个不大不小的块（比如hdfs默认的64M，或者配得再大一点），然后把这些块打散在集群的不同节点上，最后把应用代码跟着数据块走，就能在不同节点上并行计算了。与之相对应的，spark为了利用起内存，对一些中间数据尽可能的用内存访问速度进行读写，所以把这部分管理工作纳入到自己这里（对比一下，经典的hadoop mapreduce就直接交给hdfs进行管理），可是就算存到内存里，那也得沿着这个思路来啊，不然计算本地化，并行之类的就很混乱了，那好吧，我也引入个概念，就叫partition好了，目的和前面一样。然后突然发现，哎呀我靠，这不得了，不仅能做到这些，既然我把一个超大份的数据都分成一块一块的了，那每一块是不是就能独立分隔开来了？那一个超大份文件，内存完全放不下，完全可以把其中一些块放到内存里，另外一些暂时放到硬盘里嘛，好歹也比纯放到hdfs来得快嘛……于是生活就变得美好了起来。但是要注意的是，计算本地性优化并不是说绝对地把任务只发到数据所在地进行执行，还要考虑到均衡和并发能力的取舍。