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

本期走訪對象：蘇寧易購。作為新一代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生態的地位依舊穩固。