1 大數據概述

大數據特性：4v volume velocity variety value 即大量化、快速化、多樣化、價值密度低

  數據量大：大數據摩爾定律

  快速化：從數據的生成到消耗，時間窗口小，可用于生成決策的時間非常少；1秒定律，這和傳統的數據挖掘技術有著本質區別（谷歌的dremel可以在1秒內調動上千臺服務器處理PB級數據）

  價值密度低，商業價值高

大數據影響：

  對科學研究影響：出現科學研究第四方式數據（前三個分別是實驗、理論、計算）

  對思維方式影響：全樣而非抽樣、效率而非準確、相關而非因果

大數據應用：無人駕駛、智能醫療…

大數據一般指數據和大數據技術的綜合

大數據技術，是指伴隨著大數據的采集、存儲、分析和應用的相關技術，是一系列使用非傳統的工具來對大量的非結構化、半結構化、結構化數據進行處理，從而獲得分析和預測結果的一系列數據處理和分析技術

大數據兩大核心關鍵技術：分布式存儲+分布式處理

云計算：通過網絡以服務的方式為用戶提供廉價IT資源

云計算典型特征：虛擬化和多租戶

三種：IaaS、PaaS、SaaS

2 大數據處理架構Hadoop

2.1 Hadoop簡介

Hadoop是Apache軟件基金會旗下的頂級項目，開源分布式計算平臺

為普通用戶屏蔽大數據底層實現細節

是java開發的，但是支持多種編程語言寫應用

不是單一技術，是一整套解決方案的統稱，是一個項目

Hadoop兩大核心：分布式文件系統HDFS+分布式并行框架MapReduce

Hadoop創始人：Doug Cutting

谷歌發布多種大數據技術：

  2003年，谷歌發布了分布式文件系統GFS（Google File System），2004年Hadoop就把它納入自己名下進行開源實現，HDFS是GFS的開源實現

  2004年，谷歌發布了分布式并行編程框架MapReduce，2005年Hadoop也把它納入自己的平臺

隨著Hadoop發展，各種相關項目獨立脫離出來，成為獨立子項目，2008年1月Hadoop正式成為Apache頂級項目

2008年4月，Hadoop用910節點構成集群去做計算，對1T數據做排序只用了209秒，由此而火

特性:

  高可靠性，整個Hadoop平臺采用冗余副本機制，當某些機器故障剩余機器仍可提供服務

  高效性

  高可擴展性

  成本低

Hadoop不同版本，Apache Hadoop版本分為兩代

