儼然，人類社會已經(jīng)步入了精確大數(shù)據(jù)時代，隨著大數(shù)據(jù)時代的到來，海量級別的數(shù)據(jù)中心建設也正逐年增加。

“給我提供一些數(shù)據(jù)，我就能做一些改變。如果給我提供所有數(shù)據(jù)，我就能拯救世界。”微軟史密斯這樣說。未來，大數(shù)據(jù)將會在全球范圍內(nèi)掀起新一輪的熱潮。據(jù)有關專家預測，到2020年，大數(shù)據(jù)全球市場規(guī)模有望達到611.6億美元，復合年增長率將達到26%。根據(jù)IDC的預測，全球數(shù)據(jù)中心數(shù)量將在2017年達到頂峰，860萬，而國內(nèi)數(shù)據(jù)中心甚至占到了全球7%左右的市場份額。

一般來講，數(shù)據(jù)中心內(nèi)有很多計算機設備及相應的配套設施，這些設備由復雜精密的元器件組成，因此，為了保證設備的穩(wěn)定運行，對數(shù)據(jù)中心內(nèi)的環(huán)境有著很高的要求。通常，不僅要保持恒溫恒濕，還要保證穩(wěn)定的氣流、潔凈空氣等。

隨著近幾年數(shù)據(jù)中心的快速發(fā)展，隨著越來越多數(shù)據(jù)中心的建設，大數(shù)據(jù)平臺基礎建設當前的趨勢是云化與開放，這個平臺需要可以提供各類大數(shù)據(jù)相關 PaaS 服務，也需要使各類服務間可以簡單靈活的組合來滿足多變及定制的需求。如何在云上提供彈性、敏捷，卻不失穩(wěn)定和高性能的大數(shù)據(jù)平臺？如何高效的利用云計算的特點來開發(fā)大數(shù)據(jù)平臺？

一、云計算與大數(shù)據(jù)相信大家平時接觸更多的是物理機方案的大數(shù)據(jù)，本來這個話題我并不想總講，因為在我們看來大數(shù)據(jù)的發(fā)展方向是云化和開源，是一個順理成章的事情，但是在實際實施中會遇到一些阻力，這是因為我們有相當一部分人還是物理機世界做大數(shù)據(jù)的思維，還有對云計算的不信任，稍微有風吹草動就懷疑云計算，這顯然是不對的。懷疑大數(shù)據(jù)云化無外乎就是穩(wěn)定性和性能，不過好消息是越來越多的人已經(jīng)意識到也認可這個發(fā)展方向，相信以后這就不再是個話題了。我們還是從大數(shù)據(jù)本身出發(fā)。我們在準備做一個大數(shù)據(jù)項目的時候，首先是確定需求，然后就是平臺的選型，平臺的選型是一個最難、最重要的、也是大家最困惑的環(huán)節(jié)，我遇到的客戶基本上都在這個問題上有不同程度的糾結(jié)，這個完全可以理解，因為東西太多了，并且還有更多的新東西源源地不斷地出來。其實平臺的選型完全取決于你的需求，你是實時計算還是離線計算，是處理結(jié)構化數(shù)據(jù)還是非結(jié)構化數(shù)據(jù)，你的應用有沒有事務性要求等等。確定這些需求后就找相應的平臺就行了，這就要求我們對每個平臺的特點要了解。我們知道沒有一個平臺能解決所有的問題， Spark 再強大也沒有存儲，很多場景需要和 Hadoop / HBase / 對象存儲等配合起來使用，更別說替換數(shù)據(jù)倉庫了。選擇平臺或工具不能趕時髦，適用才是最正確的，有些東西并一定就只有 Hadoop 或 Spark 才能解決，比如 redis 提供了一個很好的數(shù)據(jù)結(jié)構 hyperloglogs 用來統(tǒng)計獨立事件，而內(nèi)存最多只會用到 12k 字節(jié)，跟多少個獨立事件無關，誤差不超過 1 % ，那么用這個來統(tǒng)計每個時段的獨立事情比如 UV 還是很不錯的選擇。每個平臺有自己特定的使用場景，我們不但要了解它，甚至很多時候我們還會對各個候選平臺做個 POC 或 benchmark 測試，這個時候云計算就體現(xiàn)出優(yōu)勢了，你可以快速地、低成本地做試驗。當然云計算的優(yōu)勢不僅僅這些，大數(shù)據(jù)時代有很多不確定性的東西，能夠說出半年之后你的數(shù)據(jù)量一定會增加到多少的人不會太多，云計算的彈性能很好地解決這個問題，需要多少就增加多少資源，還能釋放過剩資源給其它業(yè)務使用，上下左右任意地伸縮，這些都可以通過鼠標點擊幾分鐘完成。你甚至可以通過調(diào)用 API 的方式來操控這些平臺，比如說我的程序里接收到數(shù)據(jù)，我啟動我的 Spark 集群來處理這些數(shù)據(jù)，處理完之后我可以關閉集群；也可以通過定時器或自動伸縮功能去完成這些事情，從而極大的節(jié)約成本。云計算不僅僅有彈性、敏捷性，還非常靈活，你可以任意搭配一些組件組成不同的解決方案。比如我們現(xiàn)在要做的一件事情就是基于數(shù)據(jù)任意切換計算引擎，因為我們知道大數(shù)據(jù)是計算跟著數(shù)據(jù)走，數(shù)據(jù)在那兒，計算跑到那兒，那么有的用戶對 MapReduce 比較熟悉，他可能就是用的 Hadoop ，但過段時間他想用 Spark 了，這個時候不能讓用戶去拷貝數(shù)據(jù)到Spark集群，而應該是換掉上面的 MapReduce 變成 Spark ，數(shù)據(jù)還是原來的 HDFS 。所有的這些都能幫我們把時間和精力放在業(yè)務層面，而不是去倒騰復雜的大數(shù)據(jù)平臺。

