1 大數據概述大數據特性：4v volume velocity variety value 即大量化、快速化、多樣化、價值密度低 數據量大：大數據摩爾定律 快速化：從數據的生成到消耗，時間視窗小，可用於生成決策的時間非常少；1秒定律，這和傳統的數據挖掘技術有著本質區別（谷歌的dremel可以在1秒內... ...
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結果先寫到緩存，緩存滿的時候發生溢寫，溢寫中有分區、排序和可能發生的合併操作之後保存到磁碟文件，溢寫是多次，生成多個磁碟文件，多個磁碟文件要歸併為大的磁碟文件，那麼這