Hadoop1.0到2.0變化：

  將資源調度管理部分單獨抽離出來成為YARN框架（Yet Another Resource Negotiator)，2.0由HDFS、MapReduce和YARN三個分支構成，MapReduce只做數據處理工作效率提高，MapReduce是架構在YARN之上的第一個計算框架,YARN也可以支持其他計算框架比如流計算框架Storm批處理計算Spark(Spark采用和MapReduce一樣邏輯但是是采用內存計算）等等；

  HDFS1.0的可擴展性不好，2.0提出NN Federation技術，是名稱節點，做數據目錄服務，外界訪問都是訪問這個服務再去取數據，1.0只有一個名稱節點擴展性不好，2.0設置多個名稱節點進行分區管理；2.0還增加HA，對NameNode做了個熱備份；

知名的其他Hadoop開源版本：Hortonworks企業版，CDH（Cloudera Distribution Hadoop）、MapR、星環 等等

推薦企業來講用CDH,個人學習就用Apache Hadoop

2.2 Hadoop項目結構

從最初的兩大核心項目演化出非常多子項目成為一個生態圈

HDFS負責分布式文件存儲

YARN框架負責資源管理和調度

MapReduce是做離線計算和批處理，不能做實時計算

Tez負責DAG計算，把很多MapReduce作業進行分析優化，構建成一個有向無環圖，可以保證最好的處理效率，分清有些先做有些后做有些不要重復做

Spark的邏輯和MapReduce一樣，但是是基于內存計算，而MapReduce是基于磁盤的計算，所以Spark的性能比MapReduce高一個數量級

Hive是數據倉庫，是架構在MapReduce之上，SQL會被轉化為一堆的MapReduce作業再去執行

Pig是幫你實現流數據處理的，屬于輕量級的分析，提供類似sql的語法叫Pig Latin

Oozie是作業流調度系統

Zookeeper是做分布式協調一致性服務的，負責分布式鎖、集群管理等等

HBase 列式數據庫，非關系型分布式數據庫，支持隨機讀寫和實時應用,HDFS是做順序讀寫的，但在實際應用中很多需要隨機讀寫，就由HBase完成

Flume專門做日志收集的

Sqoop是在Hadoop和關系數據庫做數據導入導出的

Ambari是個安裝部署工具，幫你在一個集群上面非常智能化的部署和管理監控一整套Hadoop平臺各種套件

2.3 Hadoop的安裝與使用

Hadoop的安裝模式：單機模式(默認)、偽分布式模式、分布式模式

HDFS節點：NameNode、DataNode

MapReduce節點：JobTracker、TaskTracker

NameNode管理各種元數據，里面很多數據都是直接保存在內存中，內存要大并且通道優化，帶寬需求更大

SecondaryNameNode，是HDFS中的組件，是冷備份，小的集群直接和NameNode放同一臺機器即可，大的集群要獨立出來

Hadoop集群基準測試：

  自帶基準測試程序；

  用TestDFSIO基準測試，來測試HDFS的IO性能；

  用排序測試MapReduce:Hadoop自帶一個部分排序的程序，測試過程都會通過Shuffle傳輸至Reduce，可以充分測試MapReduce各個組件的性能

3 分布式文件系統HDFS

塊：不同于文件系統中的塊，大很多，默認64M，也可以更大，但是如果太大也會影響MapReduce的性能，是為了降低尋址開銷

  支持大規模文件存儲，突破單機存儲容量上限

  簡化系統設計，使元數據設計非常簡單

  適合數據備份

NameNode：負責元數據，整個HDFS的管家，相當于數據目錄

DataNode：具體負責存儲實際數據

元數據包含文件是什么、文件被分成多少塊、塊與文件的映射關系、塊被存在哪個服務器等信息

NameNode兩大數據結構FsImage、Editlog

FsImage保存系統文件樹以及文件樹中所有文件和文件夾的元數據（包括文件的復制等級、修改訪問時間、塊大小以及組成文件的塊），FsImage中沒有具體記錄塊在哪個數據節點存儲的，這個信息是單獨在內存中維護的，至于塊到底被放到哪個節點中去，這個信息是DataNode匯報而來實時維護的

Editlog記錄對數據的操作如創建、刪除、重命名等

每次啟動時候從磁盤加載FsImage和Editlog到內存中，得到最新的元數據FsImage，舊的刪除，同時創建新的空的Editlog，這個模式能夠提高系統效率

當系統運行一段時間后，Editlog變得非常大的時候，系統效率又變慢了，此時第二名稱節點Secondera NameNode開始作用幫助解決Editlog不斷增大的問題，先請求NameNode停止使用Editlog并生成edits.new,然后SeconderaNamenode通過HTTP Get方式把Editlog和FsImage下載到本地進行合并操作得到新的FsImage，再發送給NameNode，然后NameNode把edits.new改為Editlog

HDFS的數據冗余保存，冗余因子默認3，當用偽分布式的時候冗余因子只能是1，能夠加快數據傳輸速度，互為備份能夠方便檢查數據錯誤，高可靠

寫策略：如果是集群內部機器的請求，就把第一個塊放到本節點，如果來自集群外部請求，就會挑選一個磁盤不太慢cpu不太忙的節點來存放，第二個塊就放到與第一個塊不同機架的節點，第三個塊會放到與第一個塊相同機架的不同節點上，如果4、5、6.等塊就會隨機算法計算

讀策略：一個基本原則是就近讀取，HDFS提供一個API可以確定數據節點所屬的機架id，客戶端也可以調取API獲取自己所屬機架ID，確定遠近關系，當客戶端讀取數據時，從NameNode獲得數據塊不同副本的存放位置列表，列表中包含了副本所在的數據節點，可以調用API來確定客戶端和這些數據節點所屬機架id，當發現同機架id時候優先讀取該副本，否則隨機選擇

容錯：

  如果NameNode出錯整個HDFS實例將失效，會暫停服務一段時間，從SeconderaNameNode恢復過來后再提供服務，1.0是這樣,2.0有熱備HA

  如果DataNode出錯，運行期間DataNode會發送心跳給NameNode，如果故障，把故障機的塊冗余因子恢復，除了故障可以改變冗余副本位置，負載不均衡時候也可以Rebalance

  如果數據出錯，校驗碼機制，塊創建的時候同時創建校驗碼保存在同個目錄，讀取時候重新計算校驗碼和保存的校驗碼對比，不一致說明數據出錯，即進行冗余副本的再次復制

HDFS讀寫數據過程

hadoop fs 命令：-ls  -mkdir –cat

把本地文件復制到hdfs中hadoop fs –cp 本地路徑 hdfs路徑

50070端口可以web方式看到hdfs信息，用的比較少

java API方式與HDFS交互

Hadoop為HDFS和MapReduce提供基礎JAR包，叫hadoop common

4 分布式數據庫HBase

4.1 簡介

HBase是BigTable的一個開源實現,BigTable最初是為解決谷歌公司內部大規模網頁搜索問題的，BigTable是架構在GFS之上，具有非常好的性能(可以支持PB級別的數據),具有非常好的擴展性

HBase是一個高性能 高可靠列式可伸縮的分布式數據庫，特長是用來存儲非結構化和半結構化的松散數據，目標是通過水平擴展存儲海量數據

這個架構之上的pig hive等都是可以訪問HBase的數據

為啥有了關系數據庫 HDFS等等還要搞個HBase呢，原因：  雖然已經有了HDFS和MapReduce，但Hadoop主要解決大規模數據離線批量處理，Hadoop沒辦法滿足大數據實時處理需求，而傳統關系數據庫擴展能力沒法應對爆炸式數據增長，即使是讀寫分離分庫分表等操作也有不便利效率低等缺陷，只有HBase能夠滿足不斷增長的數據存儲需求

和傳統關系數據庫區別：

  不是使用關系模型設置各種字段類型，而是直接存儲未經解釋的二進制數據，由應用程序開發人員來對數據做解釋

  傳統數據庫對數據增刪改等多種操作在HBase中避免了，比如連接操作，這是非常低效的操作

  存儲模式方面基于列

  只支持對行鍵的簡單索引

  在關系數據庫中更新數據時候舊數據刪除掉，HBase中舊的版本還在，每新加的版本會生成新的時間戳標識

  可伸縮性方面，關系數據庫很難水平擴展，最多實現縱向擴展

HBase訪問接口：Java API：Shell、Thrift Gateway（異構系統在線訪問HBase）、REST Gateway（REST風格的HTTP API）；SQL類型接口：Pig、Hive

4.2 HBase數據模型

HBase是一個稀疏的多維度的排序的映射表，是列式數據庫

通過行鍵、列族、列限定符、時間戳四個元素表示，HBase中每個值都是未經解釋的字符串也就是Byte數組，由程序員自行對列類型解析

和關系數據庫不同，和關系數據庫不同的地方，列族支持動態擴展，且更新數據時候保留舊版本（與HDFS只允許追加不允許修改的特性相關）

以大表的形式來組織，不同于關系數據庫遵循第一范式第二范式第三范式等規范化分解來降低數據的冗余存儲，查詢的時候不需要多表關聯，追求的是分析的效率，用空間來換取表連接的時間

數據坐標：關系數據庫通過行列定位，HBase是通過四維坐標定位，如果把四維坐標聯合來看也可以當成鍵值數據庫

概念試圖：是一個稀疏表，很多地方是空

物理視圖：底層是按照列族方式存儲

列式數據庫優點：每列數據類型相似可以帶來很高的數據壓縮率、分析效率高

4.3 HBase實現原理

HBase功能組件：

  庫函數：用于鏈接每個客戶端

  Master服務器：管家，實現對表的分區信息維護和管理；維護了一個Region服務器列表；整個集群當中有哪些Region服務器在工作；負責對Region進行分配；負載均衡

  Region服務器：負責存取Region

客戶端并不依賴于Master去獲取信息

表會分多個Region，大Region會不斷分裂，分裂的過程不設計底層物理數據，只是修改了它的指向信息而已非常快速，訪問的還是舊的Region，后臺會有合并過程把拆分的數據進行重新操作最終寫到新的文件中得到新的Region，2006以前推薦一個Region大小100到200MB，現在一般最佳是1G到2G，實際取決于單臺服務器的有效處理能力

同一個Region是不會拆分到不同的Region服務器上的，實際中每個Region服務器能存儲10-1000個Region

HBase尋址：三層結構，首先構建一個元數據表稱.META.表，當.META.表增大后分區由-ROOT-表來維護（-ROOT-表不允許分裂只有1個Region，-ROOT-表的地址寫死在ZooKeeper文件中），為了加快數據存儲速率，元數據表都是放在內存中，所以內存大小限制了Region個數從而限制了整個HBase的數據大小，但是是滿足企業需求的

為了加速，客戶端會緩存，第一次需要三級尋址，后面就不依賴于Master了實現更快的訪問，同時要解決緩存失效問題，HBase采用惰性解決機制，每次都按照緩存信息找，當無法找到數據時候才去更新緩存再次經歷三級尋址過程

4.4 HBase運行機制

客戶端：訪問HBase的接口，為了加快訪問，將已經訪問過的信息緩存

ZooKeeper服務器：實現協同管理服務，實現分布式協調一致性，被大量用于分布式文件系統，提供配置維護、域名服務、分布式同步服務等等，在HBase中就是提供管家功能維護和管理整個HBase集群，動物園管理員，可以確保任何時候只有一個HMaster在運行

Master（主服務器）：負責HBase中表和Region的管理工作，比如對表的增刪改查都是通過Master進行管理的，同時對不同Region服務器負載均衡，負責調整分裂、合并后Region的分布，負責重新分配故障、失效的Region服務器

Region服務器：負責用戶數據的存儲和管理

每個Region服務器可以存儲10-1000個region，共用一個日志文件HLog，每個列族單獨構成一個Store，Store數據不是直接寫到底層，要先寫到MemStore緩存中，緩存滿后刷寫到磁盤文件StoreFile，StoreFile是HBase中的表現形式底層是借助于HDFS來存儲的是通過HFile文件存儲的

用戶讀寫數據過程：寫數據時候先到Region服務器，先寫緩存寫MemStore，為了保護數據，必須先寫日志HLog，只有HLog完整寫入磁盤才允許調用返回給客戶端；讀數據也是先訪問MemStore再找StoreFile，因為最新數據都在MemStore而不是磁盤StoreFile中

緩存刷新：系統會周期性把MemStrore緩存中的內容寫入磁盤StoreFile中，清空緩存，并在HLog寫入個標記，每次刷寫都會生成一個StoreFile，所以一個Store會包含多個StoreFile文件；每個Region服務器啟動都檢查HLog文件確認最近一次執行緩存刷新操作之后是否有新的寫入操作，如果發現更新則先寫入MemStore再刷寫到StoreFile最后刪除舊的HLog文件，開始為用戶提供服務

StoreFile合并：當StoreFile數量多的時候索引數據變慢，達到一定閾值執行合并為大的StoreFile，這個合并操作相當占用資源；當StoreFile合并大到一定程度后又會引發分裂操作

HLog工作原理：就是通過日志來保護數據，ZooKeeper負責監視整個集群，檢測到故障，會告訴Master服務器，Master會處理故障，Master服務器會把故障機器的遺留的HLog拉去過來，然后把各個Region的操作分拆出來，再分配給各個Region日志重做

4.5 HBase應用方案

性能優化方法：

  時間靠近的數據都存在一起   時間戳(升序排序、越到后時間戳越大，長整型64位)，可以用系統最大的整型值減去時間戳long.MAX_VALUE-timestamp作為行鍵，排序就反過來了從而改變排序順序，保證最新寫的數據讀的時候很快命中

  如果對實時性較高，將相關數據放到服務器緩存來提升讀寫性能，可以在創建表的時候設置HColumnDescriptor.setInMemory選項為true，這樣可以把相關表放入region服務器緩存中加快io

  設置HColumnDescriptor.setMaxVersions可以設置最大版本數，設置1，就不會保存過期版本，可以節省空間

  沒有達到最大版本數的數據想清理掉咋辦，設置TimeToLive參數，一旦超過生命周期就稱為過期數據，就自動被系統刪除掉，如果只需要最近兩天的數據設置setTimeToLive(2*24*60*60)，超過2天的數據自動清空

檢測性能：

  Master-status是HBase自帶工具通過web方式可以查詢HBase運行狀態

  Ganglia是UC Berkeley發起的一個開源集群監視項目用于監控系統性能也支持對HBase進行性能監控

  OpenTSDB可以從大規模集群中獲取相關的性能參數，然后存儲索引并可視化的方式提供給管理員

  Ambari是Hadoop架構上的產品，作用是創建管理，監視整個集群，HBase也是集群一部分，所以也可以對HBase進行監視

sql引擎Hive去整合HBase，另外一個產品叫Phoenix

  Hive0.6.0版本開始已經具備和HBase的整合功能，它們的接口互相通信即可實現對HBase的訪問

  Phoenix是致命SaaS提供商Salesforce的產品，開源，是構建在Apache Hadoop之上的一個SQL中間層，通過它允許開發者在HBase上執行SQL查詢

構建HBase二級索引（輔助索引）

  原生HBase是不支持二級索引的，默認索引只有行鍵，HBase原生產品只有通過單個行鍵或者行鍵起始結束點或者全表掃描三種方式來訪問

  HBase0.92版本以后的新特性叫Coprocessor，充分利用這個特性幫助建立二級索引，比如華為的Hindex、Redis Solr等等

  怎么利用特性構建二級索引Coprocessor提供2個實現：endpoint、observe(endpoint相當于關系數據庫的存儲過程，observe相當于觸發器),在更新表的同時觸發器或者存儲過程去維護索引表即二級索引，這不是HBase數據庫自身的索引，優點是非侵入性，既沒有對HBase做任何改動也不需要對上層應用做任何妥協，缺點是同時維護索引對集群壓力倍增耗時也是倍增

  華為的Hindex是java編寫的支持多個表索引也支持多個列索引，而且也支持基于部分列值的索引

  HBase+Redis，Redis是鍵值數據庫，能高效管理鍵值對，在Redis數據庫中管理索引，再定期把索引更新到HBase底層數據中，效率更高

  HBase+Solr，Solr是高性能基于Lucene的全文搜索服務器，Solr構建的是其他列和行鍵之間的對應關系，這種方式也是很高效的

4.6 HBase的安裝配置和常用Shell命令

下載HBase安裝文件，然后解壓到/usr/local，如果是單機版本解壓即可用，如果是偽分布式需要配置，bin目錄加入到path中

HBase配置有三種：單機（解壓即可用）、偽分布式（讓HBase通過HDFS存取數據）、分布式（用多臺機器存取）

偽分布式：要配置JAVA_HOME；要配置Hadoop，實現無密碼SSH登錄；要先啟動hadoop再啟動HBase，關閉也是；修改配置文件時候有個選項hbase.managers.zk，這是配置ZooKeeper的，可以單獨安裝ZooKeeper組件服務來支撐HBase，也可以用HBase自帶的ZooKeeper組件來提供服務

SHELL命令：create、list、put、get、drop

4.7 常用Java API 

HBase是java開發的，有原生java api，也支持其他語言的編程

首先要導入jar包，到hbase安裝目錄中lib目錄所有jar包導入（注意不要導入上節課的hadoop的jar包，會發生版本沖突）

Java 和shell的功能是一樣的

5 NoSQL數據庫

5.1 概述

NoSQL：not only sql  是關系數據庫的有益補充，有靈活的可擴展性、靈活的數據模型、和云計算緊密結合

傳統數據庫缺陷：

  無法滿足web2.0的需求：沒有辦法滿足海量數據需求、沒有滿足高并發需求、無法滿足高可擴展性和高可用性

  數據模型的局限性：用一個模型適應所有業務場景是不行的，hadoop針對離線分析、mongoDB和Redis都是針對在線業務，這些都是拋棄了關系模型

  web2.0關系數據庫許多特性無法發揮，事務機制和高效的查詢機制這兩個關系數據庫的突出特性在web2.0時代成為雞肋，

    web2.0通常是不要求嚴格數據庫事務的，比如發個微博失敗與否關系不大，不像銀行這些，事務機制需要很高額外開銷，

    web2.0一般不要求嚴格的讀寫實時性

    web2.0不包含大量復雜sql查詢，web2.0設計時候就避免了多表連接，連接操作是代價很高的，去結構化非規范化，寧可適當冗余來換來更好的性能

5.2 NoSQL數據庫和關系數據庫比較

關系數據庫有完備的關系代數理論作為基礎，NoSQL數據庫缺乏統一理論基礎

RDBMS是很難橫向擴展，縱向擴展也有限，NoSQL有很強的水平擴展性能

關系數據庫要事先定義嚴格的數據模式，NoSQL數據模型靈活

關系數據庫在適當數據量的時候查詢效率高，數據量級增大后查詢效率下降，NoSQL未構建面向復雜查詢的索引，查詢性能差

事務一致性方面，關系數據庫遵循ACID事務模型可以保證事務強一致性，NoSQL在設計時候放松一致性要求，采用BASE模型，BASE模型也是NoSQL數據庫三大理論之一(CAP、BASE、最終一致性)

數據完整性，關系數據庫具有保證完整性的完備機制來實現實體完整性參照完整性用戶自定義完整性等，NoSQL不能實現完整性約束

可擴展性，關系數據庫很差，NoSQL很好

可用性，關系數據庫在小規模數據時候可用性還可以，數據量級大后可用性削弱，因為關系數據庫設計之初優先保證嚴格的一致性，NoSQL有非常好的可用性，能夠迅速返回所需結果

標準化方面，關系數據庫遵循SQL標準，標準化完善，NoSQL未形成通用的行業標準，2015圖領獎獲得者邁克爾·斯通布雷克就認為NoSQL缺乏統一標準會在后面發展受到拖累

技術支持方面，關系數據庫很多是商業數據庫，能夠獲得強大的技術支持和后續服務支持，NoSQL很多是開源產品處于起步階段，技術支持不如rdbms

可維護性，關系數據庫需要dba維護，NoSQL維護更加復雜，因為它沒有成熟的基礎和實踐操作規范，維護較為復雜

RDBMS：理論完備、有嚴格標準、支持事務一致性、可以借助索引機制實現高效查詢，可擴展性差，尤其不具備水平可擴展性，無法支持海量數據存儲，數據模型定義嚴格無法滿足web2.0應用需求；用于電信銀行的關鍵業務系統

NoSQL：支持超大規模的數據存儲、數據模型靈活，缺乏底層基礎理論支撐，不支持事務強一致性，導致無法用于關鍵業務；用于互聯網企業以及傳統企業的非關鍵性業務

無法互相取代，甚至有時候需要混合架構

5.3 NoSQL數據庫的四大類型

鍵值數據庫、文檔數據庫、列數據庫、圖數據庫

鍵值數據庫：

  代表產品Redis、Memcached(Redis之前比較火的是Memcached，現在越來越多企業轉向Redis)、SimpleDB（亞馬遜在云中產品提供的鍵值數據庫）

  數據模型：鍵是一個字符串對象，值是任意類型數據，比如整型字符數組列表集合等等

  典型應用：涉及頻繁讀寫、擁有簡單數據模型的應用；內容緩存，如會話、配置文件、參數、購物車等；存儲配置和用戶數據信息等移動應用

  優點是擴展性好理論上有無上限的擴展空間，靈活性好，大量讀寫操作性能高

  缺點是無法存儲結構化信息，條件查詢效率低，鍵值數據庫根本不允許對它的值索引，值是對用戶透明的，只能一個個找到key后訪問value，也無法鍵與鍵之間關聯，實現不了復雜查詢

  不適用：鍵值數據庫根本沒有通過值查詢的路徑，如果不是通過鍵而是通過值來查詢，就不要用；不能通過兩個或以上的鍵關聯數據；一些鍵值數據庫中，產生故障時不能回滾

  使用者：百度云數據庫(Redis)

實際生產中，鍵值數據庫是理想的緩存層解決方案

列族數據庫：

  代表產品：BigTable、HBase(master slave結構)、Cassandra (不同于HBase，是對等結構，是p2p結構)

  數據模型：簡單，就是列族

  典型應用：分布式數據存儲和管理；數據在地理上分布于多個數據中心的應用；可以容忍副本中存在短期不一致情況的應用；擁有動態字段的應用

  優點：可擴展性強，查詢速度快，復雜性低

  缺點：功能少，缺乏事務一致性支持，HBase有些人說是支持一致性，但是Cassandra就不支持

  不適用：需要ACID事務特性的情形Cassandra就不適用

  使用者：Facebook(HBase),Yahoo(HBase)

5.4 NoSQL三大理論基石 CAP理論、BASE、最終一致性

CAP理論：C consistency 一致性，A availability 可用性，P partition tolerance 分區容忍性（當出現網絡分區的情況時，即系統中的一部分節點無法和其他節點通信，分離的系統也能正常運行）

理想的分布式系統是同時滿足CAP特性，但是理論研究和實踐證明這是做不到的，不能魚和熊掌兼得，只能三者取其二，必須犧牲一個性質成就另外兩個性質

BASE：Basically Available Soft state 和Eventual consistency的簡寫

Basically Available 基本可用：指一個分布式系統的一部分發生問題變得不可用時其他部分仍然可以使用，也就是允許分區失敗的情形出現

Soft state：硬狀態是數據庫一直保持一致性，軟狀態指可以有一定的滯后性

Eventual consistency最終一致性：一致性包含強一致性和弱一致性，二者區別在于高并發的數據訪問操作下，后續操作能否獲取最新的數據，最終一致性是弱一致性的一個特例

對于HBase而言，底層是借助HDFS的，而HDFS采用強一致性，在數據沒有同步到N個節點前是不會返回的，而對于Cassandra而言都可以設置三者的值，來選擇最終一致性，這些數據庫產品還會提供最終一致性的支持

5.5 從NoSQL到NewSQL數據庫

和NewSQL對應的是OldSQL，傳統數據庫設計都期望One Size Fits All，但是這種理想狀態被證明是不可實現的

轉而對改變為對不同應用場景使用不同數據庫，事務性應用用OldSQL，互聯網應用用NoSQL，分析型應用用NewSQL

NewSQL充分吸收了OldSQL和NoSQL的各自優點，仍然采用關系模型提供強事務一致性，同時借鑒NoSQL有非常好的水平擴展支持海量數據存儲

典型產品：亞馬遜的RDS、微軟SQL Azure(底層還是sql server相關技術)

5.6 文檔數據庫MongoDB

文檔數據庫是介于關系數據庫和NoSQL之間的產品，最像關系數據庫，是當前最熱門的產品

MongoDB是C++編寫的基于分布式文件存儲的開源數據庫系統

高負載情況添加更多節點保證數據服務性能，水平擴展能力強

MongoDB旨在為WEB應用提供可擴展的高性能數據存儲解決方案

MongoDB將數據存儲為一個文檔，數據結構由鍵值對組成MongoDB文檔類似JSON對象，字段值可以包含其他文檔、數組及文檔數組，文檔格式叫BSON，是Binary類型的JSON文檔

特點是：

  提供面向文檔的存儲，操作簡單容易；

  相對于鍵值數據庫有個很好的特性，它可以針對不同的任何的屬性索引，實現更快的排序；

  較好的水平擴展能力；

  有豐富的查詢表達式可查詢文檔中內嵌的對象和數組；

  可替換已完成文檔的某個指定的數據字段；

  MongoDB中MapReduce主要是用來對數據進行批量處理和聚合操作

  安裝簡單

術語和關系數據庫差不多

關系數據庫中一般遵循范式設計，查詢時候需要多表查詢，MongoDB不需要跨表連接，一個文檔即可完整表述，提供并發性易用性

一個MongoDB可以建立多個數據庫，默認數據庫“DB”，存儲在data目錄，MongoDB的單個實例可以容納多個數據庫，每個都有自己的集合和權限和自己的文件

MongoDB不需要設置相同的字段，并且相同字段不需要相同數據類型

提供shell和java api訪問方式

6 云數據庫

6.1 概述

云計算是通過網絡以服務的方式為用戶提供非常廉價的IT資源

云計算優勢：按需服務、隨時服務、通用性、高可靠性、極其廉價、規模龐大

IaaS、PaaS、SaaS

云數據庫是部署和虛擬化在云計算環境當中的數據

云數據庫繼承了云計算的特點：動態可擴展、高可用、廉價、易用性、免維護、高性能、安全

云數據庫只是關系數據庫NoSQL數據庫在云端的實現，并不是新的數據庫，也沒有全新的數據模型

6.2 云數據庫產品

最知名的是亞馬遜Amazon的云數據服務，主要是鍵值數據庫Dynamo和簡單的數據庫存儲服務SimpleDB以及關系數據庫RDS，也有分布式緩存服務的Amazon ElastiCache，也提供云中數據倉庫服務Redshift

谷歌也有云數據庫產品叫Google Cloud SQL，是基于MySQL的，支持云中事務，提供帶JDBC和DB-API支持的傳統MySQL環境，對開發者而言，Google Cloud SQL有個優勢是和Google APP Engine（PaaS層）集成的

微軟SQL Azure，基于SQL server，在推出之前很多云數據庫都是NoSQL，所以微軟推出云關系數據庫是很有貢獻的，很多企業需要事務支持，同時它也支持存儲過程，SQL Server的產品無需更改可以直接部署到SQL Azure了，但是SQL Azure的事務是局部事務而不是分布式事務

oracle也有Oracle Cloud

雅虎的PNUTS

國內的阿里騰訊百度都有自己的云數據庫，但是底層都是國外的這些數據庫，百度提供了以鍵值模型為基礎的云數據庫采用的就是Redis

6.3 云數據庫系統架構

云數據庫架構多樣，選取一種介紹，就是阿里巴巴開發的通用MySQL集群，就是UMP（Unified MySQL Platform），在阿里內部得到廣泛使用，突出特點是低成本高性能

UMP在設計時原則：

  整個系統保持單一的對外訪問入口

  消除單點故障，保證服務的高可用

  具有良好的可伸縮性，可以根據外部負載動態的增加減少計算資源

  可以實現資源之間的相互隔離

多租戶共享資料庫，可能出現某個用戶消耗的資源過多影響其他租戶導致整個系統不穩定，UMP在設計時候就有資源之間隔離限制避免此種情況發生

Mnesia：

  UMP本質上就是個分布式數據庫，分布式數據庫不需要團隊從0開發，Mnesia就是基于Erlang語言開發的分布式數據庫管理系統，專門針對電信領域開發的數據庫管理系統

  具有非常好的特性，支持事務，支持透明的數據分片，利用兩階段鎖實現分布式事務，可以線性擴展到至少50節點

  Schema可在運行時動態配置

RabbitMQ：

  是一個工業級的消息隊列產品，比較常見的商業的消息隊列產品如IBM WEBSPHERE MQ，消息隊列是用來傳遞不同組件之間的消息，一個大的分布式系統有各種組件，組件之間的消息傳遞肯定不能是面向連接的，面向連接的資源消耗大效率低，一般都是異步，面向連接的是是同步傳輸，分布式系統為了提高效率都是采用異步傳輸，采用消息隊列來保證消息生產者到消息消費者

ZooKeeper：

  HBase中提過，典型功能是高效可靠的協調服務包括統一命名服務、狀態同步服務、集群管理、分布式鎖等等，在UMP系統中ZooKeeper發揮三個作用：

    作為全局的配置服務器，一旦某個服務器的配置更改，ZooKeeper監聽到，就通知其他服務器把最新的配置取走，減少許多人工干預，實現多個服務器配置一致性

    提供分布式鎖（選出一個集群的“總管”），UMP系統設計收有Controller（管家角色），為了避免單點故障，有多個管家，但是某個時候只有一個管家能起作用

    監控所有MySQL實例，發生故障后及時探測到并報告給管家

LVS：將一組服務器構建為高性能高可用的虛擬服務器，對用戶在看只有一個ip一個服務器，但是后面是整個集群，只不過通過負載均衡技術把請求引導到集群各個節點

  Linux Virtual Server，是一個虛擬機的服務器集群系統，是一個通用的集群負載均衡框架，  UMP系統借助LVS實現集群內部的負載均衡，有故障機也能屏蔽掉

  LVS集群采用IP負載均衡技術和基于內容請求分發技術

調度器是LVS集群系統的唯一入口

  整個集群結構對用戶來講是透明的

Controller服務器：UMP集群的總管，實現各種管理服務，集群成員的管理、元數據的存儲、MySQL實例管理、故障恢復、備份遷移擴容等等功能，上面運行了一組Mnesia分布式數據庫服務，這里面有些元數據，包括集群成員、用戶的配置和狀態信息，“路由表”(記錄了用戶名到后端MySQL的映射關系)，其他的組件就可能找管家要這些元數據，同時為了避免單點故障，整個系統設置了多個Controller服務器，在某個時刻有且只有一個管家提供服務，由ZooKeeper服務器來幫你選定唯一管家

WEB控制臺：允許用戶通過web方式管理訪問平臺

Proxy服務器：向用戶提供訪問MySQL數據庫的服務，實現了MySQL協議，用戶的認證信息、資源的配額信息（QPS、IOPS、最大連接數等等）、后臺MySQL實例的地址，具有這樣的路由功能

Agent服務器：也是個代理，部署在各個MySQL服務器上管理MySQL，由該組件負責管理這個服務器并和其他服務器通信

日志分析服務器：對整個日志分析，慢日志分析

信息統計服務器：統計到系統運營數據，包括用戶連接數，每秒查詢數QPS，MySQL實例的進程狀態，這些都可以通過web界面可視化實時展現，這些信息不僅可以給用戶和管理員看，也可作為系統后期彈性資源分配的依據和自動化的MySQL實例遷移的依據

愚公系統：功能簡單也很強大，就是做數據遷移的，允許系統不停機的情況下實現動態擴容、縮容、遷移

6.4 UMP系統功能

容災、讀寫分離、分庫分表、資源管理、資源調度、資源隔離、數據安全

容災：UMP系統會為每個用戶創建2個MySQL實例一主一從，主庫從庫狀態也是由ZooKeeper服務器維護，一旦發生故障啟動主從切換，首先Controller服務器要修改路由表，然后把主庫標記不可用，通過消息中間件RabbitMQ告知所有Proxy服務器，整個過程對用戶透明，切換完成后主庫恢復，主庫追到和從庫一致，Controller服務器命令從庫鎖定，然后再次追到一致，再次切換回來，整個過程有少許故障時間

讀寫分離：利用主從實例完成讀寫分離，寫操作發到主庫，讀操作被均衡的發送到主庫和從庫

分庫分表：UMP系統支持對用戶透明的分庫分表，指的是系統運行過程中動態自動的分庫分表，但是在之前需要人工定義分庫分表規則，當采用分庫分表時，系統查詢過程是，Proxy服務器解析SQL語句，提取出重寫和分發SQL語句需要的信息，對SQL語句進行重寫，得到針對像一個的MySQL實例的子語句，分發到各個MYSQL實例執行，最后接受各個mysql實例執行結果合并最終結果給用戶

資源管理：整個UMP系統采用資源池機制對所有資源進行管理

負載均衡：負載較輕的服務器來創建MySQL實例

資源調度：UMP系統三種用戶，數據量流量都很小、中等規模、大規模需要分片分表的用戶，對于小規模用戶，一般多個用戶共享一個MySQL實例，中等規模用戶獨占一個MySQL實例，大規模的用戶占用多個MySQL實例

資源隔離：2中方式隔離

安全機制：SSL數據庫連接；提供數據訪問IP白名單；記錄用戶操作日志；SQL攔截

6.5 Amazon AWS和云數據庫

很多云計算相關的概念和服務都源于亞馬遜，別看他是電子商務，但是為云計算的發展具有里程碑意義的開拓性的貢獻

亞馬遜開創的云計算的服務模式：把IT資源作為一種服務出租給美國中小企業，他高峰期和低峰期不一樣，低峰期的時候把資源通過云計算的方式出租給中小企業，2006年推出這種方式的時候獲得非常好的市場認可，06年還沒有云計算的概念，他的業務量相當于谷歌微軟這些的總和，每年帶來幾十億美金收入，成為亞馬遜主營收入，全球用了12個區域性的數據中心，擁有非常多的用戶，在數據庫方面也如火如荼，和oracle也產生了全面競爭，Amazon RDS已經有了10萬多活躍用戶，近期推出的自己開發的關系數據庫Aurora，成長速度非常快

亞馬遜在IaaS、PaaS、SaaS三層都提供服務

區域region   12個 每個區域自成體系

可用區Availability Zone  在region之下，類似一個個數據中心機房

邊緣節點Edge Locations，負責內容分發網絡CDN，CDN服務是為了加快用戶訪問速度

網絡層提供直連服務，也提供VPN方式連接，Route 53（提供高可用高可伸縮的云域名解析系統）

計算層：EC2，Elastic Compute Cloud，彈性計算云；ELB，提供負載均衡器

存儲：S3：簡單對象存儲服務；EBS，Elastic Block Storage，彈性塊存儲服務專門針對EC2虛擬機設置；Glacier，用于較少使用的文檔存儲和備份，價格便宜；

數據庫：SimpleDB：基于云端的鍵值數據存儲服務；DynamoDB：性能高，容錯性強，支持分布式；RDS：支持MySQL，SQL Server和Oracle等數據庫；Amazon ElastiCache，數據庫緩存服務

應用程序層：企業搜索服務；隊列服務；工作流服務；內容分發服務；彈性MapReduce

部署和管理服務：可以進行自動化一鍵式的相關部署

產品分類：

  計算類：彈性計算云EC2，EC2提供了云端的虛擬機；彈性MapReduce，在云環境中部署Hadoop MapReduce環境，通過EC2虛擬機動態執行MapReduce計算任務

  存儲類：彈性塊存儲EBS；簡單消息存儲SQS；Blob對象存儲S3；NoSQl數據庫；關系數據庫RDS

EC2最大特點：允許用戶根據需求動態調整運行實例的類型和數量，實現按需付費

EC2平臺主要幾大部分：EC2實例（AMI），彈性塊存儲，彈性負載均衡

如何部署到虛擬機：需要把自己的應用程序和配置文件制成亞馬遜機器鏡像文件AMI，Amazon machine Image，然后復制到EC2實例，EC2實例是彈性伸縮的組；數據存到EBS，要加備份的話可以存到S3

EC2本地存儲是實例自帶的磁盤空間，不是持久化的，下面情況會清空：本地磁盤里的相關服務已不用了；服務故障；

為了解決本地存儲不可靠的問題，必須用EBS；

EBS通過卷來組織數據，每個EBS卷只能掛在到一個EC2實例

EBS卷不是與實例綁定而是與賬號綁定

SimpleDB：AWS上第一個NoSQL數據庫服務，鍵值數據庫，性能不是很好，現在很少用了，支持數據多副本存儲，支持高并發讀取，比較適合小型的碎片化的零散數據

  由于它涉及上的很多缺陷它有很多限制，明顯限制是單表限制，每個域最多存儲10G，沒辦法滿足大規模數據存儲需求，

  性能不穩定,可以輔助索引，更新操作由于索引開銷更大，

  它采用最終一致性，更新操作只能針對主副本進行，但可以快速傳播到其他副本，也沒有辦法滿足一些用戶需求

DynamoDB：因為SimpleDB這么多缺陷，亞馬遜推出另外的產品DynamoDB，

  吸收優點并改進，尤其提供一致性讀功能，而不是最終一致性

  根據主鍵去操作記錄不允許進行批量更新，不是SimpleDB那樣可以設置多列所以降低性能，這個時候它可以取得更好的性能

  全部采用固態盤進行存儲

RDS：關系數據服務，目前支持MySQL，Oracle，SQL Server，PG，MariaDB，Aurora，其中Aurora是最近幾年推出來的

RDS建立3T數據，帶3萬個DB實例

6.5 微軟云數據庫SQL Azure

針對行組實現事務，分區，但是不支持跨分區事務，跨了行組事務就不支持了

每個分區都是冗余副本，一般是3，一個主副本2個從副本

通常一個數據庫被分散存到3-5個實例中

6.6 云數據庫實踐

阿里云RDS：安全穩定、數據可靠、自動備份、管理透明

RDS實例是用戶購買的基本單位

7 MapReduce

7.1 概述

MapReduce是一種分布式并行編程框架

摩爾定律05年后逐漸失效，因為cpu制作工藝是有上限天花板的，單位面積能夠集成的晶體管數量實際上有上限，集成到一定程度后，布線過密會導致互相之間收到熱效應磁場效應干擾，cpu不再像以前一樣每18月性能翻倍

雖然cpu摩爾定律失效，但是數據增長卻依然遵循摩爾定律，所以一個增長一個停止增長，所以在數據處理計算能力方面的矛盾實際上就很突出，業界學術界都開始尋求其他方式提升數據處理能力，有兩條路線：一種是單核cpu到雙核到四核到8核，另外一種就是分布式并行編程

Hadoop MapReduce對谷歌的MapReduce做了開源實現，并優化

實際上谷歌MapReduce之前也有其他的并行編程框架，比如MPI，消息傳遞接口，一種非常典型的并行編程框架，再比如OpenCL或者CUDA

MapReduce模型把整個系統復雜的計算任務高度抽象為兩個函數Map和Reduce，屏蔽所有底層細節，極大降低分布式編程難度

策略：分而治之

理念：計算向數據靠攏而不是數據向計算靠攏

架構上 采用Master/Slave架構

7.2 MapReduce體系結構

client：通過客戶端提交用戶程序給JobTracker；客戶端也可以通過它提供的一些接口查看作業運行狀態

JobTracker作業跟蹤器：負責資源的監控和作業的調度；監控底層其他的TaskTracker以及當前運行的Job的健康狀況；一旦探測到失敗就把這個任務轉移到其他節點繼續執行；它還會跟蹤作業執行進度和資源使用量，它會把這些信息發送給任務調度器Task Scheduler，Task Scheduler負責具體任務調度，是個可插拔模塊，就是允許用戶自己編寫調度模塊，就是采用自己的任務調度策略去實現

TaskTracker：執行具體任務，一般接受JobTracker的命令；把自己的資源使用情況以及任務的執行進度通過心跳方式heartbeat發送給JobTracker

  在MapReduce設計中，TaskTracker以槽的概念slot，slot是一種資源調度的單位，把整個機器上面所有cpu內存資源打包，然后等分為很多slot，slot分為兩種，一種是map類型的slot，就是專門給map任務用的slot，一種是reduce類型的slot，就是專門給reduce任務用的slot，兩種slot是不通用的，這個不通用性也是設計缺陷，這個缺陷在hadoop2.0中有修復

Task任務：一種是map任務，專門執行map函數，另外一種是reduce任務，專門執行reduce函數

7.3 MapReduce工作流程

大概流程：在hdfs中數據集是各種分片split，為每個split單獨啟動一個map任務，這些map任務輸入是很多key和value，輸出也是很多key和value，然后map的結果分成很多區發送到不同的reduce上后續處理，分多少區一般取決于reduce機器，這個把map輸出結果進行排序歸并合并，這個過程叫做shuffle，這個中間包含數據分發的過程，最后reduce處理后保存到hdfs中

不同的map任務是不會互相通信的，不同的reduce任務之間也不會發生信息交換，用戶也不能顯式的從一臺機器發送消息給另外機器，所有的都是由MapReduce框架自身實現的，不需要用戶參與，大大降低應用程序開發難度

假設就2個節點，來分析下MapReduce各個階段

注意InputFormat模塊的Split是邏輯的，并不是實際物理上分片

RR：Record Reader 記錄閱讀器，根據分片的長度信息起始位置去底層HDFS找到各個塊，并讀出來為Key value形式

map由用戶自己編寫

shuffle洗牌：分區 排序 歸并 合并，之后才能發給相對應的reduce處理

reduce也是由用戶編寫的 完成分析

OutFormat模塊對輸出檢查并寫入到HDFS

邏輯分片不是越大越好或越小越好，肯定有個理想值，越小，導致啟動map任務過多，map任務切換等等都會占用過多管理資源導致效率低下，如果分片過小也會影響并行度，一般實際應用中用一個塊的大小作為一個split大小64M或者128M

map數量就是分片數量決定

最優的reduce任務個數取決于集群可用的reduce slot數量，但是一般略少些，可以預留些給可能發生的錯誤

7.4 shuffle過程原理

shuffle過程是理解MapReduce過程的核心

map結果先寫到緩存，緩存滿的時候發生溢寫，溢寫中有分區、排序和可能發生的合并操作之后保存到磁盤文件，溢寫是多次，生成多個磁盤文件，多個磁盤文件要歸并為大的磁盤文件，那么這個磁盤文件就是包含鍵值對，而且是分區排序后的，然后通知相關的reduce任務取走

reduce從不同的map機器上找到對應分區的數據拉過來，歸并合并得到鍵值對列表給reduce函數處理

完整的shuffle包含map端的shuffle和reduce端的shuffle

map端的shuffle過程

map緩存一般是100M，如果滿了再去溢寫，溢寫過程會影響后續map，所以不能等滿了才溢寫，要設置溢寫比，再沒滿的時候就開始溢寫，一般是0.8

溢寫要分區排序和可能的合并操作，分區默認是哈希函數，也可以用戶自定義，排序是默認操作不用用戶干預，排序后做可能發生的操作合并combine，和后面的歸并merge是不同的，合并是為了減少溢寫到磁盤的數據量，合并是啥呢，比如2個(a,1)鍵值對合并為(a,2),很顯然這種合并操作就能減少很多的鍵值對，合并操作不是必須的，如果是用戶定義了合并操作，這個時候會啟動，如果用戶沒定義就不啟動，但是用戶不能亂定義，注意要保證用了combine函數不能改變最終結果

生成多個溢寫文件，在整個map任務結束前，系統會自動對它們進行歸并merge，歸并為大的文件放到本地磁盤，大的文件里面的鍵值對都是分區的而且是排序的，當等待歸并的文件很多的時候就可以啟動歸并了，一般可以實現設置一個門檻值，默認是3，大于3時候還可以執行combine操作，但是小于3的時候combine不會啟動，因為數量很小不值得，combine也是要耗費資源，JobTracker會跟蹤任務，一旦探測map結束就會通知reduce任務拉走屬于它的分區數據去處理，完成map端shuffle過程

reduce端的shuffle過程

reduce任務也會向JobTracker詢問我要的數據是否可以拿了，map結束后JobTracker探測到就通知reduce，reduce任務到相依的map機器上把數據拉倒本機，再歸并合并，如果map沒有combine結果是（key,value-list)，如果合并了就是(a,2)形式，拉來數據后可以合并combine操作，最終溢寫到磁盤的文件還需要歸并為一個文件，也可能不是一個大的文件，比如50個磁盤文件，每次歸并10個，那就得到5個大的文件，這5個就不會再歸并，這是數量比較大的時候，如果數量很少，緩存就夠了，就不發生磁盤溢寫，直接在緩存中歸并操作，然后給reduce函數處理，完成reduce端shuffle過程

