專訪王峰：Hadoop生態下一代計算引擎-streaming和batch的統一
編者按：Hadoop于2006年1月28日誕生，至今已有10年，它改變了企業對數據的存儲、處理和分析的過程，加速了大數據的發展，形成了自己的極其火爆的技術生態圈，并受到非常廣泛的應用。在2016年Hadoop十歲生日之際，InfoQ策劃了一個Hadoop熱點系列文章，為大家梳理Hadoop這十年的變化，技術圈的生態狀況，回顧以前，激勵以后。本次InfoQ便采訪了阿里搜索離線基礎平臺團隊負責人王峰，和大家一起聊一聊Hadoop。
InfoQ：您是2009年開始關注Hadoop生態技術發展，并逐步將其引入阿里電商搜索技術體系。那時的Hadoop生態圈是怎樣的？可否介紹下Hadoop在阿里的歷史？
王峰：對于Hadoop，我個人很早就了解了。Hadoop 06年出來，我們07在雅虎中國見到用Hadoop做search，搜索引擎是大數據的第一個應用場景。當時和雅虎美國合作看過Hadoop應用，那時還是0.1x版本，07年也見到了HBase被首次嘗試用于yahoo vertical search中。在08年阿里第一個Hadoop項目——云梯，就在我們搜索技術中心誕生的。09、10年我重新到淘寶搜索后臺開始建立Hadoop，算是正式將Hadoop用于生產系統，以前是直接做離線數據分析、BI、統計，不支持在線業務。10年我們將整個阿里巴巴的搜索、后臺數據、商品更新這些數據用Hadoop從MySQL同步過來，做處理，建索引，更新到線上的搜索引擎，供買家搜索商品，做跟交易相關的線上系統的連接。那時也開始做HBase，剛起步，做阿里集團以及全網商品的存儲。10年時集群才100、200臺，而現在個性化搜索、推薦這種真正引導電商成交的關鍵鏈路都是在Hadoop上做，現在應該有幾千臺規模做實時交易的數據處理，這已經不是大數據場景的數據挖掘、數據訓練，這是online或者說nearline。我們是服務于在線的數據分析，比方說一個賣家更新一個商品，我們可以秒級同步到線上讓買家看到。這聽起來簡單，但像淘寶這樣的電商，這是要經過好幾百個feature的計算，很多數據處理的環節，這個過程是很長的。而我們甚至在雙11的場景，也能做到秒級。
InfoQ：對于HBase而言，Java GC和讀寫性能是它的兩大問題，這方面你們做了哪些優化嗎？
王峰：HBase我們是長期投入，現在我們有一些成員專注跟HBase。GC方面也是比較大的投入，在高并發讀寫、大數據量情況下，比如雙11，就有2千萬 QPS，那GC就成了大問題。但又不好調，Java的GC又不能代碼級改動。現在主流是用CMS GC，相對來說還是最穩定可調的，我們也針對我們應用場景做了定制調法，因為GC調法沒有規范，只能說適合你的系統。比如你要考慮訪問IO特性，來的request大小，新生代舊生代規律，像我們就是除了GC log，還配合visualvm等工具直接去看GC情況，嘗試各種參數組合去調，然后找到相對最優的，其實是磨出來的，經過實踐找到的。
而關于讀寫性能，HBase用HDFS 做文件系統，而HDFS 是高吞吐而不是低延遲，所以本身不是隨機訪問能力很強的。而且我們情況更為困難，為了提高效率，我們HDFS，YARN和HBase是混布的，HBase和HDFS 做存儲，YARN做計算調度，資源是共享的。 對此我們的解決方案是利用HDFS的新特性：支持內存、SSD、HDD混合存儲。不過混合存儲不很穩定，不很成熟，我們做了自己的優化，改進了one SSD策略。就是HDFS 有三個冗余備份,我們用一塊冗余備份做SSD，同時我們在混合架構下也做了自己策略的優化，就是有些機器有SSD，有些沒有，因為集群的機器不可能都是一樣的。我們做了特制的優化，做到訪問熱點數據或關鍵表數據都是SSD，隨機讀在SSD，順序讀在普通的機械硬盤做。這樣隨機讀、順序讀、HDFS和HBase在IO的隔離，就天然地實現了。這樣后，在高并發時，SSD的高QPS的特性可保證HBase的latency，而且成本低很多，因為只是把重要的數據的一份放在HDFS上。
InfoQ:有人說，目前YARN和HDFS 是同級別的模塊，而以后HDFS會成為YARN的一個組件，也由YARN統一調度。
王峰：我覺得理論上是可以的，但這里有一個相互依賴的問題，你要用YARN，就要有一些Storage的支持，現在是HDFS 作支持，這是循環依賴。比如我提交了我的代碼，部署一個application到YARN，比如HDFS 作為第一個application，那它存在哪里，要把包傳上來，所以至少要有一個存儲。或者說你為它單獨定制一個存儲，但我個人認為這個意義不大，比如很多人談HBase on YARN，Kafka on YARN，我覺得運維或臨時搭集群才有這個需求，生產系統沒有。因為HDFS ，HBase,Kafka都用到本地磁盤，不可能臨時搭一個就換了，因為on YARN的東西就是可以隨時漂移嘛，但我搭了HDFS ，肯定是每臺機器一個嘛， 不能是有些機器有，有些機器沒有，而且過兩天還要換？！ 數據是不適合來回移動的，否則成本會很高。你有這個需求那就類似搭虛擬機一樣，我先起來一個instance，過兩天不用了就關掉，過兩天再起起來，這個適合臨時集群，對穩定的生產集群意義不大。
InfoQ:YARN增加了對Docker的支持，您覺得Docker對YARN意義大嗎？
王峰：Docker on YARN也是一種嘗試嘛，這并不沖突，YARN作為調度管理。Docker可作為容器部分和執行器，這個趨勢更像一個輕量級虛擬化的資源管理方式，我個人覺得這是有用武之地的，特別是做一些輕量級的application的資源復用。做一些簡單的web服務啊，python程序，如果都做一個虛擬機，隔離太重了，畢竟有開銷。而這么做就好很多。YARN專注于調度，將隔離交給Docker，是不錯的解決方案，阿里內部就有很多這樣的思路，已經實現了。
InfoQ：Yarn會朝著通用資源管理和調度方向發展吧？包括對 MapReduce、Spark 短作業的支持，以及對 Web Service 等長服務的支持
王峰：恩。我覺得這是Hadoop社區最大的成長空間，一開始1.0是HDFS +MapReduce，2.0后是HDFS +YARN。HDFS作為基于大文件的分布式文件系統基本比較通用了，沒有必要找替代物了，但YARN還有類似的系統，如Mesos。不過它與YARN理念不完全一樣，也有不少場景在用Mesos。
剛剛說，作為Hadoop生態系統最大的生長空間其實在于YARN，因為HDFS比較穩定，文件系統的新功能推出也相對慢一些，重點還是在性能改進。反而是YARN可以讓更多的生態進來，比如Spark，Flink這些東西都可以on YARN，因為你在上面就可以和大家共享計算資源，所以YARN更像一個大的Hadoop生態的容器，希望把更多的新的技術包進來。這個做的好的話，我覺得它就類似linux成為大數據的os，不管什么好的東西出來，你都可以運行在這個平臺上。到那時Hadoop就只是一個代名詞，那就意味著一種大數據的開源生態啦。 現在Hadoop已經是一個生態，但現在它和Spark是非常微妙的，Spark也是一個生態，不過YARN的生態和Spark的生態不是一個概念。YARN說Spark可以跑在我上面，Spark說我可以不跑在你上面，這是一個矩陣交叉的感覺。但任何計算模型都是有生命周期的。所以我覺得Hadoop做的聰明的一點就是，把YARN這種os的概念放進來了，我不管你多好，我都可以把你放在我上面。你基于我來做，我不斷沉淀我的web os系統，以后的模型都可以跑在我上面。所以它放掉了MapReduce，MapReduce其實是配角了，我覺得它慢慢就會荒廢掉。但如果以后的計算模型可以和YARN結合好，那Hadoop生態社區就非常豐富，百花齊放。不同的新的好的東西都share資源，跑在一起，我個人覺得這是比較健康的發展方向
InfoQ：Spark vs Hadoop？它們是競爭關系？
王峰：我覺得現在來看，競爭關系也有一部分。就跟我們做產品一樣，這就像微信和ios的關系，Spark像微信，YARN像ios，當你的計算模型強到一定程度時，就希望把底下的東西蓋住。就比如微信強到一定程度時，你就不需要用ios的東西，用我微信的東西就足夠了，微信里什么東西都很全面。Spark就這樣，它很強勢，它有自己的管理系統，其實你不用考慮在YARN上起別的東西，我這已經是個生態了，要跑批處理、跑流式、跑機器學習，它很全面，它都有。這就相當于說我不是直接說和Hadoop競爭，不是對等關系，但從用戶角度來說，你的需求在Spark這層已經解決了，你可以忘記YARN那個東西，是這么一個競爭關系。但也可以是一個競合關系，就是Spark可以把他的資源管理和YARN合作，你不能假設你解決了一切的問題，這是用戶的選擇，你不可能想到一切，而如果YARN上其他方案能解決，那你run on YARN，這就是合作關系。
InfoQ：可否介紹下Hadoop生態目前最前沿的技術和概念？
王峰：分三個方向，一是調度，以YARN為主，這是一個比較核心的能力，往在線高可用方向發展。Hadoop以前是離線，以后應該走向online。以前離線調度作業，失敗就失敗了，而走向online調度就很有挑戰。現在YARN也在努力，比如說沒有單點，但離Borg還有差距。
二是存儲，HBase ,HDFS是老牌的，新的存儲出現了，druid,pinot這種新的列存儲，真正的colume加上index的這種列存儲，尤其是做數據分析的列存儲技術都是相對新的，不再是老的那些概念了。也有一些新的方向，tachyon這種分布式內存的，支持Spark的分布式內存存儲系統，這都是一些新的思路，而且以后會有很好的業務場景的，因為這都是需求逼出來的系統，有很大的應用場景。
最火的還是計算，MapReduce基本就更新掉，但不會馬上離開，它的穩定性、吞吐量還是最好的，因為它積累了太多年，在一定場景內可以存在。但我覺得就是落后產業了。 新的像實時計算，Storm，不過Storm本身不是很先進的系統，可以說是上時代的產物了，推ter的heron以及阿里的jstrom還在發展Storm體系，但我覺得這也不是體量大的系統。最大的還是Spark，Spark是現在最輝煌的系統。我們還關注Flink這個系統，這是一個新的計算引擎。從理論來看，它比Spark更沒有邊界，更先進。Spark很火，但是它畢竟是一個（batch）系統，做離線的，批處理的是它的先天優勢，可能做一些內存迭代、機器學習或者替代MapReduce做算子層更豐富的批處理。但它本質是一個batch，它最大的問題就是Spark stream,轉換成一個離散的流，可以認為是把batch切小，每個batch可以認為是無限小，比如網絡上一秒的數據形成一個RDD的batch，再來一個，再提一個，不停地提job。但是這個是batch，就相當于你再切，他還是一個batch，這是一個理論問題，不是你技術牛不牛的問題，就相當于給你一個木棍子，你切切切，你再切，切再薄的片，它還是有厚度的。但Flink是反的，它認為stream是一切，batch是special case，batch只是一個有明確start和end的stream，它是德國那個論文發的，Flink的模型在我們看來是更先進的，它自己號稱是第四代，它是說MapReduce第一代，Storm第二代，Spark第三代，它第四代。 Flink還沒發展起來，沒大廠驗證，但它基因更好，它拿流可以模擬batch，這是完全沒有約束的，就像我可以拿原子組成物體。而這是不可逆的，就像你不能把一個東西碎成原子，你只是一直切切切，但是原子可以組成任何東西。從這里來說，Flink是unlimited，它沒有明顯的技術限制。現實的例子是，我們想把數據做到毫秒級更新超大規模場景，Spark是做不到的，根據他現在的理論架構無論如何做不到，RDD是如何也做不到的。一個batch，你怎么弄也做不到一毫秒提一個job，這是不可能的。batch粒度有點粗，你要想做到，你要做無限優化，還不敢保證成功。而Flink若做無限優化，就可以stream轉batch，所有你有的東西我都有。這其實是很恐怖的，特別在一個互聯網領域，一個小東西如果基因足夠好，有足夠的成長空間，它可以長到無限大。而再大的東西遇到瓶頸的話，也會遇到危險。反正現在能看到的就是，Spark能穩定的往前走，Flink就看能不能沖起來。
InfoQ：最后一個問題，現有的Hadoop集群，版本是如何管理的？
王峰：我們團隊是使用社區的版本，做一些自己的改進，并且會把改進提交到社區。因為我覺得很私有地維護一個版本是有問題的，因為社區發展很快，你私有一個版本，短期你覺得占便宜了，把很多新的東西弄進來，自己加了一些東西社區都沒有。但一兩年以后呢？這是長跑，你可以沖刺一下，但不能年年這樣。你的團隊會有變化，人員會有更改，會有業務上的緊張，資源進度上的變化。長期跑贏社區幾乎是不可能的。我們選擇的就是專門幾個人跟這個方向，如果我們覺得這是一個好的抽象好的feature，我們就會提交給社區。我們也在培養自己的committer。我們不私有化這個東西，但肯定有一些非常定制的，這是不可避免的。比如社區就是不認這個東西，但我們業務的確有這個需求。我們會有一個阿里內部的發行版，用作集群部署的版本管理。這個版本會結合Cloudera、社區版的（patch），把有些東西拿過來，和我們自己的（patch)合進來，但是和社區是兼容的，比如社區升級，我們也會升過來，有些（patch）已經被合進社區版本了，沒合進去的我們再合一次。但不會保留太多私有版本。
受訪者簡介
王峰，淘寶花名莫問，2006年畢業后即加入阿里巴巴集團，長期從事搜索和大數據基礎技術研發工作，目前負責阿里搜索事業部離線基礎平臺團隊。自2010年開始將hadoop生態技術正式引入阿里搜索技術體系，帶領團隊打造出的數據基礎設施，每日可實時處理阿里集團內的海量商品和用戶行為數據更新，直接影響并提升搜索和推薦引導成交，承擔了阿里電商數據流程的核心職責。我們團隊管理著目前阿里最大的Hadoop集群，上面運行的搜索以及推薦業務也是阿里集團最核心的電商場景。我們希望站在Hadoop生態圈的肩膀上，基于自身業務場景優勢，在實踐中不斷產生新技術并回饋給社區，與開源技術發展形成良性循環和促進，歡迎各位Hadoop生態圈內的有志之士加入我們（微博：淘莫問），一起打造世界一流的數據基礎設施團隊。
來自： http://www.infoq.com/cn/articles/hadoop-ten-years-part01