了得網研究生_大數據基礎及應用

商品搜索

类别：

关键字：

商品分类

大數據基礎及應用
該商品所屬分類：研究生 -> 工學
【市場價】	441-640元
【優惠價】	276-400元
【作者】	呂雲翔、鐘巧靈、衣志昊
【所屬類別】	圖書教材研究生/本科/專科教材工學
【出版社】	清華大學出版社
【ISBN】	9787302466918
【折扣說明】	一次購物滿999元台幣免運費+贈品一次購物滿2000元台幣95折+免運費+贈品一次購物滿3000元台幣92折+免運費+贈品一次購物滿4000元台幣88折+免運費+贈品
【本期贈品】	①優質無紡布環保袋，做工棒！②品牌簽字筆 ③品牌手帕紙巾

版本	正版全新電子版PDF檔
您已选择：	正版全新
溫馨提示：如果有多種選項，請先選擇再點擊加入購物車。 . 電子圖書價格是0.69折，例如了得網價格是100元，電子書pdf的價格則是69元。 . 購買電子書不支持貨到付款，購買時選擇atm或者超商、PayPal付款。付款後1-24小時內通過郵件傳輸給您。 *. 如果收到的電子書不滿意，可以聯絡我們退款。謝謝。

內容介紹

開本：16開

紙張：膠版紙

包裝：平裝-膠訂

是否套裝：否

國際標準書號ISBN：9787302466918

叢書名：大數據技術與應用專業規劃教材

作者：呂雲翔、鐘巧靈、衣志昊

出版社：清華大學出版社

出版時間：2017年03月

編輯推薦

本書詳細介紹了大數據的基本概念、原理與方法，以及通過大數據實踐來講述大數據技術的應用，包括如何運用阿裡雲大數據計算平臺解決和分析實際的問題。本書*後還提供了大數據實踐案例，完整地體現了理論與實踐的有機結合

內容簡介

本書從大數據的基本概念開始，由淺入深地領會大數據的精髓。本書除了講述必要的大數據理論之外，還通過大數據實踐來講述大數據技術的應用，包括如何運用阿裡雲大數據計算平臺分析和解決實際問題，很好地體現了大數據理論與實踐的有機結合。本書分為三大部分，分別是大數據概述及基礎、大數據處理和大數據分析與應用。其中，大數據概述及基礎部分重點介紹數據組織、重要數據結構、大數據協同技術以及大數據存儲技術等內容；大數據處理部分重點介紹大數據處理框架，包括大數據批處理和流處理框架等內容；大數據分析與應用部分重點介紹數據分析技術和機器學習的相關內容，以及如何利用阿裡雲的數加平臺進行基本的大數據開發工作。本書既可以作為高等院校計算機科學、軟件工程及相關專業“大數據”課程的教材，也可以供繫統分析師、繫統架構師、軟件開發工程師和項目經理，以及其他準備或正在學習大數據技術的讀者（包括參加計算機等級考試或相關專業自學考試的人員）閱讀和參考。

目錄
部分大數據概述及基礎

第1章大數據概念和發展背景

1.1什麼是大數據

1.2大數據的特點

1.3大數據的發展

1.4大數據的應用

1.5習題

部分大數據概述及基礎

第1章大數據概念和發展背景

1.1什麼是大數據

1.2大數據的特點

1.3大數據的發展

1.4大數據的應用

1.5習題

第2章大數據繫統架構概述

2.1總體架構概述

2.1.1總體架構設計原則

2.1.2總體架構參考模型

2.2運行架構概述

2.2.1物理架構

2.2.2集成架構

2.2.3安全架構

2.3阿裡雲飛天繫統體繫架構

2.3.1阿裡雲飛天整體架構

2.3.2阿裡雲飛天平臺內核

2.3.3阿裡雲飛天開放服務

2.3.4阿裡雲飛天的特色

2.4主流大數據繫統廠商

2.4.1阿裡雲數加平臺

2.4.2Cloudera

2.4.3Hortonworks

2.4.4Amazon

2.4.5Google

2.4.6微軟

2.5習題

第3章分布式通信與協同

3.1數據編碼傳輸

3.1.1數據編碼概述

3.1.2LZSS算法

3.1.3Snappy壓縮庫

3.2分布式通信繫統

3.2.1遠程過程調用

3.2.2消息隊列

3.2.3應用層多播通信

3.2.4阿裡雲誇父RPC繫統

3.2.5Hadoop IPC的應用

3.3分布式協同繫統

3.3.1Chubby鎖服務

3.3.2ZooKeeper

3.3.3阿裡雲女媧協同繫統

3.3.4ZooKeeper在HDFS高可用方案中的使用

3.4習題

第4章大數據存儲

4.1大數據存儲技術的發展

4.2海量數據存儲的關鍵技術

4.2.1數據分片與路由

4.2.2數據復制與一致性

4.3重要數據結構和算法

4.3.1Bloom Filter

4.3.2LSM Tree

4.3.3Merkle Tree

4.3.4Cuckoo Hash

4.4分布式文件繫統

4.4.1文件存儲格式

4.4.2GFS

4.4.3HDFS

4.4.4阿裡雲盤古

4.5分布式數據庫NoSQL

4.5.1NoSQL數據庫概述

4.5.2KV數據庫

4.5.3列式數據庫

4.5.4圖數據庫

4.5.5文檔數據庫

4.6阿裡雲數據庫

4.6.1雲數據庫Redis

4.6.2雲數據庫RDS

4.6.3雲數據庫Memcache

