7月18日,"云用戶生態(tài)發(fā)展論壇暨第三屆中國云計(jì)算用戶大會(huì)"在北京國家會(huì)議中心召開。在下午的會(huì)議中，青云QingCloud系統(tǒng)工程師及大數(shù)據(jù)平臺(tái)負(fù)責(zé)人李威帶來主題為“大數(shù)據(jù)云平臺(tái)之最佳實(shí)踐”的精彩演講，以下是他的演講實(shí)錄：

李威：大家好，我是QingCloud青云的系統(tǒng)工程師李威。今天我講的這個(gè)話題可能技術(shù)性有點(diǎn)強(qiáng)，可能需要大家費(fèi)點(diǎn)腦子。分成幾大塊。第一，先說一下云計(jì)算和大數(shù)據(jù)的關(guān)系。第二，在云上做大數(shù)據(jù)平臺(tái)有什么獨(dú)特的挑戰(zhàn)。第三，我們會(huì)講一下大數(shù)據(jù)平臺(tái)它有一個(gè)比較基本的，或者說通用的一個(gè)系統(tǒng)架構(gòu)是什么樣子。最后，分享一些我們自己的，包括和在客戶那兒的一些跟大數(shù)據(jù)相關(guān)的最佳實(shí)踐。

大數(shù)據(jù)的例子，我就不說太多了，說一些我們的一些企業(yè)客戶的。比如說第一個(gè)是一個(gè)非常大型的一個(gè)跨國的一個(gè)互聯(lián)網(wǎng)社交企業(yè)。然后他們會(huì)用我們在云上的大數(shù)據(jù)的一些平臺(tái)，包括一些具體的技術(shù)，會(huì)做比如用戶畫像。就是你在社交網(wǎng)絡(luò)里面，然后為什么推薦給你的朋友正好是你可能會(huì)認(rèn)識(shí)的，然后為什么推薦給你的信息可能就是你感興趣的。這個(gè)都是用戶畫像用大數(shù)據(jù)來做的。

第二，像一個(gè)非常大型的互聯(lián)網(wǎng)的金融企業(yè)，它會(huì)用大數(shù)據(jù)做一些風(fēng)控分析。因?yàn)樵诨ヂ?lián)網(wǎng)金融，尤其是互聯(lián)網(wǎng)金融行業(yè)里面，它之所以可以和傳統(tǒng)金融PK，就是因?yàn)樗陲L(fēng)控這方面可以用大數(shù)據(jù)技術(shù)把風(fēng)險(xiǎn)控制的非常小。大家可以想一想，在P2P平臺(tái)上面，憑什么沒有像以前傳統(tǒng)銀行各種人來調(diào)查你，沒有什么抵押金，但是可以讓你用錢。包括政府部門海量信息檢索，比如它需要把全國的各種部門聯(lián)合起來，然后我需要有一個(gè)犯罪嫌疑人他有沒有可能在各個(gè)地方有一些其他數(shù)據(jù)，我可以搜索，可以挖掘，然后進(jìn)行一些分析。

大數(shù)據(jù)很火，它跟云計(jì)算到底什么關(guān)系？其實(shí)我們認(rèn)為大數(shù)據(jù)現(xiàn)在大家可能覺得到什么地方都聽見大數(shù)據(jù)，其實(shí)很可能每個(gè)人說的不一樣，也得人說的是大數(shù)據(jù)平臺(tái)，有的人說的是大數(shù)據(jù)的某個(gè)產(chǎn)品，有的人可能說的是大數(shù)據(jù)的某個(gè)應(yīng)用，比如Alpha  Go。

