蘇寧易購：Hadoop失寵前提是出現更優秀的替代品！

在筆者持續調研國內Hadoop生態系統生存現狀的同時，KDnuggets釋出的2018年資料科學和機器學習工具調查報告再次將“Hadoop失寵”言論復活。報告一出，“Hadoop被拋棄”幾個字瞬時成為各大標題黨的最愛，充斥在不同的新聞平臺。這些報告和資料是否足以動搖Hadoop在國內大資料領域的事實標準地位？本身並不擅長處理OLAP計算和ms級延遲要求的流計算，這是否會成為企業棄用Hadoop的重要原因？對於繁多的元件和搭配，企業傾向於哪種組合方式呢？

 

2018年資料科學和機器學習工具調查報告，Hadoop使用率下降35%

本期走訪物件：蘇寧易購。作為新一代B2C網上購物平臺，經過了多年大小促的流量高峰考驗，蘇寧易購的大資料平臺是如何搭建的？對於Hadoop生態的各類元件，蘇寧易購如何取捨呢？

蘇寧易購決定選用Hadoop：成熟、穩定、成本可接受！

大部分企業在進行技術選型時都會考慮成本與需求，迫切地希望知道同型別企業的選型方案，最終對可能的幾大方案進行全方位調查，得出最符合企業自身業務發展訴求的方案。蘇寧易購首先考察了Hadoop生態與自身業務需求的契合度，Hadoop可靠、易擴充套件，集海量資料儲存和計算於一體（正如Apache Hadoop專案官網所描述的）。從成本方面來看，Hadoop開源免費，不需要支付昂貴的商業軟體成本，雖然需要額外的人力成本來維護和優化，但相對來說比較少，擁有強大的開源社群支援，目前github上已有7.3K的star。

當蘇寧易購2013年開始搭建大資料平臺時，Hadoop已經成為大資料領域的事實標準，早已在國內外大型網際網路公司投產穩定執行多年，相對來說比較成熟，而且確實可以解決蘇寧易購海量資料儲存和分析需求，Hadoop便順理成章成為蘇寧易購大資料體系的基石。

在具體搭建過程中，蘇寧易購使用HDFS作為海量資料儲存系統；HBase作為表格儲存系統，提供線上實時讀寫；YARN作為統一資源管理系統，為離線和流式計算提供資源排程服務；Hive/SparkSQL作為離線SQL分析主力，小部分無法用SQL描述的需求用MR/Spark補充；SparkStreaming作為準實時計算引擎提供服務；以Spark MLLib為基礎擴充套件演算法包，支撐整個機器學習平臺。

Hadoop生態雖然足以應對海量資料儲存和離線分析場景，但對於秒級延遲要求的OLAP計算和ms級延遲要求的流計算場景卻無能為力，這也成為很多人看衰Hadoop生態的原因之一，當然目前也沒有任何一個平臺能完美應對以上所有場景。

元件級競爭激烈，Spark優勢明顯，容器興起再掀風波！

所謂無風不起浪，Hadoop生態看似穩固，但其元件級別的競爭相當激烈，Spark和Flink成為強勁對手。蘇寧易購認為，HDFS作為海量資料的儲存系統，具有非常高的可靠性和易擴充套件性，一直以來表現穩定，在大檔案儲存和分析領域，市場上還沒有能夠替代的產品；HBase在KV儲存領域佔有絕對優勢，特別是大規模資料集場景幾乎是必選方案，在GB-TB的資料規模下，Redis和其他記憶體資料庫被普遍使用；ZooKeeper作為分散式協調系統，被大規模廣泛使用，依然擁有很強的生命力；YARN與Mesos在分散式資源排程領域競爭由來已久，在不同領域各有建樹，YARN畢竟根源於Hadoop，已是Hadoop生態標配，隨著容器的興起和廣泛使用，Swarm和Kubernetes也加入資源管理領域的競爭，使這個領域的競爭更加激烈。

Spark作為記憶體型計算框架，其先進的理念、優秀的效能表現對MapReduce衝擊很大，MapReduce兩階段的計算特性雖然簡化了程式開發的難度，但引入了過多磁碟、網路IO和任務啟停開銷，成為過去已是必然，特別是SparkSQL，基本讓Hive的底層計算引擎MR無立足之地，蘇寧易購也一直在推進SparkSQL替換HQL的工作，但Hive作為資料倉儲的功能基本不會被替換。

