到年底了，想着總結下所有知識點好了~今年應用的知識點還是很多的~
![]()
Hadoop生態圈：
1、文件存儲當然是選擇Hadoop的分佈式文件系統HDFS，當然因爲硬件的告訴發展，已經出現了內存分佈式系統Tachyon，不論是Hadoop的MapReduce,Spark的內存計算、hive的MapReuduce分佈式查詢等等都可以集成在上面，然後通過定時器再寫入HDFS，以保證計算的效率，但是畢竟還沒有完全成熟。
2、那麼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中，查詢效率非常快。
![]()
3、zookeeper的作用幫助Yarn實現HA機制，它的主要作用是：
（1）創建鎖節點，創建成功的ResourceManager節點會變成Active節點，其他的切換爲StandBy.
（2）主備切換，當Active的ResourceManager節點出現異常或掛掉時，在zookeeper上創建的臨時節點也會被刪除，standy的ResourceManager節點檢測到該節點發生變化時，會重新發起競爭，直到產生一個Active節點。（這裏會有個腦裂問題，後續說明），那麼zookeeper的參數包含在zoo.cfg中（具體參考本博客中的zookeeper配置）
4、Yarn組件：這個可就大了，運行在獨立的節點上的ResourceManager和NodeManager一起組成了yarn的核心，構建了整個資源管理平臺。ResourceManager提供應用程序的調度，每個應用程序由一個ApplicationMaster管理，以Container的形式請求每個任務的計算資源。Container由ResourceMangaer調度，由每個節點的NodeManager上進行本地的管理。 所有MapReduce以及Spark的Job都是提交給Yarn進行資源申請。（具體參考博客Hadoop on Yarn各組件詳細原理），那麼權限與資源控制主要依賴於Yarn的標籤機制，可以控制比如Spark作業在Spark的資源隊列，Hadoop作業在Hadoop的資源隊列。
5、Hive組件：Hive的ETL主要用於數據的清洗與結構化，可從每日將傳統數據庫中導出的文件，創建一個Web工程用來讀入文件，使用JDBC的方式連接HiveServer2，進行數據的結構化處理。這裏有一些加快效率但是會佔用更多資源的參數，比如set hive.exec.parallel=true,該參數會讓那些存在併發job的sql運行的更快，但同時消耗更多的資源，或者set hive.exec.parallel.thread.number,加大並行度，但會佔用更多的map和reduce的資源。
6、Hbase組件：HBase的服務器體系結構遵從簡單的主從服務器架構，它由HRegion服務器(HRegion Service)羣和HBase Master服務器(HBase Master Server)構成。Hbase Master服務器負責管理所有的HRegion服務器，而Hbase中所有的服務器是通過Zookeeper來進行協調，並處理HBase服務器運行期間可能遇到的錯誤的。那麼從應用上來說，hbase使用的場景更適用於，例如流處理中的日誌記錄的單條記錄追加，或是單條結果的查詢，但對於需要表關聯的操作，hbase就變得力不從心了，當然可以集成於hive，但查詢效率嘛。。。
Hbase最重要的是rowkey的設計，怎樣預分區能夠讓數據均勻散列在各個節點。同時，要注意的是使用hbase過濾器的話，依舊會scan全表。
7、Hue組件：主要是前臺的查詢，它支持很多可視化的展示啊，sql查詢啊。方便一般的數據分析人員使用。
8、Ambari組件：各個組件都可以集成於它，屬於一個統一的監控軟件，包括安裝部署，參數調整都可以在Ambari界面完成。
Spark的生態圈組件：
我們選用的是集成於Hadoop的spark on Yarn模式：
下面一一介紹Spark On Yarn的各組件：
1、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數據清洗時所佔用的資源與內存數量。
2、SparkStreaming組件：SparkStreaming接收實時輸入數據流並將它們按批次劃分，然後交給Spark引擎處理生成按照批次劃分的結果流。SparkStreaming提供了表示連續數據流的、高度抽象的被稱爲離散流的Dstream,可以使用kafka、Flume和Kiness這些數據源的輸入數據流創建Dstream,也可以在其他Dstream上使用map、reduce、join、window等操作創建Dsteram。Dstream本質上呢，是表示RDD的序列。 那麼它的適用場景在於準實時的日誌分析，或數據接入處理。
3、SparkR: 我表示。。沒用過~~~~啊哈哈哈~（後續學習）
4、SparkML:包含用於機器學習或數據分析的算法包。在Spark後臺批處理代碼中，或SparkStreaming中都可以集成，用於更多的數據分析。（後續學習）
總結：
整個Hadoop生態圈與Spark生態圈的批處理應用流程就可以整理出來了：
1、首先由每日從傳統數據庫中導出的數據文件，由Spark後臺處理代碼進行數據的處理，或由用Java編寫的前臺代碼連接thrift進行數據的結構化。
2、通過Spark連接mysql數據表，進行後臺數據處理生成各平臺需要的數據類型與種類導入Hbase、Redis或生成Hive表等等。
3、由數據分析人員運用R或ive或SparkR、ML進行數據分析。
4、sparkStreaming通過接受kafka的數據，進行數據處理或分析，也可以通過監聽HDFS文件目錄來進行數據的定時處理。
實時項目組件：
實時項目呢，主要包含的組件有Storm、Redis、Kafka、Jetty、Netty,keepalive,nignx等。（圖木有畫哈哈），那麼下來一一進行說明。
1、Redis: Redis包括集羣模式、哨兵模式、由Twemproxy實現的代理模式。主要服務於實時系統的數據加載，並且將大部分系統配置信息都存入Redis，，走全內存可以使每條消息的延遲降低。因爲Redis沒有分佈式鎖，可以使用setnx標誌位來實現分佈式鎖的功能。
2、jetty：輕量級的servlet,可部署多份，每份裏面接入網管發送的數據，數據的存儲可存儲與BlockingQueue中，由多個線程拉取數據，進行數據的預處理。
3、ngnix與keepalive:keepalive的作用主要用於設置虛擬IP，ngnix進行消息的負載均衡，發送至各服務器的jetty。
4、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進行消費。
5、Storm:主要的編程概念:spout、blot和topology,我們需要根據數據的併發量來決定啓動多少個worker和calc,首先由Spout進行消息的接入，進行數據預處理與加載，剛纔我們說了，走全內存，直接走Redis，但是如果Redis掛掉了怎麼辦呢，那麼就備選用hbase~blot中實現主要的業務邏輯，消息的封裝啊。 這裏需要注意的是，我們不要把所有類型的事件都寫入一個topo，那麼消息延遲的概率會很大，對於不同的事件進行不同消息的封裝處理。
總結：
對於整個實時項目需要注意的就是數據的封裝與解析，怎樣提高效率，怎樣能夠讓各個模塊兒解耦，走全內存、日誌收集及問題等等。
輔助組件：
1、Ansible：ansible是新出現的自動化運維工具，基於Python開發，集合了衆多運維工具（puppet、cfengine、chef、func、fabric）的優點，實現了批量系統配置、批量程序部署、批量運行命令等功能。
2、ganglia:Ganglia是UC Berkeley發起的一個開源集羣監視項目，設計用於測量數以千計的節點。Ganglia的核心包含gmond、gmetad以及一個Web前端。主要是用來監控系統性能，如：cpu 、mem、硬盤利用率， I/O負載、網絡流量情況等，通過曲線很容易見到每個節點的工作狀態，對合理調整、分配系統資源，提高系統整體性能起到重要作用。
