Cloudera將Hadoop作為企業數據樞紐的想法非常大膽，但是現實卻大相徑庭。Hadoop距離讓其他大數據解決方案黯然失色還有很長的一段路要走.

當你有了一把足夠大的錘子時，所有的東西看起來都是釘子。這是Hadoop 2.0所面臨的眾多潛在問題之一。目前，讓開發者和終端用戶最關注的是Hadoop 2.0大規模地修改了大數據處理的框架。Cloudera計劃將Hadoop 2.0打造成一把能夠應對所有不同釘子的萬能錘子。

毫無疑問，Hadoop 2.0與之前的產品相比性能有了很大的提升。之前對于MapReduce任務，Hadoop只是一個批量數據處理框架。如今Hadoop 2.0成為了一個可在跨節點系統中部署應用的通用框架，MapReduce也能夠跨節點運行，這一功能顯然讓Cloudera感到非常興奮。在2013年10月底于紐約召開的O'Reilly Strata-Hadoop大會的主題演講，Cloudera向與會者闡述了由Hadoop驅動的“企業數據樞紐”理念。 各種形式的數據都可輸入這個樞紐中，數據在這里可被恰當處理，并被按需提取。

這聽起來非常不錯，但是有多大的可行性呢？對于那些沒有及時涉足大數據，現在才開始為海量數據農場（data farms）尋找恰當位置的企業來說，這類樞紐距離他們太遙遠了。將這些“數據孤島”納入到Hadoop設施中并不是件容易的事。

盡管Hadoop也是一個相當大的障礙，但是這一理念最大的障礙并不是Hadoop本身。通過在Strata-Hadoop大會上與廠商和用戶交流，我們發現，廠商和用戶只是將Hadoop視為一堆水桶的零件而已，它們還需要被焊接起來才能充分地發揮作用。

Hadoop的大多數功能正在通過第三方實現。這些第三方將Hadoop的功能引入到了即時部署型（ready-to-deploy）的產品當中，不僅僅是Cloudera或Cloudera的對手Hortonworks，還包括微軟（Hortonworks的合作伙伴）、亞馬遜、SoftLayer、Rackspace等云服務提供商。他們當中只有一小部分還沒有提供軟件工具所需要的各種程度的抽象化。Puppet或Python腳本在這里只是選項，不是必需的。

即便在小規模的部署當中，Hadoop活動部件和尖銳毛邊的絕對數量也非常的嚇人。在小組會議上，甲骨文產品經理Dan McClary介紹了甲骨文在創建Hadoop工具時所付出的艱辛。這讓我們看到了將Hadoop整合到可交付產品中需要付出多少努力，即便是對于甲骨文這樣的大公司來說也并不容易。McClary表示，隨著時間的推移，Hadoop的毛邊和未完善之處將在社區和廠商的共同努力下被磨平和解決，但是這個時間肯定不會馬上到來。

另一個主要障礙仍然是將應用遷移到Hadoop。基于Hadoop的新基礎設施YARN（Yet Another Resource Negotiator，另一種資源協調者）比以往更具開放性，但要想在上面運行應用必須重新編寫應用，這一工作并不輕松。屆時可能會有一些應急性設備出現，以加快這一進程。例如，可以將應用隨意加入框架內的某種虛擬化封裝工具，不過這一工作也不輕松。

目前業內正在做大量工作，例如開發連接器、數據漏斗等，以便讓Hadoop更好地與現有應用協同工作。盡管大部分人都認為現有應用最終都將遷移至Hadoop上，但是幾乎很少有研討會把重點放在將現有應用向Hadoop遷移這一問題上。與廢棄現有應用一切重新開始相比，大多數人還是希望將現有應用遷移至Hadoop。

也就是說，O'Reilly會議上活躍程度是這種情況多久才會發生的重要預兆。到2014年這時候，這一會議將在紐約曼哈頓賈維茨會議中心召開，屆時Cloudera的部分聲明可能并不會引起太多的樂觀情緒。目前的趨勢是朝著將Hadoop作為現有大數據系統的補充這一方向發展的，而不是向著將Hadoop作為現有大數據系統的升級系統發展的。