在筆者持續(xù)調(diào)研國內(nèi)Hadoop生態(tài)系統(tǒng)生存現(xiàn)狀的同時(shí)，KDnuggets發(fā)布的2018年數(shù)據(jù)科學(xué)和機(jī)器學(xué)習(xí)工具調(diào)查報(bào)告再次將“Hadoop失寵”言論復(fù)活。報(bào)告一出，“Hadoop被拋棄”幾個(gè)字瞬時(shí)成為各大標(biāo)題黨的最愛，充斥在不同的新聞平臺(tái)。這些報(bào)告和數(shù)據(jù)是否足以動(dòng)搖Hadoop在國內(nèi)大數(shù)據(jù)領(lǐng)域的事實(shí)標(biāo)準(zhǔn)地位?本身并不擅長處理OLAP計(jì)算和ms級(jí)延遲要求的流計(jì)算，這是否會(huì)成為企業(yè)棄用Hadoop的重要原因?對于繁多的組件和搭配，企業(yè)傾向于哪種組合方式呢?

本期走訪對象：蘇寧易購。作為新一代B2C網(wǎng)上購物平臺(tái)，經(jīng)過了多年大小促的流量高峰考驗(yàn)，蘇寧易購的大數(shù)據(jù)平臺(tái)是如何搭建的?對于Hadoop生態(tài)的各類組件，蘇寧易購如何取舍呢?

蘇寧易購決定選用Hadoop：成熟、穩(wěn)定、成本可接受!

大部分企業(yè)在進(jìn)行技術(shù)選型時(shí)都會(huì)考慮成本與需求，迫切地希望知道同類型企業(yè)的選型方案，最終對可能的幾大方案進(jìn)行全方位調(diào)查，得出最符合企業(yè)自身業(yè)務(wù)發(fā)展訴求的方案。蘇寧易購首先考察了Hadoop生態(tài)與自身業(yè)務(wù)需求的契合度，Hadoop可靠、易擴(kuò)展，集海量數(shù)據(jù)存儲(chǔ)和計(jì)算于一體(正如Apache Hadoop項(xiàng)目官網(wǎng)所描述的)。從成本方面來看，Hadoop開源免費(fèi)，不需要支付昂貴的商業(yè)軟件成本，雖然需要額外的人力成本來維護(hù)和優(yōu)化，但相對來說比較少，擁有強(qiáng)大的開源社區(qū)支持，目前github上已有7.3K的star。

當(dāng)蘇寧易購2013年開始搭建大數(shù)據(jù)平臺(tái)時(shí)，Hadoop已經(jīng)成為大數(shù)據(jù)領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，早已在國內(nèi)外大型互聯(lián)網(wǎng)公司投產(chǎn)穩(wěn)定運(yùn)行多年，相對來說比較成熟，而且確實(shí)可以解決蘇寧易購海量數(shù)據(jù)存儲(chǔ)和分析需求，Hadoop便順理成章成為蘇寧易購大數(shù)據(jù)體系的基石。

在具體搭建過程中，蘇寧易購使用HDFS作為海量數(shù)據(jù)存儲(chǔ)系統(tǒng);HBase作為表格存儲(chǔ)系統(tǒng)，提供在線實(shí)時(shí)讀寫;YARN作為統(tǒng)一資源管理系統(tǒng)，為離線和流式計(jì)算提供資源調(diào)度服務(wù);Hive/SparkSQL作為離線SQL分析主力，小部分無法用SQL描述的需求用MR/Spark補(bǔ)充;SparkStreaming作為準(zhǔn)實(shí)時(shí)計(jì)算引擎提供服務(wù);以Spark MLLib為基礎(chǔ)擴(kuò)展算法包，支撐整個(gè)機(jī)器學(xué)習(xí)平臺(tái)。

Hadoop生態(tài)雖然足以應(yīng)對海量數(shù)據(jù)存儲(chǔ)和離線分析場景，但對于秒級(jí)延遲要求的OLAP計(jì)算和ms級(jí)延遲要求的流計(jì)算場景卻無能為力，這也成為很多人看衰Hadoop生態(tài)的原因之一，當(dāng)然目前也沒有任何一個(gè)平臺(tái)能完美應(yīng)對以上所有場景。

