大數據全體系年終總結

　　到年末了，想着總結下全部知識點好了~今年應用的知識點仍是不少的~

　　

Hadoop生態圈：

　　一、文件存儲固然是選擇Hadoop的分佈式文件系統HDFS，固然由於硬件的告訴發展，已經出現了內存分佈式系統Tachyon，不管是Hadoop的MapReduce,Spark的內存計算、hive的MapReuduce分佈式查詢等等均可以集成在上面，而後經過定時器再寫入HDFS，以保證計算的效率，可是畢竟尚未徹底成熟。

　　二、那麼HDFS的文件存儲類型爲SequenceFile,那麼爲何用SequenceFile呢，由於SequenceFile文件是Hadoop用來存儲二進制形式的key-value對而設計的一種平面文件,可以加速MapReduce文件的讀寫。可是有個問題，SequenceFile文件並不保證其存儲的key-value數據是按照key的某個順序呢存儲的，同時不支持append操做。

　　　 固然，若是選擇Spark的話，文件存儲格式首選爲列式存儲parquet，由於一個Parquet文件是由一個header以及一個或多個block塊組成，以一個footer結尾。header中只包含一個4個字節的數字PAR1用來識別整個Parquet文件格式。文件中全部的metadata都存在於footer中。footer中的metadata包含了格式的版本信息，schema信息、key-value paris以及全部block中的metadata信息。footer中最後兩個字段爲一個以4個字節長度的footer的metadata,以及同header中包含的同樣的PAR1。不像sequence files以及Avro數據格式文件的header以及sync markers是用來分割blocks。Parquet格式文件不須要sync markers，所以block的邊界存儲與footer的meatada中，查詢效率很是快。

　　三、zookeeper的做用幫助Yarn實現HA機制，它的主要做用是：

　 （1）建立鎖節點，建立成功的ResourceManager節點會變成Active節點，其餘的切換爲StandBy.

　 （2）主備切換，當Active的ResourceManager節點出現異常或掛掉時，在zookeeper上建立的臨時節點也會被刪除，standy的ResourceManager節點檢測到該節點發生變化時，會從新發起競爭，直到產生一個Active節點。（這裏會有個腦裂問題，後續說明），那麼zookeeper的參數包含在zoo.cfg中（具體參考本博客中的zookeeper配置）

　　　　

　　四、 Yarn組件：這個可就大了，運行在獨立的節點上的 ResourceManager和NodeManager一塊兒組成了yarn的核心，構建了整個資源管理平臺。ResourceManager提供應用程序的調度， 每一個應用程序由一個ApplicationMaster管理，以 Container的形式請求每一個任務的計算資源。 Container由ResourceMangaer調度，由每一個節點的 NodeManager上進行本地的管理。 全部MapReduce以及Spark的Job都是提交給Yarn進行資源申請。（具體參考博客Hadoop on Yarn各組件詳細原理），那麼權限與資源控制主要依賴於Yarn的標籤機制，能夠控制好比Spark做業在Spark的資源隊列，Hadoop做業在Hadoop的資源隊列。

　　

　　五、 Hive組件：Hive的ETL主要用於數據的清洗與結構化，可從每日將傳統數據庫中導出的文件，建立一個Web工程用來讀入文件，使用JDBC的方式鏈接HiveServer2，進行數據的結構化處理。這裏有一些加快效率可是會佔用更多資源的參數，好比set hive.exec.parallel=true,該參數會讓那些存在併發job的sql運行的更快，但同時消耗更多的資源，或者set hive.exec.parallel.thread.number,加大並行度，但會佔用更多的map和reduce的資源。

　　六、 Hbase組件：HBase的服務器體系結構聽從簡單的主從服務器架構，它 由HRegion服務器(HRegion Service)羣和HBase Master服務器(HBase Master Server)構成。Hbase Master服務器負責管理全部的HRegion服務器，而Hbase中全部的服務器是 經過Zookeeper來進行協調，並處理HBase服務器運行期間可能遇到的錯誤的。那麼從應用上來講，hbase使用的場景更適用於，例如流處理中的日誌記錄的單條記錄追加，或是單條結果的查詢，但對於須要表關聯的操做，hbase就變得力不從心了，固然能夠集成於hive，但查詢效率嘛。。。