二、云上大數(shù)據(jù)平臺建設的挑戰(zhàn)可以看出云上的大數(shù)據(jù)能給我們帶來無與倫比的體驗，但是云上大數(shù)據(jù)最關鍵的并不是這些東西，而是穩(wěn)定性和性能，這也是懷疑大數(shù)據(jù)云化最主要的兩點。而這兩點所依賴的是 IaaS 的能力，考驗你的是虛擬化的技術好不好，不能壓力一上來就 kenel panic ，不過我們是從來沒遇到過這個問題，所以我就不多說這個。性能這個問題確實需要花大力氣說，性能分磁盤 I/O 性能和網(wǎng)絡性能，磁盤性能如果從相同配置的單節(jié)點來說，虛機確實沒有物理機性能好，這是因為虛擬化總是有損耗的，但是，如果你虛擬化技術足夠好，損耗可以降到很低，同時云計算是靠橫向擴展解決復雜問題的，而不是靠縱向擴展，一個節(jié)點不行我多加一個節(jié)點。并且我們現(xiàn)在想到了更好的辦法解決這個問題，讓磁盤性能得到更大的提升。網(wǎng)絡性能在物理世界也存在，尤其是節(jié)點一多，如果一不小心網(wǎng)絡配置不夠好，性能一樣會差。我們最近剛發(fā)布的 SDN 2.0 就幫我們的大數(shù)據(jù)解決了這個大問題，所有的主機之間網(wǎng)絡通訊都是直連，跟節(jié)點多少沒有關系，并且節(jié)點間帶寬能達到 8 Gb ，已經(jīng)接近物理網(wǎng)卡單口的上限了。況且現(xiàn)在 25 Gb 的網(wǎng)卡成本也越來越接近 10 Gb 的網(wǎng)卡，所以網(wǎng)絡不應該是問題，當然前提是你的 SDN 技術足夠牛。關于磁盤 I/O 的問題我再補充一點，我們知道 HDFS 默認的副本因子是 ３ ，但是在云上就會變得不一樣，你如果在一家云服務商上自己部署 Hadoop ，就不應該設定 3 個副本因子。這是因為 Hadoop 設計第三個副本的初衷是防止整個機架出問題而把第三個副本放在另外一個機架上，你在別人家部署的時候你肯定不知道這個信息的，所以第三個副本是沒有意義的，同時任何一家 IaaS 服務商一定會提供資源層面的副本的，數(shù)據(jù)的安全性能得到保障，所以更應該去掉第三個副本，去掉這個副本可以節(jié)省 1/3 的空間，性能還能得到提升。但是，不能因為 IaaS 有副本就把 HDFS 降低到一個副本，原因是你需要業(yè)務層面的 HA ， IaaS 的副本只能保證數(shù)據(jù)不丟，物理機出故障切換需要幾分鐘的時間，如果 HDFS 只有一個副本的話這個切換過程業(yè)務會受影響，所以 2 個副本還是必須的。即便這樣其實還不是最優(yōu)的方案，因為業(yè)務層 2 個副本加上 IaaS 層至少 2 個副本，加起來就至少 4 個副本了，比物理機方案的 3 個副本還是有差距。所以最好就是去掉底層的副本，在云上實現(xiàn)物理機世界的 3 個副本方案，然后加上 Rack awareness ，這個就跟物理機部署一樣了，但是是以云的方式交付給大家。這個工作 IaaS 提供商是可以做的，因為這些信息是可以拿到的。

