近幾年隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展和智能移動(dòng)終端的普及，用戶(hù)在使用時(shí)間上的碎片化趨勢(shì)更加明顯，使得用戶(hù)行為數(shù)據(jù)呈現(xiàn)爆炸性增長(zhǎng)。以此同時(shí)，在大數(shù)據(jù)技術(shù)背景下，更加有效的利用這些海量的數(shù)據(jù)進(jìn)行加工分析，從而了解用戶(hù)的行為特征，更好的給用戶(hù)提供最佳的服務(wù)體驗(yàn)。

“大數(shù)據(jù)”作為當(dāng)下最火熱的IT行業(yè)詞匯，在主流的數(shù)據(jù)處理工具當(dāng)中Hadoop和Spark都被大家所熟悉。不過(guò)，目前基于內(nèi)存計(jì)算的Spark適合各種迭代算法和交互式數(shù)據(jù)分析，能夠提升大數(shù)據(jù)處理的實(shí)時(shí)性和準(zhǔn)確性，已經(jīng)逐漸獲得很多企業(yè)的支持。這是否意味著我們應(yīng)該徹底拋棄Hadoop？在前不久的北京Spark亞太峰會(huì)上 ，記者有機(jī)會(huì)專(zhuān)訪到攜程大數(shù)據(jù)平臺(tái)高級(jí)經(jīng)理李亞鋒，為大家分享如何通過(guò)Spark與Hadoop大數(shù)據(jù)技術(shù)間的融合，實(shí)現(xiàn)優(yōu)勢(shì)互補(bǔ)，引導(dǎo)企業(yè)發(fā)現(xiàn)用戶(hù)的潛在需求。

嘉賓介紹

李亞鋒，攜程大數(shù)據(jù)平臺(tái)高級(jí)經(jīng)理，負(fù)責(zé)大數(shù)據(jù)底層平臺(tái)的運(yùn)營(yíng)和開(kāi)發(fā)。2002年起一直專(zhuān)注于IT互聯(lián)網(wǎng)領(lǐng)域，從事過(guò)網(wǎng)絡(luò)會(huì)議、IPTV、安全網(wǎng)關(guān)、游戲架構(gòu)、搜索引擎、推薦引擎等，主要偏后臺(tái)架構(gòu)和底層開(kāi)發(fā)。加入攜程后，開(kāi)始轉(zhuǎn)向大數(shù)據(jù)領(lǐng)域。

以下為51CTO記者對(duì)李亞鋒老師的專(zhuān)訪錄音整理

您在攜程主要負(fù)責(zé)什么工作？目前我們大數(shù)據(jù)的應(yīng)用情況和規(guī)模是怎么樣的？

目前我是攜程DI（Data infrastructure）團(tuán)隊(duì)高級(jí)經(jīng)理，主要負(fù)責(zé)大數(shù)據(jù)底層平臺(tái)的運(yùn)營(yíng)和開(kāi)發(fā)。

我2002年畢業(yè)后一直在IT互聯(lián)網(wǎng)的領(lǐng)域工作，加入攜程之后，轉(zhuǎn)向大數(shù)據(jù)領(lǐng)域。我們從4個(gè)節(jié)點(diǎn)的hadoop集群做起，目前達(dá)到200個(gè)節(jié)點(diǎn)的規(guī)模，數(shù)據(jù)達(dá)3PB，每天job數(shù)3萬(wàn)以上，每天數(shù)據(jù)增量40TB，有力支持了攜程大數(shù)據(jù)相關(guān)業(yè)務(wù)的發(fā)展。

大數(shù)據(jù)對(duì)我們公司業(yè)務(wù)的支持作用非常大，包括海量日志和metrics處理、推薦引擎、爬蟲(chóng)、用戶(hù)行為日志分析、BI報(bào)表、風(fēng)控、搜索引擎、機(jī)器學(xué)習(xí)、監(jiān)控報(bào)警等都使用到大數(shù)據(jù)技術(shù)。

目前DI團(tuán)隊(duì)有多少人？