尤其在企業(yè)里面，我們和客戶談的時(shí)候，客戶第一個(gè)比較想不明白的就是大數(shù)據(jù)的產(chǎn)品和技術(shù)太多了，而且每個(gè)場景都區(qū)別不是那么明顯。所以，在大數(shù)據(jù)這個(gè)技術(shù)里面，我們第一個(gè)要解決的就是到底怎么選擇大數(shù)據(jù)的解決方案，怎么為企業(yè)做大數(shù)據(jù)解決方案。但是，每個(gè)企業(yè)需求變化又特別大，或者有很多企業(yè)，就是傳統(tǒng)企業(yè)他們對大數(shù)據(jù)的需求不是非常明確，互聯(lián)網(wǎng)企業(yè)他們需求變化非?？臁０凑諅鹘y(tǒng)的比如建一套大數(shù)據(jù)平臺(tái)，可能花費(fèi)很多成本，時(shí)間成本、人力成本，包括金錢。但是云平臺(tái)，大家知道IaaS、PaaS、SaaS，最后所有東西都變成服務(wù)器。你要構(gòu)建一個(gè)非常復(fù)雜方案的時(shí)候成本就低，因?yàn)槟阒恍枰凑辗?wù)構(gòu)建的方式來做，而且這樣非常靈活，如果你發(fā)現(xiàn)其中方案某一部分有問題，你可以很快的替換掉，因?yàn)楹芏喽际瞧脚_(tái)上的服務(wù)。所以，它可以滿足你的業(yè)務(wù)不確定性的需求，包括業(yè)務(wù)彈性的需求。因?yàn)榇蠹抑垃F(xiàn)在變化太快了。

第二，云計(jì)算給大數(shù)據(jù)帶來的好處是什么？比如它可以自動(dòng)化運(yùn)維，一些復(fù)雜系統(tǒng)的安裝、部署、監(jiān)控都不用你自己做，在界面上非?？斓木涂梢?，非常簡單就能做完。然后還有一些包括穩(wěn)定、性能，這個(gè)不多說了，云計(jì)算的好處大家肯定知道特別多，說幾個(gè)有意思的。

比如，網(wǎng)絡(luò)和存儲(chǔ)，計(jì)算引擎的切換，這個(gè)比較有意思。也就是當(dāng)你的平臺(tái)足夠復(fù)雜，足夠大的時(shí)候，每塊部分都是一個(gè)服務(wù)器，每一塊變成一個(gè)服務(wù)器之后，可以非常靈活的替換掉它，把他換成別的產(chǎn)品實(shí)現(xiàn)，或者別的技術(shù)實(shí)現(xiàn)。后面就是Service  Orchestration，就是比如你有一個(gè)界面，需要畫各種圖，或者工具也好，但是他們有一個(gè)非常致命的缺點(diǎn)，你畫的那個(gè)圖是不能執(zhí)行的，就是是不能部署，不能執(zhí)行的。Service  Orchestration是給你一個(gè)大的拓?fù)鋱D，這也是青云今年年初發(fā)布的一個(gè)產(chǎn)品，叫做資源編排?？梢栽谠破脚_(tái)把一整套的架構(gòu)部署出來，這是云上他們這些帶來的一些好處。

云上大數(shù)據(jù)平臺(tái)的挑戰(zhàn)。很多企業(yè)做大數(shù)據(jù)平臺(tái)在物理機(jī)上做，為什么沒有在云上做？因?yàn)樘魬?zhàn)非常多。第一，穩(wěn)定性的挑戰(zhàn)，比如高可用、災(zāi)備。第二，性能。一直被人垢病的，因?yàn)槟闶翘摂M機(jī)，肯定沒有網(wǎng)絡(luò)機(jī)的硬盤快。在青云第一個(gè)IaaS層的穩(wěn)定性已經(jīng)運(yùn)行好幾年了，沒有太多可說的。垢病性能這一塊，我們?nèi)ツ曜隽塑浖x網(wǎng)絡(luò)的2.0，2.0出來之后，這個(gè)是為云計(jì)算，為大的IaaS平臺(tái)專門研發(fā)的一套SDN，可以做到點(diǎn)對點(diǎn)之間的網(wǎng)絡(luò)傳輸，可以達(dá)到物理網(wǎng)卡。第二，在硬盤這塊一直被垢病的，我們?nèi)萜骷夹g(shù)，可以把硬盤的技術(shù)降的非常低。第三個(gè)好處就是遷移，遷移技術(shù)非常好，因?yàn)楝F(xiàn)在已經(jīng)有一些比較成形的，比如關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫。

