金融風控實戰——Hive詳解（數據讀取、預處理、特徵工程）

大數據技術的介紹：

1、存儲，我們需要了解在大數據的架構下，數據大致是怎麼進行存儲的，傳統的文件系統是單機的，不能橫跨不同的機器。HDFS（Hadoop Distributed FileSystem）的設計本質上是為了大量的數據能橫跨成百上千台機器，但是用户在實際的應用中，看到的是一個文件系統而不是多個文件系統。比如要獲取/hdfs/tmp/file1的數據，看起來和單機無異，引用的是一個文件路徑，但是實際的數據存放在很多不同的機器上。作為用户，不需要知道數據具體是怎麼存儲在分佈式系統中的，就好比在單機上我們不關心文件分散在什麼磁道什麼扇區一樣。HDFS會自動為你管理這些數據；

2、數據處理，解決了存儲的問題之後，我們就要開始考慮如何處理數據了，雖然HDFS可以整體管理不同機器上的數據，但是這些數據太大了。一台機器承載着也是巨量的數據，使用一台機器跑也許需要好幾天甚至好幾周。那麼，一個非常自然的想法，既然數據可以在多台機器上存儲，難道不能使用多台機器來處理嗎？這就好比我們常使用的多核計算，類比來看，在大數據中，一台機器對應的就是一個核，因此同樣，和多核計算一樣，我們面臨着如何分配不同機器工作的問題，如果一台機器掛了如何重新啟動相應的任務，機器之間如何互相通信交換數據以完成複雜的計算等等，這就是MapReduce架構、spark的功能。

3、Mapreduce mapreduce不僅僅提供了技術上的架構，更重要的是其思想，對於巨大型任務的處理思路，其實很簡單，先map，然後reduce，它的思想和多核計算是非常相似的：

我們來概覽一下mapreduce的結構，然後把mapreduce框架下整個任務處理的流程過一遍就能體會mapreduce的思想了：首先會有一個master節點，作為用户在大數據框架中的“計算機代理”負責整個任務的調度（這樣我們就不用人為地去給不同的worker（機器）分配工作了，這是mapreduce框架非常方便的地方），然後數據的input，既然我們要把計算拆分到多台機器上，（這裏我們以簡單經典的詞頻統計為例，假設我們要統計兩篇長篇小説的詞頻），map要先把這兩篇長篇小説進行拆分，假設我們是按照章節拆分的，並且每個章節的大小恰好相同（為了便於理解這裏的假設都是非常理想的），將兩篇小説分別劃分為3個章節和2個章節，一共5個章節，然後呢，master就會分配一些worker去領任務，比如派了5個worker分別對5個章節進行詞頻統計，統計完之後得到5個結果保存緩存在硬盤上，這就是一個完整的map（映射，其實本質就是功能性函數的運行，把原始數據通過一些計算轉化為另一些數據）過程，簡單來説就是把一個任務分配給不同的機器執行，接着，我們發現，我們的最終目標是統計兩個長篇小説，此時只是得到了每個章節的詞頻統計結果，那麼，這個時候我們就需要reduce（歸約，簡單來説就是對所有worker的工作進行彙總）來分配機器，讓workers去把剛才5個workers的計算結果進行彙總，比如上圖，分配了兩個workers，一個worker彙總3個map-workers的工作結果，一個worker彙總剩下兩個workers的工作結果，最終將彙總計算的結果保存到本地的兩個文件上；

上述的過程聽起來簡單，但是實現上是非常繁瑣的，很多時候，例如對於詞頻的計算，我們要自己去手動編寫一個詞頻計算的map function，這對於數據處理與分析來説，實在太麻煩了，這就好比你想要去計算某一個特徵的取值情況，通過pandas的value_counts（）功能就可以輕鬆實現，但是現在你要自己寫個func去做統計，我們希望有個更高層更抽象的語言層來描述算法和數據處理流程，於是，就誕生了Hive和pig。Pig是接近腳本方式去描述MapReduce（沒用過），Hive則用的是SQL（hive sql，對於經常寫sql同學來説非常簡單容易上手）。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算，這樣我們就從繁瑣的MapReduce程序中解脱出來。

Hive逐漸成長成了大數據倉庫的核心組件（因為sql本身沒什麼技術門檻，一般的非技術人員也可以）。甚至很多公司的流水線作業集完全是用SQL描述，因為易寫易改，一看就懂，容易維護

但是hive也有一個個問題，Hive底層執行使用的是MapReduce引擎，仍然是一個批處理過程，難以滿足查詢的交互性，比如我們寫一個數據分析報吿，我們想要去統計譬如每個用户分別瀏覽了多少商品或者每個商品被多少用户瀏覽過，當數據量非常大的時候，hive的查詢效率是偏低的，子是又誕生了impala等分佈式交互查詢數據庫，其底層做廠非常多的性能優化大大提升了交互式查詢，數據分析的效率；

再後來，spark的橫空出世支撐了hive on spark和sparksql （也就是我們熱悉的spark dataframe的父集），尤其是spark dataframe，不僅對於sql使用者來説友好，對於pandas的使用者也是較為友好的：

這個時候，一個完整的大數據處理分析的框架就己經躍然紙上丁：

1、底層的mapreduce架構(hadoop）或spark;

2、中層的hive或pig或者在hdfs上跑impala等；

3、上層的hive on spark或是直接使用sparksal

最後，作為小白用户，我們直接可以通過例如sparksql來進行海量數據的快速分析與數據分析報吿甚至是基本的特徵工程等，這個時候，我們實際上已經較好的解決了沒有實施需求的離線問題，後續的模型訓練我們可以通過分佈式的xgb、lgb、tf等框架或者是spark ml等進行模型的訓練

那麼，如果是有實時需求的業務場景呢？比如我們想要儘量讓申請信貨的用户能夠實時得到審批的結果，該怎麼辦？

於是，流(streaning）計算就問世了，storm是最流行的流計算平台，流計算的思路是，如果要達到更實時的更新，我們可以直接在數據流進來的時候就進行相應處理，這和online learning的思想是比較類似的，比如還是詞頻統計的例子，我的數據流是一個一個的詞，我就讓他們一邊流過我就一邊開始統計了

除此之外，針對於不同的場景，有不同的成熟開源的分佈式系統，例如基於hadoop的mahout和基於spark的spark ml， Mahout是hadoop的一個機器學習庫，主要的編程模型是MapReduce; Spark ML則是基於Spark的機器學習，Spark自身擁有MLib作為機器學習庫，不過現在Mahout已經停止接受新的MapReduce算法了，向Spark遷移。

MLlib基於RDD，天生就可以與Spark SQL、 Graphx、spark Streaming無縫集成，非常的方便；

最後是關於這麼多大數據組件的集中管理，這裏貼出網上的一個很有思的例子：有了這麼多亂七八糟的工具，都在同一個集羣上運轉，大家需要互相尊重有序工作。所以另外一個重要組件是，調度系統。現在最流行的是Yarn。你可以把他看作中央管理，好比你媽在廚房監工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。只要大家都服從你媽分配，那大家都能愉快滴燒菜。你可以認為，大數據生態圈就是個廚房工具生態圈。為了做不同的菜，中國菜，日本菜，法國菜，你需要不同的工具。而且客人的需求正在複雜化，你的廚具不斷被髮明，也沒有一個萬用的廚具可以處理所有情況，因止他會變得越來越複雜。