三、大數(shù)據(jù)基礎平臺特點，從數(shù)據(jù)的生命周期來說分采集，傳輸，存儲，分析計算以及展現(xiàn)幾個階段，先講講計算，如 Spark 、Storm、MapReduce 等，他們的區(qū)別主要在實時計算和離線計算，進而影響著各自的吞吐量。 MapReduce 是老牌的大數(shù)據(jù)計算引擎，每個 Map 、 Reduce 階段通過硬盤來進行數(shù)據(jù)的交互，對硬盤 I/O 要求比較高，速度也慢，所以適合離線計算，這就導致凡是跟 MapReduce 相關的東西都比較慢，比如 Hive 。Storm 實時性比較高，但吞吐量相對來說比較小，所以它適合實時小數(shù)據(jù)塊分析計算場景。 Twitter 號稱 Heron 比 Storm 延遲更低，吞吐量更高，去年年底會開源，但我好像至今并沒有看到更多的新聞，耐心期待吧。Spark Streaming 更適合近實時較大數(shù)據(jù)塊分析計算， Spark 是一個基于內(nèi)存的分布式計算系統(tǒng)，官方上聲稱它比 Hadoop 的 MapReduce 要快 100 倍，其實 Spark 的核心是 RDD 計算模型以及基于全局最優(yōu)的 DAG 有向無環(huán)圖的編排方式，而 MapReduce 是一種著眼于局部的計算模型，直接導致了 Spark 即使基于硬盤也要比 MapReduce 快 10 倍。 Spark 是一個很值得研究的平臺，相信大家都知道它有多么優(yōu)秀。對于 SQL 分析來說現(xiàn)在主要分兩大流派，基于 MPP 的數(shù)據(jù)倉庫和 SQL-on-Hadoop ?，F(xiàn)在看起來后者占了點上風，主要的原因之一是前者需要特定的硬件支持，不過 MPP 的數(shù)據(jù)倉庫在傳統(tǒng)行業(yè)還有很大市場，也很受傳統(tǒng)行業(yè)的歡迎，因為它有 Hadoop 目前還沒有的東西，比如真正意義上支持標準的 SQL ，支持分布式事物等，使得 MPP 數(shù)據(jù)倉庫能很好的集成傳統(tǒng)行業(yè)現(xiàn)有的 BI 工具。另外， MPP 數(shù)據(jù)倉庫也在向 Hadoop 靠攏，支持普通的 X86 服務器，底層支持 Hadoop 的存儲，比如 Apache HAWQ 。青云 3 月底的樣子會提供 MPP 數(shù)據(jù)倉庫服務，是由 HAWQ 的作者兼 GreenPlum 的研發(fā)人員和我們合作開發(fā)這個服務。 SQL-on-Hadoop 就比較多了，比如 Spark SQL 、 Hive 、 Phoenix 、 Kylin 等等，Hive 是把 SQL 轉(zhuǎn)換為 MapReduce 任務，所以速度比較慢，如果對運行速度有要求，可以嘗試 Spark SQL，學起來也很簡單，Spark SQL 1.6.0 的性能有很大提升，大家感興趣可以體驗一下。還有基于 Hadoop 的 MPP 分析引擎 Impala 、 Presto 等等，我就不一一介紹了。需要注意的是有些項目還在 Apache 的孵化器里，如果想在生產(chǎn)環(huán)境中使用需加小心。這個地方有意思的是大家都跟 Hive 比，結(jié)論都是比 Hive 快多少倍，這個是肯定的，我們更想看到的這些新出來的 SQL 相互間比是怎么樣的，別總拿 Hive 比，也許是小兄弟好欺負。存儲主要就是 Hadoop/HDFS 、HBase 、對象存儲以及 MPP 數(shù)據(jù)倉庫。 Hadoop 是適合大文件一次性寫入、多次讀取的場景，不能寫很多小文件， NameNode 很容易垮掉，如果非要寫小文件的話可以網(wǎng)上搜一些小技巧。 HBase 適合隨機讀寫場景，它是一個 NoSQL 的分布式列式數(shù)據(jù)庫，是一個 sparse 、 distributed 、 persistent、 multidimensional sorted map ，把每個單詞理解透了就可以理解 HBase 是一個什么東西，它的底層用的還是 HDFS ，不過在分析場景如 scan 數(shù)據(jù)的時候它的性能是比不上 Hadoop 的，性能差 8 倍還要多。 HBase 強在隨機讀寫， Hadoop 強在分析，現(xiàn)在 Apache 孵化器里有一個叫 Kudu 的“中庸”項目，就是兼顧隨機讀寫和分析性能。 HBase 想強調(diào)的一點的是數(shù)據(jù)模型的設計，除了我們大家都知道的 rowkey 設計的重要性之外，不要用傳統(tǒng)的關系型數(shù)據(jù)庫思維建模，在大數(shù)據(jù)領域里更多的是盡量 denormalize 。傳輸現(xiàn)在主流就是 Kafka 和 Flume ，后者有加密功能， Kafka 需要在業(yè)務層做加密，如果有需求的話。 Kafka 是一個分布式、可分區(qū)、多副本的高吞吐量低延遲消息系統(tǒng)，對于活躍的流式數(shù)據(jù)處理比如日志分析是最好不過的選擇。上圖是我從一個真實客戶的 kafka 實時監(jiān)控圖截取過來的，能看出流入流出的兩個曲線完全重疊了，我們能看出它的延遲非常低（毫秒級別）。但是我們不能濫用 Kafka ，我曾經(jīng)遇到過有人想用 Kafka 做分布式事務性的業(yè)務如交易，但 Kafka 并沒有宣稱它支持消息的傳遞是 exact once ，它能做到是 at least once ，所以分布式事務性的業(yè)務應該是不適合的，需要業(yè)務層做一些工作。