4.7大數據存儲技術的趨勢

4.8習題

第二部分大數據處理

第5章分布式處理

5.1CPU多核和POSIX Thread

5.2MPI並行計算框架

5.3Hadoop MapReduce

5.4Spark

5.5數據處理技術的發展

5.6習題

第6章Hadoop MapReduce解析

6.1Hadoop MapReduce架構

6.2Hadoop MapReduce與高效能計算、網格計算的區別

6.3MapReduce工作機制

6.3.1Map

6.3.2Reduce

6.3.3Combine

6.3.4Shuffle

6.3.5Speculative Task

6.3.6任務容錯

6.4應用案例

6.4.1WordCount

6.4.2WordMean

6.4.3Grep

6.5MapReduce的缺陷與不足

6.6習題

第7章Spark解析

7.1Spark RDD

7.2Spark與MapReduce的對比

7.3Spark的工作機制

7.3.1DAG工作圖

7.3.2Partition

7.3.3Lineage容錯方法

7.3.4內存管理

7.3.5數據持久化

7.4數據的讀取

7.4.1HDFS

7.4.2Amazon S3

7.4.3HBase

7.5應用案例

7.5.1日志挖掘

7.5.2判別西瓜好壞

7.6Spark的發展趨勢

7.7習題

第8章流計算

8.1流計算概述

8.2流計算與批處理繫統的對比

8.3Storm流計算繫統

8.4Samza流計算繫統

8.5阿裡雲流計算

8.6集群日志文件的實時分析

8.7流計算的發展趨勢

8.8習題

第9章圖計算

9.1圖計算概述

9.2圖計算與流計算、批處理的對比

9.3Spark GraphX

9.4Pregel

9.5航班機場狀態分析

9.6圖計算的發展趨勢

9.7習題

第10章阿裡雲大數據計算服務平臺

10.1MaxCompute概述

10.2MR計算

10.3SQL計算

10.4Graph計算

10.5習題

第11章集群資源管理與調度

11.1集群資源統一管理繫統

11.1.1集群資源管理概述

11.1.2Apache YARN

11.1.3Apache Mesos

11.1.4Google Omega

11.2資源管理模型

11.2.1基於slot的資源表示模型

11.2.2基於小公平原則的資源分配模型

11.3資源調度策略

11.3.1調度策略概述

11.3.2Capacity Scheduler調度

11.3.3Fair Scheduler調度

11.4在YARN上運行計算框架

11.4.1MapReduce on YARN

11.4.2Spark on YARN

11.4.3YARN程序設計

11.5阿裡雲伏羲調度繫統

11.5.1伏羲調度繫統架構

11.5.25K挑戰

11.5.3伏羲優化實踐

11.6習題

第三部分大數據分析與應用

第12章數據分析

12.1數據操作與繪圖

12.1.1數據結構

12.1.2繪圖功能

12.2初級數據分析

12.2.1描述性統計分析

12.2.2回歸診斷

12.3交互式數據分析

12.3.1交互式數據分析的特征

12.3.2交互式數據處理的典型應用

12.3.3典型的處理繫統

12.4數據倉庫與分析

12.4.1數據倉庫的基本架構

12.4.2數據倉庫的實現步驟

12.4.3分布式數據倉庫Hive

12.4.4數據倉庫之SQL分析

12.4.5阿裡雲MaxCompute數據倉庫案例

12.5習題

第13章數據挖掘與機器學習技術

13.1相關理論基礎知識

13.1.1數據挖掘與機器學習簡介

13.1.2關聯分析

13.1.3分類與回歸

13.1.4聚類分析

13.1.5離群點檢測

13.1.6復雜數據類型的挖掘

13.2應用實踐

13.2.1廣告點擊率預測

13.2.2並行隨機梯度下降

13.2.3自然語言處理：文檔相似性的計算

13.2.4阿裡雲PAI與ET

13.3深度學習

13.3.1深度學習簡介

13.3.2DistBelief

13.3.3TensorFlow

13.4數據挖掘與機器學習的發展趨勢

13.5習題

第14章大數據實踐：
基於數加平臺的推薦繫統

14.1數據集簡介

14.2數據探索

14.3方案設計

14.4訓練集構造

14.4.1MapReduce環境配置

14.4.2MapReduce代碼編寫

14.4.3特征提取與標簽提取

14.4.4訓練集采樣

14.4.5缺失值填充

14.5模型訓練與預測

14.6模型預測的準確性評測

14.7特征重要性的評估

14.8總結

參考文獻

前言

前言
前言
互聯網技術不斷發展，各種技術不斷湧現，其中大數據技術已成為一顆閃耀的新星。我們已經處於數據世界，互聯網每天產生大量的數據，利用好這些數據可以給我們的生活帶來巨大的變化以及提供極大的便利。目前大數據技術受到越來越多的機構的重視，因為大數據技術可以給其創造巨大的利潤，其中的典型代表是個性化推薦以及大數據精準營銷。本書在講述大數據的基本概念、原理與方法的基礎上，詳細而全面地介紹了可以實際用於大數據實踐的各種技能，旨在使學生通過有限課時的學習後，不僅能對大數據技術的基本原理有所認識，而且能夠具備基本的大數據技術開發能力以及運用大數據技術解決基本的數據分析問題，理解大數據框架（尤其是阿裡雲大數據計算平臺），在阿裡雲大數據平臺上進行基本的大數據開發工作的能力。本書分為三大部分，分別是大數據概述及基礎、大數據處理和大數據分析與應用。其中，大數據概述及基礎部分重點介紹數據組織、重要數據結構、大數據協同技術以及大數據存儲技術等內容；大數據處理部分重點介紹大數據處理框架，包括大數據批處理和流處理框架等內容；大數據分析與應用部分重點介紹數據分析技術和機器學習的相關內容，以及如何利用阿裡雲的數加平臺進行基本的大數據開發工作。本書與其他類似著作的不同之處在於，除了講述必要的大數據理論之外，還通過大數據實踐來講述大數據技術的應用，包括如何運用阿裡雲大數據計算平臺解決和分析實際的問題，如阿裡雲MaxCompute和StreamCompute等。本書的後一章“大數據實踐：基於數加平臺的推薦繫統”是學生在做課程設計時可供模仿的一個項目，它完整地體現了理論與實踐的有機結合。本書的理論知識的教學安排建議如下。

