Hadoop社區比 Ozone 更重要的事情

作者：鄭鍇，花名鐵傑，阿里巴巴高級技術專家，Apache Hadoop PMC，Apache Kerby 創立者。深耕分佈式系統開發和開源大數據多年，目前專注於在阿里雲上提供更好用更有彈性的 Hadoop/Spark 大數據平臺。

最近幾年忙著優化大客戶上雲使用 Hadoop / Spark 這種事情，Hadoop 社區的工作參與得比較少了。偶爾參與一些投票表決的事情，貌似新晉的 committer 都跟一些新項目有關，比如 Ozone。這個事情在國內有大廠在參與，看起來力度還不小，然後時不時地就有同學跑過來問我的看法。正好 Spark 中國社區跟我約篇文章，何不就此把我的零碎看法整理出來，一箭雙鵰，如果再有人問類似的問題，我就可以把這篇文章轉給 TA。

簡單來講。Ozone 是很不錯，也很有用；但從我作為一個社區參與者的角度來看，它救不了 Hadoop，就這個項目的前後十年來說，Hadoop 社區有遠比它更重要的挑戰需要去解決。

再過個五年十年，我們不妨做個想象，在開源與雲廠商相愛相殺的格局下，在開源大數據的這個生態系統和版圖格局裡面，哪些項目會活得更滋潤，哪些項目則日漸式微？毫無疑問，新的技術新的項目仍將不斷湧出，Spark，Flink 也不能說就高枕無憂，但我想說明的是，Hadoop 生態會繼續向前發展，Hadoop 項目本身的前景則可能更加黯淡。有長久生命力的東西都有它核心的定位和使命，然後基於此不斷革新和進化。Spark 和 Flink 都定位是計算平臺，前者從批計算入手，後者從實時切入，都不斷夯實基礎補足短板支持新的計算場景完善它的生態。然而Hadoop呢？

Hadoop 項目的核心定位是什麼？我想最沒有爭議的應該是大數據平臺，核心支撐有二，一是存儲，二是調度；承載的是計算，包括各種輔助支持，比如安全。我對調度略懂，存儲上可以展開說說，姑妄言之。Hadoop 社區最近幾年，在它的核心支撐點存儲上面，應該最主要的工作就是開發 Ozone。Ozone 定位是對象存儲，類似於 AWS 的 S3，阿里雲的 OSS，只是 Hadoop 出品，雖然姍姍來遲。我記得大概是在五年前吧，那時正和社區熱火朝天地搞 HDFS EC ，突然 HortonWorks 一幫人拋出 Ozone，說是要搞對象存儲，當時給我的感覺就像是不務正業。

對吧，你不能說人家 AWS 搞 S3 受歡迎，你也要有，它跟 HDFS 有啥關係對解決 HDFS 核心挑戰有啥助益？說的最多的是解決小文件，可這個問題並非核心，一般都從數據治理入手規避掉了。還有就是近乎無限的水平擴展性，可人家是雲廠商面向海量用戶海量提供，單個用戶來部署 Hadoop 的哪有那麼大的體量？阿里巴巴數據體量非常非常大，不可能靠 Hadoop 來支撐，所以自研飛天。Hadoop 比較合適的用戶定位應該是中大規模部署，小到幾十個節點幾 PB 數據規模，大到上千節點上百 PB 數據這種。這類用戶使用 HDFS 的核心痛點是什麼呢？Ozone能不能實質性地解決這些核心挑戰？下面我們來分析看看。

第一，複雜。非常的複雜。HDFS部署一套高可用的系統，不算 active/standby NameNode，相關的 master 服務七七八八的好多個，3 個 ZK 服務，3 個 JounalNode 服務，2個 ZKFC 服務。這還只是一個實例，如果用上 federation，比如支持 2 個 namespaces，那就要翻倍了。怎麼運維管控這些服務，我想圈子裡面的同學應該沒少頭疼過。這對大量的中小用戶意味著什麼，需要專家來支持；對大體量的用戶則需要一大堆專家來優化。對大量的下游系統意味著什麼？沉重的依賴。

