【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
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 的演算法。