章節內容學時數第1章大數據概念和發展背景1第2章大數據繫統架構概述1~2第3章分布式通信與協同2~4第4章大數據存儲4~6第5章分布式處理2第6章Hadoop MapReduce解析2~4第7章Spark解析2~4第8章流計算2第9章圖計算2第10章阿裡雲大數據計算服務平臺2第11章集群資源管理與調度4~6第12章數據分析2~4第13章數據挖掘與機器學習技術2~4第14章大數據實踐：基於數加平臺的推薦繫統4~5
建議理論教學時數： 32~48學時。建議實驗（實踐）教學時數： 16~32學時。教師可以按照自己對大數據的理解適當地刪除一些章節，也可以根據教學目標，靈活地調整章節的順序，增減各章的學時數。在本書成書的過程中，得到了萬昭祎、李旭、蘇俊洋以及阿裡巴巴的李妹芳等人的大力支持，在此表示衷心的感謝。由於大數據是一門新興學科，大數據的教學方法本身還在探索之中，加之我們的水平和能力有限，本書難免有疏漏之處。懇請各位同仁和廣大讀者給予批評指正，也希望各位能將實踐過程中的經驗和心得與我們交流（yunxianglu@hotmail.com）。作者2017年1月

在線試讀

第3章分布式通信與協同在大規模分布式繫統中，為了高效地處理大量任務以及存儲大量數據，通常需要涉及多個處理節點，需要在多個節點之間通信以及協同處理。高效的節點之間的通信以及節點之間的可靠協同技術是保證分布式繫統正常運行的關鍵。3.1數據編碼傳輸3.1.1數據編碼概述
在分布式繫統中需要處理大量的網絡數據，為了加快網絡數據的傳輸速度，通常需要對傳輸數據進行編碼壓縮，當然數據編碼壓縮傳輸技術也在其他電子信息領域中大量使用，由於數字化的多媒體信息尤其是數字視頻、音頻信號的數據量特別龐大，如果不對其進行有效的壓縮難以得到實際的應用，因此數據編碼壓縮技術已成為當今數字通信、廣播、存儲和多媒體娛樂中的一項關鍵的共性技術。數據壓縮是以盡可能少的數碼來表示信源所發出的信號，減少容納給定的消息集合或數據采樣集合的信號空間。這裡講的信號空間就是被壓縮的對像，是指某信號集合所占的時域、空域和頻域。信號空間的這幾種形式是相互關聯的，存儲空間的減少意味著信號傳輸效率的提高，所占用帶寬的。隻要采取某種方法來減少某個信號空間就能夠壓縮數據。一般來說，數據壓縮主要是通過數據壓縮編碼來實現的。要想使編碼有效，必須建立相應的繫統模型。在給定的模型下通過數據編碼來消除冗餘，大致有以下3種情況。(1) 信源符號之間存在相關性。如果消除了這些相關性，就意味著數據壓縮。例如，位圖圖像像素與像素之間的相關性，動態視頻幀與幀之間的相關性。去掉這些相關性通常采用預測編碼、變換編碼等方法。(2) 信源符號之間存在分布不等概性。根據不同符號出現的不同概率分別進行編碼，概率大的符號用較短的碼長編碼，概率小的符號用較長的碼長編碼，終使信源的平均碼長達到短。通常采用統計編碼的方法。(3) 利用信息內容本身的特點(如自相似性)。用模型的方法對需傳輸的信息進行參數估測，充分利用人類的視覺、聽覺等特性，同時考慮信息內容的特性，確定並遴選出其中的部分內容(而不是全部內容)進行編碼，從而實現數據壓縮。通常采用模型基編碼的方法。目前比較認同的、常用的數據壓縮的編碼方法大致分為兩大類。(1) 冗餘壓縮法或無損壓縮法。冗餘壓縮法或無損壓縮法又稱為無失真壓縮法或熵編碼法。這類壓縮方法隻是去掉數據中的冗餘部分，並沒有損失熵，而這些冗餘數據是可以重新插入到原數據中的。也就是說，去掉冗餘不會減少信息量，而且仍可原樣恢復數據。因此，這類壓縮方法是可逆的。(2) 熵壓縮法或有損壓縮法。這類壓縮法由於壓縮了熵，也就損失了信息量，而損失的信息是不能恢復的。因此，在用門限值采樣量化時，如果隻存儲門限內的數據，那麼原來超過這個預置門限的數據將丟失。這種壓縮方法雖然可壓縮大量的信號空間，但那些丟失的實際樣值不可能恢復，是不可逆的。也就是說，在用熵壓縮法時數據壓縮要以一定的信息損失為代價，而數據的恢復隻能是近似的，應根據條件和要求在允許的範圍內進行壓縮。3.1.2LZSS算法LZSS算法屬於字典算法，是把文本中出現頻率較高的字符組合做成一個對應的字典列表，並用特殊代碼來表示這個字符。圖31為字典算法原理圖示。
第3章分布式通信與協同在大規模分布式繫統中，為了高效地處理大量任務以及存儲大量數據，通常需要涉及多個處理節點，需要在多個節點之間通信以及協同處理。高效的節點之間的通信以及節點之間的可靠協同技術是保證分布式繫統正常運行的關鍵。3.1數據編碼傳輸3.1.1數據編碼概述
在分布式繫統中需要處理大量的網絡數據，為了加快網絡數據的傳輸速度，通常需要對傳輸數據進行編碼壓縮，當然數據編碼壓縮傳輸技術也在其他電子信息領域中大量使用，由於數字化的多媒體信息尤其是數字視頻、音頻信號的數據量特別龐大，如果不對其進行有效的壓縮難以得到實際的應用，因此數據編碼壓縮技術已成為當今數字通信、廣播、存儲和多媒體娛樂中的一項關鍵的共性技術。數據壓縮是以盡可能少的數碼來表示信源所發出的信號，減少容納給定的消息集合或數據采樣集合的信號空間。這裡講的信號空間就是被壓縮的對像，是指某信號集合所占的時域、空域和頻域。信號空間的這幾種形式是相互關聯的，存儲空間的減少意味著信號傳輸效率的提高，所占用帶寬的。隻要采取某種方法來減少某個信號空間就能夠壓縮數據。一般來說，數據壓縮主要是通過數據壓縮編碼來實現的。要想使編碼有效，必須建立相應的繫統模型。在給定的模型下通過數據編碼來消除冗餘，大致有以下3種情況。(1) 信源符號之間存在相關性。如果消除了這些相關性，就意味著數據壓縮。例如，位圖圖像像素與像素之間的相關性，動態視頻幀與幀之間的相關性。去掉這些相關性通常采用預測編碼、變換編碼等方法。(2) 信源符號之間存在分布不等概性。根據不同符號出現的不同概率分別進行編碼，概率大的符號用較短的碼長編碼，概率小的符號用較長的碼長編碼，終使信源的平均碼長達到短。通常采用統計編碼的方法。(3) 利用信息內容本身的特點(如自相似性)。用模型的方法對需傳輸的信息進行參數估測，充分利用人類的視覺、聽覺等特性，同時考慮信息內容的特性，確定並遴選出其中的部分內容(而不是全部內容)進行編碼，從而實現數據壓縮。通常采用模型基編碼的方法。目前比較認同的、常用的數據壓縮的編碼方法大致分為兩大類。(1) 冗餘壓縮法或無損壓縮法。冗餘壓縮法或無損壓縮法又稱為無失真壓縮法或熵編碼法。這類壓縮方法隻是去掉數據中的冗餘部分，並沒有損失熵，而這些冗餘數據是可以重新插入到原數據中的。也就是說，去掉冗餘不會減少信息量，而且仍可原樣恢復數據。因此，這類壓縮方法是可逆的。(2) 熵壓縮法或有損壓縮法。這類壓縮法由於壓縮了熵，也就損失了信息量，而損失的信息是不能恢復的。因此，在用門限值采樣量化時，如果隻存儲門限內的數據，那麼原來超過這個預置門限的數據將丟失。這種壓縮方法雖然可壓縮大量的信號空間，但那些丟失的實際樣值不可能恢復，是不可逆的。也就是說，在用熵壓縮法時數據壓縮要以一定的信息損失為代價，而數據的恢復隻能是近似的，應根據條件和要求在允許的範圍內進行壓縮。3.1.2LZSS算法LZSS算法屬於字典算法，是把文本中出現頻率較高的字符組合做成一個對應的字典列表，並用特殊代碼來表示這個字符。圖31為字典算法原理圖示。

