以後Hadoop還有生命嗎？

在過去的幾年裡，Hadoop 得到了無數讚譽——Hadoop 是一個以大象命名的強大的、用於儲存和處理資料的開源框架。許多在 Hadoop 生態系統中投入巨資的組織發現自己處於十字路口，想知道 Hadoop 之後的生活是什麼樣的，以及未來會怎樣。本文討論了 Hadoop 之後的生活，併為進入後 Hadoop 時代的組織制定了戰略。

回憶大象

對於許多組織來說，使用 Hadoop 的生活非常好，它為處理大量非結構化資料提供了一些真正的力量。對於一些人來說，SQL-on-Hadoop 解決方案甚至有助於從更復雜（和昂貴）的資料倉儲中解除安裝工作。也就是說，像其他大象一樣，Hadoop 的護理和餵養是，嗯……不是微不足道的——尤其是在洗澡和清理圍欄的時候。我不會對我個人的寵物創傷進一步離題，但我只想說與大型動物一起生活有其不利之處。

例如，儲存在 Hadoop 分散式檔案系統 (HDFS 2.X) 中的資料的 3 倍複製方案在儲存和其他資源方面產生了 200% 的開銷。此外，Hadoop 叢集中計算和儲存之間缺乏分離導致計算（即 CPU）資源的長期利用率不足，同時不斷地最大化伺服器上​​的儲存。這助長了另一個不幸的副產品——Hadoop 叢集蔓延。

隨著資料的爆炸式增長，組織發現自己擁有越來越多的 Hadoop 叢集，每個叢集都有自己複雜的配置、較差的計算利用率以及對儲存的貪婪需求。

是的，使用 Hadoop 並不總是那麼容易，基於 Hadoop 的應用程式也不例外。Hadoop MapReduce 為處理大量資料提供了強大的功能，但需要付出一定的代價。大規模、基於磁碟的 MapReduce 應用程式效能不佳，使其不適合支援新一波的資料驅動應用程式。

此外，Hadoop 市場本身在過去幾年中經歷了重大動盪，這讓組織在思考 Hadoop 的未來時停頓了一下，這是可以理解的。鑑於挑戰和不確定性，許多組織得出的結論是，儘管它很有用，但現在是時候讓大象離開了。 

雙面困境

 當然，對於考慮在 Hadoop 之後生活的組織來說，有兩個核心問題需要回答：

• 我如何處理我的 Hadoop 分散式檔案系統 (HDFS) 資料？
• 我如何處理使用它的基於 Hadoop（例如 MapReduce）的應用程式？

起初，答案可能看起來簡單而明顯，但許多組織瞭解到答案並不像最初想象的那麼清晰或簡單。管理海量資料絕非易事，挑戰並沒有隨著 HDFS 等分散式檔案系統的出現而消失。此外，MapReduce 並沒有神奇地消除分散式資料驅動應用程式的挑戰。

基本事實是 Hadoop 是為另一個時代的資料需求而設計和優化的。今天的資料環境與十年前有很大不同。儘管如此，資料技術採用的兩個主要驅動因素仍然相同——價格和效能。也就是說，Hadoop 不再是任何一個類別的領導者。這提出了一些難以回答的難題。但是，已經出現了兩種明確的策略來幫助組織過渡到後 Hadoop 時代。

後Hadoop時代：1 – 建造一個更好的資料湖

長期以來，Hadoop 資料湖是管理大量非結構化資料的首選策略。只需將所有內容都泵入湖中，讓 MapReduce 應用程式處理它。然而，事情從未如此簡單，大多數資料湖仍然涉及大量複製和低效的資料移動。此外，隨著新興技術挑戰資料管理的關鍵假設並逐漸取代 HDFS 和 MapReduce 等 Hadoop 服務，很明顯需要一種更好的方法來管理大量資料。

輸入資料結構。

從根本上說，Data Fabric 是一種在分散式環境中高效訪問和共享資料的手段；將不同的資料資產整合在一起，並通過一組託管的增強資料服務使其可訪問。基本上，Data Fabric 從 Hadoop Data Lake 停止的地方接了過來。提供對海量資料的高效、多協議訪問，同時最大限度地減少資料移動，並幫助在計算和儲存之間提供急需的分離。 

在當今的資料環境中，單協議 Hadoop 資料湖根本不足以應對當前的挑戰。相比之下，HPE Ezmeral Data Fabric 等現代資料結構提供了極大增強的功能，同時仍提供對集中管理的資料資產的基於 HDFS 的訪問。

但是，資料網格比Data Fabric更加現代，詳細見：資料網格與Data Fabric的區別

後Hadoop時代：2 – 優化計算

如前所述，Hadoop MapReduce 應用程式多年來為處理資料提供了很多功能，並且它在某些任務（例如，distcp）上表現良好。但是，它在各種其他用例中的效能從未如此出色。因此，出現了像Spark這樣的新服務來解決 MapReduce 的缺點。

Spark 引入了重要的創新，並超越了 MapReduce 有限的功能詞彙（對映和歸約處理資料行），採用列式資料處理方法並將資料結構化為有向無環圖 (DAG)。這種方法非常適合處理複雜的工作負載，例如機器學習和圖形分析。此外，Spark 的創新與記憶體中處理模型相結合，帶來了顯著的效能提升——在某些情況下比 MapReduce 快 100 倍。

Spark 的效能大幅提升歸功於幾個因素，包括：

• Spark 不受 I/O 限制。憑藉其記憶體處理模型，Spark 不會在每次執行任務的選定部分時導致磁碟 I/O 效能損失。
• Spark 的 DAG 支援任務步驟之間的優化。與 Spark 不同，Hadoop 在 MapReduce 步驟之間沒有任何迴圈連線，這意味著在該級別不會發生效能調整。

此外，Spark 得益於靈活的部署架構，並且 Spark 叢集可以使用各種叢集管理器進行部署，包括 Kubernetes 和 Hadoop YARN。Hadoop MapReduce 仍然是批量處理大量資料的最佳選擇，但對於大多數其他用例，Spark 是更好的選擇。

鑑於 Spark 的靈活性、對人工智慧和機器學習的適用性以及效能的大幅提升，近年來它的採用率急劇增加。投資 Spark 和相關技術是未來的合理戰略。