《深入了解Hadoop（原書第2版）》——1.2大資料技術背後的核心思想

本節書摘來自華章計算機《深入了解hadoop（原書第2版）》一書中的第1章，第1.2節，作者 [美]薩米爾·瓦德卡（sameer wadkar），馬杜·西德林埃（madhu siddalingaiah），傑森·文納（jason venner），譯 于博，馮傲風，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

上文中的例子我們作了諸多假設，要表明的核心問題是雖然我們可以很快地處理資料，但是從持久性的儲存設備中讀取的速度受到限制，這是整個資料處理流程上的關鍵瓶頸所在。相對于讀寫本地節點儲存設備上的資料，通過網絡來傳輸資料會更慢。

下面列出了所有大資料處理方法中的一些共同特征：

資料分布在多個節點（網絡i/o速度<<本地磁盤i/o速度）。

計算程式離資料更近（叢集上的節點），而不是相反。

資料的處理盡量在本地完成（網絡i/o速度<<本地磁盤i/o速度）。

使用可順序讀取磁盤i/o代替随機讀取磁盤i/o（資料交換速度<<資料尋道時間）。

所有大資料計算處理模式都有一個目的，就是使輸入/輸出（i/o）并行化，進而提高資料處理性能。

根據定義，大資料是無法僅靠單台計算機資源來處理的。大資料的一個特點就是使用商用伺服器。一台典型的商用伺服器擁有2tb至4tb的磁盤。因為大資料是指遠遠超出這個容量的資料集，是以還是要将資料分布在多個節點上。

需要注意的是，我們把要處理的資料分布存放在多個計算節點，并不是因為這些資料的資料量有數十t之巨。你會發現大資料處理系統會有條不紊地在各個計算節點上計算處理所配置設定的資料。把資料分布到各個伺服器節點的最終目的是為了讓大量計算節點同時參與到資料的處理計算過程中來。哪怕僅有500gb的資料集，這麼大的資料量，叢集中的單台計算節點完全可以存儲，也會把資料分發到多台計算節點。這樣的資料分發有兩點好處：

每個資料塊會在多個節點上有多份拷貝（hadoop預設是一個資料塊有3份拷貝），這使得系統具備容錯性，當一個節點發生故障，其他節點還備份有故障節點上的資料。

為了達到資料并行處理的目的，多個節點可以同時參與資料處理過程。比如，50gb的資料被配置設定到10台計算節點，每個計算節點僅處理配置設定給自己的資料集，可以達到資料處理性能5～10倍的提升。讀者可能會問，為什麼不把這些資料存放到網絡檔案系統（nfs）中，這樣每個節點可以去讀取它要處理的部分。答案是本地存儲磁盤的資料讀取速度要遠遠高于通過網絡來讀取資料的速度。當資料分析任務啟動的時候，分析任務程式運作所需的函數庫被拷貝到各個計算節點，大資料處理系統會盡量在本地處理計算資料。我們會在後面章節中詳談。

對于我們這些精通j2ee程式設計的人來說，三層架構思想深植腦海。在三層程式設計模型中，所有的資料會通過網絡集中到一起，交由應用層來處理。我們由此形成了固有的觀念，就是資料應該是分散的，而程式應該是集中的。

大資料系統無法處理網絡過載的問題。傳輸動辄數t的資料量給應用層，使得網絡帶寬耗盡，網絡擁擠不堪，導緻傳輸效率大幅下降，甚至有可能導緻系統故障。從大資料的觀念來看，應該把資料分布存放到各個計算節點，程式也要移動到資料附近。要做到這一點，是一件很不容易的事情。除了程式要移動到存放資料的節點，程式運作所依賴的函數庫也要移動到資料處理節點才行。如果大資料系統的叢集擁有數百個計算節點，顯然那将是程式維護/部署人員的噩夢。是以，大資料系統可以讓我們集中式地部署程式代碼，大資料系統背景會在計算任務啟動之前把這些程式移動到各個資料處理節點。

