導讀：國內外都紛紛唱衰 Hadoop，認爲它沒有未來。InfoQ 曾發佈過《誰在“謀殺”Hadoop？》、《Hadoop 不再權威，開源大數據的未來何去何從？》、《Hadoop 衰落，數據湖項目開始失敗，我們該如何應對？》等多篇文章，都對 Hadoop 的未來表示擔憂。今天我們帶來了 Alex Woodie 撰寫的文章，分享了他對後 Hadoop 世界的大數據的看法和預測。
在大數據爭奪架構霸權之戰中，雲計算顯然是贏家，而 Hadoop 明顯落敗了。現在客戶已經不願在單一的 Hadoop 集羣上進行投資，轉而青睞更靈活（如果不是更便宜的話）的雲計算平臺。雖然 Hadoop 上的泡沫已經明顯破裂，但在構建大數據方面，組織仍然面臨許多問題。
HPE 在 8 月 5 日收購了 MapR，這可以說是 Hadoop 走在消亡路上的一個標誌。人們曾將 Hadoop 視爲未來的前沿平臺，但現在，它看起來就像是另一個已經過時的遺留平臺。曾經將 Hadoop 視爲推動其大數據戰略的核心技術的客戶，現在正尋求轉型，採用雲平臺來實現這些數據戰略。
無論是在技術層面還是在市場層面，這種轉變帶來的影響都是深遠的。在技術層面上，Hadoop 將計算和存儲結合在一起——這是分佈式架構的標誌之一，直到社區修改 HDFS 以支持平淡無奇的 Hadoop 3.0 的抹除碼（erasure code）時，它就已經失寵了。爲取代 HDFS，我們用大規模的基於雲的對象存儲，構建在 AWS S3 模型上，並且能夠根據需要啓動計算，使用類似 Kubernetes 的虛擬化技術，而不是 YARN。
各組織不再花費大量資金僱傭工程師團隊來運行復雜的本地 Hadoop 集羣，他們發現，使用由 AWS、Microsoft Azure 或 Google Cloud Platform 開發的預構建分佈式計算服務，並將運營控制權交給雲供應商更爲經濟。
這些雲平臺與 Hadoop 非常相似，包括了 Hadoop 世界中出現的所有計算引擎：Spark、Hive、HBase，甚至還包括 MapReduce。但是，運營複雜性的沉重負擔卻落在雲供應商身上，而不是客戶身上。
阻抗失配
Splice Machine 首席執行官兼聯合創始人 Monte Zweben 表示，Hadoop 的操作複雜性就是一名殺手。Splice Machine 爲 Hadoop 和其他平臺開發了一個關係數據庫。
他稱，“當我們想把自己運送到另一個地方，需要一輛車時，我們就會去買一輛車。但我們並不會這樣做：去買懸掛系統、燃料噴射裝置，還有一堆車軸，然後把所有的東西都放在一起。可以這麼說，我們是不會去拿材料清單的。”
“如果你看一下 Hadoop 和經銷商的商業模式，你就會明白，這些就是你需要組裝產品的材料清單。”Zweben 繼續說道，“它們非常有效，也非常強大，而且還非常複雜。它們的目標是世界上構建軟件的工程組織。它們被賣給世界各地的 IT 組織，這些組織擁有更多的操作技能，能夠實現平臺，並使其保持 7x24 的運行狀態。”
阻抗失配（Impedance Mismatch）正是 Hadoop 消亡的核心，並對 Hadoop 商業模式造成了損害。面對來自雲計算的猛攻，Hadoop 訂購停滯不前，最終導致了 MapR 和 Cloudrea 的鬥爭公開化。HPE 爲 MapR 的減價出售做好了準備，並在此過程中拯救了財富 500 強（Fortune 500 ）和全球 2000 強（Global 2000 ）中的許多客戶，使他們免受因運行不受支持的企業數據平臺版本而蒙受恥辱。在前首席執行官 Tom Reilly 和其聯合創始人之一、首席戰略官 Mike Olson 辭職後，Cloudrea 仍然沒有任命常任首席執行官。
死而不僵的大象
那麼，我們該會走向何處呢？Enterprise Strategy Group 高級分析師 Mike Leone 表示，Hadoop 背後的勢頭已經明顯減弱，但尚未完全放棄這頭“黃色大象”。
譯註： Hadoop 的吉祥物是一頭黃色大象。Hadoop 這個名稱，並不代表任何英文詞彙或縮寫詞，只是一個無中生有創造出來的名稱。當初原始開發者 Doug Cutting 在爲這個新技術命名時，他想選一個容易拼寫和發音、便於溝通，且沒有在其他地方使用過的名字，於是神來一筆地借用兒子黃色毛絨填充大象玩偶的名字，而黃色大象後來也變成了 Hadoop 的官方吉祥物，如圖：
Leone 告訴 Datanami，“用‘死亡’這個詞，真的有點過了，但市場肯定是在萎縮而不是增長。我們的研究表明，大約有 12% 的組織仍然利用 Hadoop 作爲他們分析計劃的一部分。從商業角度來看，Hadoop 有着驚人的承諾，但在交付方面卻不盡如人意了。”
組織對利用大數據有很大的期望，雖然 Hadoop 可能不是將組織帶到大數據福地的工具，但這些期望仍然存在。
“現在，隨着主要雲供應商提供的服務數量的不斷增加，有許多不同的方法可以實現 Hadoop 承諾的商業效益。”Leone 說，“對於那些對雲不感興趣的行業，主要的雲供應商希望通過 AWS Outposts 和 Google Cloud 的 Anthos 等技術，使組織能夠將它們的大數據和分析服務帶到本地環境中。”
在過去的十年裏，由於在 Hadoop 上已經投資了數十億美元，因此企業不願意關閉它們的服務器集羣。相反，大多數專家都希望 Hadoop 棧能夠堅持一段時間，運行客戶在其上構建的定製應用。它只是全球 2000 強企業數據中心中的又一項遺留技術，這些數據中心仍然運行着 IBM 大型機、AS/400，甚至是偶爾運行的 VAX 系統。
嶄新的雲架構
雲供應商戰勝企業中的 Hadoop 的一個副作用是，雲計算的功能正在被移植到企業內部部署的系統中。
基於雲的大數據系統提供商 Qubole 的首席執行官 Ashish Thusoo 稱：“雲架構正在逐步向本地數據中心發展。雲架構意味着什麼？這意味着所有的基礎設施都是作爲一種服務提供的，而不是作爲整體產品提供的。”
基於 S3 模型構建的對象存儲和基於 Kubernetes 的編排框架（允許計算快速啓動和停止），是雲計算功能進入內部部署的數據中心最明顯的例子。
“人們普遍認爲，具有計算、存儲和短暫的計算分離的雲架構具有很強的自動化能力，可以創建集羣，而且作爲服務的所有一切都可以在任何地方實現，無處不在。”Thusoo 表示，“它目前還處於發展的早期階段。它遠非主流或類似的東西。但這正是我們所看到的這些公用雲供應商試圖做的事情。”
Hadoop 經驗教訓
儘管有些人可能會認爲 Hadoop 市場的瓦解是一個失敗，但其他人會認爲它是信息技術歷史上的一個必要篇章。
Hadoop 模仿 Google 開發的技術，並在 Yahoo 投入使用，最終被其他科技巨頭採用，如 Facebook、Twitter 和 Uber 等，他們都爲開源貢獻了自己的創意。Hadoop 方法代表了構建分佈式系統的一種方法。全球 2000 強企業首次採用了這種方法。這種方法對於一些公司來說，它的效果很明顯，但對其他公司來說卻不太有效。隨着世界的發展，其他許多人認爲更好的架構理念出現了，因此我們嘗試了一些新的事物，諸如此類。
Leone 預測，Hadoop 的教訓不會被忽視。他說，“我認爲，Hadoop 爲一種新的做事方式提供了很好的介紹。對於那些等待採用大數據處理技術的組織來說，現在有更好的方法來實現這一點，即 Spark 或利用 Google Cloud Platform 的 Dataproc 或 AWS EMR 之類的雲服務。”
Cloudera 將嘗試與混合數據平臺競爭，消除雲計算供應商帶來的“廠商鎖定”困境（儘管雲計算供應商顯然將廠商鎖定視爲其商業模式的一個特徵，而不是什麼 bug）。但根據 Leone 的說法，雲計算供應商完全淘汰剩下的 Hadoop 供應商只是一個時間問題。
“雖然組織仍然可以在他們選擇的雲上利用他們首選的 Hadoop 供應商技術，但是雲計算供應商已經創建了託管服務，降低與 Hadoop 相關的所有複雜性，比如持續集成、管理和維護。”Leone 解釋道，“如果組織已經投資數十萬美元來建立爲組織創造價值的流程，那麼他們將很難改變這些工作流。將這些流程提升並將其轉移到雲計算供應商管理的更高效的基礎架構中更有吸引力。對雲計算供應商來說，最槽糕的情況是組織在他們的基礎架構上運行。對於雲計算供應商來說，最好的情況是放棄 Hadoop 供應商，使用他們提供的託管服務。”
如果 Zweben 能夠做到這一點，那麼新的雲架構的採用者將永遠不會重複他認爲 Hadoop 最槽糕的功能之一：讀取模式（schema on read）。
“在第一代 Hadoop 中，每個人都只是專注於將數據放到平臺上。關於讀取模式有很多討論。這對社區裏的每個人來說，這意味着什麼，無須擔心！只需將數據放在 Hadoop 上，人們就會以他們需要的方式來消費數據。”
“這是一個可悲的錯誤。”他繼續道，“它導致了數據沼澤。如果你將 Hadoop 的複雜性、數據沼澤的現狀和公用雲的成功結合起來，你會發現這對 Hadoop 發行公司來說是一個非常大的問題。”
有人可能會爭辯說，Cloudera、Hortonworks 和 MapR 都錯過了公用雲，現在，他們的午餐被 AWS、Azure 和 GCP 給瓜分了。Zweben 說，“這就是事實啊。”但這並不意味着客戶可以繼續使用他們的新的雲架構，就像他們濫用 Hadoop 那樣。
他說：“你可以在 S3 或 Azure 數據湖上轉儲你所有想要的數據，然後不假思索地這麼做，最終你就會跟 Cloudera、Hortonworks 和 MapR 的第一代採用者一樣最終到達同一個地方，這是錯誤的思維方式。”
在 Zweben 看來，考慮大數據的正確方式是，首先弄清楚你希望實現什麼樣的業務結果，然後從那裏開始着手構建。只有在瞭解業務挑戰之後，才能確保自己正在手機正確的數據，並以正確的方式應用機器學習。
Zweben 建議說：“首先要考慮要實現現代化的應用程序，然後找到你需要的數據和你需要注入的模型，以便實現應用程序的現代化。這種思維的倒置將徹底改變整個市場。”
原文鏈接：