所以這也就難怪近幾年有個怪現象，發軔於 Hadoop生態，卻不斷見到喊著要逃離 Hadoop，去 Hadoop 化。這裡面最明顯的就是 Spark 和它背後的 Databricks 了。解決這個複雜性的技術方案並非沒有，比如最近幾年流行起來的 Raft + RocksDB，Ozone 現在就在用。我們在阿里雲開發 JindoFS 系統，部署3個節點的 Raft Group 來提供元數據服務，把文件元數據放置在 RocksDB，靠內存來做緩存，然後用上細粒度的鎖，在部署維護上的簡便性和支撐的元數據規模上面，比 HDFS NameNode 方案簡直好太多。HDFS 社區對於改造 NameNode 實現它的 scale up 和 out，有過多次衝動，可惜因為各方勢力鬥法，一次次錯過良機，在這方面現在基本上偃旗息鼓感覺就是坐吃等死了。

其次，成本。本地存儲，數據 3 備份，簡單粗暴可靠。這在大數據的發展階段是無可置疑的，可是搞到現在基本還停留在這個水平，就有疑問了。存儲成本應該是大數據發展起來後作為存儲系統的最核心問題，畢竟數據規模一直在膨脹，要麼加快數據淘汰，要麼支持更低成本，誰能做到單位存儲成本最低，誰就能笑到最後。

解決數據3備份存儲開銷的最有效手段毫無疑問是 EC（Erasure Coding，國內譯為糾刪碼），用 6+3 的配置成本能降低到一半。HDFS 曾經兩次向 EC 發起衝鋒。第一次應該是 Hadoop 1.x，代號HDFS-RAID志氣不小，應該主要是 Facebook貢獻的，不過沿襲了他們在 Apache社區一貫的手法，雖然能 work但實現方式卻非常粗鄙，依賴著 MySQL 倒過來耦合計算框架MapReduce，非常像某個Hadoop 集群上開發的一個工具，因此在 Hadoop 升級到 YARN 時代的時候就從代碼庫裡面刪掉了。

第二次是大概五年前，Intel 在 X86 上有個 ISA-L 的庫專門做 EC 加速的，想把 EC 做進 HDFS 的心思其實早就有了，在對 Cloudera 投了大把的錢之後，終於在社區轟轟烈烈的聯手發起了代號 HDFS-EC 的又一次衝鋒。這一次發誓要做到存儲系統裡面，而不是個外掛，在最初的兩年，聲勢浩大，開發迅速，可惜因為 Hadoop 3 改動太大一直不能直接從 Hadoop 2 升級，就導致用戶一直處於觀望狀態，這後面的事情就比較拖沓了。EC 的核心貢獻者慢慢轉向新的領域，Ozone攪局分散了大半社區精力，基本上在促進 EC 落地的事情上，我認為社區不必要地耽擱了至少2年時間。也就是直到現在，大規模的 EC 上線生產部署才初見端倪，可謂姍姍來遲。

降低存儲成本的另外一種方式是使用更為廉價的後端存儲系統。HDFS 是事實上的大數據存儲系統接口標準，本來是持有數據坐擁天下之利的，可惜在架構上一直未能有效地演進革新，來支持本地存儲之外的更為廉價的後端存儲系統。微軟在 Hadoop 社區的領導者 Chris 做過這方面的努力，支持了把 Azure Blob 掛載到 HDFS 映射到 DataNode 上的一個 tier，可惜功虧一簣，最終只是個半成品。在 JindoFS 上，我們支持 OSS 這種後端，可以只寫1備份數據到它上面，數據高可靠高可用，自身只需要做好緩存加速，同時利用 OSS 的數據分層能力支持好冷熱分層存儲，在成本上能做到非常大的節省。

第三，性能。在存儲系統層面，Hadoop 利用 HDFS 多備份和數據本地化把大數據分析處理的吞吐發揮到極致，應該是到頂了。可惜 Hadoop 項目本身在大數據平臺層面，就此裹足不前，未能及時在存儲格式上進行創新和消化業界的進展（Parquet，Orc，Arrow），也就未能為各種計算引擎提供更好的支持（Spark，Flink），在場景上不能有力地支撐跟進存儲計算分離的趨勢（Alluxio），在架構上不能容納更新的存儲硬件體系（SSD，AEP，因為無用武之地）。