LZSS算法的字典模型使用自適應方式，基本的思路是搜索目前待壓縮串是否在以前出現過，如果出現過，則利用前次出現的位置和長度來代替現在的待壓縮串，輸出該字符串的出現位置及長度；否則，輸出新的字符串，從而起到壓縮的目的。但是在實際使用過程中，由於被壓縮的文件往往較大，一般使用“滑動窗口壓縮”方式，也就是說將一個虛擬的、可以跟隨壓縮進程滑動的窗口作為術語字典。LZSS算法的好處是壓縮算法的細節處理不同，隻對壓縮率和壓縮時間有影響，不會影響到解壓程序。LZSS算法的問題是速度，每次都需要向前搜索到原文開頭，對於較長的原文需要的時間是不可忍受的，這也是LZSS算法較大的一個缺點。

圖31字典算法原理

3.1.3Snappy壓縮庫Snappy是在Google公司內部生產環境中被許多項目使用的壓縮/解壓縮的鏈接庫，使用該庫的軟件包括BigTable、MapReduce和RPC等，Google公司於2011年開源了該壓縮/解壓縮庫。在Intel酷睿i7處理器上，在單核64位模式下，Snappy的壓縮速度大概可以達到250MB/s或者更快，解壓縮可以達到大約500MB/s甚至更快。如此高的壓縮速度是通過降低壓縮率來實現的，因此其輸出要比其他庫大20%~100％。Snappy對於純文本的壓縮率為1.5~1.7，對於HTML是2~4，當然，對於JPEG、PNG和其他已經壓縮過的數據的壓縮率為1.0。Snappy壓縮庫采用C 實現，同時提供了多種其他語言的接口，包括C、C#、Go、Haskell等。Snappy是面向字節編碼的LZ77類型壓縮器。Snappy采用的是字節(byte)，而不是比特(bit)，采用該壓縮庫壓縮後的數據形成一個字節流的格式，格式如下：前面幾個字節表示總體為壓縮的數據流長度，采用小端方式(littleendian)存儲，同時兼顧可變長度編碼，每個字節的後面7位存儲具體的數據，位用於表示下一個字節是否為同一個整數；剩下的字節素類型中的一種進行素素數據中的個字節，該字節的後2位表示類型。 00。文本數據，屬於未壓縮數據，類型字節的高6位用於存素的數據內容長度。當數據內容超過60個字節時，采用額外的可變長編碼方式存儲數據。 01。數據長度用3位存儲，偏移量用11位存儲。緊接著類型字節後的個字節也用於存儲偏移量。 10。類型字節中剩下的高6位用於存儲數據長度，在類型字節後的兩個字節用於存儲數據的偏移量。 11。類型字節中剩下的高6位用於存儲數據長度，數據偏移量存儲在類型字節後的4個字節，偏移量采用小端方式存儲數據。3.2分布式通信繫統分布式通信研究分布式繫統中不同子繫統或進程之間的信息交換機制。我們從各種大數據繫統中歸納出3種常見的通信機制：遠程過程調用、消息隊列和多播通信。其中，遠程過程調用的重點是網絡中位於不同機器上進程之間的交互；消息隊列的重點是子繫統之間的消息可靠傳遞；多播通信是實現信息的高效多播傳遞。這三者都是黏合子繫統的有效工具，同時，它們對於減少大數據繫統中構件之間的耦合、增強各自的獨立演進有很大的幫助作用。3.2.1遠程過程調用遠程過程調用(Remote Procedure Call，RPC)是一個計算機通信協議，通過該協議運行於一臺計算機上的程序可以調用另一臺計算機的子程序，而程序員無須額外地為這個交互編程。通用的RPC框架都支持以下特性：接口描述語言、高性能、數據版本支持以及二進制數據格式。Thrift是由Facebook公司開發的遠程服務調用框架，它采用接口描述語言定義並創建服務，支持可擴展的跨語言服務開發，所包含的代碼生成引擎可以在多種語言中，如C 、Java、Python、PHP、Ruby、Erlang、Perl、Haskell、C#、Cocoa、Smalltalk等，創建高效的、無縫的服務。其傳輸數據采用二進制格式，相對於XML和JSON體積更小，對於高並發、大數據量和多語言的環境更有優勢。Thrift包含了一個完整的堆棧結構，用於構建客戶端和服務器端。服務器包含用於綁定協議和傳輸層的基礎架構，它提供阻塞、非阻塞、單線程和多線程的模式運行在服務器上，可以配合服務器/容器一起運行，可以和現有的服務器/容器無縫結合。其使用流程大致如下。首先使用IDL定義消息體以及RPC函數調用接口。使用IDL可以在調用方和被調用方解耦，比如調用方可以使用C ，被調用方可以使用Java，這樣給整個繫統帶來了極大的靈活性。然後使用工具根據IDL定義文件生成指定編程語言的代碼。後即可在應用程序中連接使用上一步生成的代碼。對於RPC來說，調用方和被調用方同時引入後即可實現透明的網絡訪問。3.2.2消息隊列消息隊列也是設計大規模分布式繫統時經常采用的中間件產品。分布式繫統構件之間通過傳遞消息可以解除相互之間的功能耦合，這樣減輕了子繫統之間的依賴，使得各個子繫統或者構建可以獨立演進、維護或重用。消息隊列是在消息傳遞過程中保存消息的容器或中間件，其主要目的是提供消息路由並保障消息可靠傳遞。下面通過Linkedin開源的分布式消息繫統Kafka介紹消息隊列繫統的整體設計思路。Kafka采用PubSub機制，具有極高的消息吞吐量、較強的可擴展性和高可用性，消息傳遞延遲低，能夠對消息隊列進行持久化保存，且支持消息傳遞的“至少送達一次”語義。一個典型的Kafka集群中包含若干producer、若干broker、若干consumer group，以及一個ZooKeeper集群。Kafka通過ZooKeeper管理集群配置，選舉leader，以及在consumer group發生變化時進行rebalance。producer使用push模式將消息發布到broker，consumer使用pull模式從broker訂閱並消費消息。作為一個消息繫統，Kafka遵循了傳統的方式，選擇由producer向broker push消息並由consumer向broker pull消息。push模式很難適應消費速率不同的consumer，因為消息發送速率是由broker決定的。push模式的目標是盡可能以快的速度傳遞消息，但是這樣很容易造成consumer來不及處理消息，典型的表現就是拒絕服務以及網絡阻塞。pull模式可以根據consumer的消費能力以適當的速率消費信息。3.2.3應用層多播通信分布式繫統中的一個重要的研究內容是如何將數據通知到網絡中的多個接收方，這一般被稱為多播通信。與網絡協議層的多播通信不同，這裡介紹的是應用層多播通信。Gossip協議就是常見的應用層多播通信協議，與其他多播協議相比，其在信息傳遞的健壯性和傳播效率方面有較好的折中效果，使其在大數據領域中得以廣泛使用。Gossip協議也被稱為“感染協議”(Epidemic Protocol)，用來盡快地將本地更新數據通知到網絡中的所有其他節點。其具體更新模型又可以分為3種：全通知模型、反熵模型和散步謠言模型。在全通知模型中，當某個節點有更新消息時立即通知所有其他節點；其他節點在接收到通知後判斷接收到的消息是否比本地消息要新，如果是，則更新本地數據，否則，不采取任何行為。反熵模型是常用的“Gossip協議”，之所以稱之為“反熵”，是因為“熵”是用來衡量繫統混亂無序程度的指標，熵越大說明繫統越無序。繫統中更新的信息經過一定輪數的傳播後，集群內的所有節點都會獲得全局信息，所以繫統變得越來越有序，這就是“反熵”的含義。在反熵模型中，節點P隨機選擇集群中的另一個節點Q，然後與Q交換更新信息；如果Q信息有更新，則類似P一樣傳播給任意其他節點(此時P也可以再傳播給其他節點)，這樣經過一定輪數的信息交換，更新的信息就會快速傳播到整個網絡節點。散步謠言模型與反熵模型相比增加了傳播停止判斷。即如果節點P更新了數據，則隨機選擇節點Q交換信息；如果節點Q已經從其他節點處得知了該更新，那麼節點P降低其主動通知其他節點的概率，直到一定程度後，節點P停止通知行為。散布謠言模型能夠快速傳播變化，但不能保證所有節點都能終獲得更新。3.2.4阿裡雲誇父RPC繫統在分布式繫統中，不同計算機之間隻能通過消息交換的方式進行通信。顯式的消息通信必須通過Socket接口編程，而RPC可以隱藏顯式的消息交換，使得程序員可以像調用本地函數一樣來調用遠程的服務。誇父(Kuafu)是飛天平臺內核中負責網絡通信的模塊，它提供了一個RPC的接口，簡化編寫基於網絡的分布式應用。誇父的設計目標是提供高可用(7×24小時)、大吞吐量(Gigabyte)、高效率、易用(簡明API、多種協議和編程接口)的RPC服務。RPC客戶端(RPC Client)通過URI指定請求需要發送的RPC服務端(RPC Server)的地址，目前誇父支持兩種協議形式。 TCP。例如tcp://fooserver01:9000。 Nuwa。例如nuwa://nuwa01/FooServer。與用流(Stream)傳輸的TCP通信相比，誇父通信是以消息(Message)為單位的，支持多種類型的消息對像，包括標準字符串std∷string和基於std∷map實現的若干string鍵值對。誇父RPC同時支持異步(asynchronous)和同步(synchronous)的遠程過程調用形式。（1）異步調用。RPC函數調用時不等接收到結果就會立即返回，用戶必須通過顯式調用接收函數取得請求結果。（2）同步調用。RPC函數調用時會等待，直到接收到結果纔返回。在實現中，同步調用是通過封裝異步調用來實現的。在誇父的實現中，客戶端程序通過UNIX Domain Socket與本機上的一個誇父代理(Kuafu Proxy)連接，不同計算機之間的誇父代理會建立一個TCP連接。這樣做的好處是可以更高效地使用網絡帶寬，繫統可以支持上千臺計算機之間的互聯需求。此外，誇父利用女媧來實現負載均衡；對大塊數據的傳輸作了優化；與TCP類似，誇父代理之間還實現了發送端和接收端的流控(Flow Control)機制。3.2.5Hadoop IPC的應用這裡以Hadoop中的RPC框架Hadoop IPC為基礎講述RPC框架在大數據繫統中的應用。Hadoop繫統包括Hadoop Common、Hadoop Distributed File System、Hadoop MapReduce幾個重要的組成部分，其中，Hadoop Common用於提供整個Hadoop公共服務，包括Hadoop IPC。在Hadoop繫統中，Hadoop IPC為HDFS、MapReduce提供了高效的RPC通信機制，在HDFS中，DFSClient模塊需要與NameNode模塊通信、DFSClient模塊需要與DataNode模塊通信、MapReduce客戶端需要與JobTracker通信，Hadoop IPC為這些模塊之間的通信提供了一種便利的方式。目前實現的Hadoop IPC具有采用TCP方式連接、支持超時、緩存等特征。Hadoop IPC采用的是經典的C/S結構。Hadoop IPC的Server端相對比較復雜，包括Listener、Reader、Handler和Responder等多種類型的線程，Listener用於偵聽來自IPC Client端的連接，同時也負責管理與Client端之間的連接，包括Client端超時需要刪除連接； Reader線程用於讀取來自Client端的數據，Handler線程用於處理來自Client端的請求，執行具體的操作； Responder線程用於返回處理結果給Client端。一般配置是一個Listener、多個Reader、多個Handler和一個Responder。Hadoop IPC的組成如圖32所示。