我們說解決這些挑戰(zhàn)之后，我們會(huì)有一個(gè)大數(shù)據(jù)的平臺(tái)系統(tǒng)架構(gòu)出來這個(gè)架構(gòu)其實(shí)都是一個(gè)非常通用的架構(gòu)。就是你可能在很多企業(yè)里面，不管京東、美團(tuán)、亞馬遜，可能看到的基本都是這樣的樣子。其實(shí)先從左開始看起，其實(shí)是一個(gè)數(shù)據(jù)的生命周期，就是數(shù)據(jù)從哪個(gè)地方收集，可能是日志，可能是傳感器，收集過來到中間的核心平臺(tái)，最下面一層就是IaaS，青云所有PaaS層的服務(wù)都是基于IaaS做的，就是都是在云上面的。然后到第一個(gè)就是存儲(chǔ)。中間三個(gè)大塊，第一個(gè)叫實(shí)時(shí)計(jì)算，叫Storm，當(dāng)然Twitter現(xiàn)在出來的可能宣稱比Storm更強(qiáng)。第二，就是Batch  Processing，第三個(gè)就是Big  SQL，包括像Kylim等。右邊就是你做所有平臺(tái)可能都會(huì)做的，包括它的數(shù)據(jù)管理、監(jiān)控、安全，包括用來做分布式的配置中心的一項(xiàng)東西。

所有的數(shù)據(jù)經(jīng)過存儲(chǔ)、計(jì)算之后，你可能會(huì)通過一些，就是你想要一些非常好的用戶友好的方式使用這些數(shù)據(jù)，我們一般可能會(huì)把數(shù)據(jù)提交到比如說像一些交互性比較好的技術(shù)組件里面，這樣在最上層，不管報(bào)表還是可視化，像Hadoop生態(tài)圈里面比較流行的做可視化就比較方便。

我現(xiàn)在畫的這個(gè)圖里面，基本上就是在大數(shù)據(jù)的生命周期里面最核心的，或者說最主流的產(chǎn)品或者技術(shù)都涵蓋在里面了，青云自己的大數(shù)據(jù)平臺(tái)也是按照這個(gè)架構(gòu)來做的。

接下來先說一下，我會(huì)按照這個(gè)架構(gòu)，挨個(gè)的挨個(gè)的說。第一，先說一下計(jì)算。計(jì)算上面最經(jīng)典的就是Hadoop，這個(gè)圖不需要太多說。如果大家平時(shí)研究大數(shù)據(jù)，可以提一點(diǎn)，從2.0后之，它的HDFS有高可用，把之前的變成Yarn來支持，這樣會(huì)提升很大的性能。第二個(gè)計(jì)算型的架構(gòu)就是Spark，比如它上面有主流的一些功能。如果做實(shí)時(shí)計(jì)算，Storm肯定首選的。MapReduce延遲非常高，但是吞吐量很大。MapReduce的硬盤非常高，Spark Streaming由于它是硬盤計(jì)算，所以計(jì)算還好。如果之前有一些Hadoop生態(tài)圈的基礎(chǔ)，可能選Spark比較好，如果不是要求非常實(shí)時(shí)，因?yàn)镾park平臺(tái)非常強(qiáng)，它本身就是一個(gè)平臺(tái)，現(xiàn)在的平臺(tái)發(fā)展非?？欤钥赡苓xSpark，對你要求非常高，現(xiàn)在我們碰見的客戶都有。第二，Big  SQL里面，提幾個(gè)，一個(gè)是Phoenix，提供了SQ語言上包裝的產(chǎn)品。第二種就是MPP的。

