hadoop是不是已經快過時了

1樓：龍佐天下

沒有吧，雖然現在spark很火，但是還是無法取代hadoop的吧

2樓：一個人的小站

hadoop即將過時了嗎？

hadoop 這個單詞如今鋪天蓋地，幾乎成了大資料的代名詞。僅僅數年時間，hadoop 從邊緣技術迅速成長為一個事實標準。如今想玩轉大資料，搞企業分析或者商業智慧，沒有 hadoop 還真不行。

但 hadoop 狂熱的背後卻醞釀著一場技術變革，hadoop 的核心技術在 google 那裡已經過時，因為 hadoop 並不擅長處理「快資料」。

今天，hadoop 似乎已經毫無爭議地成了企業大資料技術標準，看上去 hadoop 將根植企業，其地位在未來十年似乎都不會動搖。但是 gigaom 的專欄作家 mike miller 卻發出了「不和諧」的聲音：「企業真的會為一個盛極而衰的技術買單嗎？

」起源：google 檔案系統和 google mapreduce

為了** hadoop 的生命週期我們需要回溯 hadoop 的靈感源泉——google 的 mapreduce。為了迎接資料大**的挑戰，google 的工程師 jeff dean 和 sanjay ghemawat 架構了兩個影響深遠的系統：google file system（gfs）和 google mapreduce（gmr）。

前者是一個能在通用硬體上管理 eb（exabyte）級資料的出色的可行方案。後者則是一個同樣出色的，能在通用伺服器上大規模並行處理資料的模型設計實現。

gmr 的出彩之處在於能夠讓普通的 google 使用者和開發者也能夠進行高速、容錯的大資料處理。gmr 和 gfs 成了搜尋引擎資料處理引擎的核心，該引擎抓取、分析並分級 web 頁面，並最終為使用者呈現日常搜尋結果。

hadoop 生態系統

我們再回頭看看 apache hadoop 的兩大組成部分：hadoop 分散式檔案系統和 hadoop，確實就是 gfs 和 gmr 的翻版。雖然 hadoop 正在發展成為一個無所不包的資料管理和處理生態系統，但是在這個生態系統的核心，依然是 mapreduce 系統。

所有的資料和應用最終都將降解為 map 和 reduce 的工作。

google 已經進化，hadoop 能否跟上？

有趣的事情是，gmr 已經不再佔據 google 軟體堆疊中的顯赫位置。當企業被 hadoop 解決方案鎖定到 mapreduce 上時，google 卻已經準備淘汰 mapreduce 技術。雖然 apache 專案和 hadoop 商業發行版本試圖通過 hbase、hive 和下一代 mapreduce（亦即 yarn）彌補 hadoop 的短板。

但筆者認為只有用全新的，非 mapreduce 架構的技術替代 hadoop 核心（hdfs 和 zookeeper）才能與谷歌的技術抗衡。（這裡有一個更加技術性的闡述：gluecon-miller-horizon）

增量索引過濾器（percolator for incremental indexing）和頻繁變化資料集分析。hadoop 是一臺大型「機器」，當啟動並全速運轉時處理資料的效能驚人，你唯一需要操心的就是硬碟的傳輸速度跟不上。但是每次你準備啟動分析資料時，都需要把所有的資料都過一遍，當資料集越來越龐大時，這個問題將導致分析時間無限延長。

那麼 google 是如何解決讓搜尋結果返回速度越來越接近實時的呢？答案是用增量處理引擎 percolator 代替 gmr。通過只處理新增的、改動過的或刪除的文件和使用二級指數來高效率建目錄，返回查詢結果。

percolator **的作者寫道：「將索引系統轉換成增量系統…將文件處理延遲縮短了 100 倍。」這意味著索引 web 新內容的速度比用 mapreduce 快 100 倍！

類似大型強子對撞機產生的資料將不斷變大，twitter 也是如此。這也是為什麼 hbase 中會新增觸發流程，而 twitter storm 正在成為實時處理流資料的熱門技術。

用於點對點分析的 dremel。google 和 hadoop 生態系統都致力於讓 mapreduce 成為可用的點對點分析工具。從 sawzall 到 pig 和 hive，建立了大量的介面層，但是儘管這讓 hadoop 看上去更像 sql 系統，但是人們忘記了一個基本事實——mapreduce (以及 hadoop)是為組織資料處理任務開發的系統，誕生於工作流核心，而不是點對點分析。

今天有大量的 bi/分析查詢都是點對點模式，屬於互動和低延遲的分析。hadoop 的 map 和 reduce 工作流讓很多分析師望而卻步，而且工作啟動和完成工作流執行的漫長週期對於很多互動性分析來說意味著糟糕的使用者體驗。於是，google 發明了 dremel（業界也稱之為 bigquery 產品）專用工具，可以讓分析師數秒鐘內就掃描成 pb（petabyte）的資料完成點到點查詢，而且還能支援視覺化。

google 在 dremel 的**中聲稱：「dremel 能夠在數秒內完成數萬億行資料的聚合查詢，比 mapreduce 快上 100 倍！」

分析圖資料的 pregel。google mapreduce 的設計初衷是分析世界上最大的資料圖譜——網際網路。但是在分析人際網路、電信裝置、文件和其他一些圖資料時就沒有那麼靈光了，例如 mapreduce 在計算單源最短路徑（sssp）時效率非常低下，已有的並行圖演算法庫 parallel bgl 或者 cgmgraph 又沒有容錯。

於是 google 開發了 pregel，一個可以在分散式通用伺服器上處理 pb 級別圖資料的大型同步處理應用。與 hadoop 經常在處理圖資料時產生指數級資料放大相比，pregel 能夠自然高效地處理 sssp 或 pagerank 等圖演算法，所用時間要短得多，**也簡潔得多。

目前唯一能與 pregel 媲美的開源選擇是 giraph，這是一個早期的 apache 孵化專案，呼叫了 hdfs 和 zookeeper。githb 上還有一個專案 golden orb 可用。

總結總而言之，hadoop 是一個可以在普通通用硬體叢集上進行大規模資料處理的優秀工具。但是如果你希望處理動態資料集、點對點分析或者圖資料結構，那麼 google 已經為我們展示了大大優於 mapreduce 範型的技術選擇。毫無疑問，percolator、dremel 和 pregel 將成為大資料的新「三巨頭」，正如 google 的老「三巨頭」：

gfs、gmr 和 bigtable 所做的那樣。

3樓：亮晶晶的星星

hadoop是大資料裡面的知識，應該說沒有過時吧，現在大資料不是正好很火嗎？目前itjob好像有這麼的老師可以諮詢下。

最近對大資料感興趣，hadoop是不是過時了，應該深入學習spark

4樓：匿名使用者

第一、資料量巨大bai。從tb級別du，躍升到pb級別;

第二**、地理位置信答

hadoop是不是已經快過時了

現在玩悠悠球是不是過時了，悠悠球會過時嗎

都出四核手機了雙核是不是要過時

本人想買部諾基亞6300是不是有點過時了

其他用戶還看了：