【pySpark教程】Big Data, Hardware trends, and Spark（二）
Big Data, Hardware trends, and Spark
在本系列課程中，我們會學習如下內容：
- Data Management
- Semi-Structed Data
- Structured Data
- 實驗二：使用 Spark 分析網路伺服器日誌
- 資料分析與機器學習
- 資料處理
- 資料分析
- 機器學習
- 實驗三：文字分析與實體解析
- 實驗四：Spark 機器學習介紹
The Big Data Problem
傳統的資料分析的工具有下面這些，包括：Unix shell命令，Pandas 和 R 語言等等。這些工具都是執行到單個機器上的，遇到Big Data Problem 的時候就不太能work了。
那麼 Big Data Problem 是啥呢？
- 資料增加速度大於計算效能
- 資料來源越來越豐富
>> Web, mobile, scientific,… - 儲存變得越來越便宜
>> 基本上每18個月便宜一半 - 但是CPU效能的增長速度卻達不到這樣的水平
舉一些 Big Data Examples
可以看到，從disk中讀取 1TB 資料需要3個小時，而且單個機器已經很難處理這樣規模的資料了，一個解決方法就是把資料分佈到大型叢集中去。
Hardware for Big Data
如果叢集使用的是廉價的機器，那麼很容易發生一些問題：
- Failures（Google的資料）
1~5% 硬碟會損壞/年
0.2% 記憶體條損壞/年 - Network 速度 VS 共享記憶體
從網路中讀取的速度遠遠小於從硬碟或者記憶體中讀取的速度 - Uneven performance
機器的效能不均，有些機器很快，有些則計算的很慢
Distributing Work
叢集的計算有沒有困難的地方？
第一個challenge就是，如何將任務分配到不同的機器中？
來看一個例子（統計詞頻）：
1. 檔案不是很大的情況下：
很簡單，使用一個hash 表就能解決問題了。
2. 檔案很大的情況下：
這種情況下，其實也很簡單，就是使用MapReduce 的思想，把資料map之後處理，然後再reduce結果。
上圖貌似可以解決問題了，但是，當資料特別大的時候，machine 5 的壓力特別大，因為它要儲存所有的結果（可能會存不下）。
這種情況下，可以採用下面這種分而治之的思想，把結果也分佈到不同的機器上：
這就是 Google 在04年提出的 Map Reduce：
有便捷，肯定也會有缺陷，使用這種分而治之思想，會帶來哪些問題呢？
- 資料的傳輸非常耗時
- 處理更多的機器意味著你需要解決更多的機器故障帶來的問題
Solution：當一臺機器故障的時候，你可以將這個未完成的任務分配給其他機器，或者等到這臺機器恢復的時候再重新分配給它； - 機器多了，效能差距也會變大，所以，你還需解決效能不均帶來的問題
Solution：如果有一臺機器非常慢，一直無法完成任務，那麼你可以殺掉這個任務，並將它分配給其他機器；
所以，沒有什麼萬能方法，你想要達到一些便利，就需要面對由此而來的困擾。
Map Reduce
Map Reduce 在每一次任務完成之後，都要把結果寫入硬碟，並在下一次任務開始再讀進來。
如果我們的job是迭代式的（比如，機器學習中的迭代優化），那麼計算效能就會非常慢。因為，每一次的迭代，你都需要重新讀寫。我們都知道，讀寫硬碟是一件非常非常耗時的事情。
Apache Spark
隨著記憶體價格越來越低，我們可以更多的利用記憶體來進行計算。Spark 正是利用了記憶體速率高的特點，大大改進了Map Reduce的效能。
下圖是 MapReduce 的過程：
下圖是 Spark 的過程：
避免頻繁的網路、硬碟讀取，使得Spark速度大大提升。
Spark 發展到現在已經非常成熟，它提供了很多的資料分析工具，如下圖：
Spark 與 Hadoop 的不同之處：
這些不同之處，帶來了一些效能上的提升如下：
Spark，擁有Hadoop MapReduce所具有的優點；
但不同於MapReduce的是Job中間輸出結果可以儲存在記憶體中，從而不再需要讀寫HDFS。
Spark 能更好地適用於資料探勘、機器學習等需要迭代優化的 MapReduce 的演算法。