從四個(gè)方面和大家交流一下：云計(jì)算與大數(shù)據(jù)，云上大數(shù)據(jù)平臺(tái)建設(shè)的挑戰(zhàn)，大數(shù)據(jù)基礎(chǔ)平臺(tái)，數(shù)據(jù)格式。
一、云計(jì)算與大數(shù)據(jù)
相信大家平時(shí)接觸更多的是物理機(jī)方案的大數(shù)據(jù)，本來(lái)這個(gè)話(huà)題我并不想總講，因?yàn)樵谖覀兛磥?lái)大數(shù)據(jù)的發(fā)展方向是云化和開(kāi)源，是一個(gè)順理成章的事情，但是在實(shí)際實(shí)施中會(huì)遇到一些阻力，這是因?yàn)槲覀冇邢喈?dāng)一部分人還是物理機(jī)世界做大數(shù)據(jù)的思維，還有對(duì)云計(jì)算的不信任，稍微有風(fēng)吹草動(dòng)就懷疑云計(jì)算，這顯然是不對(duì)的。懷疑大數(shù)據(jù)云化無(wú)外乎就是穩(wěn)定性和性能，不過(guò)好消息是越來(lái)越多的人已經(jīng)意識(shí)到也認(rèn)可這個(gè)發(fā)展方向，相信以后這就不再是個(gè)話(huà)題了。
我們還是從大數(shù)據(jù)本身出發(fā)。我們?cè)跍?zhǔn)備做一個(gè)大數(shù)據(jù)項(xiàng)目的時(shí)候，首先是確定需求，然后就是平臺(tái)的選型，平臺(tái)的選型是一個(gè)最難、最重要的、也是大家最困惑的環(huán)節(jié)，我遇到的客戶(hù)基本上都在這個(gè)問(wèn)題上有不同程度的糾結(jié)，這個(gè)完全可以理解，因?yàn)闁|西太多了，并且還有更多的新東西源源地不斷地出來(lái)。
其實(shí)平臺(tái)的選型完全取決于你的需求，你是實(shí)時(shí)計(jì)算還是離線(xiàn)計(jì)算，是處理結(jié)構(gòu)化數(shù)據(jù)還是非結(jié)構(gòu)化數(shù)據(jù)，你的應(yīng)用有沒(méi)有事務(wù)性要求等等。確定這些需求后就找相應(yīng)的平臺(tái)就行了，這就要求我們對(duì)每個(gè)平臺(tái)的特點(diǎn)要了解。我們知道沒(méi)有一個(gè)平臺(tái)能解決所有的問(wèn)題， Spark 再?gòu)?qiáng)大也沒(méi)有存儲(chǔ)，很多場(chǎng)景需要和 Hadoop / HBase / 對(duì)象存儲(chǔ)等配合起來(lái)使用，更別說(shuō)替換數(shù)據(jù)倉(cāng)庫(kù)了。
選擇平臺(tái)或工具不能趕時(shí)髦，適用才是最正確的，有些東西并一定就只有 Hadoop 或 Spark 才能解決，比如 redis 提供了一個(gè)很好的數(shù)據(jù)結(jié)構(gòu) hyperloglogs 用來(lái)統(tǒng)計(jì)獨(dú)立事件，而內(nèi)存最多只會(huì)用到 12k 字節(jié)，跟多少個(gè)獨(dú)立事件無(wú)關(guān)，誤差不超過(guò) 1 % ，那么用這個(gè)來(lái)統(tǒng)計(jì)每個(gè)時(shí)段的獨(dú)立事情比如 UV 還是很不錯(cuò)的選擇。
每個(gè)平臺(tái)有自己特定的使用場(chǎng)景，我們不但要了解它，甚至很多時(shí)候我們還會(huì)對(duì)各個(gè)候選平臺(tái)做個(gè) POC 或 benchmark 測(cè)試，這個(gè)時(shí)候云計(jì)算就體現(xiàn)出優(yōu)勢(shì)了，你可以快速地、低成本地做試驗(yàn)。
當(dāng)然云計(jì)算的優(yōu)勢(shì)不僅僅這些，大數(shù)據(jù)時(shí)代有很多不確定性的東西，能夠說(shuō)出半年之后你的數(shù)據(jù)量一定會(huì)增加到多少的人不會(huì)太多，云計(jì)算的彈性能很好地解決這個(gè)問(wèn)題，需要多少就增加多少資源，還能釋放過(guò)剩資源給其它業(yè)務(wù)使用，上下左右任意地伸縮，這些都可以通過(guò)鼠標(biāo)點(diǎn)擊幾分鐘完成。你甚至可以通過(guò)調(diào)用 API 的方式來(lái)操控這些平臺(tái)，比如說(shuō)我的程序里接收到數(shù)據(jù)，我啟動(dòng)我的 Spark 集群來(lái)處理這些數(shù)據(jù)，處理完之后我可以關(guān)閉集群；也可以通過(guò)定時(shí)器或自動(dòng)伸縮功能去完成這些事情，從而極大的節(jié)約成本。
云計(jì)算不僅僅有彈性、敏捷性，還非常靈活，你可以任意搭配一些組件組成不同的解決方案。比如我們現(xiàn)在要做的一件事情就是基于數(shù)據(jù)任意切換計(jì)算引擎，因?yàn)槲覀冎来髷?shù)據(jù)是計(jì)算跟著數(shù)據(jù)走，數(shù)據(jù)在那兒，計(jì)算跑到那兒，那么有的用戶(hù)對(duì) MapReduce 比較熟悉，他可能就是用的 Hadoop ，但過(guò)段時(shí)間他想用 Spark 了，這個(gè)時(shí)候不能讓用戶(hù)去拷貝數(shù)據(jù)到Spark集群，而應(yīng)該是換掉上面的 MapReduce 變成 Spark ，數(shù)據(jù)還是原來(lái)的 HDFS 。所有的這些都能幫我們把時(shí)間和精力放在業(yè)務(wù)層面，而不是去倒騰復(fù)雜的大數(shù)據(jù)平臺(tái)。
二、云上大數(shù)據(jù)平臺(tái)建設(shè)的挑戰(zhàn)
可以看出云上的大數(shù)據(jù)能給我們帶來(lái)無(wú)與倫比的體驗(yàn)，但是云上大數(shù)據(jù)最關(guān)鍵的并不是這些東西，而是穩(wěn)定性和性能，這也是懷疑大數(shù)據(jù)云化最主要的兩點(diǎn)。而這兩點(diǎn)所依賴(lài)的是 IaaS 的能力，考驗(yàn)?zāi)愕氖翘摂M化的技術(shù)好不好，不能壓力一上來(lái)就 kenel panic ，不過(guò)我們是從來(lái)沒(méi)遇到過(guò)這個(gè)問(wèn)題，所以我就不多說(shuō)這個(gè)。
性能這個(gè)問(wèn)題確實(shí)需要花大力氣說(shuō)，性能分磁盤(pán) I/O 性能和網(wǎng)絡(luò)性能，磁盤(pán)性能如果從相同配置的單節(jié)點(diǎn)來(lái)說(shuō)，虛機(jī)確實(shí)沒(méi)有物理機(jī)性能好，這是因?yàn)樘摂M化總是有損耗的，但是，如果你虛擬化技術(shù)足夠好，損耗可以降到很低，同時(shí)云計(jì)算是靠橫向擴(kuò)展解決復(fù)雜問(wèn)題的，而不是靠縱向擴(kuò)展，一個(gè)節(jié)點(diǎn)不行我多加一個(gè)節(jié)點(diǎn)。并且我們現(xiàn)在想到了更好的辦法解決這個(gè)問(wèn)題，讓磁盤(pán)性能得到更大的提升。
網(wǎng)絡(luò)性能在物理世界也存在，尤其是節(jié)點(diǎn)一多，如果一不小心網(wǎng)絡(luò)配置不夠好，性能一樣會(huì)差。我們最近剛發(fā)布的 SDN 2.0 就幫我們的大數(shù)據(jù)解決了這個(gè)大問(wèn)題，所有的主機(jī)之間網(wǎng)絡(luò)通訊都是直連，跟節(jié)點(diǎn)多少?zèng)]有關(guān)系，并且節(jié)點(diǎn)間帶寬能達(dá)到 8 Gb ，已經(jīng)接近物理網(wǎng)卡單口的上限了。況且現(xiàn)在 25 Gb 的網(wǎng)卡成本也越來(lái)越接近 10 Gb 的網(wǎng)卡，所以網(wǎng)絡(luò)不應(yīng)該是問(wèn)題，當(dāng)然前提是你的 SDN 技術(shù)足夠牛。
關(guān)于磁盤(pán) I/O 的問(wèn)題我再補(bǔ)充一點(diǎn)，我們知道 HDFS 默認(rèn)的副本因子是 ３ ，但是在云上就會(huì)變得不一樣，你如果在一家云服務(wù)商上自己部署 Hadoop ，就不應(yīng)該設(shè)定 3 個(gè)副本因子。這是因?yàn)?Hadoop 設(shè)計(jì)第三個(gè)副本的初衷是防止整個(gè)機(jī)架出問(wèn)題而把第三個(gè)副本放在另外一個(gè)機(jī)架上，你在別人家部署的時(shí)候你肯定不知道這個(gè)信息的，所以第三個(gè)副本是沒(méi)有意義的，同時(shí)任何一家 IaaS 服務(wù)商一定會(huì)提供資源層面的副本的，數(shù)據(jù)的安全性能得到保障，所以更應(yīng)該去掉第三個(gè)副本，去掉這個(gè)副本可以節(jié)省 1/3 的空間，性能還能得到提升。
但是，不能因?yàn)?IaaS 有副本就把 HDFS 降低到一個(gè)副本，原因是你需要業(yè)務(wù)層面的 HA ， IaaS 的副本只能保證數(shù)據(jù)不丟，物理機(jī)出故障切換需要幾分鐘的時(shí)間，如果 HDFS 只有一個(gè)副本的話(huà)這個(gè)切換過(guò)程業(yè)務(wù)會(huì)受影響，所以 2 個(gè)副本還是必須的。即便這樣其實(shí)還不是最優(yōu)的方案，因?yàn)闃I(yè)務(wù)層 2 個(gè)副本加上 IaaS 層至少 2 個(gè)副本，加起來(lái)就至少 4 個(gè)副本了，比物理機(jī)方案的 3 個(gè)副本還是有差距。所以最好就是去掉底層的副本，在云上實(shí)現(xiàn)物理機(jī)世界的 3 個(gè)副本方案，然后加上 Rack awareness ，這個(gè)就跟物理機(jī)部署一樣了，但是是以云的方式交付給大家。這個(gè)工作 IaaS 提供商是可以做的，因?yàn)檫@些信息是可以拿到的。
三、大數(shù)據(jù)基礎(chǔ)平臺(tái)
圖1 系統(tǒng)架構(gòu)
接下來(lái)我們看看有哪些大數(shù)據(jù)平臺(tái)以及它們的特點(diǎn)，從數(shù)據(jù)的生命周期來(lái)說(shuō)分采集，傳輸，存儲(chǔ)，分析計(jì)算以及展現(xiàn)幾個(gè)階段，上面這張圖描述了這幾個(gè)階段現(xiàn)在比較流行的工具和平臺(tái)。
圖2 計(jì)算平臺(tái)
首先講講計(jì)算，如 Spark 、Storm、MapReduce 等，他們的區(qū)別主要在實(shí)時(shí)計(jì)算和離線(xiàn)計(jì)算，進(jìn)而影響著各自的吞吐量。 MapReduce 是老牌的大數(shù)據(jù)計(jì)算引擎，每個(gè) Map 、 Reduce 階段通過(guò)硬盤(pán)來(lái)進(jìn)行數(shù)據(jù)的交互，對(duì)硬盤(pán) I/O 要求比較高，速度也慢，所以適合離線(xiàn)計(jì)算，這就導(dǎo)致凡是跟 MapReduce 相關(guān)的東西都比較慢，比如 Hive 。
Storm 實(shí)時(shí)性比較高，但吞吐量相對(duì)來(lái)說(shuō)比較小，所以它適合實(shí)時(shí)小數(shù)據(jù)塊分析計(jì)算場(chǎng)景。 Twitter 號(hào)稱(chēng) Heron 比 Storm 延遲更低，吞吐量更高，去年年底會(huì)開(kāi)源，但我好像至今并沒(méi)有看到更多的新聞，耐心期待吧。
Spark Streaming 更適合近實(shí)時(shí)較大數(shù)據(jù)塊分析計(jì)算， Spark 是一個(gè)基于內(nèi)存的分布式計(jì)算系統(tǒng)，官方上聲稱(chēng)它比 Hadoop 的 MapReduce 要快 100 倍，其實(shí) Spark 的核心是 RDD 計(jì)算模型以及基于全局最優(yōu)的 DAG 有向無(wú)環(huán)圖的編排方式，而 MapReduce 是一種著眼于局部的計(jì)算模型，直接導(dǎo)致了 Spark 即使基于硬盤(pán)也要比 MapReduce 快 10 倍。 Spark 是一個(gè)很值得研究的平臺(tái)，相信大家都知道它有多么優(yōu)秀。
對(duì)于 SQL 分析來(lái)說(shuō)現(xiàn)在主要分兩大流派，基于 MPP 的數(shù)據(jù)倉(cāng)庫(kù)和 SQL-on-Hadoop 。
現(xiàn)在看起來(lái)后者占了點(diǎn)上風(fēng)，主要的原因之一是前者需要特定的硬件支持，不過(guò) MPP 的數(shù)據(jù)倉(cāng)庫(kù)在傳統(tǒng)行業(yè)還有很大市場(chǎng)，也很受傳統(tǒng)行業(yè)的歡迎，因?yàn)樗?Hadoop 目前還沒(méi)有的東西，比如真正意義上支持標(biāo)準(zhǔn)的 SQL ，支持分布式事物等，使得 MPP 數(shù)據(jù)倉(cāng)庫(kù)能很好的集成傳統(tǒng)行業(yè)現(xiàn)有的 BI 工具。另外， MPP 數(shù)據(jù)倉(cāng)庫(kù)也在向 Hadoop 靠攏，支持普通的 X86 服務(wù)器，底層支持 Hadoop 的存儲(chǔ)，比如 Apache HAWQ 。青云 3 月底的樣子會(huì)提供 MPP 數(shù)據(jù)倉(cāng)庫(kù)服務(wù)，是由 HAWQ 的作者兼 GreenPlum 的研發(fā)人員和我們合作開(kāi)發(fā)這個(gè)服務(wù)。 SQL-on-Hadoop 就比較多了，比如 Spark SQL 、 Hive 、 Phoenix 、 Kylin 等等，Hive 是把 SQL 轉(zhuǎn)換為 MapReduce 任務(wù)，所以速度比較慢，如果對(duì)運(yùn)行速度有要求，可以嘗試 Spark SQL，學(xué)起來(lái)也很簡(jiǎn)單，Spark SQL 1.6.0 的性能有很大提升，大家感興趣可以體驗(yàn)一下。
還有基于 Hadoop 的 MPP 分析引擎 Impala 、 Presto 等等，我就不一一介紹了。需要注意的是有些項(xiàng)目還在 Apache 的孵化器里，如果想在生產(chǎn)環(huán)境中使用需加小心。這個(gè)地方有意思的是大家都跟 Hive 比，結(jié)論都是比 Hive 快多少倍，這個(gè)是肯定的，我們更想看到的這些新出來(lái)的 SQL 相互間比是怎么樣的，別總拿 Hive 比，也許是小兄弟好欺負(fù)。
圖3 存儲(chǔ)-Hadoop
存儲(chǔ)主要就是 Hadoop/HDFS 、HBase 、對(duì)象存儲(chǔ)以及 MPP 數(shù)據(jù)倉(cāng)庫(kù)。 Hadoop 是適合大文件一次性寫(xiě)入、多次讀取的場(chǎng)景，不能寫(xiě)很多小文件， NameNode 很容易垮掉，如果非要寫(xiě)小文件的話(huà)可以網(wǎng)上搜一些小技巧。 HBase 適合隨機(jī)讀寫(xiě)場(chǎng)景，它是一個(gè) NoSQL 的分布式列式數(shù)據(jù)庫(kù)，是一個(gè) sparse 、 distributed 、 persistent、 multidimensional sorted map ，把每個(gè)單詞理解透了就可以理解 HBase 是一個(gè)什么東西，它的底層用的還是 HDFS ，不過(guò)在分析場(chǎng)景如 scan 數(shù)據(jù)的時(shí)候它的性能是比不上 Hadoop 的，性能差 8 倍還要多。 HBase 強(qiáng)在隨機(jī)讀寫(xiě)， Hadoop 強(qiáng)在分析，現(xiàn)在 Apache 孵化器里有一個(gè)叫 Kudu 的“中庸”項(xiàng)目，就是兼顧隨機(jī)讀寫(xiě)和分析性能。 HBase 想強(qiáng)調(diào)的一點(diǎn)的是數(shù)據(jù)模型的設(shè)計(jì)，除了我們大家都知道的 rowkey 設(shè)計(jì)的重要性之外，不要用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)思維建模，在大數(shù)據(jù)領(lǐng)域里更多的是盡量 denormalize 。
傳輸現(xiàn)在主流就是 Kafka 和 Flume ，后者有加密功能， Kafka 需要在業(yè)務(wù)層做加密，如果有需求的話(huà)。 Kafka 是一個(gè)分布式、可分區(qū)、多副本的高吞吐量低延遲消息系統(tǒng)，對(duì)于活躍的流式數(shù)據(jù)處理比如日志分析是最好不過(guò)的選擇。
圖4 Kafka 和 Flume
上圖是我從一個(gè)真實(shí)客戶(hù)的 kafka 實(shí)時(shí)監(jiān)控圖截取過(guò)來(lái)的，能看出流入流出的兩個(gè)曲線(xiàn)完全重疊了，我們能看出它的延遲非常低（毫秒級(jí)別）。
但是我們不能濫用 Kafka ，我曾經(jīng)遇到過(guò)有人想用 Kafka 做分布式事務(wù)性的業(yè)務(wù)如交易，但 Kafka 并沒(méi)有宣稱(chēng)它支持消息的傳遞是 exact once ，它能做到是 at least once ，所以分布式事務(wù)性的業(yè)務(wù)應(yīng)該是不適合的，需要業(yè)務(wù)層做一些工作。
四、數(shù)據(jù)格式
最后一個(gè)我想強(qiáng)調(diào)的是數(shù)據(jù)格式，數(shù)據(jù)格式的正確選擇對(duì)大數(shù)據(jù)怎么強(qiáng)調(diào)都不為過(guò)。選擇錯(cuò)了會(huì)極大的浪費(fèi)存儲(chǔ)空間，大數(shù)據(jù)本來(lái)數(shù)據(jù)量就大，經(jīng)不起成倍空間的浪費(fèi)，性能也會(huì)因?yàn)楦袷竭x擇錯(cuò)誤急劇下降，甚至都無(wú)法進(jìn)行。
數(shù)據(jù)格式要記住兩點(diǎn)，可分割和可塊壓縮�？煞指畹囊馑季褪且粋�(gè)大文件從中間切割，分析器還能不能單獨(dú)解析這兩個(gè)文件，比如 XML ，它有 open tag 和 close tag ，如果中間來(lái)一刀， XML Parser 就不會(huì)認(rèn)識(shí)。但 CSV 就不一樣，它是一個(gè)個(gè)的記錄，每一行單獨(dú)拿出來(lái)還是有意義的。
可塊壓縮指的是每個(gè)分割出來(lái)的塊能否獨(dú)自解壓縮，這是因?yàn)榍懊嬲f(shuō)過(guò)的大數(shù)據(jù)是計(jì)算跟著數(shù)據(jù)走，所以每個(gè)節(jié)點(diǎn)的計(jì)算是分析本地的數(shù)據(jù)，從而做到并行計(jì)算。但有些壓縮格式如 gzip ， CSV 在解壓的時(shí)候需要從第一分割塊開(kāi)始才能解壓成功，這樣就做不到真正的并行計(jì)算。
五、總結(jié)
最后總結(jié)前面講的幾個(gè)觀(guān)點(diǎn)：大數(shù)據(jù)的發(fā)展方向是云化，云計(jì)算才是大數(shù)據(jù)基礎(chǔ)平臺(tái)最好的部署方案；大數(shù)據(jù)解決方案中應(yīng)該根據(jù)你的需求來(lái)選擇平臺(tái)；數(shù)據(jù)格式的選擇很重要，通常情況記住要選擇可分割和可塊壓縮的數(shù)據(jù)格式。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴(lài)品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：基于云計(jì)算的大數(shù)據(jù)平臺(tái)基礎(chǔ)設(shè)施建設(shè)實(shí)踐
本文網(wǎng)址：http://www.oesoe.com/html/solutions/14019319895.html
相關(guān)文章
