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