大資料線上分析處理的特點

• . 資料來源源不斷的到來；
• 資料需要儘快的得到處理，不能產生積壓；
• 處理之後的資料量依然巨大，仍然後TB級甚至PB級的資料量；
• 處理的結果能夠儘快的展現；

以上四個特點可以總結為資料的收集->資料的傳輸->資料的處理->資料的展現。其中資料的處理一般涉及資料的聚合，資料的處理和展現能夠在秒級或者毫秒級得到響應。

針對這些問題目前形成了 Flume  +  kafka  +  Storm / Spark  +  Hbase / Redis 的技術架構

 

Flume介紹

Flume 專注於大資料的收集和傳輸，用來解決線上分析處理特點，資料來源源不斷的到來的問題。類似的大資料開源系統有 Logstash  和 Fluentd 。

三者區別如下：

• Logstash 主要 和 Elasticsearch 、 Kibana  結合使用，俗稱 ELK 框架； Logstash 主要負責將資料來源的資料轉換成 Elasticsearch  認識的索引結構供 Kibana 查詢
• Fluentd 當前的使用者已經很少，逐漸被功能更強大的 Flume 代替了
• Flume 能夠支援多種資料來源並且輸出到多種輸出源，並且支援多種格式的資料

 

架構圖

架構圖中 Source  用來連線輸出源，Sink 用來連線輸出源，Channel 是 Flume 內部資料傳輸通道(主要包括 Memory Channel 和 File Channel)。

其中 Source 連線的輸入源可以但不限於：

• Avro
• Thrift 
• Exec(unix command  output)
• JMS (Java Message Service)
• Kafka
• NetCat (可以使用 nc –lk port 測試)
• Syslog
• Custom 

 

其中 Sink 連線的輸出源可以但不限於：

• Hdfs
• Hive 
• Avro
• Thrift 
• File Roll
• Hbase
• ElasticSearch (提供的功能和 Logstash 一樣，但是不如Logstash 豐富，大多數時候需要自己構造 ElasticSearch  文件和索引)
• Kafka
• Custom

 

Flume 也能多個 Agent 相連形成 Agent 鏈

Flume 也能多個 Agent 進行資料來源的合併

 

Spark 和 Storm 介紹

Spark (Spark Streaming) 和  Storm 專注於將資料按照時間視窗進行聚合和處理。用來解決線上分析處理特點，資料需要儘快的得到處理的問題。所以經常被稱作流式處理框架。

兩者的區別如下：

• Storm  提供比 Spark 更加實時的流式處理；
• Spark 提供比Storm更加多的服務，Spark 逐漸已經形成類似 Hadoop 的生態圈了。

 

目前Spark 生態圈包含的生態系統如下(而且還正在逐漸的壯大中):

目前 Spark 有三種叢集管理模式:

• Standalone：一種簡單的叢集管理，其包括一個很容易搭建叢集的Spark；
• Apache Mesos ：一種通用的叢集管理,可以執行Hadoop MapReduce和服務應用的模式；
• Hadoop YARN : Hadoop2.0中的資源管理模式。

其中第二種和第三種都是使用 Spark 做任務管理和排程，Mesos 和 Yarn 做資源管理和排程

Spark 工作元件

 

Strom 結構圖

Storm 的工作元件:

• topology：一個拓撲是一個個計算節點組成的圖，每個節點包換處理的邏輯，節點之間的連線表示資料流動的方向；
• spout：表示一個流的源頭，產生tuple；
• bolt:   處理輸入流併產生多個輸出流，可以做簡單的資料轉換計算，複雜的流處理一般需要經過多個bolt進行處理。

 

Strom  拓撲topology的組成

 

HBase介紹

HBase 專注於大資料儲存和提供查詢，用來解決線上分析處理特點，資料經過處理後資料量依然巨大的儲存和展現問題。類似的大資料開源系統有 Cassandra 。

兩者區別如下：

• Cassandra  滿足可用性和分割槽容忍性，允許資料的不一致(不同客戶端可能看到不一樣的情況)、 Cassandra  提供了類似 SQL 的  CQL 查詢語言，查詢方便；
• HBase 滿足一致性和分割槽容忍性，擁有強大的記錄集一致性。HBase不支援 SQL 需要使用者部署第三方服務來支援 SQL (如 Apache Phoenix)；

 

架構圖

組成部件說明：