7.5 MapReduce應用程序執行過程

大概分為6個過程

  程序部署：把執行的用戶程序邏輯分發到各個機器

  選出一部分worker作為map機器，選出另外一部分worker作為reduce機器，

  讀數據，鍵值對，map機器選出部分空閑機器執行分片，然后給map機器執行，結果給緩存

  本地寫數據，map端shuffle

  遠端讀數據，reduce端shuffle

  寫數據，輸出保存到hdfs

5個階段：輸入文件、Map階段、中間文件（位于本地磁盤）、Reduce階段、輸出文件

輸入輸出都是HDFS，但是中間數據不是HDFS，就是磁盤

7.6 實例分析：WordCount

詞頻統計

首先看是否能用MapReduce，只有滿足分而治之的策略和數據集可以，并行執行彼此不會依賴對方

如有combine

7.7 MapReduce具體應用

關系代數運算：（選擇、投影、并、交、差、連接）、矩陣運算、矩陣乘法、分組聚合運算

用MapReduce實現關系的自然連接

7.8 MapReduce編程實踐

hadoop執行MapReduce任務的方式： hadoop jar；Pig；Hive；Python；SHell

8 數據倉庫Hive

8.1 概述

OLAP分析：多維數據分析

8.2 Hive簡介

傳統的數據倉庫即是負責存儲也負責分析