圖32Hadoop IPC的組成
執行HDFS讀文件操作，首先DFSClient利用Hadoop IPC框架發起一次RPC請求給NameNode，獲取DataBlock信息。在執行HDFS數據恢復操作的時候，DFSClient需要執行recoverBlock RPC操作，發送該請求到DataNode節點上。
3.3分布式協同繫統當前的大規模分布式繫統涉及大量的機器，這些機器之間需要進行大量的網絡通信以及各個節點之間的消息通信協同。為了減少分布式繫統中這些工作的重復開發，解耦出分布式協同繫統，有效地提高了分布式計算、分布式存儲等繫統的開發速度。3.3.1Chubby鎖服務Chubby是Google公司研發的針對分布式繫統協調管理的粗粒度服務，一個Chubby實例大約可以負責1萬臺4核CPU機器之間對資源的協同管理。這種服務的主要功能是讓眾多客戶端程序進行相互之間的同步，並對繫統環境或資源達成一致的認知。Chubby的理論基礎是Paxos（一致性協議），Paxos是在完全分布式環境下不同客戶端能夠通過交互通信並投票對於某個決定達成一致的算法。Chubby以此為基礎，但是也進行了改造，Paxos是完全分布的，沒有中心管理節點，需要通過多輪通信和投票來達成終的一致，所以效率低； Chubby出於對繫統效率的考慮，增加了一些中心管理策略，在達到同一目標的情況下改善了繫統效率。Chubby的設計目標基於以下幾點：高可用性、高可靠性、支持粗粒度的建議性鎖服務、支持小規模文件直接存儲。這些當然是用高性能與存儲能力折中而來的。圖33是Google論文中描述的Chubby的整體架構，可以容易地看出Chubby共有5臺服務器，其中一個是主服務器，客戶端與服務器之間使用RPC交互。那麼，其他服務器是干什麼的？它們純粹是作為主服務器不可用後的替代品。而ZooKeeper的多餘服務器均是提供就近服務的，也就是服務器會根據地理位置與網絡情況來選擇對哪些客戶端給予服務。