這就形成一個局面是 Hadoop 自身日漸式微，但新項目卻不斷湧現，基礎性的重複性的大家各自造輪子，導致整個生態系統臃腫不堪集成難度非常之大，看看 Hadoop 背後的廠商Cloudera和它的主要產品CDH，就知道它為什麼越來越名副其實真像頭大象了。我們在 JindoFS 上面的做法是，在各個計算引擎都依賴的基礎支持都會盡量下沉，存儲和計算結合起來優化，除了Hadoop 標準的那些文件系統接口外，我們支持額外的擴展方式，避免中間適配實現直通。達到的效果是，用相同的集群配置，在單文件操作上我們跟 HDFS 不相上下，但是在端到端的作業性能上面，我們能夠普遍比 HDFS快，很多情況下甚至有幾倍的性能提升。

在平臺層面，Hadoop 需要不斷進化的事情就太多了，然而因為類似的情況，不能說是停滯不前也談不上有非常大的發展。比如安全，Hadoop很早就支持了Kerberos，可是在怎麼集成和支持更多的企業級認證，或者適配雲端環境上，一直沒有什麼實質性的變化。權限支持是在外圍項目裡面做的，Cloudera 的 Sentry 和 HortonWorks 的 Ranger 各行其是終於又合二為一。YARN 上面的調度可能稍微好些，不過還是力量發散，之前分出去個 Slider做了很久又合併回YARN，這兩年又在忙活一個 Submarine支持深度學習，然後在關鍵核心的追趕 K8S 或者是擁抱融入K8S上面顯得後勁乏力，導致YARN現在也是進退失據。

Hadoop社區之所以一再地發生上述情況，究其原因是在它發展的關鍵階段，缺乏一個主心骨，Cloudera 和HortonWorks 長期鬥法相互拆臺，即便現在合併了，也仍然缺乏一個核心的領導人物，協調好各大山頭能夠聚焦在真正核心的問題上，而是各憑興趣自打小算盤，不斷地挖牆腳分化Hadoop 社區本就日漸式微的力量，東搞一塊，西拉一堆，看上去都挺有道理的，但對Hadoop 項目本身，對Hadoop這個大數據平臺的核心定位，從長遠來看百害而無一益。Ozone就是這個情形下的產物，也是最好的例證。

回到Ozone，它能代替HDFS成為一個更好的大數據存儲方案嗎？它能解決上面所說的核心痛點嗎？複雜，成本，和性能。並不能，實際上也許恰恰相反。Ozone使得Hadoop看上去更加龐大複雜了，一個對象存儲系統做到生產上線的程度它不會複雜嗎？複雜 + 複雜。在存儲上它仍然採取三備份的策略，也未必會有社區精力去支持EC，因此成本也不會降低。至於性能？HDFS 是為大數據分析量身打造的文件系統，是計算對存儲的原生依賴，一個對象存儲系統必須要再加上一層適配，比如OzoneFS，才能滿足計算上的用途，即使是在一些場景上比HDFS快，那也是拿長處比短處，不見得真英雄。如果把HDFS的弊端給幹掉，比如像JindoFS，把元數據放在K/V的數據庫裡面，採取細粒度的目錄/文件鎖，充分的併發，HDFS文件系統方式而不是對象存儲這種實際上可以做得更快。

公有云上不大可能有Ozone什麼事，各家雲廠商都在主推自己的對象存儲產品（AWS的S3，Aliyun 上的OSS），而且已經形成規模效應會越來越便宜，可以保證好多個9的高可用，有哪個用戶會蛋疼到自己來自建Ozone集群為了使用對象存儲，成本不低，性能不高，又很複雜？混合雲或者Cloudera所謂的企業雲上，可能有一定的用戶，但是它能跑得過雲計算髮展的大勢嗎？不排除有一些重量級的走開源路線的互聯網公司，比如國內的小米，滴滴，美團，京東這種，基於Ozone來構建自己的存儲計算分離方案，目前來看也不太明朗，因為Ozone來得太次了，這些互聯網公司紅利吃盡規模到頂，搞到現在基本上都已經有了自己成熟的一套。現在是需要省成本，所以反倒像HDFS EC這種技術應該會加快部署落地，線下IDC機房擴不動了或者相比上雲代價太大，增量基本上都會上公有云，哪有資源大規模部署Ozone？。

