企業級大資料處理方案-02.環境決定需求、效能決定選型

標籤：

      上講，講述了大概九種的技術種類以及他們的領域。那麼既然有吃飯的，那就必須有做飯的。因此大資料技術結構的選型，必須有的組成部分至少三種（來源、計算、儲存）

最簡單的資料處理架構：

最少單元的資料處理方案，當然這個不是最好的，為什麼呢，問題：

1.串流資料（Streaming）時，資料量小時，資料存放區到HDFS中，20M或者100K，這種情況是有的。這種計算結果的儲存極大浪費了儲存空間。HDFS不適用於大批量小檔案的儲存，（只是不適用，不是不能）

2.資料量大時，資料處理不過來（receiver資料接收不過來，崩了，那行我起上幾個receiver不就行了，那萬一資料量忽大忽小咋辦，就挑戰你程式極限，咋辦？receiver多了浪費，少了不行，沒有最優解）

鑒於上面兩種問題，怎麼辦？（這說明上述技術結構不行，那就改），我們學習IO時，有封裝管道，大管套小管，相當於有了個緩衝池，效率就高了，鑒於此，我們給技術分塊中間加個緩衝層（哪個技術能滿足要求呢？那當然是訊息佇列了）

為了提高資料的大小不一，我們需要kafka做資料緩衝層

其資料處理結構如：

    技術結構成為這種形式，這樣控制資料流速，交流kafka管理，合理增加receiver（streaming資料接收點）

    配置kafka設定檔，認為幹預預設配置，可以解決資料扭曲。保證spark叢集資料資料接收衡量。將處理後的資料結果，送到kafka中，緩衝我們的結果資料，資料量有了積累，持久化到HDFS中，來解決小檔案造成儲存空間的浪費。

     這樣就最優了嗎？如果是流式計算的話，這樣確實不錯了，但是也只是不錯而已，為什麼呢，這樣只是對資料處理而已，（資料處理？）當然是，一般而言的資料處理是廣義上的，實際中，資料處理是指資料從資料來源到資料資料可以分析之前的過程稱之為資料處理。資料加工到圖表展示是資料分析階段，這個過程中資料的多維度分析、對比，提取價值曲線，呈現。這在大資料運算中佔一半比重，資料採礦來需要合理的分析才能提取到價值東西，呈現給客戶。這樣似乎和資料選型沒有太明顯的關係？

    乍一看，是沒關係，細想，我們沒有大資料這些新生技術時，傳統的資料分析都是基於mysql和oracle這種關係型資料庫分析的。在實際生產中項目構建時，都是逐步替換的，資料互動的耦合，後台與前端的聯絡，還是資料庫形式資料與資料庫形式資料好整合，是故，假若我們要替代傳統資料庫的大資料記憶體 分布式可擴充的資料庫可以排上用場了。這樣的資料處理結構又在會發生改變，如：

      當然在做離線處理時，我們能將資料直接基記憶體擷取，或者說我們資料來源放在記憶體中，不論是離線計算還是流式計算，都會從磁碟擷取曆史資料做長周期彙總運算時，這些資料在記憶體擷取必然提高運算效率。這樣基於資料的記憶體管理顯得尤為重要,tachyon作為分布式記憶體檔案管理系統，解決了這樣一部分問題，其結構

     這樣資料處理和分析業務，基本完善，最佳化之後大大提高了運行效率，然而大資料另一種處理情境，當日品質非常巨大是，目標資料的搜尋擷取又將成資料處理和分析的瓶頸，怎麼解決這個問題。hBase作為分布式列式儲存的非關係型資料庫來說，他更像資料搜尋引擎，為什嗎？（因為他不是基於列搜尋，而是行健）其搜尋速度也是非常恐懼的，如果你忽略了行健、搞了個UUID，那你來大資料就是來搞笑的，HBase不是資料庫，鑒於此，理解為搜尋引擎更為切且。

  俗話說雙拳難敵四手，好漢架不住人多。所以搜尋的資料量達到百萬級時，速率也會下下降。這樣有沒有提高的辦法呢？有，提高搜尋效的唯一辦法就是索引，索引的好，查詢就更快。為啥呢？（關係型資料到HBase轉型就知道了）我們和利用Lucene和solr建立文本搜尋引擎，做海量資料的索引和模糊結果基於HBase的精確尋找，擷取結果。將大批量的查詢結果變為精確的小批量搜尋，可使HBase的查詢速率更快，也可以給使用者提供海量未經處理資料的搜尋體驗和索引資料處理分析的（精確計算）。其結構

 

      整個大資料處理業務的技術選型，與功能搭配就是如此。你要看到本質搭配，不是說別人用什麼，我用什麼，實際選型，是根據真實業務情境和生產對接情況。

企業級大資料處理方案-02.環境決定需求、效能決定選型