今天寫程式碼寫到用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來得快嘛……於是生活就變得美好了起來。但是要注意的是，計算本地性優化並不是說絕對地把任務只發到資料所在地進行執行，還要考慮到均衡和併發能力的取捨。