那回到這篇文章的題目本身，Hadoop社區比Ozone更重要的事情是什麼？總結一下，那就是堅持Hadoop作為大數據基礎平臺這一核心定位，同時積極擁抱雲計算髮展大勢，重點做好以下幾個方面。

第一，強化大數據存儲解決方案的定位，加快完善落地EC這一關鍵成本利器，技術架構改造升級，去除HDFS不合時宜的複雜性並能夠支持各種後端系統，做好數據冷熱分層，利用各種手段降本提效。

第二，積極支持存儲計算分離場景，引入緩存架構（Alluxio），在存儲格式等方面提供基礎框架，有能力充分發揮各種硬件潛力，為各種計算引擎做好優化支持，增強Hadoop平臺的粘性和向心力。

第三，積極擁抱公有云，充分支持和優化好主要雲廠商的對象存儲產品而不是自己另搞一套（Ozone）；面對現實擁抱容器化和雲原生，改造YARN積極融入K8S結束精神分裂，為用戶提供更好的計算調度方案，而不是讓廣大的用戶觀望糾結。

像從Hadoop社區走出去的眾多項目（Hbase）一樣，我不否認Ozone本身的價值，放眼開源世界，貌似還找不到像樣的對象存儲項目（也許Ceph算一個？），Hadoop利用餘暉趕緊推出一個新的方案綁定輸出，也不失為一個策略，而且脫掉社區的外衣就具體的廠商而言，未必就沒有很大的落地應用價值。我只是想說，從這個項目的長遠考慮，Hadoop社區有比它更重要的事情，關乎未來。

姑妄言之吧。作為Hadoop社區一位成員的反思，我仍然是希望Hadoop項目能夠繼續向前健康發展，也希望哪一天條件成熟在更大層面回過頭去為Hadoop再做一些貢獻。現在Hadoop社區有一個好現象是，華人面孔越來越多了，像Ozone和Submarine這種新拉出來的子項目，可以起到發展社區的作用，所以有興趣做開源同時又需要造輪子的同學，建議參與到這些新項目，與社區共同成長。阿里巴巴計算平臺的開源大數據部門（EMR），也非常歡迎有社區經驗的同學加入我們共同打造JindoFS，一起繁榮開源生態。

關於JindoFS，它沉澱了我們在Hadoop上關於核心定位的諸多思考，事實證明，這種思考非常有益。正是兩年前我們在阿里雲上結合大量的各種用戶使用場景反覆琢磨，什麼才是EMR這種開源大數據平臺（基於Hadoop/Spark）的真正核心價值，我們才決定兵分兩路研發Jindo引擎，一路指向以Spark為核心的計算（JindoSpark，杭州團隊，計算），一路就是本文反覆提到的JindoFS（上海團隊，計算+存儲），在雲原生上我們去年也開始了團隊的組建（北京）。在核心價值上做文章，如今成效顯著，JindoFS大量用戶落地，我們的開源大數據產品E-MapReduce也剛剛喜報傳來，性價比（性能/成本）再一次打破世界紀錄，霸榜TPC-DS，有好奇心的同學可以自己去上TPC官網上看看。JindoFS的全面介紹敬請期待下文，到時探討一下看它是怎麼在雲原生大行其道的今天，如何在諸多方面繼承，發展和超越HDFS的。對我們上述相關工作領域感興趣的同學可以郵件聯繫我（zhengkai.zkATalibaba-inc.com），北上杭都在大量找人，我們歡迎你。

阿里巴巴開源大數據技術團隊成立Apache Spark中國技術社區，定期推送精彩案例，技術專家直播，問答區近萬人Spark技術同學在線提問答疑，只為營造純粹的Spark氛圍，歡迎釘釘掃碼加入！