組件級(jí)競爭激烈，Spark優(yōu)勢明顯，容器興起再掀風(fēng)波!

所謂無風(fēng)不起浪，Hadoop生態(tài)看似穩(wěn)固，但其組件級(jí)別的競爭相當(dāng)激烈，Spark和Flink成為強(qiáng)勁對手。蘇寧易購認(rèn)為，HDFS作為海量數(shù)據(jù)的存儲(chǔ)系統(tǒng)，具有非常高的可靠性和易擴(kuò)展性，一直以來表現(xiàn)穩(wěn)定，在大文件存儲(chǔ)和分析領(lǐng)域，市場上還沒有能夠替代的產(chǎn)品;HBase在KV存儲(chǔ)領(lǐng)域占有絕對優(yōu)勢，特別是大規(guī)模數(shù)據(jù)集場景幾乎是必選方案，在GB-TB的數(shù)據(jù)規(guī)模下，Redis和其他內(nèi)存數(shù)據(jù)庫被普遍使用;ZooKeeper作為分布式協(xié)調(diào)系統(tǒng)，被大規(guī)模廣泛使用，依然擁有很強(qiáng)的生命力;YARN與Mesos在分布式資源調(diào)度領(lǐng)域競爭由來已久，在不同領(lǐng)域各有建樹，YARN畢竟根源于Hadoop，已是Hadoop生態(tài)標(biāo)配，隨著容器的興起和廣泛使用，Swarm和Kubernetes也加入資源管理領(lǐng)域的競爭，使這個(gè)領(lǐng)域的競爭更加激烈。

Spark作為內(nèi)存型計(jì)算框架，其先進(jìn)的理念、優(yōu)秀的性能表現(xiàn)對MapReduce沖擊很大，MapReduce兩階段的計(jì)算特性雖然簡化了程序開發(fā)的難度，但引入了過多磁盤、網(wǎng)絡(luò)IO和任務(wù)啟停開銷，成為過去已是必然，特別是SparkSQL，基本讓Hive的底層計(jì)算引擎MR無立足之地，蘇寧易購也一直在推進(jìn)SparkSQL替換HQL的工作，但Hive作為數(shù)據(jù)倉庫的功能基本不會(huì)被替換。

Spark作為Hadoop生態(tài)系統(tǒng)中的重要組件，在大數(shù)據(jù)計(jì)算領(lǐng)域依然不可或缺，Spark SQL, Spark MLLib已被廣泛應(yīng)用。但是，蘇寧易購認(rèn)為，Spark目前只是作為計(jì)算引擎存在，數(shù)據(jù)存儲(chǔ)還需要依靠HDFS，S3，Ceph等系統(tǒng)。未來的資源肯定要統(tǒng)一管理，只有資源集中管理、統(tǒng)一調(diào)配才能充分被利用，即使不On YARN模式運(yùn)行，也會(huì)on Mesos或者on Kubernetes之類的系統(tǒng)去運(yùn)行。至于資源統(tǒng)一管理帶來的隔離性要求，這是YARN、Mesos們要考慮的問題。蘇寧易購計(jì)劃在下半年啟動(dòng)統(tǒng)一資源管理項(xiàng)目，將流計(jì)算、離線計(jì)算資源統(tǒng)一管理調(diào)度，預(yù)計(jì)能節(jié)省30%左右的機(jī)器成本。

此外，F(xiàn)link作為近幾年出現(xiàn)的計(jì)算框架，與Spark比較相似，都期望提供流處理、批處理統(tǒng)一API編程模式，但兩者看問題的角度完全不同。Spark最先發(fā)力批處理，后做成微批處理實(shí)現(xiàn)流計(jì)算，而Flink從一開始就面向流計(jì)算，將數(shù)據(jù)看成Unbounded，將批處理當(dāng)做流的一種特殊情況。基于此，目前Flink更多的被用在流計(jì)算領(lǐng)域，比如阿里深度定制的Blink已成為其內(nèi)部主流的流處理框架。從設(shè)計(jì)角度來說，F(xiàn)link也有很多亮點(diǎn)，比如支持Event-Time，支持Exactly-Once的處理語義，支持分布式異步checkpoint等。蘇寧易購目前內(nèi)部主推Flink，期望能替代有點(diǎn)老邁的Storm。