　　　 Hbase最重要的是rowkey的設計，怎樣預分區可以讓數據均勻散列在各個節點。同時，要注意的是使用hbase過濾器的話，依舊會scan全表。

　

　　七、 Hue組件：主要是前臺的查詢，它支持不少可視化的展現啊，sql查詢啊。方便通常的數據分析人員使用。

 

　　八、 Ambari組件：各個組件均可以集成於它，屬於一個統一的監控軟件，包括安裝部署，參數調整均可以在Ambari界面完成。

　　

Spark的生態圈組件：

　　咱們選用的是集成於Hadoop的spark on Yarn模式：

　　

　　下面一一介紹Spark On Yarn的各組件：

　　一、 SparkSql組件：從Spark 1.0版本起，Spark開始支持Spark SQL，它最主要的用途之一就是可以直接從Spark平臺上面獲取數據。而且Spark SQL提供比較流行的 Parquet列式存儲格式以及從 Hive表中直接讀取數據的支持。

　　以後，Spark SQL還增長了對JSON等其餘格式的支持。到了Spark 1.3 版本Spark還可使用SQL的方式進行DataFrames的操做。咱們經過JDBC的方式經過前臺業務邏輯執行相關sql的增刪改查，經過遠程鏈接linux對文件進行導入處理，使項目可以初步支持Spark平臺，現現在已支持Spark2.0.2版本。

　　    它擁有本身的sql解析引擎 Catalyst,提供了提供瞭解析（一個很是簡單的用Scala語言編寫的SQL解析器）、 執行（Spark Planner,生成基於RDD的物理計劃）和 綁定（數據徹底存放於內存中）。使用ThriftServer鏈接後臺SparkSQL,它是一個 JDBC/ODBC接口，經過配置 Hive-site.xml，就可使前臺用JDBC/ODBC鏈接ThriftServer來訪問SparkSQL的數據。ThriftServer經過 調用hive元數據信息找到表或 文件信息在hdfs上的具體位置，並經過Spark的RDD實現了hive的接口。加快前臺的查詢或者限制後臺ETL數據清洗時所佔用的資源與內存數量。

 

　　二、 SparkStreaming組件：SparkStreaming 接收實時輸入數據流並將它們 按批次劃分，而後交給Spark引擎處理 生成按照批次劃分的結果流。SparkStreaming提供了表示 連續數據流的、 高度抽象的被稱爲離散流的 Dstream,可使用 kafka、Flume和Kiness這些數據源的輸入數據流建立 Dstream,也能夠在其餘Dstream上使用map、reduce、join、window等操做建立Dsteram。Dstream本質上呢，是 表示RDD的序列。 那麼它的適用場景在於準實時的日誌分析，或數據接入處理。

　　

　　三、 SparkR: 我表示。。沒用過~~~~啊哈哈哈~（後續學習）

 

　　四、 SparkML:包含用於機器學習或數據分析的算法包。在Spark後臺批處理代碼中，或SparkStreaming中均可以集成，用於更多的數據分析。（後續學習）

 

總結：

　　整個Hadoop生態圈與Spark生態圈的批處理應用流程就能夠整理出來了：

　　一、首先由每日從傳統數據庫中導出的數據文件，由Spark後臺處理代碼進行數據的處理，或由用Java編寫的前臺代碼鏈接thrift進行數據的結構化。

　　二、經過Spark鏈接mysql數據表，進行後臺數據處理生成各平臺須要的數據類型與種類導入Hbase、Redis或生成Hive表等等。

　　三、由數據分析人員運用R或ive或SparkR、ML進行數據分析。

　　四、sparkStreaming經過接受kafka的數據，進行數據處理或分析，也能夠經過監聽HDFS文件目錄來進行數據的定時處理。

 