前文提到的大資料系統的兩個特點，決定了配置設定到計算節點的資料要在計算節點本地處理。所有的大資料程式設計模型都是基于分布式和并行處理的。網絡i/o比本地磁盤i/o慢了好幾個數量級。資料被分發到各個計算節點，程式運作依賴庫也移動到了資料所在節點，計算節點就地計算處理資料的條件完備了。

雖然典型的大資料處理系統都希望把資料處理過程放在擁有資料的節點本地完成，但并不是每次都能實作。大資料系統會把計算任務盡量排程到離資料最近的節點。本章節的後續部分會介紹一些内容，其中大資料系統中某些特定的處理任務需要跨節點擷取資料。分布在各個計算節點的計算結果，最終要彙聚到一個計算節點（著名的mapreduce架構的reduce階段或其他海量資料并行化處理程式設計模型的類似階段），起碼這一步是需要跨節點擷取資料的。但是，在大多數的用例場景下，資料結果彙集階段的資料量，相對于計算節點本地處理的原始資料量來說是微不足道的。此過程的網絡開銷可以忽略不計（但也不總是這樣）。

首先，你要了解資料是如何從磁盤上讀取的。磁盤頭首先要移動到所尋找的資料所在的磁盤位置。這個過程稱為尋道（seek）操作，是需要花費很多時間的。一旦磁盤頭移動到目的位置後，資料便被順序地讀取出來。這叫做資料的傳輸（transfer）操作。尋道時間大約需要10毫秒，資料傳輸速度量級為20毫秒（1mb），這意味着，如果我們從磁盤上彼此不相鄰的1mb扇區來讀取100mb資料，會花費10（尋道時間）×100（尋道100次）＝1秒，再加上20（每兆資料傳輸所需時間）×100＝2秒。讀取100mb的資料總共需要3秒鐘的時間。如果我們從磁盤上彼此相鄰的扇區來順序讀取100mb資料，将花費10（尋道時間）×1（尋道100次）＋20×100＝2秒（譯者注：此處應為2.01秒，疑為作者筆誤）。讀取100mb的資料總共需要2.01秒時間。

需要注意的是上文資料讀取速度計算是基于jeff dean博士在2009年發表的文章。不得不承認，這個數字現在肯定有變化，實際上，資料的讀取速度更快了。但是，所得結果間的比值沒有變化，是以我們仍然可以拿來說明問題。

大多數的資料讀取密集型的大資料程式設計模型都利用了這個特征。資料被順序地從磁盤上讀出，然後在記憶體中過濾資料。與此不同的是典型的關系型資料庫管理系統（rdbms）模型，它們往往是以随機讀寫資料為主。

假設我們要計算2000年美國各州的總銷售量，并按州排序，銷售資料已經随機分發到各個計算節點。利用大資料計算技術，計算這個總量要分成如下步驟：

1）每個計算節點讀取分發給自己的全部資料，然後過濾掉不是2000年的銷售資料。計算節點從本地磁盤順序讀取被随機分發到該節點上的資料。在記憶體中過濾掉不用的資料，而不是在磁盤上過濾，這樣做可以避免磁盤的尋道時間。

2）各個計算節點在處理資料時，每發現一個新的州，就為它建立一個新的分組，把銷售資料加到對應的已存在的州分組中。（程式會在各個計算節點運作，分别做本地資料處理。）

3）當所有的節點都完成了本地所有資料的磁盤讀取工作，按照州編号分别計算了其銷售總額，它們會分别把各自的計算結果發送到一個特定的計算節點（我們稱之為彙聚（assembler）節點），這個彙聚節點是各個計算節點在計算任務伊始由所有節點協商出來的。

4）這個指定的彙聚節點會從所有計算節點按照州編号彙聚全部結果，把各個州的來自不同計算節點的資料分别相加。

5）彙聚節點按照州把最終結果排序，并輸出排序結果。

這個過程示範了一個大資料處理系統的典型特征：關注于使系統吞吐量（機關時間内系統處理的資料量）最大化，而非處理結果延時（請求響應的快慢，這個是評價事務性系統好壞的關鍵名額，因為我們想盡快獲得響應）。