基於雲計算的大數據平臺基礎設施建設實踐

大數據平臺基礎建設當前的趨勢是雲化與開放，這個平臺須要能夠提供各種大數據相關 PaaS 服務，也須要使各種服務間能夠簡單靈活的組合來知足多變及定製的需求。如何在雲上提供彈性、敏捷，卻不失穩定和高性能的大數據平臺？如何高效的利用雲計算的特色來開發大數據平臺？

本期中國互聯網技術聯盟分享活動中青雲QingCloud 系統工程師周小四給你們帶來基於雲計算的大數據平臺基礎設施建設以及其架構特色的主題分享。

如下是分享原文。

——————

你們晚上好，我是周小四，英文名字 Ray ，江湖尊稱「四爺"，如今負責青雲QingCloud 大數據平臺的開發。今天跟你們分享一下在雲上建設大數據基礎平臺的問題，下面我提到的大數據是特指大數據基礎平臺，好比 Hadoop 、Spark 等，而不是指上層應用。

我會從四個方面和你們交流一下：雲計算與大數據，雲上大數據平臺建設的挑戰，大數據基礎平臺，數據格式。

　1、雲計算與大數據

相信你們平時接觸更多的是物理機方案的大數據，原本這個話題我並不想總講，由於在咱們看來大數據的發展方向是雲化和開源，是一個瓜熟蒂落的事情，可是在實際實施中會遇到一些阻力，這是由於咱們有至關一部分人仍是物理機世界作大數據的思惟，還有對雲計算的不信任，稍微有風吹草動就懷疑雲計算，這顯然是不對的。懷疑大數據雲化無外乎就是穩定性和性能，不過好消息是愈來愈多的人已經意識到也承認這個發展方向，相信之後這就再也不是個話題了。

咱們仍是從大數據自己出發。咱們在準備作一個大數據項目的時候，首先是肯定需求，而後就是平臺的選型，平臺的選型是一個最難、最重要的、也是你們最困惑的環節，我遇到的客戶基本上都在這個問題上有不一樣程度的糾結，這個徹底能夠理解，由於東西太多了，而且還有更多的新東西源源地不斷地出來。

其實平臺的選型徹底取決於你的需求，你是實時計算仍是離線計算，是處理結構化數據仍是非結構化數據，你的應用有沒有事務性要求等等。肯定這些需求後就找相應的平臺就好了，這就要求咱們對每一個平臺的特色要了解。咱們知道沒有一個平臺能解決全部的問題， Spark 再強大也沒有存儲，不少場景須要和 Hadoop / HBase / 對象存儲等配合起來使用，更別說替換數據倉庫了。

選擇平臺或工具不能趕時髦，適用纔是最正確的，有些東西並必定就只有 Hadoop 或 Spark 才能解決，好比 redis 提供了一個很好的數據結構 hyperloglogs 用來統計獨立事件，而內存最多隻會用到 12k 字節，跟多少個獨立事件無關，偏差不超過 1 % ，那麼用這個來統計每一個時段的獨立事情好比 UV 仍是很不錯的選擇。

每一個平臺有本身特定的使用場景，咱們不但要了解它，甚至不少時候咱們還會對各個候選平臺作個 POC 或 benchmark 測試，這個時候雲計算就體現出優點了，你能夠快速地、低成本地作試驗。

固然雲計算的優點不只僅這些，大數據時代有不少不肯定性的東西，可以說出半年以後你的數據量必定會增長到多少的人不會太多，雲計算的彈性能很好地解決這個問題，須要多少就增長多少資源，還能釋放過剩資源給其它業務使用，上下左右任意地伸縮，這些均可以經過鼠標點擊幾分鐘完成。你甚至能夠經過調用 API 的方式來操控這些平臺，好比說個人程序裏接收到數據，我啓動個人 Spark 集羣來處理這些數據，處理完以後我能夠關閉集羣；也能夠經過定時器或自動伸縮功能去完成這些事情，從而極大的節約成本。

雲計算不只僅有彈性、敏捷性，還很是靈活，你能夠任意搭配一些組件組成不一樣的解決方案。好比咱們如今要作的一件事情就是基於數據任意切換計算引擎，由於咱們知道大數據是計算跟着數據走，數據在那兒，計算跑到那兒，那麼有的用戶對 MapReduce 比較熟悉，他可能就是用的 Hadoop ，但過段時間他想用 Spark 了，這個時候不能讓用戶去拷貝數據到Spark集羣，而應該是換掉上面的 MapReduce 變成 Spark ，數據仍是原來的 HDFS 。全部的這些都能幫咱們把時間和精力放在業務層面，而不是去倒騰複雜的大數據平臺。

2、雲上大數據平臺建設的挑戰

