未來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）的應用程式？

後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 步驟之間沒有任何迴圈連線，這意味著在該級別不會發生效能調整。