包括我在內(nèi)，總共6人。

咱們現(xiàn)在團(tuán)隊(duì)里有六個(gè)人，成員不是很多，團(tuán)隊(duì)的分工情況大致是什么狀況？

攜程的業(yè)務(wù)線比較長(zhǎng)，部門(mén)比較多，相對(duì)于我們要支持的業(yè)務(wù)部門(mén)和數(shù)據(jù)規(guī)模來(lái)說(shuō)，DI團(tuán)隊(duì)人手確實(shí)偏緊。我們采用了一種比較新的工作方式，就是DevOps（開(kāi)發(fā)運(yùn)維），用來(lái)提高整個(gè)團(tuán)隊(duì)的效率。團(tuán)隊(duì)成員既做開(kāi)發(fā)又做運(yùn)維，把運(yùn)維的工作化解掉。我們要求團(tuán)隊(duì)成員除了能解決生產(chǎn)環(huán)境出現(xiàn)的各種問(wèn)題外，還能修復(fù)bug，開(kāi)發(fā)工具，并且為社區(qū)貢獻(xiàn)代碼。這樣對(duì)團(tuán)隊(duì)成員的能力要求比較高，這方面的人才也比較緊缺。

攜程大數(shù)據(jù)平臺(tái)正在快速發(fā)展中，我們希望有志之士加盟，大家一起成長(zhǎng)。

作為專(zhuān)門(mén)做在線旅游服務(wù)的公司，大數(shù)據(jù)給攜程的業(yè)務(wù)帶來(lái)什么轉(zhuǎn)變呢？

用戶(hù)到攜程的平臺(tái)，一般都有一個(gè)比較明確的消費(fèi)目的，但并不等于說(shuō)他沒(méi)有個(gè)性化方面的需求。這些個(gè)性化的需求在傳統(tǒng)的小數(shù)據(jù)時(shí)代是不能滿(mǎn)足的。當(dāng)我們積累到足夠的用戶(hù)數(shù)據(jù)，大數(shù)據(jù)技術(shù)就能分析出用戶(hù)的喜好與購(gòu)買(mǎi)習(xí)慣，得出的結(jié)果有時(shí)甚至比用戶(hù)自己還要了解自己。通過(guò)對(duì)數(shù)據(jù)的分析，了解用戶(hù)的行為特征，以及他們對(duì)服務(wù)的期待，然后利用這些數(shù)據(jù)，我們就可以對(duì)用戶(hù)做到精準(zhǔn)細(xì)分，有針對(duì)性地對(duì)用戶(hù)提供個(gè)性化服務(wù)和推薦，從而使用戶(hù)得到更好的服務(wù)體驗(yàn)。

攜程業(yè)務(wù)正在從PC端往移動(dòng)端轉(zhuǎn)型，目前大概有一半的業(yè)務(wù)是在移動(dòng)端完成的，應(yīng)該說(shuō)這個(gè)轉(zhuǎn)型還是非常成功的。移動(dòng)端的用戶(hù)行為數(shù)據(jù)會(huì)遠(yuǎn)大于PC端，這對(duì)我們來(lái)說(shuō)是一個(gè)挑戰(zhàn)，同時(shí)也是一個(gè)機(jī)會(huì)。

作為OTA（在線旅游服務(wù)商）的龍頭，攜程在這個(gè)行業(yè)深耕十多年，有非常龐大的交易數(shù)據(jù)和用戶(hù)數(shù)據(jù)，這是我們一個(gè)非常大的優(yōu)勢(shì)。利用這些龐大的歷史數(shù)據(jù)，加上我們的品牌優(yōu)勢(shì)，在大數(shù)據(jù)方向進(jìn)行突破，加大投入和研發(fā)，未來(lái)肯定會(huì)產(chǎn)生很多意想不到的成果。

總而言之，利用大數(shù)據(jù)技術(shù)可以幫助公司明確市場(chǎng)定位，分析用戶(hù)行為，發(fā)現(xiàn)潛在需求，進(jìn)行趨勢(shì)預(yù)測(cè)，營(yíng)銷(xiāo)創(chuàng)新，智能決策等等。