• Client：使用HBase RPC機制與HMaster和HRegionServer進行通訊；
• Zookeeper:  儲存hbase:meta 表等元資料資訊；HRegionServer把自己以Emphedral方式註冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康狀況；Zookeeper避免HMaster單點問題；
• HMaster:   主要負責Table和Region的管理工作:

    管理使用者對錶的增刪改查操作

    管理HRegionServer的負載均衡，調整Region分佈

    Region Split後，負責新Region的分佈

    在HRegionServer停機後，負責失效HRegionServer上Region遷移

 

• HRegionServer：HBase中最核心的模組，主要負責響應使用者I/O請求，向HDFS檔案系統中讀寫資料：

   HRegionServer管理一些列HRegion物件；

   每個HRegion對應Table中一個Region，HRegion由多個HStore組成；

   每個HStore對應Table中一個Column Family的儲存；

 

客戶端寫資料過程圖

 

Region的 Split 和 StoreFile  的 Compact:

Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增長到一定閾值 -> 觸發Compact合併操作 -> 多個StoreFile合併成一個StoreFile，同時進行版本合併和資料刪除 -> 當StoreFiles Compact後，逐步形成越來越大的StoreFile -> 單個StoreFile大小超過一定閾值後，觸發Split操作，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer 上，使得原先1個Region的壓力得以分流到2個Region上。
由此過程可知，HBase只是增加資料，有所得更新和刪除操作，都是在Compact階段做的，所以，使用者寫操作只需要進入到記憶體即可立即返回，從而保證I/O高效能；

 

 

大資料離線處理和常用工具

大資料離線處理特點

• 資料量巨大且儲存時間長；
• 在大量資料上進行復雜的批量運算；
• 資料在計算之前已經完全到位，不會發生變化；
• 能夠方便的查詢批量計算的結果；

不像線上計算當前呈現的各種框架和架構，離線處理目前技術上已經成熟，大家使用的均是:  使用 Hdfs  儲存資料，使用 MapReduce  做批量計算，計算完成的資料如需資料倉庫的儲存，直接存入 Hive , 然後從Hive 進行展現。

 

Hdfs 介紹

Hdfs 是一種分散式檔案系統，和任何檔案系統一樣 Hdfs 提供檔案的讀取，寫入，刪除等操作。Hdfs 是能夠很好的解決離線處理中需要儲存大量資料的要求。Hdfs和本地檔案系統的區別如下：

• Hdfs 不支援隨機讀寫；
• Hdfs 是分散式檔案系統，支援資料多備份；

Hdfs 多備份資料存放策略： 第一個副本放在和client所在的node裡（如果client不在叢集範圍內，則這第一個node是隨機選取的，當然系統會嘗試不選擇哪些太滿或者太忙的node）；第二個副本放置在與第一個節點不同的機架中的node中（隨機選擇）；第三個副本和第二個在同一個機架，隨機放在不同的node中。如果還有更多的副本就隨機放在叢集的node裡。

 

架構圖

 

客戶端讀取資料流程圖

客戶端寫入資料流程圖

MapReduce 介紹

 

MapReduce 是一種分散式批量計算框架，分為 Map 階段和 Reduce 階段。 MapReduce  能夠很好的解決離線處理中需要進行大量計算的要求。 MapReduce 從出現到現在經歷了第一代 MapReduce  v1 和 第二代 MapReduce  Yarn。

Yarn 框架相對於老的 MapReduce 框架有以下優勢:

• 減小了 JobTracker的資源消耗，之前JobTracker  既負責資源分配，也負責任務監控，Yarn 將這兩項任務分別交給了 ResourceManager  和 ApplicationMaster  ，減少了之前 JobTracker 單點失敗的風險；
• MRv1 將資源分別 Map slot 和 Reduce slot 而且相互之前不能使用，Yarn將資源分別CPU、記憶體，相互之前能夠通用，更加靈活也更加合理；

 

架構圖

Yarn 框架各個元件的功能:

• ResourceManager: 負責資源的排程，由兩個元件組成:    排程器和應用管理 ApplicationsManager (ASM) ；
• ApplicationsManager (ASM) :主要用於管理AM；
• ApplicationMaster (AM) :主要用於管理其對應的應用程式，如MapReduce作業，DAG作業等；
• NodeManager  (NM):主要用於管理某個節點上的task和資源；
• Container :容器中封裝了機器資源，如記憶體，CPU, 磁碟，網路等，每個任務會被分配一個容器，該任務只能在該容器中執行，並使用該容器封裝的資源

 