Spark作為Hadoop生態系統中的重要元件，在大資料計算領域依然不可或缺，Spark SQL, Spark MLLib已被廣泛應用。但是，蘇寧易購認為，Spark目前只是作為計算引擎存在，資料儲存還需要依靠HDFS，S3，Ceph等系統。未來的資源肯定要統一管理，只有資源集中管理、統一調配才能充分被利用，即使不On YARN模式執行，也會on Mesos或者on Kubernetes之類的系統去執行。至於資源統一管理帶來的隔離性要求，這是YARN、Mesos們要考慮的問題。蘇寧易購計劃在下半年啟動統一資源管理專案，將流計算、離線計算資源統一管理排程，預計能節省30%左右的機器成本。

此外，Flink作為近幾年出現的計算框架，與Spark比較相似，都期望提供流處理、批處理統一API程式設計模式，但兩者看問題的角度完全不同。Spark最先發力批處理，後做成微批處理實現流計算，而Flink從一開始就面向流計算，將資料看成Unbounded，將批處理當做流的一種特殊情況。基於此，目前Flink更多的被用在流計算領域，比如阿里深度定製的Blink已成為其內部主流的流處理框架。從設計角度來說，Flink也有很多亮點，比如支援Event-Time，支援Exactly-Once的處理語義，支援分散式非同步checkpoint等。蘇寧易購目前內部主推Flink，期望能替代有點老邁的Storm。

目前Flink剛剛釋出1.5版本，修復了很多Bug，新增了很多特性，比如對SQL和Table的增強，優化了網路棧；社群也比較活躍，共有3700多個star，保持5個月左右一次大版本釋出的頻率。在流計算領域，Flink絕對是強有力的競爭者。

Gartner看衰言論解讀：看事情的角度不同可能造成結果差異！

經過十多年的發展，Hadoop已經比較成熟且執行穩定，生態也相對完善，在海量資料儲存和分析領域已經成為事實標準。至於Gartner的唱衰論調，蘇寧易購認為，Hadoop就好比日常生活中的水電煤，因為太普遍反而引不起特別關注，或者，Gartner報告中所說的Hadoop是指狹義上的Hadoop，也就是原始的HDFS和MapReduce組合。如果單看這兩大元件的發展，MapReduce確實在逐漸退出舞臺，被Spark/Flink所取代。

蘇寧易購認為，Hadoop失寵前提一定是出現更強大的可替代大資料解決方案，現在來看，並沒有這樣的方案出現。儲存和計算領域確實持續出現了一些受追捧的新元件，比如OLAP領域的Druid和Clickhouse，就是用來彌補Hadoop在海量資料多維實時分析場景下的不足。比如Flink，採用流處理、批處理統一API程式設計模式解決兩種模式、兩種API帶來的不統一、程式設計門檻高等問題。

短期內，蘇寧易購沒有顛覆性調整大資料底層平臺架構的計劃，仍然以Hadoop生態系統為核心，並對Hadoop的未來充滿信心，但會在一些Hadoop覆蓋不到的場景中引入其他元件並持續投入，比如Druid\Elasticsearch。

筆者點評：

在前期的多份採訪中，筆者曾一再表明，Hadoop的關注度確實在下降，而關注度確實是Gartner報告的一個重要考察因素。但是，KDnuggets報告明確表明Hadoop的使用率也在下降。當然，這兩大報告的受訪主體以美洲和歐洲使用者為主，亞洲使用者參與率較低，這也是前期不少使用者在評論區留言表明國內外資料量的規模差異是造成該結論並不適用國內的重要原因。到底多大的資料量可以被稱為大資料，這個標準在國內外確實是有差異的。如果資料量不大，確實可能對Hadoop沒有需求，但國內的資料量顯然大於國外，這可能是國內對Hadoop需求較大的重要原因。

其次，Hadoop生態內元件級別的替換淘汰是很正常的，但這暫時還不會上升到生態層面。正如蘇寧易購所言，在沒有更加強大的替代品出現之前，Hadoop生態的地位依舊穩固。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2156117/，如需轉載，請註明出處，否則將追究法律責任。