隨著移動互聯時代的到來，人們的雙手得到解放，因為通過智能手機APP和觸摸屏就可以徹底解決交互性和易用性的問題，這也使用戶行為數據呈現爆炸性 增長。大數據技術可以幫助我們對海量的數據進行加工分析，了解用戶的行為特征，以及他們對服務的期待，從而使用戶得到更好的服務體驗。

Hadoop 和Spark都是大家熟悉的大數據處理技術。大家都了解，基于內存計算的Spark適合各種迭代算法和交互式數據分析，能夠提升大數據處理的實時性和準確 性，已經逐漸獲得很多企業的支持，那是否意味著我們應該徹底拋棄Hadoop？在不久前的北京Spark亞泰峰會上 ，我們有機會專訪到攜程大數據平臺高級經理李亞鋒，與我們分享怎樣通過Spark與Hadoop等大數據技術間的融合，實現優勢互補，引導企業發現用戶的 潛在需求。

嘉賓介紹

李亞鋒，攜程大數據平臺高級經理，負責大數據底層平臺的運營和開發。2002年起一直專注于IT互聯網領域，做過網絡會議、IPTV、安全網關、游戲架構、搜索引擎、推薦引擎等，主要偏后臺架構和底層開發。加入攜程后，開始轉向大數據領域。

以下為51CTO記者對李亞鋒老師的專訪錄音整理。

您在攜程主要負責什么工作？目前我們大數據應用的情況是怎么樣的？

目前我是攜程DI（Data infrastructure）團隊高級經理，主要負責大數據底層平臺的運營和開發。

我2002年畢業后一直在IT互聯網的領域工作，加入攜程之后，轉向大數據領域。我們從4個節點的hadoop集群做起，目前達到200個節點規模，數據達3PB，每天job數3萬以上，每天數據增量40TB，有力支持了攜程大數據相關業務的發展。

大數據對我們公司業務的支持作用非常大，包括海量日志和metrics處理、推薦引擎、爬蟲、用戶行為日志分析、BI報表、風控、搜索引擎、機器學習、監控報警等都使用到大數據技術。

目前DI團隊有多少人？

包括我在內，總共6人。

咱們現在團隊里有六個人，成員不是很多，團隊的分工情況大致是什么狀況？

攜程的業務線比較長，部門比較多，相對于我們要支持的業務部門和數據規模來說，DI團隊人手確實偏緊。我們采用了一種比較新的工作方式，就是 DevOps（開發運維），用來提高整個團隊的效率。團隊成員既做開發又做運維，把運維的工作化解掉。我們要求團隊成員除了能解決生產環境出現的各種問題 外，還能修復bug，開發工具，并且為社區貢獻代碼。這樣對團隊成員的能力要求比較高，這方面的人才也比較緊缺。

攜程大數據平臺正在快速發展中，歡迎有志之士加盟，大家一起成長。

作為專門做在線旅游服務的公司，大數據給攜程的業務帶來什么轉變呢？

用戶到攜程的平臺，一般都有一個比較明確的消費目的，但并不等于說他沒有個性化方面的需求。這些個性化的需求在傳統的小數據時代是不能滿足的。當我 們積累到足夠的用戶數據，大數據技術就能分析出用戶的喜好與購買習慣，有時甚至比用戶自己還要了解自己。了解用戶的行為特征，以及他們對服務的期待，然后 利用這些數據，我們就可以對用戶做到精準細分，有針對性地對用戶提供個性化服務和推薦，從而使用戶得到更好的服務體驗。

攜程業務正在從PC端往移動端轉型，目前大概有一半的業務是在移動端完成的，應該說這個轉型還是非常成功的。移動端的用戶行為數據會遠大于PC端，這對我們來說是一個挑戰，同時也是一個機會。

作為OTA（在線旅游服務商）的龍頭，攜程在這個行業深耕十多年，有非常龐大的交易數據和用戶數據，這是我們一個非常大的優勢。利用這些龐大的歷史 數據，加上我們的品牌優勢，在大數據方向進行突破，加大投入和研發，未來肯定會產生很多意想不到的成果，拉大競爭對手與我們的距離。

總而言之，利用大數據技術可以幫助公司明確市場定位，分析用戶行為，發現潛在需求，進行趨勢預測，營銷創新，智能決策等等。

在使用Spark之前，我們還用過什么大數據的處理方法？

以前使用Hadoop/HBase，現在我們還在用。目前我們是把Spark和Hadoop/HBase結合起來在用。

我個人認為，實時性要求不高的，傳統的MapReduce還是可以的。第一它技術很成熟，第二它比較穩定，缺點就是慢一點，其他沒什么。另外，存儲 那塊現在HDFS還是不可能取代的，高容錯，高吞吐，分布式，也很穩定。還有實時讀寫方面，HBase也不會被spark取代。我認為底層存儲還是要用 Hadoop/HBase。

隨著技術的不斷發展，我們的選擇更多了，選擇也更趨于理性，關鍵是要看你的需求是什么。如果兩邊都差不多，那我們選擇一個穩定的。比方說這個job 跑一小時能接受，跑兩個小時也能接受，但我們要求穩定，肯定用MapReduce更合適。如果只是單純考慮效率，肯定是選擇一個執行速度快的系統。原來是 沒有選擇，只能通過各種手段優化，但是這個治標不治本，因為它受框架限制，性能不可能提升很多倍。現在有像Spark這樣更好的分布式計算引擎出來了，能 夠數倍的提高效率。那么我們的考慮是，對延遲要求比較高的job，可以考慮挪一部分出來放在spark引擎計算；延遲要求不高的，還是放在傳統的 mapreduce引擎計算。這兩個并不矛盾，關鍵還是要看哪個更適合你的需求。