Hive 介紹

Hive 是一種資料倉庫，Hive 中的資料儲存於檔案系統( 大部分使用 Hdfs)，Hive 提供了方便的訪問資料倉庫中資料的  HQL 方法，該方法將 SQL 翻譯成MapReduce。  能夠很好的解決離線處理中需要對批量處理結果的查詢。

Hive 將元資料存放在 metastore 中, Hive 的 metastore 有三種工作方式:

• 內嵌Derby方式:   在同一時間只能有一個程序連線使用資料庫；
• Local方式 :   使用本地 Mysql 資料庫儲存元資料；
• Remote方式:  使用遠端已經搭建完成的 Mysql 資料庫儲存元資料;

 

架構圖

OLAP 和 OLTP處理和常用工具

OLAP 和 OLTP 特點

OLAP (聯機分析處理)  和 OLTP (聯機事務處理) 在查詢方面的特點：

• OLTP  單次查詢返回資料量小，但是經常會涉及伺服器端簡單的聚合操作，要求查詢響應速度快，一般應用於線上處理；
• OLAP 單次查詢返回資料量巨大，伺服器端進行的處理複雜，經常包含上卷(從細粒度資料向高層的聚合)、下鑽(將彙總資料拆分到更細節的資料)類似的操作；

 

Elasticsearch 介紹

Elasticsearch  是一種基於 文件 的 底層使用 Lucene  進行檢索的分散式NoSql 叢集。Elasticsearch  檢索大量文件類資料響應速度很快，更夠為 線上 OLTP 提供支援。類似的大資料開源系統有 Solr。

兩者的區別如下

• Elasticsearch是分散式的。不需要其他元件，分發是實時的，被叫做”Push replication” 並且完全支援 Apache Lucene 的接近實時的搜尋；
• 建立索引時，搜尋效率下降，實時索引搜尋效率不高；
• 隨著資料量的增加，Solr的搜尋效率會變得更低，而Elasticsearch卻不會有明顯變化

所以， Solr的架構不適合實時搜尋的應用，也就不適合 OLTP 處理

 

架構圖

Impala 介紹

Impala 是 Cloudera 公司主導開發的新型查詢系統，它提供 SQL 語義，能查詢儲存在 Hadoop 的 Hdfs 和 Hbase 中的 PB 級大資料。已有 的 Hive 系統雖然也提供了 SQL 語義，但由於 Hive 底層執行使用的是 MapReduce 引擎，仍然是一個批處理過程，難以滿足查詢的互動性。相比之 下，Impala 的最大特點就是它的快速。

所以， Impala 使得在 TB 甚至 PB 級資料上進行  OLTP  分析成為可能。

 

架構圖

Impala 主要通過以下兩種技術實現快速查詢大量資料：

• 實現了巢狀型資料的列儲存；
• 使用了多層查詢樹，使得任務可以在數千個節點上並行執行和聚合結果；

列儲存可以減少查詢時處理的資料量，有效提升 查詢效率。多層查詢樹則借鑑了分散式搜尋引擎的設計，查詢樹的根節點負責接收查詢，並將查詢分發到下一層節點，底層節點負責具體的資料讀取和查詢執行，然後將結果返回上層節點。

 

Kylin 介紹

Kylin 是由國人作為主要貢獻者的一個旨在對 Hadoop 環境下分析流程進行加速、且能夠與 SQL 相容性工具順利協作的解決方案，目前 Kylin 已經成功將SQL介面與多維分析機制（OLAP）引入 Hadoop，旨在對規模極為龐大的資料集加以支援。

Kylin 能夠在大資料分析領域實現以下各項特性: 

• 規模化環境下的極速 OLAP 引擎: 削減 Hadoop 環境中處理超過百億行資料時的查詢延遲時間；
• Hadoop上的 ANSI SQL 介面:  Kylin 能夠在 Hadoop 之上提供 ANSI SQL 並支援大部分 ANSI SQL查詢功能；
• 利用 OLAP cube（立方體）對數百億行資料進行查詢；

 

架構圖

 

Kylin 的大體設計思路：

• 從Hive當中讀取資料（這些資料被儲存在HDFS之上）；
• 執行Map Reduce任務以實現預計算 ；
• 將cuba資料儲存在HBase當中 
• 利用Zookeeper進行任務協調