存儲(chǔ)。最初就是HDFS，第一，一定是為大文件設(shè)計(jì)的，不是為海量小文件設(shè)計(jì)的。如果想處理海量小文件，在青云平臺(tái)上有一個(gè)想象就是對象存儲(chǔ)，我們當(dāng)時(shí)設(shè)計(jì)的時(shí)候不管文件什么類型，不管文件什么大小，都可以用這個(gè)存儲(chǔ)。HDFS為什么不能存海量小文件，原因很簡單，像Linux里面所有數(shù)據(jù)都有一個(gè)索引，如果存海量小文件，索引的數(shù)據(jù)有一個(gè)特點(diǎn)，不管數(shù)據(jù)文件大還是小，索引的數(shù)據(jù)都是一樣的大。存海量小文件的時(shí)候其實(shí)文件沒有多大，它會(huì)非常影響性能，導(dǎo)致數(shù)據(jù)整個(gè)存儲(chǔ)空間沒有利用慢，但是性能已經(jīng)不可用了。

第二個(gè)比較主流的存儲(chǔ)就是Hbase，Hbase是架構(gòu)在HDFS之上，它可以存非常寬的樣表，也可以存非常高的樣表，所有表的數(shù)據(jù)分布在每個(gè)節(jié)點(diǎn)上，其實(shí)它的架構(gòu)比這個(gè)復(fù)雜多了。其實(shí)你可以看成對應(yīng)一個(gè)表的概念。不知道大家有沒有人看Hbase，可能剛開始看Hbase比較費(fèi)解，因?yàn)樗橇惺降拇鎯?chǔ)，和以前看到的數(shù)據(jù)庫解的不一樣。其實(shí)它的定義非常簡單，就是最上面，第二行那句話，是一個(gè)稀疏的、分布式的、多維的、持久化的一個(gè)影射。稀疏的就是是一個(gè)單位格的比，Hbase在存儲(chǔ)格式上已經(jīng)解決了這個(gè)問題，可以存一個(gè)稀疏的表。第二，分布式的就不用解釋了。這個(gè)圖里面可以看到有一些時(shí)間戳的概念在里面，這是一個(gè)比如第一個(gè)是一個(gè)記錄的Row  Key，然后有一個(gè)Column  Families，然后有一個(gè)版本號。

存儲(chǔ)里面的選型，剛才說了幾個(gè)，做存儲(chǔ)選型怎么選？并不一定是一開始肯定會(huì)聽到很多人說Hbase一定比HDFS快，這些說法都是不責(zé)任的，都是一定要在什么場景下。比如說Hadoop，這樣的方式就是在做全局文件掃描的時(shí)候是快的，但是像Hbase做隨機(jī)存儲(chǔ)的時(shí)候是快的，所以也是分場景的。但是像中間這個(gè)KUDU，昨天一個(gè)客戶說他們正在用一個(gè)KUDU，屬于一個(gè)中間的方案，介于HDFS和Hbase之間的一個(gè)存儲(chǔ)引擎，現(xiàn)在還沒有看到大規(guī)模的生產(chǎn)應(yīng)用。這個(gè)就是今年年初做的一個(gè)數(shù)據(jù)倉庫，Greenplum  Database，是去年開源的。之前Greenplum的核心就能工業(yè)他們自己出來，它最大的一個(gè)好處，我們覺得有幾個(gè)，第一個(gè)是標(biāo)準(zhǔn)的SQL，你可能看到很多市面上的產(chǎn)品都說支持SQL，但是其實(shí)都不是標(biāo)準(zhǔn)的。不是標(biāo)準(zhǔn)的意味著什么？比如很多語法不一樣，你以前像數(shù)據(jù)工程師，數(shù)據(jù)分析師，他們用的比較高級的用法都沒法用。但是，Greenplum  Database不一樣，因?yàn)樗暮诵挠?jì)算引擎我們覺得比MySQL更好，它還有很多別的特點(diǎn)。