Hive本身不支持存儲也不支持分析，它只相當于給了用戶一個編程接口，一個編程的語言，讓用戶通過類sql語言HiveQL去編寫分析需求，

它是架構在Hadoop核心組件HDFS和MapReduce之上的

Hive兩個特性：采用批處理方式處理海量數據；Hive提供了一系列ETL工具；

Pig類似Hive，但是區別是它是輕量級的，做實時輕量級分析而不是大規模海量數據的批處理，Pig主要用于數據倉庫的ETL環節

HBase是可以支持實時交互式查詢的數據庫，彌補HDFS只能追加不能修改，不支持隨機讀寫的缺陷

Mahout，很多機器學習算法，Mahout都幫你實現了，你自己不用編寫基礎算法代碼了，能夠幫助企業分析人員快速構建BI應用

Facebook是Hive數據倉庫的開發者,開源貢獻給Apache

Hive對外訪問接口：CLI，一種命令行工具；HWI，Hive Web Interface，是hive的web接口；JDBC和ODBC；Thrift Server，基于THrift架構開發的接口，允許外界通過這個接口實現對Hive的RPC調用

驅動模塊Driver：包含編譯器，優化器，執行器，負責把用戶輸入的HQL轉換為MapReduce作業

元數據存儲模塊Metastore：就是來存儲元數據的，是一個獨立的關系數據庫，這個關系數據庫可以是hive自帶的derby，也可以是其他數據庫比如MySQL