能夠看出雲上的大數據能給咱們帶來無與倫比的體驗，可是雲上大數據最關鍵的並非這些東西，而是穩定性和性能，這也是懷疑大數據雲化最主要的兩點。而這兩點所依賴的是 IaaS 的能力，考驗你的是虛擬化的技術好很差，不能壓力一上來就 kenel panic ，不過咱們是歷來沒遇到過這個問題，因此我就很少說這個。

性能這個問題確實須要花大力氣說，性能分磁盤 I/O 性能和網絡性能，磁盤性能若是從相同配置的單節點來講，虛機確實沒有物理機性能好，這是由於虛擬化老是有損耗的，可是，若是你虛擬化技術足夠好，損耗能夠降到很低，同時雲計算是靠橫向擴展解決複雜問題的，而不是靠縱向擴展，一個節點不行我多加一個節點。而且咱們如今想到了更好的辦法解決這個問題，讓磁盤性能獲得更大的提高。

網絡性能在物理世界也存在，尤爲是節點一多，若是一不當心網絡配置不夠好，性能同樣會差。咱們最近剛發佈的 SDN 2.0 就幫咱們的大數據解決了這個大問題，全部的主機之間網絡通信都是直連，跟節點多少沒有關係，而且節點間帶寬能達到 8 Gb ，已經接近物理網卡單口的上限了。何況如今 25 Gb 的網卡成本也愈來愈接近 10 Gb 的網卡，因此網絡不該該是問題，固然前提是你的 SDN 技術足夠牛。

關於磁盤 I/O 的問題我再補充一點，咱們知道 HDFS 默認的副本因子是 ３ ，可是在雲上就會變得不同，你若是在一家雲服務商上本身部署 Hadoop ，就不該該設定 3 個副本因子。這是由於 Hadoop 設計第三個副本的初衷是防止整個機架出問題而把第三個副本放在另一個機架上，你在別人家部署的時候你確定不知道這個信息的，因此第三個副本是沒有意義的，同時任何一家 IaaS 服務商必定會提供資源層面的副本的，數據的安全性能獲得保障，因此更應該去掉第三個副本，去掉這個副本能夠節省 1/3 的空間，性能還能獲得提高。

可是，不能由於 IaaS 有副本就把 HDFS 下降到一個副本，緣由是你須要業務層面的 HA ， IaaS 的副本只能保證數據不丟，物理機出故障切換須要幾分鐘的時間，若是 HDFS 只有一個副本的話這個切換過程業務會受影響，因此 2 個副本仍是必須的。即使這樣其實還不是最優的方案，由於業務層 2 個副本加上 IaaS 層至少 2 個副本，加起來就至少 4 個副本了，比物理機方案的 3 個副本仍是有差距。因此最好就是去掉底層的副本，在雲上實現物理機世界的 3 個副本方案，而後加上 Rack awareness ，這個就跟物理機部署同樣了，可是是以雲的方式交付給你們。這個工做 IaaS 提供商是能夠作的，由於這些信息是能夠拿到的。

3、大數據基礎平臺

接下來咱們看看有哪些大數據平臺以及它們的特色，從數據的生命週期來講分採集，傳輸，存儲，分析計算以及展示幾個階段，上面這張圖描述了這幾個階段如今比較流行的工具和平臺。

首先講講計算，如 Spark 、Storm、MapReduce 等，他們的區別主要在實時計算和離線計算，進而影響着各自的吞吐量。 MapReduce 是老牌的大數據計算引擎，每一個 Map 、 Reduce 階段經過硬盤來進行數據的交互，對硬盤 I/O 要求比較高，速度也慢，因此適合離線計算，這就致使凡是跟 MapReduce 相關的東西都比較慢，好比 Hive 。

Storm 實時性比較高，但吞吐量相對來講比較小，因此它適合實時小數據塊分析計算場景。 Twitter 號稱 Heron 比 Storm 延遲更低，吞吐量更高，去年年末會開源，但我好像至今並無看到更多的新聞，耐心期待吧。

Spark Streaming 更適合近實時較大數據塊分析計算， Spark 是一個基於內存的分佈式計算系統，官方上聲稱它比 Hadoop 的 MapReduce 要快 100 倍，其實 Spark 的核心是 RDD 計算模型以及基於全局最優的 DAG 有向無環圖的編排方式，而 MapReduce 是一種着眼於局部的計算模型，直接致使了 Spark 即便基於硬盤也要比 MapReduce 快 10 倍。 Spark 是一個很值得研究的平臺，相信你們都知道它有多麼優秀。

對於 SQL 分析來講如今主要分兩大流派，基於 MPP 的數據倉庫和 SQL-on-Hadoop 。