在使用Spark之前，我們還用過(guò)什么大數(shù)據(jù)的處理方法？

以前使用Hadoop/HBase，現(xiàn)在我們還在用。目前我們是把Spark和Hadoop/HBase結(jié)合起來(lái)在用。

我個(gè)人認(rèn)為，實(shí)時(shí)性要求不高的，傳統(tǒng)的MapReduce還是可以的。第一它技術(shù)很成熟，第二它比較穩(wěn)定，缺點(diǎn)就是慢一點(diǎn)，其他沒(méi)什么。另外，存儲(chǔ)那塊現(xiàn)在HDFS還是不可能取代的，高容錯(cuò)，高吞吐，分布式，也很穩(wěn)定。還有實(shí)時(shí)讀寫(xiě)方面，HBase也不會(huì)被spark取代。我認(rèn)為底層存儲(chǔ)還是要用Hadoop/HBase。

隨著技術(shù)的不斷發(fā)展，我們的選擇更多了，選擇也更趨于理性，關(guān)鍵是要看你的需求是什么。如果兩邊都差不多，那我們選擇一個(gè)穩(wěn)定的。比方說(shuō)這個(gè)job跑一小時(shí)能接受，跑兩個(gè)小時(shí)也能接受，但我們要求穩(wěn)定，肯定用MapReduce更合適。如果只是單純考慮效率，肯定是選擇一個(gè)執(zhí)行速度快的系統(tǒng)。原來(lái)是沒(méi)有選擇，只能通過(guò)各種手段優(yōu)化，但是這個(gè)治標(biāo)不治本，因?yàn)樗芸蚣芟拗?，性能不可能提升很多倍?，F(xiàn)在有像Spark這樣更好的分布式計(jì)算引擎出來(lái)了，能夠數(shù)倍的提高效率。那么我們的考慮是，對(duì)延遲要求比較高的job，可以考慮挪一部分出來(lái)放在spark引擎計(jì)算；延遲要求不高的，還是放在傳統(tǒng)的mapreduce引擎計(jì)算。這兩個(gè)并不矛盾，關(guān)鍵還是要看哪個(gè)更適合你的需求。

對(duì)Spark來(lái)說(shuō)，最大的優(yōu)勢(shì)在于速度，那這個(gè)速度是怎么實(shí)現(xiàn)的呢？它相當(dāng)于是用空間換時(shí)間，所以它耗資源，占內(nèi)存。從運(yùn)營(yíng)的角度看，它的成本會(huì)比MapReduce要高。spark在資源管理這塊目前還不夠成熟，但這都是發(fā)展中的問(wèn)題，以后應(yīng)該會(huì)解決。從整個(gè)架構(gòu)來(lái)講，我認(rèn)為Spark和Hadoop兩個(gè)應(yīng)該是互補(bǔ)，并不是說(shuō)完全排斥、對(duì)立的。

您認(rèn)為Spark以后會(huì)代替Hadoop嗎？

我覺(jué)得是不太可能代替。因?yàn)镠adoop畢竟被很多大公司驗(yàn)證過(guò)，是沒(méi)有問(wèn)題的，它肯定是可用的東西。Spark有很多的做法也是參考Hadoop來(lái)實(shí)現(xiàn)的?，F(xiàn)在Spark還在推廣階段，還沒(méi)有被大規(guī)模的使用。我認(rèn)為Hadoop的地位未來(lái)會(huì)降一點(diǎn)，這個(gè)是肯定的，但是它不會(huì)消失，不可能被Spark取代。

Spark基于內(nèi)存上面進(jìn)行計(jì)算，像您說(shuō)相當(dāng)于“空間換時(shí)間”，我們會(huì)不會(huì)考慮它會(huì)造成我們資源的浪費(fèi)？