Karmasphere、Hue、Qubole等都能訪問Hive，尤其是Qubole提供了一種數據倉庫即服務的功能，可以通過Quble的方式把數據倉庫部署到AWS云計算平臺上，直接以服務的方式提供給你，你企業本身不需部署

Hive HA基本原理：Hive很多時候表現不穩定，HA來解決，用多個Hive實例構建資源池，把資源池通過HAProxy提供給用戶

8.3 HQL轉換MapReduce的工作原理

連接操作在前章已經講過了如何用MapReduce實現

當啟動MapReduce程序時，Hive本身是不會生成MapReduce程序的

需要通過一個標識“Job執行計劃”的xml文件驅動執行內置的、原生的Mapper模塊和Reducer模塊

Hive也不用和JobTracker部署在同一節點，這要互相可以通信就可以初始化MapReduce任務

通常在大型集群，會有專門的網關機來部署Hive

8.4 Impala

類似Hive的數據分析，性能高3-30倍，是幫你實時交互性查詢功能

Impala是Cloudera開發新型查詢系統，可以支持PB級數據，數據可以存在HDFS或HBase，都可以通過Impala查詢

Impala運行依賴于Hive元數據，Impala不是獨立運行的

Impala最初設計是參考谷歌公司的Dremel系統并做了很多改進

Impala采用了與商業并行關系數據庫類似的分布式查詢引擎，可以直接與HDFS和HBase進行交互查詢

虛線部分是Impala組件，但是Impala不是單獨部署的，實線部分是其他的組件HDFS HBase Hive

Impala主要3個組件：

  Impalad負責查詢任務：三個模塊，Query Planner查詢計劃器、Query Coordinator查詢協調器、Query Exec Engine查詢執行引擎；任務是負責協調客戶端提交的查詢請求的執行；與HDFS ND運行在同一節點，大數據分析一定要遵循計算向數據靠攏，所以肯定是注入到數據節點上就近分析數據；給其他Impalad分配任務以及收集其他Impalad的執行結果匯總；Impalad也會執行其他Impalad分配的任務對本地hdfs和hbase里面的數據進行操作；

  State Store負責維護元信息和狀態信息：每個查詢提交，系統會創建個Statestored進程，來跟蹤各個節點執行進度以及健康狀況；負責收集分布在集群各個Impalad進程的資源信息用于查詢調度

  CLI命令行接口，同時也提供其他接口包括Hue、JDBC及ODBC

Impala的元數據是直接存儲在Hive中的，它借助Hive來存儲Impala的元數據

Impala采用和Hive采用相同元數據、SQL語法，ODBS驅動和用戶接口

在一個Hadoop平臺上可以統一部署Hive和Impala等分析工具，實現在一個平臺上可以同時滿足批處理和實時查詢

---

Impala查詢執行過程

00 當用戶提交查詢前，Impala先創建一個負責協調客戶端提交查詢的Impalad進程，該進程會向Impala State Store提交注冊訂閱信息，State Store會創建一個statestored進程，statestored進程通過創建多個線程來處理Impalad的注冊訂閱信息

01 用戶通過CLI客戶端提交查詢到Impalad進程，Impalad的Query Planner對SQL語句解析，生成解析樹，Planner把這個查詢的解析樹編程若干PlanFragment，發送到Query Coordinator

02 Query Coordinator查詢MySQL元數據庫中獲取元數據，從HDFS的名稱節點中獲取數據地址，以得到存儲這個查詢相關數據的所有數據節點

03 Coordinator初始化相應Impalad上的任務執行，即把查詢任務分配給所有存儲這個查詢相關數據的數據節點

04 Query Executor通過流式交換中間輸出，并由Query Coordinator匯聚來自各個impalad的結果

05 Coordinator把匯總后的結果返回給CLI客戶端

---

Impala和Hive比較

1. Hive適合長時間的批處理查詢分析，而Impala適合實時交互式SQL查詢

2. Hive依賴MapReduce計算框架，Impala把執行計劃表現為一顆完整的執行計劃樹，直接分發執行計劃到各個Impalad執行查詢

3. Hive執行時候如果內存放不下數據就使用外存，以保證查詢能順序執行完成；Impala在遇到內存放不下數據時，不會利用外存所以impala目前處理查詢會受到一定限制

1.Hive和Impala使用相同的存儲池，都支持把數據存在HDFS和HBase中

2.Hive和Impala都使用相同元數據

3.Hive和Impala對sql的解釋處理比較類似，都是通過詞法分析生成執行計劃

總結下，  Impala的目的不是替換現有的MapReduce工具，實際生產中，可以組合使用，用hive來處理數據，處理結果用impala查詢

8.5 Hive編程實踐

hadoop安裝好了之后就有了HDFS和MapReduce，此外Hive Hbase等等都要額外安裝

然后針對單機模式、偽分布式、分布式模式不同配置hive即可，修改hive-site.xml實現，如果不存在，可以參考$HIVE_HOME/conf目錄下的hive-default.xml.template創建

用HQL完成wordcount

9 Hadoop再探討

9.1 Hadoop的優化和發展

Hadoop剛推出的時候的局限和不足：

  抽象層次低，需人工編碼

表達能力有限

  開發者自己管理job間的依賴關系

  難以看到程序的整體邏輯

  執行迭代操作效率低

  資源比較浪費

  實時性差

之后業界學界進行改進，

  一方面，兩大核心組件的架構設計改進，演進為MapReduce2.0和HDFS2.0

  另一方面，不斷豐富Hadoop生態系統，包括Pig、Tez、Spark和Kafka等

9.2 HDFS2.0的新特性

HDFS HA  解決單點故障

HDFS Federation  解決3個問題：水平擴展問題，系統整體性能受限于單個名稱節點的吞吐量，難以資源隔離

多個名稱節點之間互相獨立，且向后兼容，單名稱節點的架構可以無縫遷移過來，共享塊池，構建全局命名空間，一般采用客戶端掛在表的方式對各個命名空間相關數據進行共享和訪問，通過訪問不同的掛載點訪問不同的子命名空間

9.3 新一代資源管理器YARN

MapReduce1.0缺陷：

  存在單點故障：只有一個JobTracker負責整個作業的調度、管理、監控

  JobTracker“大包大攬”導致任務過重

  容易出現內存溢出：MapReduce1.0在分配資源的時候只考慮MapReduce任務數，而不考慮內存cpu等資源，就是按照人頭劃分，不管高矮胖瘦，一旦有個很耗內存的任務，馬上導致內存溢出

  資源劃分不合理：把cpu內存打包強行劃分slot再劃分2部分為map slot和reduce slot，兩種slot不通用，導致資源浪費

YARN設計思路：

MapReduce1.0即是計算框架也是資源管理調度框架

Hadoop2.0以后把MapReduce1.0中資源調度的部分單獨抽離出來形成YARN

YARN是一個純粹的資源管理調度框架

被剝離資源管理調度功能的MapReduce框架成為MapReduce2.0，它是運行在YARN之上的純粹的計算框架，不再負責資源調度

---

YARN體系結構

ResourceManager：處理客戶端請求；啟動/監控ApplicationMaster；監控NodeManager；資源分配和調度

ApplicationMaster：為應用程序申請資源，并分配給內部任務；任務調度、監控與容錯

NodeManager：單個節點上的資源管理；處理來自ResourceManager的命令；處理來自ApplicationMaster的命令

ResourceManager（RM）：是一個全局的資源管理器，負責整個系統的資源管理和分配，主要包含兩個組件，即調度器（Scheduler）和應用程序管理器（Applications Manager）

  調度器接收來自ApplicationMaster的應用程序資源請求，把集群中的資源以“容器”的形式分配給提出申請的應用程序，容器的選擇通常會考慮應用程序所要處理數據的位置，進行就近選擇實現“計算向數據靠攏”

    容器（Container）作為動態資源分配單位，每個容器中都封裝了一定數量的cpu內存磁盤等資源，從而限定每個應用程序可以使用的資源量

    調度器被設計成是一個可插拔的組件，YARN不僅自身提供了很多直接可用的調度器，也允許用戶自定義調度器

  應用程序管理器負責系統中所有應用程序的管理工作，主要包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態并在失敗時重新啟動等

ApplicationMaster：ResourceManager接收用戶提交的作業，按照作業的上下文信息及從NodeManager收集來的容器狀態信息，啟動調度過程，為用戶作業啟動一個ApplicationMaster，  ApplicationMaster也是運行在容器當中的

  當用戶作業提交時，ApplicationMaster和ResourceManager協商獲取資源，ResourceManager會以容器的形式為ApplicationMaster分配資源

  把獲得的資源二次分配給內部的各個任務（Map或Reduce任務）

  與NodeManager保持交互通信，進行應用程序的啟動、運行、監控或停止，監控申請到的資源使用情況，對所有任務的執行進度和狀態進行監控，并在任務發生失敗時執行失敗恢復即重新申請資源重啟任務

  定時與ResourceManager發送心跳信息，報告資源的使用情況和應用的進度信息

  當作業完成時，ApplicationMaster向ResourceManager注銷容器執行周期完成

NodeManager：是駐留在一個YARN集群中的每個節點上的代理，主要負責如下工作：

  容器生命周期管理

  監控每個容器資源使用情況

  以心跳方式向ResourceManager保持通信

  向ResourceManager匯報作業的資源使用情況和每個容器的運行狀態

  跟蹤節點健康狀況

  接收來自ApplicationMaster的啟動/停止容器的各種請求

NodeManager主要負責管理抽象的容器，只處理與容器相關的事情，不具體負責每個任務（Map任務、Reduce任務或其他計算框架的任務）自身狀態的管理，因為這些工作由ApplicationMaster完成的，ApplicationMaster會不斷與NodeManager通信來掌握各個任務的執行狀態

YARN的組件實際上不是獨立的，是和Hadoop組件統一部署的

---

YARN工作流程

1 用戶編寫客戶端應用程序向YARN提交應用程序

2 YARN中的ResourceManager負責接收和處理來自客戶端的請求，為應用程序分配一個容器，在該容器中啟動一個ApplicationMaster

3 ApplicationMaster被創建后會首先向ResourceManager注冊

4 ApplicationMaster采用輪詢的方式向ResourceManager申請資源

5 ResourceManager會以“容器”的形式向提出申請的ApplicationMaster分配資源

6 在容器中啟動任務（運行環境、腳本）

7 各個任務向ApplicationMaster匯報自己的狀態和進度

8 應用程序運行完成后ApplicationMaster向ResourceManager的應用程序管理器注銷并關閉自己，釋放自己獲取到的資源

---

YARN框架和MapReduce1.0框架比對

從MapReduce1.0框架發展到YARN框架，客戶端并沒有發生變化，其大部分調用API及接口都保持兼容，因此，原來針對Hadoop1.0開發的代碼不用太大改動就可以放到Hadoop2.0上執行

優勢：

  大大減少了承擔中心服務功能ResourceManager的資源消耗

  ApplicationMaster來完成需要大量消耗資源的任務調度和監控

  多個作業對應多個ApplicationMaster實現了監控分布化

MapReduce1.0既是一個計算框架也是個資源調度框架，但是只支持MapReduce編程模型

YARN是一個純粹的資源調度框架，在它上面可以運行包括MapReduce在內的不同類型的計算框架，只要編程實現相應的ApplicationMaster，比如可以在YARN上運行Storm框架，為什么YARN可以為不同框架提供資源調度呢，核心是因為ApplicationMaster是可替換模塊

---

YARN的發展目標

要實現一個集群多個框架：在一個YARM框架之上搭建同一個集群，可以同時運行各種計算框架比如MapReduce、Spark、Storm、Tez、Graph等等，由YARN框架為上層框架提供統一的資源調度管理功能，并且根據負載，調整各自占用資源，實現集群資源共享和資源彈性伸縮，實現在一個集群上不同應用負載混搭，有效提高了集群的利用率，不同計算框架可以共享底層存儲，避免數據集跨集群移動