我們說完計(jì)算的產(chǎn)品，說完存儲(chǔ)的產(chǎn)品，接下來一些數(shù)據(jù)的傳輸。數(shù)據(jù)傳輸我們說一個(gè)最經(jīng)典的Kafka，是分布式、可分區(qū)、多副本、低延遲的。低延遲什么意思？左右這兩張圖長的很像，其實(shí)就是Kafka相當(dāng)于進(jìn)入和留出的數(shù)據(jù)，Kafka就是領(lǐng)英開源的，因?yàn)槲覀兤脚_(tái)提供了Kafka服務(wù)，他們現(xiàn)在也在用，這是他們是使用出來的一個(gè)產(chǎn)品。意思就是Kafka的延遲非常低，基本數(shù)據(jù)不落下來，直接就出去了。

為什么它可以這樣？有兩個(gè)非常本質(zhì)的原因：第一，它在寫數(shù)據(jù)的時(shí)候是直接寫到PageCatch里面，往外發(fā)的時(shí)候直接通過Linux發(fā)出去的，所以它的吞吐量延時(shí)非常低，這是兩個(gè)核心的原因。Kafka的架構(gòu)非常簡單，就是三個(gè)松偶合的，比如最上層是它的生產(chǎn)者，然后是一個(gè)集群，中間是一個(gè)服務(wù)器，Kafka的服務(wù)器，下面是它的消費(fèi)者。它的生產(chǎn)者一個(gè)集群都可以往broker里面發(fā)數(shù)據(jù)，相當(dāng)于broker把數(shù)據(jù)發(fā)到第一個(gè)Partition里面，第二個(gè)發(fā)到第二個(gè)Partition里面，Partition第一個(gè)主要概念就是你發(fā)布的消息是什么，你生產(chǎn)出的消息相對于在Kafka里面有幾個(gè)隊(duì)列，每個(gè)隊(duì)列就是一個(gè)Partition。

第二個(gè)集群就是它的消費(fèi)者，消費(fèi)者可以提比較重要的一點(diǎn)，它有一個(gè)消費(fèi)組的概念，這個(gè)組的概念非常重要。當(dāng)你想把一個(gè)Topic的消息想多播出去，想被很多個(gè)消費(fèi)者處理的時(shí)候，這個(gè)時(shí)候需要建多個(gè)消費(fèi)組，這個(gè)消息才能被多個(gè)消費(fèi)者來消費(fèi)。如果只建了一個(gè)消費(fèi)組，哪怕這個(gè)消費(fèi)組有好幾個(gè)消費(fèi)者，每次都是由一個(gè)消費(fèi)者處理的。第二個(gè)問題，就是消費(fèi)組里面消費(fèi)者的數(shù)量，這里面一個(gè)是兩個(gè)，一個(gè)是四個(gè)，就是一個(gè)消息里面有四個(gè)Partition，如果有四個(gè)消費(fèi)者，正好一對一，每個(gè)消費(fèi)者消費(fèi)一個(gè)Partition，如果只有一個(gè)消費(fèi)者，有一個(gè)會(huì)消費(fèi)兩個(gè)Partition。這種情況比較好。有一種情況要避免，就是比如有5個(gè)消費(fèi)者，你那個(gè)Topic只有4個(gè)隊(duì)列，你就會(huì)浪費(fèi)掉一個(gè)消費(fèi)者。這個(gè)是需要注意的。

說完了計(jì)算，說完了存儲(chǔ)，說完了傳出，然后說一些我們碰到的問題。第一個(gè)大問題就是復(fù)制因子的問題，為什么原生的不用考慮，但是云上為什么要獨(dú)特考慮呢？原因很簡單，因?yàn)樵谠粕厦嫠械姆?wù)都是基于IaaS做的，IaaS這一層本身有高可用，就是它的數(shù)據(jù)本身就是有副本的，如果你還照搬物理機(jī)上的做法，你就找三個(gè)副本，你想想2×3就是6個(gè)。所以，第一個(gè)就是要去副本，把它用兩個(gè)副本，這是我們最開始想的方案，用兩個(gè)副本就行了。但是，后來我們覺得兩個(gè)副本還是2×2=4，還是空間浪費(fèi)上會(huì)多一點(diǎn)。