圖33Chubby整體架構

Chub中的主服務器由所有服務器選舉推出，但是並非從始至終一直都由其擔任這一角色，它是有“任期”的，即Master Lease，一般長達幾秒。如果無故障發生，一般繫統盡量將“租約”交給原先的主服務器，否則可以通過重新選舉得到一個新的全局管理服務器，這樣就實現了主服務器的自動切換。客戶端通過嵌入的庫程序，利用RPC通信和服務器進行交互，對Chubby的讀/寫請求都由主服務器負責。主服務器遇到數據更新請求後會更改在內存中維護的管理數據，通過改造的Paxos協議通知其他備份服務器對相應的數據進行更新操作，並保證在多副本環境下的數據一致性；當多數備份服務器確認更新完成後，主服務器可以認為本次更新操作正確完成。其他所有備份服務器隻是同步管理數據到本地，保持數據和主服務器完全一致。通信協議如圖34所示。

圖34Client與Chubby的通信

KeepAlive是周期性發送的一種消息，它有兩方面的功能：延長租約有效期，攜帶事件信息告訴客戶端更新。事件包括文件內容的修改、子節點的增刪改、Master出錯等。在正常情況下，租約會由KeepAlive一直不斷延長。如果C1在未用完租約期時發現還需使用，便發送鎖請求給Master，Master給它LeaseM1； C2在過了租約期後，發送鎖請求給Master，可是未收到Master的回答。其實此刻Master已經掛了，於是Chubby進入寬限期，在這期間Chubby要選舉出新的Master。Google論文裡對於這段時期有一個更形像的名字——Grace Period。在選舉出Master後，新的主服務器下令前主服務器發的Lease失效，大家必須申請一份新的。然後C2獲得了LeaseM2。C3又恢復到正常情況。在圖34中4、5、6、7、8是通過Paxos算法選舉Master的顫抖期。在此期間有可能產生問題，Amazon的分布式服務就曾因此宕機，導致很長時間服務不可用。3.3.2ZooKeeperZooKeeper是Yahoo！公司開發的一套開源高吞吐分布式協同繫統，目前已經在各種NoSQL數據庫及諸多開源軟件中獲得廣泛使用。分布式應用中的各節點可以通過ZooKeeper這個第三方來確保雙方的同步，比如一個節點是發送，另一個節點是接收，但發送節點需要確認接收節點成功收到這個消息，因而就可以通過與一個可靠的第三方交互來獲取接收節點的消息接收狀態。ZooKeeper也是由多臺同構服務器構成的一個集群，共用信息存儲在集群繫統中。共用信息采用樹形結構來存儲，用戶可以將其看作一個文件繫統，隻是這些文件是一直存放在內存中的，文件存儲容量受到內存的限制。既然ZooKeeper可以被看作一個文件繫統，那麼它就具有文件繫統相應的功能，隻是在ZooKeeper和文件繫統中功能的叫法不同。ZooKeeper提供創建節點、刪除節點、創建子節點、獲取節點內容等功能。ZooKeeper服務由若干臺服務器構成，每臺服務器內存中維護相同的樹形數據結構。其中的一臺通過ZAB原子廣播協議選舉作為主服務器，其他的作為從服務器。客戶端可以通過TCP協議連接任意一臺服務器，如果是讀操作請求，任意一個服務器都可以直接響應請求；如果是寫數據操作請求，則隻能由主服務器來協調更新操作。Chubby在這一點上與ZooKeeper不同，所有的讀/寫操作都由主服務器完成，從服務器隻是用於提高整個協調繫統的可用性。在帶來高吞吐量的同時，ZooKeeper的這種做法也帶來了潛在的問題：客戶端可能讀到過期的數據。因為即使主服務器已經更新了某個內存數據，但是ZAB協議還未能將其廣播到從服務器。為了解決這一問題，在ZooKeeper的接口API函數中提供了Sync操作，應用可以根據需要在讀數據前調用該操作，其含義是接收到Sync命令的從服務器從主服務器同步狀態信息，保證兩者完全一致。3.3.3阿裡雲女媧協同繫統女媧(Nuwa)繫統為飛天提供高可用的協調服務(Coordination Service)，是構建各類分布式應用的核心服務，它的作用是采用類似文件繫統的樹形命名空間來讓分布式進程互相協同工作。例如，當集群變更導致特定的服務被迫改變物理運行位置時，如服務器或者網絡故障、配置調整或者擴容時，借助女媧繫統可以使其他程序快速定位到該服務新的接入點，從而保證了整個平臺的高可靠性和高可用性。女媧繫統基於類Paxos協議，由多個女媧Server以類似文件繫統的樹形結構存儲數據，提供高可用、高並發用戶請求的處理能力。女媧繫統的目錄表示一個包含文件的集合。與UNIX中的文件路徑一樣，女媧中的路徑是以“/”分割的，根目錄(Root entry)的名字是“/”，所有目錄的名字都是以“/”結尾的。與UNIX文件路徑的不同之處在於：女媧繫統中的所有文件或目錄都必須使用從根目錄開始的路徑。由於女媧繫統的設計目的是提供協調服務，而不是存儲大量數據，所以每個文件的內容(Value)的大小被限制在1MB以內。在女媧繫統中，每個文件或目錄都保存有創建者的信息。一旦某個路徑被用戶創建，其他用戶就可以訪問和修改這個路徑的值(即文件內容或目錄包含的文件名)。女媧繫統支持Publish/Subscribe模式，其中一個發布者、多個訂閱者(One Publisher/Many Subscriber)的模式提供了基本的訂閱功能；另外，還可用通過多個發布者、多個訂閱者(Many Publisher/Many Subscriber)的模式提供分布式選舉(Distributed Election)和分布式鎖的功能。另外一個使用女媧繫統來實現負載均衡的例子：提供某一服務的多個節點，在服務啟動的時候在女媧繫統的同一目錄下創建文件，例如server1創建文件nuwa://cluster/myservice/server1，server2在同一目錄下創建nuwa://cluster/myservice/server2。當客戶端使用遠程過程調用時首先列舉女媧繫統服務中nuwa://cluster/myservice目錄下的文件，這樣就可以獲得server1和server2，客戶端隨後可以從中選擇一個節點發出自己的請求，從而實現負載均衡。3.3.4ZooKeeper在HDFS高可用方案中的使用HDFS由3個模塊構成，分別包括Client、NameNode和DataNode。NameNode負責管理所有的DataNode節點，保存block和DataNode之間的對應信息，Client讀取文件和寫入文件都需要NameNode節點的參與，因此NameNode發揮著至關重要的作用。在當前設計中，NameNode是單節點方式，存在單點故障問題，即NameNode節點宕機之後HDFS無法再對外提供數據存儲服務，需要設計一種HDFS NameNode節點的高可用方法。總體來講，維護HDFS高可用基於以下兩個目的：（1）在出現NameNode節點故障時HDFS仍然可以對外提供數據的讀取和寫入服務。（2） HDFS會出現版本的更新迭代，以保證HDFS在更新過程中仍然可以對外提供服務。HDFS為了實現上述目的，采用的方式是再提供一個額外的NameNode節點，以此達到HDFS的高可用目的。在使用過程中部署兩個NameNode節點，一個NameNode節點為Active節點，另一個NameNode節點是Standby節點。在正常情況下，Active的NameNode節點服務正常的請求，一旦出現Active NameNode節點故障，則Standby NameNode節點切換變成Active節點，然後這個新的Active NameNode繼續提供NameNode的功能，使HDFS可以繼續正常工作。但是為了保證上述過程正常運行，需要解決以下問題：（1） Standby如何知道Active節點出現故障無法正常服務，需要探測繫統何時出現故障。（2）當出現Active NameNode節點故障時，多個Standby NameNode節點如何選擇一個新的Active NameNode節點。一種解決上述問題的HDFS高可用方法是采用ZK Failover Controller的方法，具體結構如圖35所示。

