Thinking in BigDate（九）大資料hadoop叢集下離線資料存放區和挖掘架構

前序：

       2月23日，在中關村，海澱黃莊丹棱街SOHO大廈好未來會議室，hadoop專家吳超大俠，針對hadoop初學者的概念梳理，以及簡單介紹針對日誌分析案例。在回來的第二天，趕上了這次草根面對面交流。說是草根，像我這樣的是草根，其餘的都是大俠。在這一次交流中，主要是針對初級想瞭解hadoop的人員的，主要講的內容，在我的上一篇Thinking in BigDate（八）大資料Hadoop核心架構HDFS+MapReduce+Hbase+Hive內部機理詳解 部落格中基本都有所涉及。這裡我們又為什麼又費言說這麼多，只有一個目的，從這裡你可以獲得擴充你知識的另一個途徑。

       這段時間一直忙著，架構圖的梳理與後期項目該如何開展，以及自己的學習狀況。雖然看上去很簡單的一個架構圖，其實它需要你瞭解其中每一個點。我記得上次July和夏粉來北航講座，July說到一句話：當你把你知道的東西，寫下來，讓人看明白是一種境界；當你能把自己寫下來的東西給人講明白，又是另一種境界。在這個過程中，我們都需要曆練。雖然自己寫部落格並沒有太長的時間，但是我深知吳超大俠、July的痛苦，說明白點，部落格就是一件太耽誤時間的事，而選擇權在你手上。就這樣還有人一直傻二愣的的再寫。

基於hadoop叢集下海量離線資料存放區和挖掘分析架構：

       架構圖採用主流的Hadoop+Hive+Hbase叢集架構平台。最簡單的利用，包含了基本的基於hadoop叢集下的日誌分析過程。但此架構圖，又不僅局限於簡單的基於日誌資料處理。我們可以把它定位到，把基於傳統資料採礦技術，移植到Hadoop叢集平台上，提高計算效率，節省時間，降低開發成本。說到這裡就必須多說一點，傳統資料採礦和基於Hadoop叢集下的資料分析過程有什麼區別？

       我想這也是一直困擾大家的問題。旁人看熱鬧，行人看門道。把基於傳統資料採礦的過程移植到hadoop叢集中，好在哪兒？問題在於：傳統資料採礦過程，基於單機或放在記憶體比較大的小型機上去跑資料，去建模型，7-8GB的資料，在參數不多的情況下，建模的過程，我想稍微熟悉建模過程的人，會有一個時間上的概念，10幾個小時或者上天已經是好的了。太耗時了，太耽誤時間了。而當資料越來越大，就面臨這一瓶頸。自此，分布式的概念提出來了，分布式出來了，自然就會引入叢集的概念。叢集就是一群機器處理一個問題，或叢集中不同的機器處理不同階段的問題。除此時間問題之外，還有什麼優勢？其實，也一直困擾著我，我一有機會就會向那些大牛去請教，還有什麼優點，他們也是堂堂不知其所言。

      這裡再多說兩句還有什麼優勢：1、非關係型資料（Nosql），類記錄檔資料。2、即時性。但這兩點又不是傳統資料採礦的核心。其實，一個時間節省的問題，就足可以為之探究了。

      這裡沒有採用現主流基於記憶體計算引擎Spark叢集架構。後續如有涉及，再細討論。

1、資料存放區層

     功能：資料收集、處理、儲存、裝載

     包含：Data Integration、ETL、資料倉儲

     工具：Sqoop、Flume、Kettle、Hive。

     簡介：

      (1)Sqoop：資料收集工具，用於把相關資料匯入Hadoop叢集中。

      (2)Flume:分布式日誌收集工具，適用於網站、伺服器等記錄檔的收集。

      (3)Kettle：一種開源免費的ETL工具。還有很多收費的ETL工具。在中國這都免費。

      (4)Hive：基於Hadoop叢集架構下的資料倉儲的建立工具。主要是為了，類SQL與SQL之間的轉換。

       資料存放區層，是前提。而前提的前提，就是資料的收集與ETL，在前面的部落格中提到前期資料搜集和ETL過程可能會佔整個項目工程的75%甚至以上的時間。可見，前期的工作多麼的重要，沒有前面，後面無從談起。

2、叢集架構層

      功能：離線資料分析系統

      核心：大資料存放區和叢集系統：Hive0.12.0 & Hadoop2.2.0 & HBase0.96.1

      簡介：

       (1)Hadoop:開源叢集分布式架構平台。2.2.0為最新版本。

       (2)HBase：面向列的分散式資料庫，適合構建低並發延時性資料服務系統。

       (3)HDFS：Distributed File System，是海量資料存放區的標準。

       叢集架構層：說的是，也是叢集平台的核心。我們常說的搭建hadoop平台，一般指的就是Hive+Hadoop+HBase。這需要自己去按照說明文檔，在linux下搭建平台。其實，在我們配置Hadoop相關係統檔案的時候，我們已經可以測試資料了，我們可以通過上傳一個不是很大資料，測試hadoop是否運行成功。HBase+Hive是為大資料處理準備的。這裡不介紹如何去配置系統檔案，綜合網上相關的文檔，配置安裝應該都沒有問題。

      目的在於，梳理一下整個大資料採礦整體的流程。在腦海裡梳理一下，有一張架構圖。