為什么：

  一個企業當中存在不同的業務應用場景，需要采用不同的計算框架

  MapReduce實現離線批處理

  用Impala實現實時交互式查詢分析

  使用Storm框架實現流失數據實時分析

  使用Spark實現迭代計算

為了避免不同類型應用之間互相干擾，企業把內部集群切分為多個集群，分別安裝不同計算框架，即一個框架一個集群，這樣帶來新問題，集群資源利用率低數據無法共享維護代價高

10 Spark

10.1 Spark概述

Spark最初由伯克利大學的AMP實驗室于2009年開發，是基于內存計算的大數據并行計算框架，可用于構建大型的低延遲的數據分析應用程序

和Hadoop不同，Hadoop是基于磁盤的大數據計算框架，Spark是基于內存的大數據計算框架

2013年Spark加入Apache孵化器項目后發展迅速，如今已成為Apache軟件基金會最重要的三大分布式計算系統開源項目之一（Spark、Storm、Hadoop）

Spark的成名之路和Hadoop差不多，2014年時候打破hadoop的基準排序記錄，用206個節點花了23分鐘100T數據排序，hadoop是2000節點72分鐘100TB，Spark用了十分之一的計算資源獲得了3倍的速度

Spark特點：

  運行速度快：使用DAG執行引擎以支持循環數據流與內存計算，與MapReduce不一樣，MapReduce是代用一輪又一輪的迭代方式去執行，而Spark是采用有向無環圖DAG的方式

  容易使用：支持Java、Scala、Python和R語言，也支持Spark Shell進行交互式編程

  通用性：整個Spark作為一個完整的生態系統，它提供了完整而強大的技術軟件棧，包括SQL查詢、流式計算、機器學習和圖算法組件，提供了非常多的軟件套裝，包括支持內存計算的Spark Core，包括可以完成sql查詢的Spark SQL，以及可以完成流式計算的Spark Streaming還有完成機器學習的組件Spark MLib，另外一個是完成圖計算的軟件GraphX

  運行模式多樣：可運行于獨立的集群模式，可運行于Hadoop中，也可以運行于Amazon EC2等云環境中，并且可以訪問HDFS、Cassandra、HBase、Hive等多種數據源

Scala是一門現代的多范式編程語言，平滑的集成面向對象和面向函數式編程這兩種風格，,運行于java平臺，兼容現有java程序

Scala特性：

  Scala具有強大的并發性，支持函數式編程，可以更好的支持分布式系統

  Scala語法簡潔能夠提供優雅的API

  Scala兼容Java，運行速度快，且能融合到Hadoop生態圈

Scala是Spark主要編程語言，但Spark還支持Java、Python、R作為編程語言

Scala的優勢是提供REPL（Read-Eval-Print-Loop，交互式解釋器），提高開發效率

---

Spark和Hadoop對比

Hadoop缺陷：

  表達能力有限

  磁盤IO開銷大

  延遲高

  任務之間銜接需要IO開銷

  在前一個任務執行完成之前，其他任務就無法開始，難以勝任復雜、多階段的計算任務，尤其是機器學習數據挖掘等需要反復迭代的計算

Spark相比于Hadoop MapReduce的優勢：

  Spark的計算模式也屬于MapReduce，但不局限于Map和Reduce操作，還提供了了多種數據集操作類型，編程模式更加靈活

  Spark基于內存計算，將中間結果放入內存，迭代計算效率更高

  Spark是基于DAG有向無環圖的任務調度執行機制，要由于Hadoop MapReduce的迭代執行機制（Tez框架也是基于DAG）

10.2 Spark生態系統

對3種場景，可以用MapReduce+Impala+Storm滿足需求

但是帶來問題：

  不同場景的輸入輸出數據無法做到無縫共享，通常需要進行數據格式的轉換

  不同的軟件需要不同的維護團隊，使用成本大

  難以對同一個集群的各個軟件統一資源調度，YARN可以，但是YARN支持計算框架也是有限

Spark設計：遵循“一個軟件棧滿足不同應用場景”的理念，逐漸形成一套完整的生態系統

Spark可以部署在YARN上，為企業提供一站式的大數據解決方案

Spark生態系統足以應對上述3中場景，即同時支持批處理、交互式查詢和流數據處理

Spark生態系統已經成為伯克利技術軟件棧BDAS（Berkeley Data Analytics Stack）的重要組成部分

10.2 Spark運行架構

基本概念和架構設計

RDD，Resillient Distributed Dataset,彈性數據集，是分布式內存的一個抽象概念，提供了一種高度受限的共享內存模型。把數據從磁盤讀出來后被封裝成RDD，然后可以對RDD里面的數據進行分區，RDD里面相關的分析數據可以放到不同的數據節點來并行計算

DAG，Directed Acyclic Graph，有向無環圖，反應RDDD之間的依賴關系

Executor，是運行在工作節點（workernode）的一個進程，負責運行task

Application：用戶編寫的Spark程序

Task：運行在Executor上的工作單元

Job：一個job包含多個RDD以及作用于RDD上面的各種操作

Stage：是job的基本調度單位，一個Job會分為多組Task，每組Task被成為Stage，或者被成為TaskSet，代表了一組關聯的，相互之間沒有shuffle依賴關系的任務組成的任務集

集群資源管理器可以用它自帶的，也可以用Mesos和YARN框架，是Spark最核心的組件

與Hadoop MapReduce相比，Spark采用的executor有2個優點：

  利用多線程來執行具體任務減少任務的啟動開銷

  Executor中有一個BlockManager存儲模塊，會將內存和磁盤視共同作為統一存儲設備，有效減少IO開銷，如果內存空間足夠大的時候，優先寫內存，寫滿后才會溢寫到磁盤Spark運行基本流程

01 為應用構建起基本運行環境，即由Driver創建一個SparkContext進行資源申請、任務的分配和監控

02 資源管理器為Executor分配資源，并啟動Executor進程

03 SparkContext根據RDD的依賴關系構建DAG圖，DAG圖提交DAGScheduler解析為Stage，然后把一個個TaskSet提交給底層調度器TaskScheduler處理

     Executor向SparkContext申請Task，Task Scheduler將Task發放給Executor運行并提供應用程序代碼

04 Task在Executor上運行把執行結果反饋給TaskScheduler，然后反饋給DAGScheduler,運行完畢后寫入數據并釋放所有資源

Spark運行架構特點：

  每個Application都要自己專屬的Executor進程，并且該進程在Application運行期間一直駐留。Executor以多線程的方式運行Task

  Spark運行過程與資源管理器無關，只要能獲取Executor并能保持通信即可

  Task采用了數據本地性和推測數據執行等優化機制

---

RDD概念

設計背景：許多迭代計算（比如機器學習、圖計算等）和交互式數據挖掘工具，共同之處是不同計算階段之間會重用中間結果；目前MapReduce框架都是把中間結果寫磁盤，帶來大量的數據復制、磁盤io和序列化開銷

RDD就是滿足這種需求而出現的，它提供了一個抽象的數據結構

我們不必擔心底層數據的分布式特性，只需將具體的應用邏輯表達為一系列轉換處理

不同RDD之間的轉換操作形成依賴，可以實現管道化，避免中間數據存儲

一個RDD就是一個分布式對象集合，本質上是一個只讀的分區記錄集合，每個RDD可分為多個區，每個分區就是一個數據集片段，并且一個RDD的不同分區可以被保存到集群的不同節點上，從而可以在集群中的不同節點間進行并行計算

RDD提供了一種高度受限的共享內存模型，即RDD是只讀的記錄分區的集合，不能直接修改，只能基于穩定的物理存儲中的數據集創建RDD，或者通過在其他RDD上執行確定的轉換操作（如map、join和group by）而創建得到新的RDD

RDD提供了一組豐富的常見的數據運算，分為“動作”（Action）和“轉換”（Transformation)兩種類型

RDD提供的轉換接口都非常簡單，都是類似map,filter,groupby,join等粗粒度的數據轉換操作，而不是針對某個數據項的細粒度修改（不適合網頁爬蟲）

表面上RDD的功能很受限、不夠強大，實際上RDD已經被實踐證明可以高效地表達許多框架的編程模型（比如MapReduce、SQL、Pregel）

Spark用Scala語言實現了RDD的API，程序員可以通過調用API實現對RDD的各種操作

這一些列處理成為一個Lineage（血緣關系），即DAG拓撲排序的結果，反應了不同RDD之間相互依賴關系，完全可以實現管道化處理

優點：惰性調用、管道化、避免同步等待、不需要保存中間結果、每次操作變得簡單

---

RDD特性

RDD是整個Spark的核心

Spark采用RDD以后能夠實現高效計算的原因：

  高效的容錯性：

    現有容錯機制：數據復制或記錄日志  代價昂貴

    RDD具有天生的容錯性：血緣關系、重新計算丟失分區、無需回滾系統、重算過程在不同節點間并行、只記錄粗粒度的操作

  中間結果持久化到內存，數據在內存中的多個RDD之間傳遞，避免了不必要的磁盤開銷

  存放的數據可以是Java對象，避免了不必要的序列化和反序列化開銷

---

RDD的依賴關系和運行過程

RDD之間的依賴關系（寬依賴、窄依賴）是劃分Stage的依據

窄依賴：表現為一個或多個父親RDD的分區對應于一個子RDD的分區

寬依賴：表現為一個父RDD的一個分區對應一個子RDD的多個分區

Spark通過分析各個RDD的依賴關系生成DAG再通過分析各個RDD中分區之間的依賴關系來決定如何劃分Stage

具體方法是，在DAG中進行反向解析，遇到寬依賴就斷開，寬依賴一般都是存在shuffle的情況，遇到窄依賴就把當前RDD加到stage中，將窄依賴盡量劃分在同一個Stage，可以實現流水線計算，從而使得數據可以直接在內存中進行交換，避免磁盤io開銷

劃分完的stage有2中類型：ShuffleMapStage、ResultStage

  ShuffleMapStage，不是最終stage，在它之后還有其他stage，所以他的輸出一定需要經過Shuffle過程，并作為后續Stage的輸入；這種Stage以Shuffle為輸出邊界，其輸入邊界可以從外部獲取數據，也可以是另外一個ShuffleMapStage的輸出，其輸出可以是另一個stage的開始;一個job中可能有也可能沒有該類型stage

  ResultStage,最終stage，沒有輸出，而是直接產生結果或者存儲，這種stage是直接輸出結果，其輸入邊界可以是從外部獲取數據也可以是另一個ShuffleMapStage；每個job必定至少含有一個這個類型stage

RDD運行過程：首先第一步是創建RDD對象，從數據源去讀取相關數據生成RDD對象；SparkContext負責計算RDD之間的依賴關系，構建DAG;DAGScheduler負責把DAG圖分解成多個Stage，每個Stage中包含了多個Task，每個Task會被TaskScheduler分發給各個WorkderNode上的Executor去執行

10.4 Spark SQL

Shark即Hive on Spark，為了實現和Hive兼容，Shark在HiveQL方面重用了Hive中HiveQL的解析、邏輯執行計劃翻譯、執行計劃優化等邏輯，可以近似認為僅將物理執行計劃從MapReduce作業替換為Spark作業，通過Hive的HiveQL解析，把HiveQL翻譯成Spark上的RDD操作

為了兼容hive，導致問題：執行計劃完全依賴于hive，不方便添加新的優化策略；因為Spark是線程級并行，而Hive是進程級并行，因此Spark在兼容Hive的實現上存在線程安全問題，導致Shark不得不用另外一套獨立維護的打了補丁的Hive源碼分支

所以放棄Shark轉而Spark SQL

Spark SQL基本上繼承了Shark的功能并做了相當多的改進，Spark SQl在Hive兼容層面僅依賴HiveQL解析、Hive元數據，也就是，從HQL被解析成抽象語法樹（AST）起，就全部由Spark SQL接管了。Spark SQL執行計劃生成和優化都由Gatalyst（函數式關系查詢優化框架）負責

Spark SQL增加了SchemaRDD（即帶有Schema信息的RDD）使用戶可以在Spark SQL中執行SQL語句 SchemaRDD允許封裝更多數據源數據，可以RDD、Hive、HDFS、Cassandra、JSON  數據類型更多，可以完成更強大的分析功能 

備注：SchemaRDD在后來的Spark SQL演化為DataFrame；

10.5 Spark的部署和應用方式

Spark三種部署方式：Standalone  類似MapReduce1.0，自帶資源管理框架，slot為資源分配單位，不同的是不區分map slot和reduce slot；Spark on Mesos，Mesos和Spark有一定親緣關系；Spark on YARN

