分佈式計算這一塊，自己也是剛接觸不久，故在此做一下簡單的記錄，以便後續的學習。首先總結一下市面上的主要大數據解決方案：
| 解決方案 | 開發商 | 類型 | 描述 |
|---|---|---|---|
| storm | 流式處理 | Twitter 的新流式大數據分析解決方案 | |
| S4 | Yahoo! | 流式處理 | 來自 Yahoo! 的分佈式流計算平臺 |
| Hadoop | Apache | 批處理 | MapReduce 範式的第一個開源實現 |
| Spark | UC Berkeley AMPLab | 批處理 | 支持內存中數據集和恢復能力的最新分析平臺 |
| Disco | Nokia | 批處理 | Nokia 的分佈式 MapReduce 框架 |
| HPCC | LexisNexis | 批處理 | HPC 大數據集羣 |
結合自己所找的一些資料，本文主要介紹Hadoop和spark兩種：
1.spark
（一）瞭解Hadoop
Hadoop是Apache開源組織的一個分佈式計算開源框架(http://hadoop.apache.org/)，用java語言實現開源軟件框架，實現在大量計算機組成的集羣中對海量數據進行分佈式計算。Hadoop框架中最核心設計就是：HDFS和MapReduce，HDFS實現存儲，而MapReduce實現原理分析處理，這兩部分是hadoop的核心。數據在Hadoop中處理的流程可以簡單的按照下圖來理解：數據通過Haddop的集羣處理後得到結果，它是一個高性能處理海量數據集的工具 。核心設計有三塊：
- HDFS:實現了一個分佈式文件存儲系統
- MapReduce:實現海量數據並行計算（分佈式運算框架）
-
YARN: Yet Another Resource Negotiator 資源管理調度系統
（二）使用Hadoop
由於Hadoop採用分佈式存儲與計算，可以將較大的數據分佈存儲，然後運算可以很大的解決由於內存不足導致程序終止的問題，故在這裏對常用的使用命令進行總結：
從開發機通過hadop進入自己的集羣文件：
$ hdfs dfs -ls /user
新建文件tt
hdfs dfs -mkdir hdfs://xx/tt
刪除文件
hdfs dfs –rm -r hdfs://xx/tt
複製文件
hdfs dfs –cp hdfs://xx/tt hdfs://yy/
從開發機上傳文件xx到集羣
hdfs dfs -put xx hdfs://xx/tt
從集羣上下載文件到開發機
hdfs dfs -get hdfs://xx/tt
2.spark
Apache Spark是一個圍繞速度、易用性和複雜分析構建的大數據處理框架，最初在2009年由加州大學伯克利分校的AMPLab開發，並於2010年成爲Apache的開源項目之一，與Hadoop和Storm等其他大數據和MapReduce技術相比，Spark有如下優勢：
- Spark提供了一個全面、統一的框架用於管理各種有着不同性質（文本數據、圖表數據等）的數據集和數據源（批量數據或實時的流數據）的大數據處理的需求
- 官方資料介紹Spark可以將Hadoop集羣中的應用在內存中的運行速度提升100倍，甚至能夠將應用在磁盤上的運行速度提升10倍
目標：
- 架構及生態
- spark 與 hadoop
- 運行流程及特點
- 常用術語
- standalone模式
- yarn集羣
- RDD運行流程
Spark與hadoop區別與聯繫:(https://www.cnblogs.com/cxxjohnson/p/8909578.html)
- Hadoop有兩個核心模塊，分佈式存儲模塊HDFS和分佈式計算模塊Mapreduce
- spark本身並沒有提供分佈式文件系統，因此spark的分析大多依賴於Hadoop的分佈式文件系統HDFS
- Hadoop的Mapreduce與spark都可以進行數據計算，而相比於Mapreduce，spark的速度更快並且提供的功能更加豐富
- 關係圖如下：
引深點：分佈式計算
分佈式計算簡單來說，是把一個大計算任務拆分成多個小計算任務分佈到若干臺機器上去計算，然後再進行結果彙總， 目的在於分析計算海量的數據。海量計算最開始的方案是提高單機計算性能，如大型機，後來由於數據的爆發式增長、單機性能卻跟不上，纔有分佈式計算這種妥協方案。 因爲計算一旦拆分，問題會變得非常複雜，像一致性、數據完整、通信、容災、任務調度等問題也都來了。下面以一個需求爲例進行說明，產品要求從數據庫中100G的用戶購買數據，分析出各地域的消費習慣金額等。 如果沒什麼時間要求，程序員小明就寫個對應的業務處理服務程序，部署到服務器上，讓它慢慢跑就是了，小明預計10個小時能處理完。 後面產品嫌太慢，讓小明想辦法加快到3個小時。
（1）分片算法
這是一種介於單機計算和成熟計算框架的過度解決方案，分佈式計算通過對計算任務進行拆分，實現成本和需求雙滿足了。 如果數據能以水平拆分的方式，分佈到5臺機器上，每臺機器只計算自身的1/5數據，這樣即能在3小時內完成產品需求了。小明需要把這些數據按照一定維度進行劃分。 按需求來看以用戶ID劃分最好，由於用戶之間沒有狀態上的關聯，所以也不需要事務性及二次迭代計算。 小明用簡單的hash取模對id進行劃分。
f(memberid) % 5 = ServerN
這樣程序可以分別部署到5臺機器上，然後程序按照配置只取對應餘數的用戶id，計算出結果併入庫。 這種方式多機之間毫無關聯，不需要進行通信，可以避免很多問題。 機器上的程序本身也不具備分佈式的特性，它和單機一樣，只計算自身獲取到的數據即可，所以如果某臺機器上程序崩潰的話，處理方式和單機一樣，比如記錄下處理進度，下次從當前進度繼續進行後續計算。
（2）消息隊列
使用分片方式相對比較簡單，但有如下不足之處。
- 它不具有負載均衡的能力，如果某臺機器配置稍好點，它可能最先計算完，然後空閒等待着。也有可能是某些用戶行爲數據比較少，導致計算比較快完成。
- 還有一個弊端就是每臺機器上需要手動更改對應的配置， 這樣的話多臺機器上的程序不是完全一樣的，這樣可以用遠程配置動態修改的辦法來解決。
小明這種方式引入了個第三方，消息隊列。 小明先用一個單獨的程序把用戶信息推送到消息隊列裏去，然後各臺機器分別取消費這個隊列。 於是就有了3個角色：
- 推送消息的，簡稱Master。
- 消息隊列，這裏以Rabbitmq爲例。
- 各個處理程序，簡稱Worker或Slave都行。
雖然僅僅引入了個第三方，但它已經具備了分佈式計算的很多特性。
- 計算任務分發。 Master把需要計算的用戶數據，不斷的推送消息隊列。
- 程序一致性。 Worker訂閱相同的消息隊列即可，無需更改程序代碼。
- 任意擴容。 由於程序完全一樣，意味着如果想要加快速度，重複部署一份程序到新機器即可。 當然這是理論上的，實際當中會受限於消息隊列、數據庫存儲等。
- 容災性。 如果5臺中某一臺程序掛了也不影響，利用Rabbitmq的消息確認機制，機器崩潰時正在計算的那一條數據會在超時，在其他節點上進行消費處理。
（3）hadoop
如上面所描述的，Hadoop是一套海量數據計算存儲的基礎平臺架構，數據越大越能提現其性能，小明對此進行了如下設計
- 目標任務是100G用戶數據的計算任務。
- ”任務劃分“ 對應Master和消息隊列。
- “子任務” 對應Worker的業務邏輯。
- ”結果合併“ 對應把每個worker的計算結果入庫。
- “計算結果” 對應入庫的用戶消費習慣數據。
參考鏈接：
https://blog.csdn.net/gwd1154978352/article/details/81095592
http://hadoop.apache.org/docs/r1.0.4/cn/quickstart.html（Hadoop快速入門）
https://blog.csdn.net/andrew_yuan/article/details/80306101（Hadoop入門篇）
https://www.cnblogs.com/mushroom/p/4959904.html（淺談分佈式計算的開發與實現）