hadoop離線資料儲存和挖掘架構
阿新 • • 發佈：2019-01-04
前序：
當你把你知道的東西，寫下來，讓人看明白是一種境界；當你能把自己寫下來的東西給人講明白，又是另一種境界。在這個過程中，我們都需要歷練。基於hadoop叢集下海量離線資料儲存和挖掘分析架構：
架構圖採用主流的Hadoop+Hive+Hbase叢集架構平臺。最簡單的利用，包含了基本的基於hadoop叢集下的日誌分析過程。但此架構圖，又不僅侷限於簡單的基於日誌資料處理。我們可以把它定位到，把基於傳統資料探勘技術，移植到Hadoop叢集平臺上，提高計算效率，節省時間，降低開發成本。說到這裡就必須多說一點，傳統資料探勘和基於Hadoop叢集下的資料分析過程有什麼區別？
我想這也是一直困擾大家的問題。旁人看熱鬧，行人看門道。把基於傳統資料探勘的過程移植到hadoop叢集中，好在哪兒？問題在於：傳統資料探勘過程，基於單機或放在記憶體比較大的小型機上去跑資料，去建模型，7-8GB的資料，在引數不多的情況下，建模的過程，我想稍微熟悉建模過程的人，會有一個時間上的概念，10幾個小時或者上天已經是好的了。太耗時了，太耽誤時間了。而當資料越來越大，就面臨這一瓶頸。自此，分散式的概念提出來了，分散式出來了，自然就會引入叢集的概念。叢集就是一群機器處理一個問題，或叢集中不同的機器處理不同階段的問題。除此時間問題之外，還有什麼優勢？其實，也一直困擾著我，我一有機會就會向那些大牛去請教，還有什麼優點，他們也是堂堂不知其所言。
這裡再多說兩句還有什麼優勢：1、非關係型資料（Nosql），類日誌檔案資料。2、實時性。但這兩點又不是傳統資料探勘的核心。其實，一個時間節省的問題，就足可以為之探究了。
這裡沒有采用現主流基於記憶體計算引擎Spark叢集架構。後續如有涉及，再細討論。
1、資料儲存層
功能：資料收集、處理、儲存、裝載
包含：資料整合、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：分散式檔案系統，是海量資料儲存的標準。
叢集架構層：說的是，也是叢集平臺的核心。我們常說的搭建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工程師來說，可能上面的工作是多此一舉。但是能整理出來，在時間上的消費，為後來者提供一個解決方案，確實一件好事。長按識別關注我們，每天都有技術和精彩內容分享哦！~