ref: http://www.sohu.com/a/155141436_151779

提起“大資料”就不得不提起有關資料的處理，雖然有人說過大資料在資料質量方面的要求不比傳統資料的要求那麼嚴格，當然這也是分場景的斷言，但是無論何時資料處理在大資料的生態中始終處於不可缺少的地位，因為資料處理的時效性行，準確性直接影響資料的分析與挖掘，分析的最終結果影響業務的營銷與收入。

一般而言，資料處理包括前期資料的規整，比如時間格式化，欄位的補齊等；中期，比如為了統計出某個指標，需要多報表關聯進行資料邏輯處理等，概況為兩個原則分別為保證資料的完整性，準確性，即在儘量保證資料的完整性也就是不要無故的丟失底層採集的資料情況下對資料處理要保證準確性，比如你的資料裡面時間是UTC時區，那你要根據你的業務判斷是否需要進行時區修正，比如你的使用者id原則上都是數字型別但是出現空的，那你要弄清使用者id為空是什麼場景下發生，資料處理應該怎麼處理，是保留還是放棄等。

而現階段的有關資料的處理，有傳統的ETL工具利用多執行緒處理檔案的方式；有寫MapReduce，有利用Hive結合其自定義函式，以及最近比較熱的利用Spark進行資料清洗等，可以說每種方式都有各自的使用場景。因此，我們在實際的工作中，需要根據不同的特定場景來選擇資料處理方式。

下面就幾種資料處理框架進行一下場景比較：

1.傳統的ETL工具比如Kettle、Talend、Informatica等，視覺化操作，上手比較快，但是對於資料量上升導致效能出問題，可優化的空間就不是很大了，畢竟底層人家都已經幫你封裝好了.

2.寫Mapreduce進行資料處理，需要利用java、python等語言進行開發除錯，沒有視覺化操作介面來的那麼方便，在效能優化方面，常見的有在做小表跟大表關聯的時候，可以先把小表放到快取中(通過呼叫Mapreduce的api),另外可以通過重寫Combine跟Partition的介面實現，壓縮從Map到reduce中間資料處理量達到提高資料處理效能。

3.Hive，在沒有出現下面要說的Spark之前，Hive可謂獨佔鰲頭，涉及離線資料的處理基本都是基於Hive來做的，早期的阿里的雲梯1就是充分利用Hive的特性來進行資料處理Hive採用sql的方式底層基於Hadoop的Mapreduce計算框架進行資料處理，所以他的優化方案很多，常見的場景比如資料傾斜，當多表關聯其中一個表比較小，可以採用mapjoin，或者設定set hive.groupby.skewindata=true等，當碰到資料量比較大的時候，可以考慮利用分桶，分割槽（分為靜態分割槽，動態分割槽）進行資料重新組織儲存，這樣在利用資料的時候就不需要整表去掃描，比如淘寶常常對一個業務場景利用不同演算法進行營銷活動，每個演算法的營銷活動可以存放到不同的分桶中，這樣統計資料的時候就會提高效率。對於hive的效能優化我後面會有一個專題進行介紹，這裡只簡單提一下常用的場景。

4.Spark基於記憶體計算的準Mapreduce，在離線資料處理中，一般使用Spark sql進行資料清洗，目標檔案一般是放在hdf或者nfs上，在書寫sql的時候，儘量少用distinct，group by reducebykey 等之類的運算元，要防止資料傾斜。在優化方面主要涉及配置每臺叢集每臺機器執行task的程序個數，記憶體使用大小，cpu使用個數等。從我個人的角度來看，我覺得spark sql跟上面所說的hive sql差不多，只不過spark sql更加傾向於記憶體處理。但是他不具有較強的模板話，如果修改裡面邏輯要重新編譯除錯執行，比較適合改動比較小的業務場景，比如資料倉庫

模型中ods，dwd層的資料處理。因為這兩層都是寬表級別的粗處理，目的很簡單旨在資料最優儲存支撐上層ads層報表開發。

目前業內資料處理，阿里的Odps平臺底層利用自己的一套Hadoop叢集每天提供上P級的資料處理，每天有上百資料開發工程師在上面寫Hive sql，當然這麼龐大的資料平臺維護的人員也不少，每天有工程師24小時輪流值班。Facebook目前正在進行是將Hive sql的指令碼遷移到spark sql，當然這也是他們的業務發展的需求，華為目前還是在基於Hadoop叢集雲化ETL處理資料，其他的一些小公司或者中型公司要麼買外面創業型資料公司的服務，要麼自己研發了一個ETL資料處理平臺。

最後通過以上個人對於目前業內資料處理這塊的一些總結，我覺得不管用什麼方式進行資料處理，都要嚴格遵守資料完整性，準確性這兩個原則。