四、 數(shù)據(jù)格式的正確選擇對大數(shù)據(jù)怎么強調(diào)都不為過。選擇錯了會極大的浪費存儲空間，大數(shù)據(jù)本來數(shù)據(jù)量就大，經(jīng)不起成倍空間的浪費，性能也會因為格式選擇錯誤急劇下降，甚至都無法進行。數(shù)據(jù)格式要記住兩點，可分割和可塊壓縮?？煞指畹囊馑季褪且粋€大文件從中間切割，分析器還能不能單獨解析這兩個文件，比如 XML ，它有 open tag 和 close tag ，如果中間來一刀， XML Parser 就不會認識。但 CSV 就不一樣，它是一個個的記錄，每一行單獨拿出來還是有意義的?？蓧K壓縮指的是每個分割出來的塊能否獨自解壓縮，這是因為前面說過的大數(shù)據(jù)是計算跟著數(shù)據(jù)走，所以每個節(jié)點的計算是分析本地的數(shù)據(jù)，從而做到并行計算。但有些壓縮格式如 gzip ， CSV 在解壓的時候需要從第一分割塊開始才能解壓成功，這樣就做不到真正的并行計算。

五、總結(jié)：大數(shù)據(jù)的發(fā)展方向是云化，云計算才是大數(shù)據(jù)基礎平臺最好的部署方案；大數(shù)據(jù)解決方案中應該根據(jù)你的需求來選擇平臺；數(shù)據(jù)格式的選擇很重要，通常情況記住要選擇可分割和可塊壓縮的數(shù)據(jù)格式。