到年底了，想着總結下所有知識點好了~今年應用的知識點還是很多的~
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負載、網絡流量情況等，通過曲線很容易見到每個節點的工作狀態，對合理調整、分配系統資源，提高系統整體性能起到重要作用。