實時項目組件：

　　實時項目呢，主要包含的組件有Storm、Redis、Kafka、Jetty、Netty,keepalive,nignx等。（圖木有畫哈哈），那麼下來一一進行說明。

　　一、 Redis: Redis包括集羣模式、哨兵模式、由Twemproxy實現的代理模式。主要服務於實時系統的數據加載，而且將大部分系統配置信息都存入Redis，，走全內存可使每條消息的延遲下降。由於Redis沒有分佈式鎖，可使用setnx標誌位來實現分佈式鎖的功能。

　　二、 jetty：輕量級的servlet,可部署多份，每份裏面接入網管發送的數據，數據的存儲可存儲與BlockingQueue中，由多個線程拉取數據，進行數據的預處理。

　　三、 ngnix與 keepalive:keepalive的做用主要用於設置虛擬IP，ngnix進行消息的負載均衡，發送至各服務器的jetty。

　　四、 kafka: Kafka is a distributed,partitioned,replicated commit logservice。它提供了相似於JMS的特性，可是在設計實現上徹底不一樣，此外它並非JMS規範的實現。 kafka對消息保存時根據Topic進行歸類，發送消息者成爲Producer,消息接受者成爲Consumer,此外kafka集羣有多個kafka實例組成， 每一個實例(server)成爲broker。不管是kafka集羣，仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。

　　

　　    一個Topic能夠認爲是 一類消息，每一個topic將被分紅 多個partition(區),每一個partition在存儲層面是 append log文件。任何發佈到此partition的消息都會被直接 追加到log文件的尾部，每條消息在文件中的位置稱爲 offset（偏移量），offset爲一個long型數字，它是惟一標記一條消息。它惟一的標記一條消息。kafka並無提供其餘額外的索引機制來存儲offset，由於在 kafka中幾乎不容許對消息進行「隨機讀寫」。

　　　  kafka和JMS（Java Message Service）實現(activeMQ)不一樣的是:即便消息被消費,消息仍然不會被當即刪除.日誌文件將會 根據broker中的配置要求, 保留必定的時間以後刪除;好比log文件保留2天,那麼兩天後,文件會被清除,不管其中的消息是否被消費.kafka經過這種簡單的手段,來釋放磁盤空間,以及 減小消息消費以後對文件內容改動的磁盤IO開支.

　　　 那麼繼續咱們的流程，又Jetty接入的消息，發送至不一樣的kafka主題，供下面storm進行消費。

　　五、 Storm:主要的編程概念: spout、 blot和 topology,咱們須要根據數據的併發量來決定啓動多少個worker和calc,首先由Spout進行消息的接入，進行數據預處理與加載，剛纔咱們說了，走全內存，直接走Redis，可是若是Redis掛掉了怎麼辦呢，那麼就備選用hbase~blot中實現主要的業務邏輯，消息的封裝啊。 這裏須要注意的是，咱們不要把全部類型的事件都寫入一個topo，那麼消息延遲的機率會很大，對於不一樣的事件進行不一樣消息的封裝處理。

　　

總結：

　　對於整個實時項目須要注意的就是數據的封裝與解析，怎樣提升效率，怎樣可以讓各個模塊兒解耦，走全內存、日誌收集及問題等等。

 輔助組件：

一、 Ansible：ansible是新出現的自動化運維工具，基於Python開發，集合了衆多運維工具（puppet、cfengine、chef、func、fabric）的優勢，實現了 批量系統配置、 批量程序部署、 批量運行命令等功能。

二、 ganglia:Ganglia是UC Berkeley發起的一個開源集羣監視項目，設計 用於測量數以千計的節點。Ganglia的核心包含 gmond、 gmetad以及 一個Web前端。主要是用 來監控系統性能，如：cpu 、mem、硬盤利用率， I/O負載、網絡流量狀況等，經過曲線很容易見到每一個節點的工做狀態，對合理調整、分配系統資源，提升系統總體性能起到重要做用。