之前很多企業是采用Hadoop+storm部署的，這種部署比較繁瑣用Spark架構的

注意，這種部署的架構，Spark Streaming無法實現毫秒級的流計算,只是秒級，因此，對于需要毫秒級實時響應的企業應用而言，仍需要采用專業流計算框架如Storm

最后就是混合部署，由于Hadoop生態中一些組件所實現的功能，Spark無法替代，比如Storm；而且現有企業很多基于Hadoop開發，完全轉移到Spark上需要一定成本

不同框架統一部署在YARN上，可以實現資源按需伸縮；不同負載應用混搭，集群利用率高，可以削峰填谷；共享數據存儲，避免數據跨集群遷移

10.6 Spark編程實踐

Spark的安裝和啟動

Spark需要java環境和hadoop環境，然后進入官網下載，解壓下來設置環境變量就好了

運行模式：單機模式、偽分布式、分布式

Spark Shell僅支持Scala、Python兩種

在Spark程序中必須創建個SparkContext對象，該對象是Spark程序的入口，負責創建RDD、啟動任務等，但是在SparkShell中，默認是自動創建了，可以通過sc變量進行訪問在一條代碼中同時使用多個API，連續進行計算，稱為鏈式操作，不僅可以使Spark代碼更加簡潔，也優化了計算過程

Spark應用程序

對代碼打包調試運行，支持Scala、python、R、Java，不同工具打包不一樣

11 流計算

11.1 流計算概述

靜態數據 ：數據倉庫的數據就是典型的靜態數據

流數據：近年來，在web應用、網絡監控、傳感檢測等領域，興起了一種新的數據密集型應用-流數據，即數據以大量、快速、時變的流形式持續到達

比如PM2.5檢測、電子商務網站用戶點擊流，這些數據必須要馬上立刻實時分析才能夠捕獲它的商業價值，要迅速的給出相關的分析結果，這兩種類型都是非常典型的流式數據產生方式，都是實時產生，數據像流水一樣實時不斷的到達，叫做流式數據，簡稱流數據

流數據特征：

  數據快速持續到達，潛在大小也許是無窮盡的

  數據來源眾多，格式復雜

  數據量大，但是不十分關注存儲，一旦被處理，要么被丟棄，要么被歸檔存儲

  注重數據整體價值，不過分關注個別數據

  數據順序顛倒，或者不完整，系統無法控制將要處理的新到達的數據元素的順序

流計算概念以及典型框架

流計算：實時獲取不同數據源的海量數據經過實時分析處理，獲得有價值的信息

流計算基本理念：數據的價值隨著時間的流逝而降低，如用戶點擊流；因此，當事件出現就應該立即進行處理，而不是緩存起來進行批量處理；就需要一個低延遲、可擴展、高可靠的處理引擎，被成為流計算系統

流計算系統要求：高性能、海量式、實時性、分布式、易用性、可靠性

業界為滿足需求開發的框架分為三類：

  商業級：IBM InfoSphere Streams；IBM StreamBase；

  開源框架：Twitter Storm；Yahoo！S4（Simple Scalable Streaming System）；Samza；Spark Streaming

  公司為支持自身業務開發的流計算框架：Facebook、百度、淘寶

11.2 流計算處理流程開源分布式日志采集系統：facebook scribe；領英 kafka；hadoop flume；hadoop chukwa

11.3 流計算的應用

11.4 開源流計算框架Storm

開源框架Storm

Storm是推特公司開發的一個框架，是開源免費的

Storm對于實時計算的意義，就相當于hadoop對于批處理的意義

可以簡單高效可靠的處理流數據，支持多種編程語言，處理非常靈活

可以非常方便的和現有的數據庫產品還要一些隊列產品進行融合，從而開發出非常強大的流計算系統

推特公司分層數據處理架構采用Storm和Hadoop結合，實時部分借助Storm和Cassandra，批處理部分借助hadoop和ElephantDB，對實時處理結果和批處理結果進行了無縫的融合

storm應用領域非常多包括：實時分析、在線機器學習、持續計算、遠程RPC、數據提取、轉換加載等等

特點：  整合性、簡易API、可擴展、可靠消息處理、支持各種編程語言、快速部署、免費開源

---

Storm設計思想

Storm主要術語：

還沒有全文機構定義，不翻譯

tuple是一堆值，每個值有一個名字，并且每個值可以是任意類型

tuple本來應該是Key-Value的Map，由于各個組件間傳遞的tuple的字段名稱已經事先定義好了，所以tuple只需要按序填入各個value，所以就是個value list

Spout：Storm認為每個Stream都有一個源頭，并把這個源頭抽象為Spout，中文是自來水龍頭

通常Spout會從外部數據源（隊列、數據庫等）讀數據，然后封裝為Tuple形式，發送到Stream中

Spout是一個主動角色，在接口內有個nextTuple函數，Storm框架會不停的調用該函數Bolt是一個被動角色，其接口有一個execute（tuple input）方法，在接收到消息之后就會調用該函數，用戶可以在此方法中執行自己的處理邏輯Topology相當于MapReduce的job，包含用戶的處理邏輯，Topology里面每個組件都是并行運行的

Storm運行方式與hadoop類似，hadoop運行的是MapReduce作業，而storm運行的是Topology

不同的是mapreduce處理完就結束，topology是持續不斷處理除非人工結束

Storm集群采用“Master-Worker”的節點方式，Master節點運行名為Nimbus的后臺程序負責在集群范圍內分發代碼、為Worker分配任務和監測故障，Worker節點運行名為Supervisor的后臺程序，負責監聽分配給它所在機器的工作，即根據Nimbus分配的任務來決定啟動或停止worker進程，一個worker節點上運行多個worker進程

中間加入zookeeper是為了保證高可用和快速故障恢復，借助zookeeper，使得Nimbus進程或者Supervisor進程意外終止，重啟也能讀取、恢復之前的狀態并繼續工作，使得storm極其穩定

每個worker進程都屬于一個特定Topology，每個Supervisor節點的worker可以是多個，每個worker對Topology中的每個組件（Spout或Bolt）運行一個或者多個executor線程來提供task的運行服務

實際的數據處理由task完成

所有的Topology任務的提交必須在storm客戶端節點上進行，提交后，由Nimbus節點分配給其他Supervisor節點進行處理

Nimbus節點首先將提交的Topology進行分片，分成一個個task，分配給相應的Supervisor，并將Task和Supervisor相關信息提交給zookeeper集群

Supervisor會去zookeeper集群上認領自己的task，通知自己的worker進程進行tak的處理

11.5 Spark Streaming、Samza以及三種流計算框架的比較

Spark是面向批處理的實時計算框架，基于內存的計算，實時性好

如何將面向批處理的框架來處理流數據？基本原理是將實時數據流以時間片（秒級）為單位進行拆分，然后經spark引擎以類似批處理的方式處理每個時間片數據

Spark Streaming可以整合多種數據源如Kafka、Flume、HDFS、甚至是普通的TCP套接字經過處理后的數據可存儲至文件系統、數據庫，或顯示在儀表盤里

Spark Streaming是把數據流抽象為DStream（Discretized Stream，離散化數據流），表示連續不斷的數據流，每段數據流轉換為RDD處理，對Dstream的操作最終都轉變為RDD的操作

Spark Streaming  VS Storm

   Spark Streaming無法實現毫秒級流計算

   相比于Storm，RDD數據集更容易做搞笑的容錯處理

   Spark Streaming采用的小批量處理的方式使得它可以同時兼容批量和實時數據處理的邏輯和算法，因此，方便了一些需要歷史數據和實時數據聯合分析的特定應用場合

Samza：一個作業（job）是對一組輸入流進行處理轉換為輸出流的程序；分區，它既不是Tuple也不是Dstream而是一條條消息；任務，一個作業會被進一步分割成多個任務（Task）來執行，其中，每個任務處理作業中的一個分區，分區之間沒有定義順序，從而允許每個任務獨立運行；YARN調度器負責把任務分發給各個機器，最終，一個工作中的多個任務會被分發到各個機器進行分布式并行處理

數據流圖

Samza架構：

  流數據層：負責數據流的收集分發，流處理層和執行層都被設計為可插拔的，開發人員可以使用其他框架代替YARN和Kafka

  執行層

  處理層

處理分析過程

Samza客戶端需要執行一個Samza作業時，它會向YARN的ResouceManager提交作業請求

ResourceManager通過與NodeManager溝通為該作業分配容器來運行Samza ApplicationMaster

Samza ApplicationMaster進一步向ResouceManager申請運行任務的容器

獲得容器后，Samza ApplicationMaster與容器所在的NodeManager溝通啟動該容器并運行samza task runner

samza task runner負責執行具體的samza任務，完成流數據處理分析

Stom、Spark Streaming和Samza

編程靈活性來講Storm是比較靈活的選擇

當需要在一個集群中把流計算、圖計算、機器學習、SQL查詢分析等進行結合時候選用Spark Streaming

當有大量的狀態需要處理時，比如每個分區都有數十億個元組，則可以選擇Samza

11.6 Storm編程實踐

storm需要的環境：ceontos、storm、jdk1.7、zookeeper、python

安裝過程：安裝JAVA、安裝zookeeper、安裝storm、關閉storm

具體過程略

12 圖計算

12.1 圖計算簡介

圖計算是專門針對圖結構的數據的處理：

  現實世界中，許多大數據都是以大規模圖或網絡的形式呈現，比如社交網絡數據、傳染病傳播途徑、交通事故對路況影響

  許多非圖的大數據，也常常被轉換為圖模型后進行分析

  圖數據結構能非常好的表達數據之間的關聯性

  關聯性計算是大數據計算的核心–通過獲得數據的關聯性，可以從噪音很多的海量數據中抽取有用的信息

典型應用，相似用戶商品推薦、熱門話題追根溯源

傳統圖計算算法存在的典型問題：

  常常表現出非常差的內存訪問局限性

  針對單個頂點的處理工作過少

  計算過程伴隨者并行度的改變

針對這些問題，后來專門開發的軟件就可以解決：

  為特定的圖應用定制相應的分布式實現，但是通用性不好

  基于現有的分布式計算平臺進行圖計算，比如mapreduce這種針對批處理的用來進行圖計算，性能和易用性都沒法達到最優，這種單輸入兩階段粗粒度的計算框架面對圖結構力不從心，圖計算特征是多次迭代稀疏結構和細粒度數據

  使用單機的圖算法庫BGL、LEAD、NetworkX、JDSL、Standford GraphBase和FGL等，但是這些都是單機的，面對大規模計算問題表現出局限性

  使用已有的并行圖計算系統，比如，Parallel BGL和CGM Graph，實現了很多并行圖算法，但是這些在有些機制方面并沒有完善的設計，比如尤其是沒有很好的容錯

正因為如此才誕生圖計算通用軟件 ：

  基于遍歷算法的、實時的圖數據庫，比如Neo4j、OrientDB、DEX、Infinite Graph

  以圖頂點為中心的、基于消息傳遞批處理的并行引擎，比如GoldenOrb、Giraph、Pregel、Hama

BSP（Bulk Synchronous Parallel Computing Model）模型叫整體同步并行計算模型或者簡稱為大同步模型，通過網絡連接起來的處理器，一系列的全局超步

三個組件：

  局部計算，每個處理器只讀取本地內存中的值，各個處理器之間都是異步并行執行

  通訊，不同的處理器計算完成之后需要通過消息的方式交換數據，為了更好的完成下次迭代計算，put操作get操作

  柵欄同步，處理器計算有快慢，設置路障類似的，等待所有執行完畢才執行下次迭代

12.2 Pregel簡介

Pregel是谷歌公司發布的一款商業圖計算產品

發布Pregel之前，03 04年谷歌發布了GFS、MapReduce、BigTable，hadoop都是對這三個的開源實現，這三個產品成為云計算和大數據的基石

谷歌在后hadoop時代的新“三駕馬車”，Caffeine、Dremel、Pregel，Caffeine幫助谷歌快速實現大規模網頁索引的構建，Dremel，實時的交互式分析產品，采用只讀嵌套型的獨特數據結構，支持PB級別的數據分析只要2到3秒鐘響應，Pregel，基于BSP模型實現的并行圖處系統

12.3 Pregel圖計算模型

01 Pregel計算模型以有向圖作為輸入

02 有向圖的每個頂點都有一個String類型的頂點ID

03 每個頂點都有一個可修改的用戶自定義值與之關聯

04 每條有向邊都和其源頂點關聯，并記錄了其目標頂點id

05 邊上有一個用戶可修改的自定義值與之關聯

