基於雲端計算的大資料平臺基礎設施建設實踐 排序

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

本期青雲QingCloud 系統工程師周小四給大家帶來基於雲端計算的大資料平臺基礎設施建設以及其架構特點的主題分享。

以下是分享原文。
——————

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

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

一、雲端計算與大資料

相信大家平時接觸更多的是物理機方案的大資料，本來這個話題我並不想總講，因為在我們看來大資料的發展方向是雲化和開源，是一個順理成章的事情，但是在實際實施中會遇到一些阻力，這是因為我們有相當一部分人還是物理機世界做大資料的思維，還有對雲端計算的不信任，稍微有風吹草動就懷疑雲端計算，這顯然是不對的。懷疑大資料雲化無外乎就是穩定性和效能，不過好訊息是越來越多的人已經意識到也認可這個發展方向，相信以後這就不再是個話題了。

我們還是從大資料本身出發。我們在準備做一個大資料專案的時候，首先是確定需求，然後就是平臺的選型，平臺的選型是一個最難、最重要的、也是大家最困惑的環節，我遇到的客戶基本上都在這個問題上有不同程度的糾結，這個完全可以理解，因為東西太多了，並且還有更多的新東西源源地不斷地出來。

其實平臺的選型完全取決於你的需求，你是實時計算還是離線計算，是處理結構化資料還是非結構化資料，你的應用有沒有事務性要求等等。確定這些需求後就找相應的平臺就行了，這就要求我們對每個平臺的特點要了解。我們知道沒有一個平臺能解決所有的問題， Spark 再強大也沒有儲存，很多場景需要和 Hadoop / HBase / 物件儲存等配合起來使用，更別說替換資料倉儲了。

選擇平臺或工具不能趕時髦，適用才是最正確的，有些東西並一定就只有 Hadoop 或 Spark 才能解決，比如 redis 提供了一個很好的資料結構 hyperloglogs 用來統計獨立事件，而記憶體最多隻會用到 12k 位元組，跟多少個獨立事件無關，誤差不超過 1 % ，那麼用這個來統計每個時段的獨立事情比如 UV 還是很不錯的選擇。

每個平臺有自己特定的使用場景，我們不但要了解它，甚至很多時候我們還會對各個候選平臺做個 POC 或 benchmark 測試，這個時候雲端計算就體現出優勢了，你可以快速地、低成本地做試驗。

當然雲端計算的優勢不僅僅這些，大資料時代有很多不確定性的東西，能夠說出半年之後你的資料量一定會增加到多少的人不會太多，雲端計算的彈效能很好地解決這個問題，需要多少就增加多少資源，還能釋放過剩資源給其它業務使用，上下左右任意地伸縮，這些都可以透過滑鼠點選幾分鐘完成。你甚至可以透過呼叫 API 的方式來操控這些平臺，比如說我的程式裡接收到資料，我啟動我的 Spark 叢集來處理這些資料，處理完之後我可以關閉叢集；也可以透過定時器或自動伸縮功能去完成這些事情，從而極大的節約成本。

雲端計算不僅僅有彈性、敏捷性，還非常靈活，你可以任意搭配一些元件組成不同的解決方案。比如我們現在要做的一件事情就是基於資料任意切換計算引擎，因為我們知道大資料是計算跟著資料走，資料在那兒，計算跑到那兒，那麼有的使用者對 MapReduce 比較熟悉，他可能就是用的 Hadoop ，但過段時間他想用 Spark 了，這個時候不能讓使用者去複製資料到Spark叢集，而應該是換掉上面的 MapReduce 變成 Spark ，資料還是原來的 HDFS 。所有的這些都能幫我們把時間和精力放在業務層面，而不是去倒騰複雜的大資料平臺。

二、雲上大資料平臺建設的挑戰

可以看出雲上的大資料能給我們帶來無與倫比的體驗，但是雲上大資料最關鍵的並不是這些東西，而是穩定性和效能，這也是懷疑大資料雲化最主要的兩點。而這兩點所依賴的是 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 提供商是可以做的，因為這些資訊是可以拿到的。

三、大資料基礎平臺

接下來我們看看有哪些大資料平臺以及它們的特點，從資料的生命週期來說分採集，傳輸，儲存，分析計算以及展現幾個階段，上面這張圖描述了這幾個階段現在比較流行的工具和平臺。

首先講講計算，如 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 ，所以分散式事務性的業務應該是不適合的，需要業務層做一些工作。

四、 資料格式

最後一個我想強調的是資料格式，資料格式的正確選擇對大資料怎麼強調都不為過。選擇錯了會極大的浪費儲存空間，大資料本來資料量就大，經不起成倍空間的浪費，效能也會因為格式選擇錯誤急劇下降，甚至都無法進行。

資料格式要記住兩點，可分割和可塊壓縮。可分割的意思就是一個大檔案從中間切割，分析器還能不能單獨解析這兩個檔案，比如 XML ，它有 open tag 和 close tag ，如果中間來一刀， XML Parser 就不會認識。但 CSV 就不一樣，它是一個個的記錄，每一行單獨拿出來還是有意義的。

可塊壓縮指的是每個分割出來的塊能否獨自解壓縮，這是因為前面說過的大資料是計算跟著資料走，所以每個節點的計算是分析本地的資料，從而做到平行計算。但有些壓縮格式如 gzip ， CSV 在解壓的時候需要從第一分割塊開始才能解壓成功，這樣就做不到真正的平行計算。

五、 總結

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

更多可以到：community.qingcloud.com