目前Flink剛剛發(fā)布1.5版本，修復(fù)了很多Bug，新增了很多特性，比如對SQL和Table的增強(qiáng)，優(yōu)化了網(wǎng)絡(luò)棧;社區(qū)也比較活躍，共有3700多個(gè)star，保持5個(gè)月左右一次大版本發(fā)布的頻率。在流計(jì)算領(lǐng)域，F(xiàn)link絕對是強(qiáng)有力的競爭者。

Gartner看衰言論解讀：看事情的角度不同可能造成結(jié)果差異!

經(jīng)過十多年的發(fā)展，Hadoop已經(jīng)比較成熟且運(yùn)行穩(wěn)定，生態(tài)也相對完善，在海量數(shù)據(jù)存儲(chǔ)和分析領(lǐng)域已經(jīng)成為事實(shí)標(biāo)準(zhǔn)。至于Gartner的唱衰論調(diào)，蘇寧易購認(rèn)為，Hadoop就好比日常生活中的水電煤，因?yàn)樘毡榉炊黄鹛貏e關(guān)注，或者，Gartner報(bào)告中所說的Hadoop是指狹義上的Hadoop，也就是原始的HDFS和MapReduce組合。如果單看這兩大組件的發(fā)展，MapReduce確實(shí)在逐漸退出舞臺(tái)，被Spark/Flink所取代。

蘇寧易購認(rèn)為，Hadoop失寵前提一定是出現(xiàn)更強(qiáng)大的可替代大數(shù)據(jù)解決方案，現(xiàn)在來看，并沒有這樣的方案出現(xiàn)。存儲(chǔ)和計(jì)算領(lǐng)域確實(shí)持續(xù)出現(xiàn)了一些受追捧的新組件，比如OLAP領(lǐng)域的Druid和Clickhouse，就是用來彌補(bǔ)Hadoop在海量數(shù)據(jù)多維實(shí)時(shí)分析場景下的不足。比如Flink，采用流處理、批處理統(tǒng)一API編程模式解決兩種模式、兩種API帶來的不統(tǒng)一、編程門檻高等問題。

短期內(nèi)，蘇寧易購沒有顛覆性調(diào)整大數(shù)據(jù)底層平臺(tái)架構(gòu)的計(jì)劃，仍然以Hadoop生態(tài)系統(tǒng)為核心，并對Hadoop的未來充滿信心，但會(huì)在一些Hadoop覆蓋不到的場景中引入其他組件并持續(xù)投入，比如Druid\Elasticsearch。

筆者點(diǎn)評(píng)：

在前期的多份采訪中，筆者曾一再表明，Hadoop的關(guān)注度確實(shí)在下降，而關(guān)注度確實(shí)是Gartner報(bào)告的一個(gè)重要考察因素。但是，KDnuggets報(bào)告明確表明Hadoop的使用率也在下降。當(dāng)然，這兩大報(bào)告的受訪主體以美洲和歐洲用戶為主，亞洲用戶參與率較低，這也是前期不少用戶在評(píng)論區(qū)留言表明國內(nèi)外數(shù)據(jù)量的規(guī)模差異是造成該結(jié)論并不適用國內(nèi)的重要原因。到底多大的數(shù)據(jù)量可以被稱為大數(shù)據(jù)，這個(gè)標(biāo)準(zhǔn)在國內(nèi)外確實(shí)是有差異的。如果數(shù)據(jù)量不大，確實(shí)可能對Hadoop沒有需求，但國內(nèi)的數(shù)據(jù)量顯然大于國外，這可能是國內(nèi)對Hadoop需求較大的重要原因。

其次，Hadoop生態(tài)內(nèi)組件級(jí)別的替換淘汰是很正常的，但這暫時(shí)還不會(huì)上升到生態(tài)層面。正如蘇寧易購所言，在沒有更加強(qiáng)大的替代品出現(xiàn)之前，Hadoop生態(tài)的地位依舊穩(wěn)固。