圖35基於ZooKeeper的HDFS高可用方法

采用ZK(ZooKeeper)設計HDFS高可用方案基於以下幾點： (1) ZooKeeper提供了小規模的任意數據信息的強一致性。(2) 可以在ZooKeeper集群中創建一個臨時znode節點，當創建該znode節點的Client失效時，該臨時znode節點會自動刪除。(3) 能夠監控ZooKeeper集群中的一個znode節點的狀態發生改變，並被異步通知。上述設計的基於ZK的HDFS高可用方法由ZKFC、HealthMonitor、ActiveStandbyElector幾個主要部分組成。（1） HealthMonitor是一個線程，用於監控本地NameNode的狀態信息，維持一個狀態信息的視圖，監控采用RPC方式。當狀態信息發生改變時，通過callback接口方式發送消息給ZKFC。（2） ActiveStandbyElector主要用於和ZooKeeper進行協調，ZKFC與它通信主要由兩個函數調用，分別是joinElection和quitElection。（3） ZKFailoverController訂閱來自ActiveStandbyElector和HealthMonitor的消息，同時管理NameNode的狀態。整體運行過程如下：啟動的時候初始化HealthMonitor去監控本地NameNode節點，同時用ZooKeeper信息來初始化ActiveStandbyElector，不立即把該NameNode節點加入選舉。同時，隨著ActiveStandbyElector和HealthMonitor狀態的改變，ZKFC做出對應的響應。3.4習題1. 簡述數據編碼傳輸的好處。2. 簡要介紹Snappy壓縮庫，包括功能和數據格式。3. 簡要介紹Chubby的工作原理。4. 簡述ZooKeeper在HDFS高可用方案中發揮作用的理由。

書摘插畫

網友評論我們期待著您對此商品發表評論

相關商品

商品搜索

商品分类

【醫學】

【各大出版社】