在每個超步S中，圖中的所有頂點都會并行執行相同的用戶自定義函數

每個頂點可以接收前一個超步（S-1）中發送給它的消息，修改其自身及射邊的狀態，并發送消息給其他頂點，甚至是修改整個圖的拓撲結構

邊并不是核心對象，在邊上不會運行相應的計算，只有頂點才會執行用戶自定義函數進行相應計算

傳遞消息的基本方法：遠程讀取、共享內存

而Pregel都沒有采用，而是采用消息傳遞模型，原因：

  消息傳遞有足夠的表達能力

  有助于提升系統整體性能，Pregel不需要遠程讀取，避免遠程讀取帶來的高延遲，消息傳遞是異步批量的方式，而共享內存方式高耦合制約擴展性

Pregel計算過程：

  01 Pregel的計算過程是由被成為“超步”的迭代組成的

  02 在每個超步中，每個頂點都會并行執行用戶自定義函數

在Pregel計算過程中，一個算法什么時候結束是由所有頂點狀態決定

在第0個超步，所有頂點活躍

一個頂點不需要繼續執行進一步計算時就會把自己的狀態設置為“停機”

Pregel計算框架必須根據條件判斷來決定是否將其顯式喚醒進入活躍狀態

Pregel實例

12.4 Pregel的C++ API

Pregel已經預先定義好了一個基類–Vertex類

在Vertex類中，定義了三個值類型參數，分別表示頂點、邊和消息。每個頂點都有一個給定類型的值與之對應

編寫Pregel程序時候，compute是虛函數，要用戶自己定義處理邏輯

---

消息傳遞機制和Compiler

Pregel的消息傳遞機制：頂點之間的通訊是借助于消息傳遞機制來實現的，每條消息都包含消息值和需要到達的目標頂點id，注意目標頂點不一定是相連的，有可能經過多個邊才到達

在某個超步S中，一個頂點可以發送任意數量的消息，這些消息將在下個超步S+1中被其他頂點接收

Combiner：Pregel計算框架在消息發出去之前，Combiner可以將發送到同一個頂點的多個消息合并，大大減少了傳輸和緩存的開銷

默認情況下是不開啟Combiner的

只有在對計算結果無影響的情況下才能啟用Combiner，并不適用所有場景

當用戶打算開啟Combiner時候，可以繼承Combiner類并覆寫虛函數Combine()

通常只對那些滿足交換律和結合律的操作才可以開啟Combiner

---

Aggregator：提供了一種全局通信監控和數據查看的機制

在一個超步S中，每個頂點都可以向Aggregator發送一個數據，Pregel計算框架會對這些值進行聚合操作產生一個值，在下一個超步(S+1)中每個頂點都可以看到這個值

拓撲改變：

  對全局拓撲改變，Pregel采用了惰性協調機制

  對于本地的局部拓撲改變，是不會引發沖突的，頂點或邊的本地增減能夠立即生效，很大程度上簡化了分布式編程

輸入輸出都是靈活多變的

12.5 Pregel的體系結構

執行過程：在Pregel計算框架中，一個大型圖會被劃分成多個分區，每個分區都包含一部分頂點以及其為起點的邊，即子圖；一個頂點應該被分配到哪個分區上，是由一個函數決定的，系統默認是hash(D) mod N其中N為所有分區總數，id是頂點標識符，當然用戶也可以改寫不用哈希函數，采用固定分區函數后，可以根據頂點id快速判斷頂點屬于哪個分區

01 選擇集群中的多臺機器執行圖計算任務，有一臺機器會被選為Master其他機器作為Workder

02 Master會把一個圖分成多個區，并把分區分配到多個Worker。一個Worker會領到一個或多個分區，每個worker知道所有其他worker所分配到的分區情況

03 Master會把用戶輸入劃分成多個部分，然后，Master會為每個Worker分配用戶輸入的一部分。如果一個Worker從輸入內容加載到的頂點，剛好是自己所分配的分區中的頂點，就會立刻更新相應的數據結構，否則，該worker會根據加載到的頂點的id，把它發送到其所屬的分區所在的worker上，當所有的輸入被加載后，圖中所有的頂點被標記活躍狀態

04 Master向每個Worker發送指令，Worker收到指令后，開始運行一個超步，當一個超步中的所有工作都完成，Worker會通知Master并報告自己在下一步超步還處于活躍狀態的頂點的數量，每個分區worker都啟一個線程

05 計算過程結束后，Master會給所有的Worker發送指令，通知每個Workder對自己的計算結果進行持久化存儲

容錯性：

  Pregel采用檢查點機制實現容錯。在每個超步開始，Master會通知所有的Worker把自己管轄的分區的狀態寫入到持久化設備，狀態包括頂點值邊的值和接收的消息，一旦發生錯誤，從這個地方恢復

  Master會周期性的向每個Worker發送ping消息，Worker收到ping消息后會給Master一個反饋消息，每個worker上都保存了一個或多個分區的狀態信息

  當worker發生故障，它所維護的分區的當前狀態就會丟失

  master一旦檢測到workder故障失效后，會把失效worker的分區重新分配到其他worker上

---

Master、Worker和Aggregator

Worker，一般在執行過程中它的信息是保存在內存中，只有在超步開始時候才利用檢查點機制把分區狀態持久化，分區中每個頂點的狀態信息包括頂點當前值、出射邊列表、消息隊列、標志位；worker會對自己管轄的分區中的每個頂點進行遍歷，并調用頂點上的compute()函數，調用時候會把三個參數傳送給compute函數，頂點當前值、消息迭代器、出射邊迭代器；Pregel中，為了獲得更好的性能，“標志位”和輸入消息隊列是分開保存的，保存一份頂點值和邊的值，但是保存2份標志位和消息隊列，這兩份分別用于當前超步和下一個超步；如果一個頂點V在超步S接收消息表示V在下一個超步S+1中處于活躍狀態；發送消息，如果是自己機器，直接把消息放入到與目標頂點U對應的消息隊列中，遠程機器，不是馬上發過去，暫時緩存本地，當緩存中的消息數達到一個事先設置好的閾值，這些緩存消息會被批量異步發送出去，傳輸到目標頂點所在的Worker上，可以減少啟動開銷，也可以在緩存中combine，減少開銷

Master，扮演管家的角色，主要協調各Worker執行各個任務；Master維護著關于當前處于”有效“狀態的Worker信息，包括每個Worker的id和地址以及worker被分配到的分區信息；Master中保存這些信息的大小只與分區數量有關而與頂點和邊 的數量無關；Master向所有處于有效狀態的worker發送相同指令，然后等待worker回復，在指定時間沒有回應說明該worker失效，master會進入恢復模式；在每個超步中，圖計算的各種工作，會在”路障barrier“之前結束，包括輸入輸出、計算保存、檢查點恢復；Master在內部運行了一個http服務器來顯示圖計算過程的各種信息，比如圖大小、出度分布的柱狀圖、處于活躍的頂點數量、在當前超步的時間信息和消息數量、所有用戶自定義Aggregator的值；

Aggregator，聚合函數，在執行圖計算過程的某個超步S中，每個Worker會利用一個Aggregator對當前本地分區中包含的所有頂點值進行歸約，得到一個本地的局部歸約值；在超步S結束時，所有Worker會將所有包含局部歸約值的Aggregator的值最后匯總得到全局值，然后提交給Master；在S+1開始時，Master會將Aggregator的值發送給每個Worker

12.6 Pregel的應用實例——單源最短路徑

Dijkstra算法是解決單源最短路徑的貪婪算法

12.7 Hama的安裝和使用

Hama是google pregel的開源實現，pregel是個商業軟件

與hadoop適合于分布式大數據處理不同，Hama主要用于分布式的矩陣、圖、網格的計算

Hama是在HDFS上實現的BSP（Bulk Synchronous Parallel）計算框架，彌補Hadoop在圖計算能力上的不足

安裝過程是jdk環境，下載解壓縮配置環境即可

第13講 大數據在不同領域的應用

13.1 大數據應用概覽

互聯網：推薦系統

生物醫學：流行病預測、智慧醫療、生物信息學

物流：智能物流、中國智能物流骨干網-菜鳥

城市管理：智能交通、環保檢測、城市規劃、安防領域

金融：高頻交易、市場情緒分析、信貸風險分析

汽車領域：無人駕駛騎車

零售行業：發現關聯購買行為、客戶群體細分

餐飲行業：餐飲O2O

電信行業：電信客戶離網分析

能源行業：智能電網

體育娛樂：投拍影視作品、訓練球隊、預測比賽結果

安全領域：防御網絡攻擊、預防犯罪

政府領域：選舉

13.2 推薦系統

搜索引擎只能幫助我們查詢明確的需求

為了讓用戶從海量信息中高效的獲得自己所需信息，推薦系統應運而生。推薦系統是大數據在互聯網領域的典型應用.，他可以分析用戶的歷史記錄來了解用戶的喜好從而主動的為用戶推薦其感興趣的信息，滿足用戶的個性化推薦需求

推薦系統是自動聯系用戶和物品的一種工具，和搜索引擎相比，推薦系統通過研究用戶的興趣偏好，進行個性化計算，推薦系統可發現用戶的興趣點幫助用戶從海量信息中去發掘自己潛在的需求

推薦系統可以創造全新的商業和經濟模式，（例子：幫助實現長尾商品的銷售）

長尾理論：電子商務網站銷售種類繁多，雖然絕大多數商品都不熱門，但這些不熱門的商品總數量極其龐大，所累計的總銷售額將是一個可觀的數字，也許會超過熱門商品所帶來的銷售額

專家推薦和熱門推薦無法推薦長尾產品

個性化推薦可通過推薦系統來實現，推薦系統通過發掘用戶的行為記錄找到用戶的個性化需求，發現用戶潛在的消費傾向，從而將長尾商品準確的推薦給需要它的用戶，進而提升銷量，實現用戶與商家的雙贏

基于用戶的協同過濾UserCF

最知名的推薦算法

協同過濾分為基于用戶的協同過濾、基于物品的協同過濾

cf：Collaboration Filter

1992年提出，是推薦系統中最古老的算法，最基本的思想是趣味相投

UserCF算法實現的2個步驟：找到和目標用戶興趣相似的用戶集合；找到該集合中的用戶所喜歡的且目標用戶沒聽說過的物品推薦給目標用戶

主要是衡量用戶相似度的算法：比較多比如泊松相關系數、余弦相似度、調整余弦相似度

余弦相似度算法：

很多用戶并沒有對同樣的物品產生交集，相似度0，沒有必要浪費計算，設計一個物品到用戶的倒排表，最大程度的減少計算量

得到用戶間的相似度后，再使用如下公式

基于物品的協同推薦ItemCF

ItemCF是目前業界應用最多的算法，無論是亞馬遜還是Netflix，其推薦系統的基礎都是ItemCF算法，是給目標用戶推薦那些和他們喜歡的物品相似的物品。ItemCF算法主要分析用戶的行為記錄來計算物品之間的相似度

ItemCF算法基于的假設是物品A和物品B具有很大的相似度是因為喜歡物品A的用戶大多也喜歡物品B

計算物品之間的相似度；根據物品的相似度和用戶的歷史行為，給用戶生成推薦列表

UserCF和ItemCF比較：

UserCF適合新聞推薦、微博話題推薦等場景，其推薦結果在新穎性方面有優勢，缺點是隨著用戶數增大，計算復雜性越來越高，而且UserCF推薦結果相關性較弱，難以對推薦結果作出解釋容易受大眾影響而推薦熱門物品

ItemCF適合電子商務、圖書、電影等場景，可以利用用戶的歷史行為給推薦結果，更容易解釋推薦結果，讓用戶更信服，但是傾向于推薦與用戶已購買物品相似的物品，往往會出現多樣性不足、推薦新穎性較低的問題

13.3 大數據在智能醫療和智能物流領域運用

基于大數據的綜合健康服務平臺  目標：覆蓋全生命周期、豐富內涵、結構合理的以人為本全面連續的綜合健康服務體系，利用大數據技術和智能設備技術，提供線上線下相結合的公眾健康服務，實現“未病先防、已病早治、愈后防復”，滿足社會公眾多層次、多方位的健康服務需求，提升人民群眾的身心健康水平

智能物流：典型的是阿里巴巴構建的中國物流骨干網，簡稱菜鳥網

菜鳥網采用天網+地網的模式

天網：天貓牽頭負責與各大物流快遞公司對接的數據平臺

地網：中國智能物流骨干網CSN

天網指導地網運行

天網提前計算并布貨

大數據系統對物流系統優化的作用