如今看起來後者佔了點上風，主要的緣由之一是前者須要特定的硬件支持，不過 MPP 的數據倉庫在傳統行業還有很大市場，也很受傳統行業的歡迎，由於它有 Hadoop 目前尚未的東西，好比真正意義上支持標準的 SQL ，支持分佈式事物等，使得 MPP 數據倉庫能很好的集成傳統行業現有的 BI 工具。另外， MPP 數據倉庫也在向 Hadoop 靠攏，支持普通的 X86 服務器，底層支持 Hadoop 的存儲，好比 Apache HAWQ 。青雲 3 月底的樣子會提供 MPP 數據倉庫服務，是由 HAWQ 的做者兼 GreenPlum 的研發人員和咱們合做開發這個服務。 SQL-on-Hadoop 就比較多了，好比 Spark SQL 、 Hive 、 Phoenix 、 Kylin 等等，Hive 是把 SQL 轉換爲 MapReduce 任務，因此速度比較慢，若是對運行速度有要求，能夠嘗試 Spark SQL，學起來也很簡單，Spark SQL 1.6.0 的性能有很大提高，你們感興趣能夠體驗一下。

還有基於 Hadoop 的 MPP 分析引擎 Impala 、 Presto 等等，我就不一一介紹了。須要注意的是有些項目還在 Apache 的孵化器裏，若是想在生產環境中使用需加當心。這個地方有意思的是你們都跟 Hive 比，結論都是比 Hive 快多少倍，這個是確定的，咱們更想看到的這些新出來的 SQL 相互間比是怎麼樣的，別總拿 Hive 比，也許是小兄弟好欺負。

存儲主要就是 Hadoop/HDFS 、HBase 、對象存儲以及 MPP 數據倉庫。 Hadoop 是適合大文件一次性寫入、屢次讀取的場景，不能寫不少小文件， NameNode 很容易垮掉，若是非要寫小文件的話能夠網上搜一些小技巧。 HBase 適合隨機讀寫場景，它是一個 NoSQL 的分佈式列式數據庫，是一個 sparse 、 distributed 、 persistent、 multidimensional sorted map ，把每一個單詞理解透了就能夠理解 HBase 是一個什麼東西，它的底層用的仍是 HDFS ，不過在分析場景如 scan 數據的時候它的性能是比不上 Hadoop 的，性能差 8 倍還要多。 HBase 強在隨機讀寫， Hadoop 強在分析，如今 Apache 孵化器裏有一個叫 Kudu 的「中庸」項目，就是兼顧隨機讀寫和分析性能。 HBase 想強調的一點的是數據模型的設計，除了咱們你們都知道的 rowkey 設計的重要性以外，不要用傳統的關係型數據庫思惟建模，在大數據領域裏更多的是儘可能 denormalize 。

傳輸如今主流就是 Kafka 和 Flume ，後者有加密功能， Kafka 須要在業務層作加密，若是有需求的話。 Kafka 是一個分佈式、可分區、多副本的高吞吐量低延遲消息系統，對於活躍的流式數據處理好比日誌分析是最好不過的選擇。

上圖是我從一個真實客戶的 kafka 實時監控圖截取過來的，能看出流入流出的兩個曲線徹底重疊了，咱們能看出它的延遲很是低（毫秒級別）。

可是咱們不能濫用 Kafka ，我曾經遇到過有人想用 Kafka 作分佈式事務性的業務如交易，但 Kafka 並無宣稱它支持消息的傳遞是 exact once ，它能作到是 at least once ，因此分佈式事務性的業務應該是不適合的，須要業務層作一些工做。

4、 數據格式

最後一個我想強調的是數據格式，數據格式的正確選擇對大數據怎麼強調都不爲過。選擇錯了會極大的浪費存儲空間，大數據原本數據量就大，經不起成倍空間的浪費，性能也會由於格式選擇錯誤急劇降低，甚至都沒法進行。

數據格式要記住兩點，可分割和可塊壓縮。可分割的意思就是一個大文件從中間切割，分析器還能不能單獨解析這兩個文件，好比 XML ，它有 open tag 和 close tag ，若是中間來一刀， XML Parser 就不會認識。但 CSV 就不同，它是一個個的記錄，每一行單獨拿出來仍是有意義的。

可塊壓縮指的是每一個分割出來的塊可否獨自解壓縮，這是由於前面說過的大數據是計算跟着數據走，因此每一個節點的計算是分析本地的數據，從而作到並行計算。但有些壓縮格式如 gzip ， CSV 在解壓的時候須要從第一分割塊開始才能解壓成功，這樣就作不到真正的並行計算。

5、 總結

最後總結前面講的幾個觀點：大數據的發展方向是雲化，雲計算纔是大數據基礎平臺最好的部署方案；大數據解決方案中應該根據你的需求來選擇平臺；數據格式的選擇很重要，一般狀況記住要選擇可分割和可塊壓縮的數據格式。

更多內容community.qingcloud.com