Spark里面分了幾大塊，第一塊叫Spark SQL，可以部分取代Hadoop hive；第二個(gè)是機(jī)器學(xué)習(xí)MLLib，可以取代mahout；第三個(gè)是圖計(jì)算GraphX，可以取代Pregel；第四塊是流式計(jì)算spark streaming，可以取代storm。每一塊解決不同的問(wèn)題，不同的模塊可以有不同的集群，它可以獨(dú)立擴(kuò)容。

Spark對(duì)資源是有一定的浪費(fèi)，但浪費(fèi)也是相對(duì)的，要看你使用的頻率高不高。如果這個(gè)集群很繁忙，經(jīng)常不斷地有人提交工作，RDD重用率很高，那就不是浪費(fèi)。這就好比建了個(gè)大房子，如果一年只住一次，那其實(shí)很浪費(fèi)。如果這個(gè)房子住了很多人，而且天天住，那就不浪費(fèi)。

您覺(jué)得在整個(gè)行業(yè)來(lái)看，目前spark發(fā)展的是什么樣？我們?cè)谶@塊兒有什么優(yōu)勢(shì)呢？

我個(gè)人的感覺(jué)，spark現(xiàn)在已經(jīng)是逐步走向生產(chǎn)環(huán)節(jié)，開(kāi)始真正投入使用了，但是大規(guī)模的使用還是不太多。橫向比較的話(huà)，我們攜程應(yīng)該是走在前面的，我們是真正在用了，很多公司還在嘗試使用階段，有的在測(cè)試階段，還沒(méi)有真正地在生產(chǎn)環(huán)境大規(guī)模使用。大家可能認(rèn)為這個(gè)技術(shù)還不是非常成熟，從商業(yè)角度來(lái)講投入到項(xiàng)目中還是有一定的風(fēng)險(xiǎn)。任何新技術(shù)都會(huì)有風(fēng)險(xiǎn)，這個(gè)是很正常的。但只要在駕馭范圍之內(nèi)，風(fēng)險(xiǎn)還是可以控制的。

整體來(lái)看，大家對(duì)這個(gè)東西比較期待，發(fā)展勢(shì)頭很猛，但目前還是比較謹(jǐn)慎。

現(xiàn)在的數(shù)據(jù)規(guī)模增長(zhǎng)的這么厲害，數(shù)量大，種類(lèi)多，我們?cè)趺磳?duì)它進(jìn)行具體地分析挖掘，來(lái)為業(yè)務(wù)創(chuàng)造價(jià)值的？

現(xiàn)在是移動(dòng)互聯(lián)網(wǎng)時(shí)代，移動(dòng)互聯(lián)網(wǎng)時(shí)代一個(gè)突出的問(wèn)題是有很多用戶(hù)數(shù)據(jù)。PC不便攜帶和移動(dòng)，傳統(tǒng)手機(jī)操作不方便、應(yīng)用少，智能手機(jī)通過(guò)APP和觸摸屏徹底解決了交互性和易用性問(wèn)題，從而導(dǎo)致產(chǎn)生更多的用戶(hù)行為數(shù)據(jù)。數(shù)據(jù)增長(zhǎng)速度會(huì)遠(yuǎn)遠(yuǎn)超過(guò)業(yè)務(wù)增長(zhǎng)速度，比如攜程2014年的大數(shù)據(jù)增長(zhǎng)了6倍，但是業(yè)務(wù)并沒(méi)有增長(zhǎng)6倍，兩者并非1：1關(guān)系。

數(shù)據(jù)大量增加有兩個(gè)原因：

1）用戶(hù)的行為確實(shí)變多了，因?yàn)閼?yīng)用越來(lái)越多，操作也越來(lái)越便捷。

2）大家嘗到了大數(shù)據(jù)的甜頭了，然后就會(huì)到處埋點(diǎn)，到處收集數(shù)據(jù)。這樣一來(lái)，原來(lái)認(rèn)為沒(méi)用的數(shù)據(jù)，現(xiàn)在就變成有用的數(shù)據(jù)，自然而然數(shù)據(jù)就多了。

