【學習筆記】大資料技術原理與應用（MOOC視訊、廈門大學林子雨）

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

天網指導地網運作

天網提前計算并布貨

大資料系統對物流系統優化的作用

作者：九命貓幺

部落格出處：http://www.cnblogs.com/yongestcat/

歡迎轉載，轉載請标明出處。

如果你覺得本文還不錯，對你的學習帶來了些許幫助，請幫忙點選右下角的推薦