從四個方面和大家交流一下：云計算與大數據，云上大數據平臺建設的挑戰，大數據基礎平臺，數據格式。
一、云計算與大數據
相信大家平時接觸更多的是物理機方案的大數據，本來這個話題我并不想總講，因為在我們看來大數據的發展方向是云化和開源，是一個順理成章的事情，但是在實際實施中會遇到一些阻力，這是因為我們有相當一部分人還是物理機世界做大數據的思維，還有對云計算的不信任，稍微有風吹草動就懷疑云計算，這顯然是不對的。懷疑大數據云化無外乎就是穩定性和性能，不過好消息是越來越多的人已經意識到也認可這個發展方向，相信以后這就不再是個話題了。
我們還是從大數據本身出發。我們在準備做一個大數據項目的時候，首先是確定需求，然后就是平臺的選型，平臺的選型是一個最難、最重要的、也是大家最困惑的環節，我遇到的客戶基本上都在這個問題上有不同程度的糾結，這個完全可以理解，因為東西太多了，并且還有更多的新東西源源地不斷地出來。
其實平臺的選型完全取決于你的需求，你是實時計算還是離線計算，是處理結構化數據還是非結構化數據，你的應用有沒有事務性要求等等。確定這些需求后就找相應的平臺就行了，這就要求我們對每個平臺的特點要了解。我們知道沒有一個平臺能解決所有的問題， 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 提供商是可以做的，因為這些信息是可以拿到的。
三、大數據基礎平臺
圖1 系統架構
接下來我們看看有哪些大數據平臺以及它們的特點，從數據的生命周期來說分采集，傳輸，存儲，分析計算以及展現幾個階段，上面這張圖描述了這幾個階段現在比較流行的工具和平臺。
圖2 計算平臺
首先講講計算，如 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 比，也許是小兄弟好欺負。
圖3 存儲-Hadoop
存儲主要就是 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 是一個分布式、可分區、多副本的高吞吐量低延遲消息系統，對于活躍的流式數據處理比如日志分析是最好不過的選擇。
圖4 Kafka 和 Flume
上圖是我從一個真實客戶的 kafka 實時監控圖截取過來的，能看出流入流出的兩個曲線完全重疊了，我們能看出它的延遲非常低（毫秒級別）。
但是我們不能濫用 Kafka ，我曾經遇到過有人想用 Kafka 做分布式事務性的業務如交易，但 Kafka 并沒有宣稱它支持消息的傳遞是 exact once ，它能做到是 at least once ，所以分布式事務性的業務應該是不適合的，需要業務層做一些工作。
四、數據格式
最后一個我想強調的是數據格式，數據格式的正確選擇對大數據怎么強調都不為過。選擇錯了會極大的浪費存儲空間，大數據本來數據量就大，經不起成倍空間的浪費，性能也會因為格式選擇錯誤急劇下降，甚至都無法進行。
數據格式要記住兩點，可分割和可塊壓縮。可分割的意思就是一個大文件從中間切割，分析器還能不能單獨解析這兩個文件，比如 XML ，它有 open tag 和 close tag ，如果中間來一刀， XML Parser 就不會認識。但 CSV 就不一樣，它是一個個的記錄，每一行單獨拿出來還是有意義的。
可塊壓縮指的是每個分割出來的塊能否獨自解壓縮，這是因為前面說過的大數據是計算跟著數據走，所以每個節點的計算是分析本地的數據，從而做到并行計算。但有些壓縮格式如 gzip ， CSV 在解壓的時候需要從第一分割塊開始才能解壓成功，這樣就做不到真正的并行計算。
五、總結
最后總結前面講的幾個觀點：大數據的發展方向是云化，云計算才是大數據基礎平臺最好的部署方案；大數據解決方案中應該根據你的需求來選擇平臺；數據格式的選擇很重要，通常情況記住要選擇可分割和可塊壓縮的數據格式。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.vmgcyvh.cn/
本文標題：基于云計算的大數據平臺基礎設施建設實踐
相關文章