后來我們想更高級的方案是什么？就是我們在IaaS這一層提供一種能力，讓PaaS層可以選擇，說我要幾個(gè)副本，就是變成一個(gè)選項(xiàng)，這樣比如像大數(shù)據(jù)這樣，或者非常脆弱的應(yīng)用，但是有時(shí)候比如不需要，有它自己的一個(gè)副本的策略，完全不需要IaaS層的副本，這個(gè)時(shí)候就根據(jù)你自己的配置，或者根據(jù)你自己的產(chǎn)品的需要可以配置IaaS層的副本策略，這樣跟物理就是一樣的了。

這個(gè)參數(shù)調(diào)優(yōu)，比如像典型的大數(shù)據(jù)里面每個(gè)產(chǎn)品或者每個(gè)平臺(tái)都有兩三百個(gè)參數(shù)，這個(gè)太正常了，這個(gè)時(shí)候做調(diào)優(yōu)第一個(gè)重要的步驟就是你應(yīng)該知道我們應(yīng)該盡量去知道這些調(diào)優(yōu)的參數(shù)之間什么關(guān)系，他們之間到底什么關(guān)系，不能只知道每一個(gè)參數(shù)是干什么的，要不然調(diào)一個(gè)，影響另外一個(gè)，或者調(diào)按沒有任何反應(yīng)，那是因?yàn)槟銢]有把這個(gè)關(guān)系搞清楚。像這樣的圖，可以把yarn里面的Node  Manager都弄的比它小，然后是yarn里面分配的內(nèi)存，這個(gè)之間的關(guān)系嘎明白，在做性能調(diào)優(yōu)的時(shí)候是很重要的。

最后一個(gè)比較重要的最佳實(shí)踐就是在數(shù)據(jù)格式上，這個(gè)肯定很多人都會(huì)忽略。但是在大數(shù)據(jù)里面非常重要，為什么？因?yàn)閿?shù)據(jù)很大，數(shù)據(jù)量非常大的時(shí)候，如果不注重?cái)?shù)據(jù)格式就會(huì)導(dǎo)致這幾個(gè)問題。比如可能性能會(huì)下降，然后你的空間反而浪費(fèi)了很多，成倍的上升。

其實(shí)數(shù)據(jù)格式比較注意的項(xiàng)非常多。我們挑出兩個(gè)比較重要的準(zhǔn)則，第一這個(gè)數(shù)據(jù)格式要可分隔。可分隔支持的格式有這些，比較多的像Avro、Parquet  Lzop+index、SequenceFile，不支持的就是XML、JSON文件。

然后可塊壓縮的，支持的就是Avro、Parquet、Lzop+index、SequenceFile，不支持的就是CSV、JSON記錄。大家可以想一下，我們在大數(shù)據(jù)平臺(tái)里面計(jì)算都是并行計(jì)算，它所有的數(shù)據(jù)都是分開來計(jì)算的，然后每一個(gè)分片對它進(jìn)行計(jì)算，所以，第二個(gè)是可塊壓縮的。其實(shí)還有很多點(diǎn)，比如數(shù)據(jù)格式是不是支持眼鏡的，像Avro就支持，就是數(shù)據(jù)格式的老版本和新版本還是可以兼容的。包括像SequenceFile，可伸縮，可壓縮，但是它只在Hadoop這個(gè)生態(tài)系統(tǒng)，不像Avro和Parquet。我們7月28號在北京飯店有一個(gè)青云自己的用戶大會(huì)，我們只負(fù)責(zé)服務(wù)，上面都是各個(gè)行業(yè)的精英講他們自己技術(shù)的干貨，產(chǎn)品的干貨，我們是這樣形式做的。掃描好像有個(gè)禮物，謝謝大家！