數(shù)據(jù)規(guī)模肯定是爆炸式增長(zhǎng)，所有行業(yè)趨勢(shì)都是這樣。如果某一天我們換一種角度來(lái)思考當(dāng)下發(fā)生的問(wèn)題，原來(lái)可能覺(jué)得沒(méi)有價(jià)值的數(shù)據(jù)，可能一下子變得很有價(jià)值。前提是有歷史數(shù)據(jù)，否則無(wú)法進(jìn)行分析。

現(xiàn)在很多公司提倡量化管理，或者說(shuō)數(shù)字化管理。量化管理的前提是要有數(shù)據(jù)，所有的行為和現(xiàn)象都要數(shù)字化。所有的決策必須基于事實(shí)，數(shù)據(jù)就是事實(shí)，因?yàn)閿?shù)據(jù)是不會(huì)說(shuō)假話(huà)（盡管存在數(shù)據(jù)噪音和數(shù)據(jù)質(zhì)量問(wèn)題，但這些可以通過(guò)技術(shù)手段處理掉）。也許有些數(shù)據(jù)不一定有用，但是它不會(huì)說(shuō)假話(huà)。這樣一來(lái)就產(chǎn)生了各種各樣的數(shù)據(jù)，全部收集起來(lái)，量就非常大。像我們攜程每天量化指標(biāo)數(shù)據(jù)四百多億個(gè)條，如果放在傳統(tǒng)的數(shù)據(jù)庫(kù)，而且要實(shí)時(shí)讀寫(xiě)/查詢(xún)，傳統(tǒng)的技術(shù)很難實(shí)現(xiàn)。我們是通過(guò)HBase來(lái)處理，可以做到實(shí)時(shí)讀寫(xiě)海量metrics。很多東西在過(guò)去認(rèn)為不可能的，現(xiàn)在變成可能，或者已經(jīng)做到了，所以大數(shù)據(jù)整個(gè)發(fā)展前景還是不錯(cuò)的。

現(xiàn)在在大數(shù)據(jù)里面有沒(méi)有其他的技術(shù)是您現(xiàn)在還想比較多關(guān)注的，還正在研究的，有這樣的技術(shù)嗎？如何做技術(shù)選擇？

除了HDFS/HBase/mapreduce/hive/spark/storm之外，我們還關(guān)注presto。

Presto是facebook新發(fā)布的產(chǎn)品，與spark sql類(lèi)似，主要解決hive查詢(xún)慢的問(wèn)題。

對(duì)下一代大數(shù)據(jù)處理技術(shù)，比如Caffeine、Pregel、Dremel，我們也在關(guān)注和跟進(jìn)相關(guān)產(chǎn)品或項(xiàng)目。

我的個(gè)人觀點(diǎn)是，做技術(shù)選擇的時(shí)候，選擇A而不選擇B的原因，并不是說(shuō)A就一定比B好，而是因?yàn)樗且粋€(gè)系統(tǒng)，是一個(gè)完整的東西。如果形成了一個(gè)生態(tài)圈的話(huà)，那么它有很多東西在內(nèi)部可以消化掉，不用一會(huì)兒跟這個(gè)系統(tǒng)做接口，一會(huì)兒跟那個(gè)系統(tǒng)做接口，數(shù)據(jù)都在同一個(gè)系統(tǒng)內(nèi)部流動(dòng)。如果是自成一體，有時(shí)一個(gè)問(wèn)題解決了，可能導(dǎo)致三個(gè)問(wèn)題一起解決。如果是三個(gè)獨(dú)立系統(tǒng)，同一個(gè)問(wèn)題可能需要在三個(gè)系統(tǒng)分別去解決，效率會(huì)低不少。

對(duì)于分布式系統(tǒng)而言，擴(kuò)展性和伸縮性一般都不是問(wèn)題，all in one系統(tǒng)運(yùn)營(yíng)成本更低。比如spark可以同時(shí)解決多個(gè)問(wèn)題，無(wú)需部署多套不同系統(tǒng)，而storm只解決流式計(jì)算問(wèn)題，因此我個(gè)人更偏向spark。