Hadoop曾經(jīng)是開源人士的寵兒，在其鼎盛時期一時風(fēng)頭無兩。然而隨著其功能的擴充，系統(tǒng)也變得越來越復(fù)雜，似乎它已經(jīng)不再能夠滿足當(dāng)今時代的數(shù)據(jù)管理需求，關(guān)于“Hadoop已死”的論調(diào)時有出現(xiàn)。那么，Hadoop是否真的已經(jīng)跌下神壇？對于這個問題，或許我們需要更加理性地思考。

Cloudera認為，Hadoop代表的是數(shù)據(jù)領(lǐng)域的開源社區(qū)，即使傳統(tǒng)的Hadoop已經(jīng)不復(fù)存在，但“Hadoop哲學(xué)”永存。作為領(lǐng)先的企業(yè)數(shù)據(jù)云公司，Cloudera從未停止擁抱新的主流技術(shù)，持續(xù)為客戶帶來價值。Cloudera Data Platform（CDP）的誕生便是其持續(xù)創(chuàng)新的最佳證明，它提供了擁有一致的安全及治理能力的數(shù)據(jù)平臺，來幫助企業(yè)更好的對生命周期內(nèi)的數(shù)據(jù)進行控制。重要的是，它依舊是100%基于“Hadoop哲學(xué)”。

技術(shù)永遠是在“打破”與“被打破”中得以發(fā)展。最初，Hadoop的框架最核心的設(shè)計就是HDFS和MapReduce。后來，MapReduce逐漸被Spark取代，從前的“Hadoop發(fā)行版”如今所提供的軟件包含了Spark、HBase、Hive，Kafka、Flink、NiFi等眾多組件，早已超出了最初的批處理功能和基于磁盤的本地部署。

通常， Apache項目較大堆棧的特點是在任何層都具有可替換性。各發(fā)行商已相互競爭多年，角逐各個項目。許多發(fā)行商都有自己的版本，這些版本仍然是開源的。根據(jù)Apache網(wǎng)站上的說法，Hadoop如今包含兩個文件系統(tǒng)（HDFS和Hadoop Ozone），一個用于并行處理大數(shù)據(jù)集的系統(tǒng)Hadoop MapReduce，一個作業(yè)調(diào)度和集群資源管理器Hadoop YARN，以及近期發(fā)布的一個機器學(xué)習(xí)引擎Submarine。

數(shù)據(jù)存儲的革新從未停止

在數(shù)據(jù)遷移至云愈演愈烈的時代，來自云平臺的對象存儲正在逐漸取代HDFS。Apache Ozone在某種程度上是為了創(chuàng)建一個現(xiàn)代開放式的替代方案，它符合所有層的理念。一些人提到了Hadoop兼容文件系統(tǒng)（HCFS），然而，事實上Apache軟件基金會無法確定第三方文件系統(tǒng)是否與Apache Hadoop兼容，相關(guān)言論皆為供應(yīng)商所作聲明，Apache軟件基金會并未對此進行驗證。

一些IT專家可能會辯稱MapReduce曾是主流，但如今它經(jīng)常被Spark所替代，甚至有人認為Spark才是我們應(yīng)該談?wù)摰臉藴驶幚斫M件。另外，還有人表示：“可以動態(tài)處理數(shù)據(jù)的時候，就不要等著數(shù)據(jù)停下來”，他們對Kafka、NiFi和Flink也提出了相同的看法。

Apache的定義確實包含了機器學(xué)習(xí)組件，但Submarine是第二年才出現(xiàn)的新項目，而它現(xiàn)在已升級為頂級項目。可以說，早期基于Mahout的機器學(xué)習(xí)嘗試并未主導(dǎo)Hadoop的使用，Submarine也許會取得更大的成功。Gartner的研究表明，市場正在轉(zhuǎn)向功能更齊全的商業(yè)產(chǎn)品，而不再是針對工程師的開源代碼算法集合。Submarine正是一個朝著這個方向發(fā)展的更完整的集合，因此，與“Hadoop組件”相比，它更有希望成為一個機器學(xué)習(xí)開發(fā)平臺。

豐富生態(tài)，打造專屬“平臺”

從這些組件以及其他所有組件中所選取的特定集合都將具有自己獨特的優(yōu)勢，來適用于特定的用例。在其他層有類似的替代方案，但其實還有另一個關(guān)鍵點，就是幾乎沒有用例僅依賴一層，絕大部分重要的企業(yè)級需求都可能依賴于其中的三層或更多層。因此，“平臺”這一概念其實相當(dāng)于我們所說的“發(fā)行版”，只不過換了一個說法而已。

談到現(xiàn)在使用的具體技術(shù)，從傳統(tǒng)的商業(yè)智能分析、數(shù)據(jù)集成、數(shù)據(jù)庫管理系統(tǒng)（DBMS）、機器學(xué)習(xí)供應(yīng)商到云平臺供應(yīng)商，如今每個人都想擁有一個“平臺”。通常情況下，他們都在某些核心堆棧的某些層上替換了一些組件，特定層的一些替代組件可與其他層的替代組件進行通信。例如，您可能想在AWS上使用Spark（與Kinesis而不是Kafka一起使用）從S3讀取日志數(shù)據(jù)，因為所連接的應(yīng)用程序選擇了Kinesis進行存儲。Spark可以做到這一點，然而并非所有項目都有如此豐富的生態(tài)系統(tǒng)。在使用Microsoft HDInsight和Google DataProc時也會出現(xiàn)類似的情況，無論在哪里部署，都會有“本地收藏夾”選項。

早期的Hadoop團隊通常只關(guān)心自己的集群之內(nèi)，他們無需太擔(dān)心與訪問控制以外的其余結(jié)構(gòu)的治理或安全性的連接。如今的團隊還需要對所交付的商業(yè)軟件包中的許多組件進行檢測，以實現(xiàn)基于角色的精細安全性、元數(shù)據(jù)管理、沿襲、數(shù)據(jù)質(zhì)量、遷移性以及分布式應(yīng)用程序的協(xié)調(diào)等等。使用這項技術(shù)的團隊在日常工作中需要與公司內(nèi)的其余業(yè)務(wù)和技術(shù)部門進行協(xié)調(diào)、交換數(shù)據(jù)并參與策略的執(zhí)行。此外，還需要有資源管理、編配、治理和安全等工作。

從具體問題出發(fā)

所有這些都表明Hadoop這個名稱已不再能夠表示我們當(dāng)今堆棧中的各項技術(shù)的真正作用，現(xiàn)在我們應(yīng)該開始討論的是數(shù)據(jù)湖、機器學(xué)習(xí)、運營數(shù)據(jù)管理等用例，將這些具體用例作為設(shè)計、開發(fā)、集成和運營計劃的基礎(chǔ)會更具說明性和實用性?；蛟S我們可以通過擁抱“Hadoop哲學(xué)”來實現(xiàn)這一目標。

曾經(jīng)的Hadoop供應(yīng)商早已開始這一轉(zhuǎn)型。我們也應(yīng)該根據(jù)用例、功能活動、結(jié)果和受眾等方面重新思考，以便為高價值用戶提供以分析為依據(jù)的更高首選產(chǎn)品可視性。談?wù)揌adoop還是有意義的，不過如果單純從Hadoop這個主題開始，就無法有效地推進討論成果。我們應(yīng)該從具體問題出發(fā)，比如客戶系統(tǒng)，基于機器學(xué)習(xí)的數(shù)字化轉(zhuǎn)型，或者是為現(xiàn)場運行提供更豐富的數(shù)據(jù)，實現(xiàn)我們思考方式的轉(zhuǎn)型。