自己通過閱讀了解論文和極客時間相關講解，并通過自己已有的框架知識，總結該文章，閱讀需要有一定的大資料基礎知識，
文章目錄
- MapReduce的計算模型
- MapReduce如何使得開發者無需關心分布式的存在（易用性）
- MapReduce 的性能優化
- 遺憾與缺陷
MapReduce整篇論文分為三個部分
MapReduce的計算模型
面對海量的資料，我們所需要的計算，有以下三種情況：
-
第一種，面對所有的資料，我們都只需要單條資料就能完成處理，
-
第二種，需要匯總多條資料才能完成計算，（將相同的搬運到一個節點，不同的仍舊可以在不同的節點）
-
第三種，就是第一二種的結合，例如提取關鍵字，統計關鍵字的出現次數，
所以對應的計算模型，就是Map（第一種）和Reduce（第二種），
-
Map：映射函式，將接受的一個key-value轉化為0到多個新的key-value輸出，
-
Reduce：化簡函式，接收一個key及其下所有的Value，然后化簡為一組新的值Value輸出出去，
Map 幫助我們解決了并行在很多臺機器上處理互相之間沒有依賴關系的資料；而 Reduce 則用來處理互相之間有依賴關系的資料，我們可以通過 MapReduce 框架自帶的 Shuffle 功能，通過排序來根據設定好的 Key進行分組，把相同 Key 的資料放到同一個節點上，供 Reduce 處理，
MapReduce如何使得開發者無需關心分布式的存在（易用性）
用戶只需撰寫對應的Map和Reduce的邏輯，
-
MapReduce的協同
指master對于map和reduce的協調，由master找到對應的空閑節點啟動對應的worker，
其中磁區函式把輸出的資料分成 R 個不同的區域，而這些本地檔案的位置，會被 worker 傳回給到 master 節點，再由 master 節點將這些地址轉發給 reduce 任務所在的 worker 那里，reduce去進行拉取，
整個程序map和reduce是不會直接通信的，都是與master進行互動，
因與Hadoop的MapReduce基本一樣，故不做贅述程序，
在Hadoop1.0中，JobTracker既承擔了調度的任務，又承擔了master的任務，這使得服務器一多，JobTracker的負載就很重，所以就有了Hadoop集群承載服務器的上限，其成為脆弱的‘單點’，
在Hadoop2.0中，將JobTracker的任務分為Resource Mananger（調度任務）和 Application Master（master，單個任務的管理），回歸了論文中的設計，
-
MapReduce的容錯
worker節點的失效：
MapReduce 框架解決問題的方式非常簡單，就是換一臺服務器重新運行這個 Worker 節點被分配到的所有任務，master 節點會定時地去 ping 每一個worker 節點，一旦 worker 節點沒有回應，我們就會認為這個節點失效了，
master節點的失效：
方案一：任由其失敗，再重新提交就可以，
方案二：master中的資訊定時存入Checkpoint，當失敗重啟后，讀取Checkpoint，不至于重新運行整個任務，
-
對錯誤資料視而不見
MapReduce 會記錄 Map 或者 Reduce 函式，運行出錯的具體資料的行號，如果同樣行號的資料執行重試還是出錯，它就會跳過這一行的資料，如果這樣的資料行數在總體資料中的比例很小，那么整個 MapReduce 程式會忽視這些錯誤，仍然執行完成，（我們不可能為了一條資料（大資料場景下，幾條資料的錯誤并不會對結果造成影響）），而去重新掃描幾個TB的資料），
MapReduce 的性能優化
-
把程式搬到資料那里（盡可能減少網路傳輸）
GFS 知道每一個 Block 的資料是在哪臺服務器上的，而 MapReduce，會找到同樣服務器上的 worker，來分配對應的map 任務，如果那臺服務器上沒有，那么它就會找離這臺服務器最近的、有 worker 的服務器，來分配對應的任務，
-
Combiner（減少map和reduce間網路傳輸）
在map端進行輕度聚合，然后再交由reduce聚合，（也可以減少reduce端的壓力）
注意不要改變邏輯，如算平均值，不能用這種方法，
-
MapReduce的dubug
master 里面內嵌一個 HTTP 服務器，將 master 的各種狀態展示出來，我們可以看到任務的執行情況，完成進度，輸入多少，輸出多少，以及每個任務的日志資訊，
MapReduce 框架里提供一個計數器（counter）的機制，所有 map 和 reduce 的計數器都會匯總到 master 節點上，通過上面的 HTTP 服務器里展現出來，（我們可以統計有價值的資訊，例如有多少個資訊是非法的，如果比例太高，我們需要調整對應的程式），
在Hadoop，這個HTTP服務器即指我們訪問的8088號埠，
遺憾與缺陷
分布式：仍舊會讓用戶意識到分布式的存在，無論是 Combiner還是Partitioner，都讓用戶明白其面對的仍舊為分布式，
性能：每個任務開銷比較大，我們必須先使得資料本地化，復制到各個worker節點，才能啟動行程，
? 所有的中間資料都要讀寫多次硬碟，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/428577.html
標籤：其他
下一篇：PanacheEntity-在投影到DTO期間，在panache物體中出現QuerySyntaxException意外令牌