專訪攜程李亞鋒：大數據技術融合下的Spark更具魅力

「大數據」做爲當下最火熱的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。
- 原文地址：http://www.bi168.cn/>>http://www.bi168.cn/thread-4792-1-1.html