大資料”作為當下最火熱的it行業詞彙，在主流的資料處理工具當中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）大家嘗到了大資料的甜頭了，然後就會到處埋點，到處收集資料。這樣一來，原來認為沒用的資料，現在就變成有用的資料，自然而然資料就多了。
資料規模肯定是爆炸式增長，所有行業趨勢都是這樣。如果某一天我們換一種角度來思考當下發生的問題，原來可能覺得沒有價值的資料，可能一下子變得很有價值。前提是有曆史資料，否則無法進行分析。
現在很多公司提倡量化管理，或者說數字化管理。量化管理的前提是要有資料，所有的行為和現象都要數字化。所有的決策必須基于事實，資料就是事實，因為資料是不會說假話（盡管存在資料噪音和資料品質問題，但這些可以通過技術手段處理掉）。也許有些資料不一定有用，但是它不會說假話。這樣一來就産生了各種各樣的資料，全部收集起來，量就非常大。像我們攜程每天量化名額資料四百多億個條，如果放在傳統的資料庫，而且要實時讀寫/查詢，傳統的技術很難實作。我們是通過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。
原文釋出時間為：2014-12-24
本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号