3、分散式運算引擎層

     功能：針對密集型資料計算

     核心：Yarn、MapReduce

     簡介：

      (1)Yarn：分布式資源管理架構，也可以理解為管理類MapReduce這種分散式處理平台的架構。

      (2)Map/Reduce：基於密集型離線資料分析架構。這區別於現在很火的基於記憶體資料處理的Spark架構。

       這裡可能涉及到資料處理的過程，在上一篇部落格中，談到MapReduce的內部機理。其實就是把資料分塊分發到不同機器上並發處理資料，最後把處理完的資料整合到一起，輸出。其實看似簡單，細分到每一塊，我們就會看到，資料是如何在單機上去走的。這裡逃不掉到的是資料還是一行行的讀取，你也沒有別的辦法。這裡你要做的工作就是，去寫MapReduce函數，這個是根據資料的類型，業務需求，去寫相應的函數。

 

4、演算法合成層

     功能：整合資料採礦演算法

     核心：HiveQL、R語言、Mahout

     簡介：

      (1)HiveQL：上面提到，類SQL，這也是選擇Hive的原因，有利於傳統資料庫操作員到NoSql資料庫操作之間的轉型。

      (2)R語言：主要用與統計分析、繪圖的語言等。提供了一套完整的資料處理、計算和製圖軟體系統，也為下面的資料視覺效果提供了前提。

      (3)Mahout：主要是整合機器學習等相關經典演算法的實現。可以更有效提供，挖掘資料背後隱藏的規律。

       演算法合成層，其實是資料採礦，資料規律之間挖掘的核心。通過這些經典的或最佳化過的演算法，為我們在海量資料面前，挖掘出有用價值的資料提供了方面。如果大家，瞭解一些資料採礦和機器學習的一些內容的話，我們會知道兩個概念：一、訓練集。二、測試集。這裡我們也會更多的提到建模，而構建模型的兩個範疇就是，構建訓練集合測試集的過程。訓練集，是把未經處理資料抽取一部分用來構建模型，找到其中的一些規律。然後用剩下的資料，當測試集，去測試模型構建的準確率。其實更深入討論一下，我們就會面臨一個業界頭疼的問題，準確率問題。因為我們所有的測試都是針對線下的資料去構建模型，這種方式對離線資料分析沒有太大的影響，原因在於：離線資料，是不可變的，在很大情況下滿足，在訓練集測試的規律滿足測試集的規律。而在更多的情況下，如基於即時線上資料的機器學習，這要求就非常的高了。這就會遇到一個通用的詬病：如何解決線下測試準確了極高的模型，如何保證線上上準確率卻很差。他們給出的辦法：就是沒有辦法，調參數，不斷的測試，提高準確率。

       這裡不再多說，先梳理整個架構。

5、資料視覺效果層

       其實上面已經講到了一個可視化整合工具，就是R語言。當我們把通過Hadoop叢集，業務梳理後的資料再寫回HDFS中時候，這些資料有些已經是有規律的資料了。有些資料是提取出來製作報表、餅圖或柱狀圖等。其實對上面已經處理完的資料還有下一步的處理過程就是：把HDFS或Hive資料倉儲中的資料匯入傳統關係型資料庫。用傳統視覺化檢視進行展示，這是目前很主流的方法。當資料匯入傳統關係型資料庫中，最後一步就是BI，傳統BI。大家都在忙著吵大資料概念，可不要把傳統的優勢忘記，不然也只是丟了西瓜，撿了芝麻。

       說了這麼多廢話，其實就是為了引出，基於傳統離線資料存放區和挖掘架構圖。這是為我們自己接下來的工作，提前梳理好要做的內容。

 

 

（自己梳理的過程，轉載請標明出處）

總結：

       最近一段時間，一直在整理技術核心架構，一方面為寫策劃方案；一方面是為了接下來學習打下基礎。上面的架構圖基本已經涉及基於傳統資料採礦移植到Hadoop叢集的一些流程。為不清楚或初學者提供一個解決方案，知道一個流程應該從哪方面入手。對於熟悉整個流程的Hadoop工程師來說，可能上面的工作是多此一舉。但是能整理出來，在時間上的消費，為後來者提供一個解決方案，自是一件好事。

       自己也是作為一個初學者。還有時間，也願意抽出時間，把最近一段時間的學習整理一下，是為了積累。如有不足，後續改正。

CopyrightBUAA