對Spark來說，最大的優勢在于速度，那這個速度是怎么實現的呢？它相當于是用空間換時間，所以它耗資源，占內存。從運營的角度看，它的成本會比 MapReduce要高。spark在資源管理這塊目前還不夠成熟，但這都是發展中的問題，以后應該會解決。從整個架構來講，我認為Spark和 Hadoop兩個應該是互補，并不是說完全排斥、對立的。

您認為Spark以后會代替Hadoop嗎？

我覺得是不太可能代替。因為Hadoop畢竟被很多大公司驗證過，是沒有問題的，它肯定是可用的東西。Spark有很多的做法也是參考Hadoop 來實現的。現在Spark還在推廣階段，還沒有被大規模的使用。我認為Hadoop的地位未來會降一點，這個是肯定的，但是它不會消失，不可能被 Spark取代。

Spark基于內存上面進行計算，像您說相當于“空間換時間”，我們會不會考慮它會造成我們資源的浪費？

Spark里面分了幾大塊，第一塊叫Spark SQL，可以部分取代Hadoop hive；第二個是機器學習MLLib，可以取代mahout；第三個是圖計算GraphX，可以取代Pregel；第四塊是流式計算spark streaming，可以取代storm。每一塊解決不同的問題，不同的模塊可以有不同的集群，它可以獨立擴容。

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

您覺得在整個行業來看，目前spark發展的是什么樣？我們在這塊兒有什么優勢呢？

我個人的感覺，spark現在已經是逐步走向生產環節，開始真正投入使用了，但是大規模的使用還是不太多。橫向比較的話，我們攜程應該是走在前面 的，我們是真正在用了，很多公司還在嘗試使用階段，有的在測試階段，還沒有真正地在生產環境大規模使用。大家可能認為這個技術還不是非常成熟，從商業角度 來講投入到項目中還是有一定的風險。任何新技術都會有風險，這個是很正常的。但只要在駕馭范圍之內，風險還是可以控制的。

整體來看，大家對這個東西比較期待，發展勢頭很猛，但目前還是比較謹慎。

現在的數據規模增長的這么厲害，數量大，種類多，我們怎么對它進行具體地分析挖掘，來為業務創造價值的？

現在是移動互聯網時代，移動互聯網時代一個突出的問題是有很多用戶數據。PC不便攜帶和移動，傳統手機操作不方便、應用少，智能手機通過APP和觸 摸屏徹底解決了交互性和易用性問題，從而導致產生更多的用戶行為數據。數據增長速度會遠遠超過業務增長速度，比如攜程2014年的大數據增長了6倍，但是 業務并沒有增長6倍，兩者并非1：1關系。

數據大量增加有兩個原因：

1）用戶的行為確實變多了，因為應用越來越多，操作也越來越便捷。

2）大家嘗到了大數據的甜頭了，然后就會到處埋點，到處收集數據。這樣一來，原來認為沒用的數據，現在就變成有用的數據，自然而然數據就多了。

數據規?？隙ㄊ潜ㄊ皆鲩L，所有行業趨勢都是這樣。如果某一天我們換一種角度來思考當下發生的問題，原來可能覺得沒有價值的數據，可能一下子變得很有價值。前提是有歷史數據，否則無法進行分析。

現在很多公司提倡量化管理，或者說數字化管理。量化管理的前提是要有數據，所有的行為和現象都要數字化。所有的決策必須基于事實，數據就是事實，因 為數據是不會說假話（盡管存在數據噪音和數據質量問題，但這些可以通過技術手段處理掉）。也許有些數據不一定有用，但是它不會說假話。這樣一來就產生了各 種各樣的數據，全部收集起來，量就非常大。像我們攜程每天量化指標數據四百多億個條，如果放在傳統的數據庫，而且要實時讀寫/查詢，傳統的技術很難實現。 我們是通過HBase來處理，可以做到實時讀寫海量metrics。很多東西在過去認為不可能的，現在變成可能，或者已經做到了，所以大數據整個發展前景 還是不錯的。

現在在大數據里面有沒有其他的技術是您現在還想比較多關注的，還正在研究的，有這樣的技術嗎？如何做技術選擇？

除了HDFS/HBase/mapreduce/hive/spark/storm之外，我們還關注presto。

Presto是facebook新發布的產品，與spark sql類似，主要解決hive查詢慢的問題。

對下一代大數據處理技術，比如Caffeine、Pregel、Dremel，我們也在關注和跟進相關產品或項目。

我的個人觀點是，做技術選擇的時候，選擇A而不選擇B的原因，并不是說A就一定比B好，而是因為它是一個系統，是一個完整的東西。如果形成了一個生 態圈的話，那么它有很多東西在內部可以消化掉，不用一會兒跟這個系統做接口，一會兒跟那個系統做接口，數據都在同一個系統內部流動。如果是自成一體，有時 一個問題解決了，可能導致三個問題一起解決。如果是三個獨立系統，同一個問題可能需要在三個系統分別去解決，效率會低不少。

對于分布式系統而言，擴展性和伸縮性一般都不是問題，all in one系統運營成本更低。比如spark可以同時解決多個問題，無需部署多套不同系統，而storm只解決流式計算問題，因此我個人更偏向spark。