|
作者：Monte Zweben是AI數(shù)據(jù)平臺公司Splice Machine的首席執(zhí)行官。 Hadoop正在慢慢地死去，但是致命因素就隱藏在我們眼皮底下。（提示：在標題中。）
復雜性可能為Hadoop發(fā)行版敲響喪鐘。 對于Hadoop的三大分銷商而言，2019年可謂是困難重重的一年。從對于1月份完成的Cloudera/Hortonworks合并的內部樂觀和外部懷疑，到MapR在5月份發(fā)布即將完蛋的信函、隨后被HPE收購，再到Cloudera在6月份非常糟糕的周三（股價暴跌和首席執(zhí)行官Tom Reilly離職），這個領域盡是不好的消息。也許最有說服力的內容來自Cloudera的季度收益公告，該公告將Hadoop的挑戰(zhàn)描述為需要云解決方案： “雖然第一季度一些客戶因預料新平臺的發(fā)布而選擇推遲續(xù)訂和擴展協(xié)議，從而影響了我們的全年前景，但這種客戶反饋和熱情證實了客戶需要我們目標市場中的企業(yè)數(shù)據(jù)云解決方案?！?/span> 好多文章聲稱，公共云已殺死了Hadoop，但是正如我之前在這里所寫的那樣，對于這種分布式技術的未來，我卻持相反的看法。公共云消除了運維復雜性方面的挑戰(zhàn)。這對像Cloudera、Hortonworks和MapR這些很晚進入到云時代的Hadoop發(fā)行版公司來說是沉重的打擊。AWS、Azure和谷歌云平臺（GCP）幾乎消除了運行Hadoop生態(tài)系統(tǒng)核心組件的運維復雜性。然而我認為，即便在公共云，成功采用這項技術仍存在巨大的挑戰(zhàn)。AWS的產品頁面上實際上有數(shù)百種計算和存儲解決方案。我們認為業(yè)界對開發(fā)人員過于依賴。Hadoop是一套很棒的技術組件！我們用它來搭建自己的數(shù)據(jù)平臺。但是與為Hadoop實施而苦惱的多位CIO交談后發(fā)現(xiàn)，我逐漸認為這些組件可能實在太低級了。打個比方，我們需要運輸時，我們根據(jù)運輸需求購買汽車。我們并不購買單獨的汽車零部件，比如噴油器、車軸、發(fā)動機和懸架系統(tǒng)。我們讓那些部件由制造商來組裝。同樣，你要連接AWS Dynamo來運行應用程序時、連接AWS Redshift來分析數(shù)據(jù)、連接AWS SageMaker來構建機器學習模型、連接AWS EMR來運行基于Spark的ETL等時，你就在組裝“汽車”。這就是“Lambda架構”所謂的管道膠帶。然而，這導致了復雜性和數(shù)據(jù)移動。而數(shù)據(jù)移動導致了等待數(shù)據(jù)進行“ETL處理”時常常遇到的延遲。此外，創(chuàng)建這些架構所需的技能稀缺且昂貴。因此，無論是不是可以通過遷移到云端來消除運維復雜性（這的確并非易事），你仍然面臨把所有計算和存儲部件捆綁起來的集成復雜性。我們的觀點是，就像用于運輸?shù)摹捌嚒币粯樱拘枰笠?guī)?？蓴U展的基礎設施來處理操作、分析和機器學習等混合工作負載，但它們應該沒必要自行組裝該實用功能。我們認為，Hadoop的某些組件很適合嵌入和集成，從而讓公司既能夠構建新的應用程序，又能夠更新改造現(xiàn)有的應用程序。另一些公司以其他方式將這些組件集成起來。不過，我們認為這種預先集成必不可少；除非預先集成普及開來，否則 Hadoop仍很難，即便在公共云也是如此。
|
