作者:陳 飈

“昔我十年前，與君始相識”

一瞬間Hadoop也到了要初中擇校的年齡了。十年前還沒有Hadoop，幾年前國內IT圈裡還不知道什麼是Hadoop，而現在幾乎所有大型企業的IT系統中有已經有了Hadoop的叢集在運行了各式各樣的任務。

2006年專案成立的一開始，“Hadoop”這個單詞只代表了兩個元件——HDFS和MapReduce。到現在的10個年頭，這個單詞代表的是“核心”(即Core Hadoop專案)以及與之相關的一個不斷成長的生態系統。這個和Linux非常類似，都是由一個核心和一個生態系統組成。36大資料（http://www.36dsj.com/）

現在Hadoop儼然已經成為企業資料平臺的“新常態”。我們很榮幸能夠見證Hadoop十年從無到有，再到稱王。在我們感動於技術的日新月異時，希望能通過本文能為Hadoop的昨天、今天和明天做出一點自己的解讀，算是為Hadoop慶祝10歲生日獻上的禮物。36大資料（http://www.36dsj.com/）

Hadoop編年史

2002年10月，Doug Cutting和Mike Cafarella建立了開源網頁爬蟲專案Nutch。

2003年10月，Google發表Google File System論文。

2004年7月，Doug Cutting和Mike Cafarella在Nutch中實現了類似GFS的功能，即後來HDFS的前身。

2004年10月，Google發表了MapReduce論文。

2005年2月，Mike Cafarella在Nutch中實現了MapReduce的最初版本。

2005年12月，開源搜尋專案Nutch移植到新框架，使用MapReduce和NDFS(Nutch Distributed File System )來執行，在20個節點穩定執行。

2006年1月，Doug Cutting加入雅虎，Yahoo!提供一個專門的團隊和資源將Hadoop發展成一個可在網路上執行的系統。

2006年2月，Apache Hadoop專案正式啟動以支援MapReduce和HDFS的獨立發展。

2006年2月，Yahoo!的網格計算團隊採用Hadoop。

2006年3月，Yahoo!建設了第一個Hadoop叢集用於開發。

2006年4月，第一個Apache Hadoop釋出。

2006年4月，在188個節點上(每個節點10GB)執行排序測試集需要47.9個小時。

2006年5月，Yahoo!建立了一個300個節點的Hadoop研究叢集。

2006年5月，在500個節點上執行排序測試集需要42個小時(硬體配置比4月的更好)。

2006年11月，研究叢集增加到600個節點。

2006年11月，Google發表了Bigtable論文，這最終激發了HBase的建立。

2006年12月，排序測試集在20個節點上執行1.8個小時，100個節點上執行3.3小時，500個節點上執行5.2小時，900個節點上執行7.8個小時。

2007年1月，研究叢集增加到900個節點。

2007年4月，研究叢集增加到兩個1000個節點的叢集。

2007年10月，第一個Hadoop使用者組會議召開，社群貢獻開始急劇上升。

2007年，百度開始使用Hadoop做離線處理。

2007年，中國移動開始在“大雲”研究中使用Hadoop技術。

2008年，淘寶開始投入研究基於Hadoop的系統——雲梯，並將其用於處理電子商務相關資料。

2008年1月，Hadoop成為Apache頂級專案。

2008年2月，Yahoo!運行了世界上最大的Hadoop應用，宣佈其搜尋引擎產品部署在一個擁有1萬個核心的Hadoop叢集上。

2008年4月，在900個節點上執行1TB排序測試集僅需209秒，成為世界最快。

2008年6月，Hadoop的第一個SQL框架——Hive成為了Hadoop的子專案。

2008年7月，Hadoop打破1TB資料排序基準測試記錄。Yahoo!的一個Hadoop叢集用209秒完成1TB資料的排序 ，比上一年的紀錄保持者保持的297秒快了將近90秒。

2008年8月，第一個Hadoop商業化公司Cloudera成立。

2008年10月，研究叢集每天裝載10TB的資料。

2008年11月，Apache Pig的最初版本釋出。

2009年3月，17個叢集總共24000臺機器。36大資料（http://www.36dsj.com/）

2009 年3月，Cloudera推出世界上首個Hadoop發行版——CDH(Cloudera’s Distribution including Apache Hadoop)平臺，完全由開放原始碼軟體組成。

2009年4月，贏得每分鐘排序，59秒內排序500GB(在1400個節點上)和173分鐘內排序100TB資料(在3400個節點上)。

2009年5月，Yahoo的團隊使用Hadoop對1 TB的資料進行排序只花了62秒時間。

2009年6月，Cloudera的工程師Tom White編寫的《Hadoop權威指南》初版出版，後被譽為Hadoop聖經。

2009年7月 ，Hadoop Core專案更名為Hadoop Common;

2009年7月 ，MapReduce 和 Hadoop Distributed File System (HDFS) 成為Hadoop專案的獨立子專案。

2009年7月 ，Avro 和 Chukwa 成為Hadoop新的子專案。

2009年8月，Hadoop創始人Doug Cutting加入Cloudera擔任首席架構師。

2009年10月，首屆Hadoop World大會在紐約召開。

2010年5月 ，Avro脫離Hadoop專案，成為Apache頂級專案。

2010年5月 ，HBase脫離Hadoop專案，成為Apache頂級專案。

2010年5月，IBM提供了基於Hadoop 的大資料分析軟體——InfoSphere BigInsights，包括基礎版和企業版。

2010年9月，Hive( Facebook) 脫離Hadoop，成為Apache頂級專案。

2010年9月，Pig脫離Hadoop，成為Apache頂級專案。

2010年-2011年，擴大的Hadoop社群忙於建立大量的新元件(Crunch，Sqoop，Flume，Oozie等)來擴充套件Hadoop的使用場景和可用性。

2011年1月，ZooKeeper 脫離Hadoop，成為Apache頂級專案。

2011年3月，Apache Hadoop獲得Media Guardian Innovation Awards 。

2011年3月， Platform Computing 宣佈在它的Symphony軟體中支援Hadoop MapReduce API。

2011年5月，Mapr Technologies公司推出分散式檔案系統和MapReduce引擎——MapR Distribution for Apache Hadoop。

2011年5月，HCatalog 1.0釋出。該專案由Hortonworks 在2010年3月份提出，HCatalog主要用於解決資料儲存、元資料的問題，主要解決HDFS的瓶頸，它提供了一個地方來儲存資料的狀態資訊，這使得 資料清理和歸檔工具可以很容易的進行處理。

2011年4月，SGI(Silicon Graphics International)基於SGI Rackable和CloudRack伺服器產品線提供Hadoop優化的解決方案。

2011年5月，EMC為客戶推出一種新的基於開源Hadoop解決方案的資料中心裝置——GreenPlum HD，以助其滿足客戶日益增長的資料分析需求並加快利用開源資料分析軟體。Greenplum是EMC在2010年7月收購的一家開源資料倉庫公司。

2011年5月，在收購了Engenio之後， NetApp推出與Hadoop應用結合的產品E5400儲存系統。

2011年6月，Calxeda公司發起了“開拓者行動”，一個由10家軟體公司組成的團隊將為基於Calxeda即將推出的ARM系統上晶片設計的伺服器提供支援。併為Hadoop提供低功耗伺服器技術。

2011年6月，資料整合供應商Informatica釋出了其旗艦產品，產品設計初衷是處理當今事務和社會媒體所產生的海量資料，同時支援Hadoop。

2011年7月，Yahoo!和矽谷風險投資公司 Benchmark Capital建立了Hortonworks 公司，旨在讓Hadoop更加可靠，並讓企業使用者更容易安裝、管理和使用Hadoop。

2011年8月，Cloudera公佈了一項有益於合作伙伴生態系統的計劃——建立一個生態系統，以便硬體供應商、軟體供應商以及系統整合商可以一起探索如何使用Hadoop更好的洞察資料。

2011年8月，Dell與Cloudera聯合推出Hadoop解決方案——Cloudera Enterprise。Cloudera Enterprise基於Dell PowerEdge C2100機架伺服器以及Dell PowerConnect 6248乙太網交換機。

2012年3月，企業必須的重要功能HDFS NameNode HA被加入Hadoop主版本。

2012年8月，另外一個重要的企業適用功能YARN成為Hadoop子專案。

2012年10月，第一個Hadoop原生MPP查詢引擎Impala加入到了Hadoop生態圈。

2014年2月，Spark逐漸代替MapReduce成為Hadoop的預設執行引擎，併成為Apache基金會頂級專案。

2015年2月，Hortonworks和Pivotal抱團提出“Open Data Platform”的倡議，受到傳統企業如Microsoft、IBM等企業支援，但其它兩大Hadoop廠商Cloudera和MapR拒絕參與。

2015年10月，Cloudera公佈繼HBase以後的第一個Hadoop原生儲存替代方案——Kudu。

2015年12月，Cloudera發起的Impala和Kudu專案加入Apache孵化器。

注：來源網路，不一一列舉。36大資料（http://www.36dsj.com/）

技術篇

現在Hadoop在一月釋出了2.7.2的穩定版， 已經從傳統的Hadoop三駕馬車HDFS，MapReduce和HBase社群發展為60多個相關元件組成的龐大生態，其中包含在各大發行版中的元件就有25個以上，包括資料儲存、執行引擎、程式設計和資料訪問框架等。

Hadoop在2.0將資源管理從MapReduce中獨立出來變成通用框架後，就從1.0的三層結構演變為了現在的四層架構：

1. 底層——儲存層，檔案系統HDFS

2. 中間層——資源及資料管理層，YARN以及Sentry等

3. 上層——MapReduce、Impala、Spark等計算引擎

4. 頂層——基於MapReduce、Spark等計算引擎的高階封裝及工具，如Hive、Pig、Mahout等等

我們欣慰地看到開源文化為Hadoop社群和生態帶來的蓬蓬髮展，但又確實存在一些碎片化和重複化現象。

複雜的生態和過多的元件幾乎讓很多企業仍然等待一個像以前IBM一樣的巨頭廠商能提供標準化的解決方案。不過隨著圍繞Hadoop和Spark的生態圈日益穩固，核心會變得穩定得多。

儲存層

HDFS已經成為了大資料磁碟儲存的事實標準，用於海量日誌類大檔案的線上儲存。經過這些年的發展，HDFS的架構和功能基本固化，像HA、異構儲存、本地資料短路訪問等重要特性已經實現，在路線圖中除了Erasure Code已經沒什麼讓人興奮的feature。

隨著HDFS越來越穩定，社群的活躍度頁越來越低，同時HDFS的使用場景也變得成熟和固定，而上層會有越來越多的檔案格式封裝：列式儲存的檔案格式，如Parquent，很好的解決了現有BI類資料分析場景;以後還會出現新的儲存格式來適應更多的應用場景，如陣列儲存來服務機器學習類應用等。

未來HDFS會繼續擴充套件對於新興儲存介質和伺服器架構的支援。隨著資料量的增大，跨機房部署相信也終會在基線版本中實現。基於HDFS的儲存機制，

將HBase作為儲存層似乎有點牽強：其底層使用HDFS作為檔案儲存。不過在邏輯角度，還是傾向與將HBase定位為儲存層或資料訪問層，因為其提供了另外一種場景的資料儲存和訪問方案。2015年HBase 釋出了1.0版本，這也代表著 HBase 走向了穩定。

最新HBase新增特性包括：更加清晰的介面定義，多Region 副本以支援高可用讀，Family粒度的Flush以及RPC讀寫佇列分離等。未來HBase不會再新增大的新功能，而將會更多的在穩定性和效能方面進化，尤其是大記憶體支援、記憶體GC效率等。

Kudu是Cloudera在2015年10月才對外公佈的新的分散式儲存架構，與HDFS完全獨立。其實現參考了2012年Google發表的Spanner論文。鑑於Spanner在Google 內部的巨大成功，Kudu被譽為下一代分析平臺的重要組成，用於處理快速資料的查詢和分析，填補HDFS和HBase之間的空白。其出現將進一步把Hadoop市場向傳統資料倉庫市場靠攏。

另一方面，分散式記憶體檔案系統也在興起，旨在消除不同任務或不同計算框架間的資料共享時的轉化代價，並提供記憶體快取以提高熱資料處理效能。這一市場以前使用第三方Redis或Memcached，到後來能為分析提供更多原生支援的Tachyon或Ignite，而現在又迎來了新貴Arrow。

Apache Arrow專案為列式記憶體儲存的處理和互動提供了規範。目前來自Apache Hadoop社群的開發者們致力於將它制定為大資料系統專案的事實性標準。

Arrow專案受到了Cloudera、Databricks等多個大資料巨頭公司支援，很多committer同時也是其他明星大資料專案(如HBase、Spark、Kudu等)的核心開發人員。再考慮到Tachyon等似乎還沒有找到太多實際接地氣的應用場景，Arrow的高調出場可能會成為未來新的記憶體分析檔案介面標準。

管控層

管控又分為資料管控和資源管控。36大資料（http://www.36dsj.com/）

隨著Hadoop叢集規模的增大以及對外服務的擴充套件，如何有效可靠的共享利用資源是管控層需要解決的問題。脫胎於MapReduce1.0的YARN成為了Hadoop 2.0通用資源管理平臺。

由於佔據了Hadoop的地利，業界對其在資源管理領域未來的前景非常看好。傳統其他資源管理框架如Mesos，還有現在興起的Docker等都會對YARN未來的發展產生影響。

如何提高YARN效能、如何與容器技術深度融合，如何更好的適應短任務的排程，如何更完整的多租戶支援、如何細粒度的資源管控等都是企業實際生產中迫在眉睫的需求，需要YARN解決。要讓Hadoop走得更遠，未來YARN需要做的工作還很多。

另一方面大資料的安全和隱私越來越多的受到關注。Hadoop依靠且僅依靠Kerberos來實現安全機制，但每一個元件都將進行自己的驗證和授權策略。

開源社群似乎從來不真正關心安全問題，如果不使用來自Hortonworks的Ranger或來自Cloudera 的Sentry這樣的元件，那麼大資料平臺基本上談不上安全可靠。

Cloudera剛推出的RecordService元件使得Sentry在安全競賽中拔得先機。RecordService不僅提供了跨所有元件一致的安全顆粒度，而且提供了基於Record的底層抽象(有點像Spring，代替了原來Kite SDK的作用)，讓上層的應用和下層儲存解耦合的同時、提供了跨元件的可複用資料模型。

計算引擎層

Hadoop生態和其他生態最大的不同之一就是“單一平臺多種應用”的理念了。傳的資料庫底層只有一個引擎，只處理關係型應用，所以是“單一平臺單一應用”;而NoSQL市場有上百個NoSQL軟體，每一個都針對不同的應用場景且完全獨立，因此是“多平臺多應用”的模式。而Hadoop在底層共用一份HDFS儲存，上層有很多個元件分別服務多種應用場景，如：

確定性資料分析：主要是簡單的資料統計任務，例如OLAP，關注快速響應，實現元件有Impala等;探索性資料分析：主要是資訊關聯性發現任務，例如搜尋，關注非結構化全量資訊收集，實現元件有Search等;預測性資料分析：主要是機器學習類任務，例如邏輯迴歸等，關注計算模型的先進性和計算能力，實現元件有Spark、MapReduce等;資料處理及轉化：主要是ETL類任務，例如資料管道等，關注IO吞吐率和可靠性，實現元件有MapReduce等

其中，最耀眼的就是Spark了。IBM宣佈培養100萬名Spark開發人員，Cloudera在One Platform倡議中宣佈支援Spark為Hadoop的預設通用任務執行引擎，加上Hortonworks全力支援Spark，我們相信Spark將會是未來大資料分析的核心。

雖然Spark很快，但現在在生產環境中仍然不盡人意，無論擴充套件性、穩定性、管理性等方面都需要進一步增強。同時，Spark在流處理領域能力有限，如果要實現亞秒級或大容量的資料獲取或處理需要其他流處理產品。

Cloudera宣佈旨在讓Spark流資料技術適用於80%的使用場合，就考慮到了這一缺陷。我們確實看到實時分析(而非簡單資料過濾或分發)場景中，很多以前使用S4或Storm等流式處理引擎的實現已經逐漸Kafka+Spark Streaming代替。

Spark的流行將逐漸讓MapReduce、Tez走進博物館。

服務層

服務層是包裝底層引擎的程式設計API細節，對業務人員提供更高抽象的訪問模型，如Pig、Hive等。

而其中最炙手可熱的就是OLAP的SQL市場了。現在，Spark有70%的訪問量來自於SparkSQL!SQL on Hadoop到底哪家強?Hive、Facebook的Pheonix、Presto、SparkSQL、Cloudera推的Impala、MapR推的Drill、IBM的BigSQL、還是Pivital開源的HAWQ?

這也許是碎片化最嚴重的地方了，從技術上講幾乎每個元件都有特定的應用場景，從生態上講各個廠家都有自己的寵愛，因此Hadoop上SQL引擎已經不僅僅是技術上的博弈(也因此考慮到本篇中立性，此處不做評論)。

可以遇見的是，未來所有的SQL工具都將被整合，有些產品已經在競爭鍾逐漸落伍，我們期待市場的選擇。

周邊的工具更是百花齊放，最重要的莫過於視覺化、任務管理和資料管理了。

有很多開源工具都支援基於Hadoop 的查詢程式編寫以及即時的圖形化表示，如HUE、Zeppelin等。使用者可以編寫一些SQL或Spark程式碼以及描述程式碼的一些標記，並指定視覺化的模版，執行後儲存起來，就可供其他人複用，這鐘模式也被叫做“敏捷BI”。這個領域的商業產品更是競爭激烈，如Tableau、Qlik等。

排程類工具的鼻祖Oozie能實現幾個MapReduce任務串連執行的場景，後來的Nifi及Kettle等其他工具則提供了更加強大的排程實現，值得一試。

毫無疑問，相對與傳統的資料庫生態，Hadoop的資料治理相對簡單。Atlas是Hortonworks新的資料治理工具，雖然還談不上完全成熟，不過正取得進展。Cloudera的Navigator是Cloudera商業版本的核心，匯聚了生命週期管理、資料溯源、安全、審計、SQL遷移工具等一系列功能。

Cloudera收購Explain.io以後將其產品整合為Navigator Optimizator元件，能幫助使用者把傳統的SQL應用遷移到Hadoop平臺並提供優化建議，可以節省數人月的工作量。

演算法及機器學習

實現基於機器學習的自動的智慧化資料價值挖掘是大資料和Hadoop最誘人的願景了，也是很多企業對大資料平臺的最終期望。隨著可獲得的資料越來越多，未來大資料平臺的價值更多的取決於其計算人工智慧的程度。

現在機器學習正慢慢跨出象牙塔，從一個少部分學術界人士研究的科技課題變成很多企業正在驗證使用的資料分析工具，而且已經越來越多的進入我們的日常生活。

機器學習的開源專案除了之前的Mahout、MLlib、Oryx等，今年發生了很多令人矚目的大事，迎來了數個明星巨頭的重磅加入：

2015年1月，Facebook開源前沿深度學習工具“Torch”。

2015年4月，亞馬遜啟動其機器學習平臺Amazon Machine Learning，這是一項全面的託管服務，讓開發者能夠輕鬆使用歷史資料開發並部署預測模型。

2015年11月，谷歌開源其機器學習平臺TensorFlow。36大資料（http://www.36dsj.com/）

同一月，IBM開源SystemML併成為Apache官方孵化專案。36大資料（http://www.36dsj.com/）

同時，微軟亞洲研究院將分散式機器學習工具DMTK通過Github開源。DMTK由一個服務於分散式機器學習的框架和一組分散式機器學習演算法組成，可將機器學習演算法應用到大資料中。

2015年12月，Facebook開源針對神經網路研究的伺服器“Big Sur”，配有高效能圖形處理單元(GPUs)，轉為深度學習方向設計的晶片。

產業篇

現在使用Hadoop的企業以及靠Hadoop賺錢的企業已經成千上萬。幾乎大的企業或多或少的已經使用或者計劃嘗試使用Hadoop技術。就對Hadoop定位和使用不同，可以將Hadoop業界公司劃分為四類：

1. 第一梯隊：這類公司已經將Hadoop當作大資料戰略武器。

2. 第二梯隊：這類公司將Hadoop 產品化。

3. 第三梯隊：這類公司創造對Hadoop整體生態系統產生附加價值的產品。

4. 第四梯隊：這類公司消費Hadoop，並給規模比第一類和第二類小的公司提供基於Hadoop的服務。

時至今日，Hadoop雖然在技術上已經得到驗證、認可甚至已經到了成熟期。但與之對應的以Hadoop為代表的大資料基礎平臺產業界仍然還在迷茫和探索。

雖然大資料的市場很大，但單純Hadoop產品和服務市場，和傳統關係型事務資料庫市場相比還不到1%。

雖然很多高調的創業公司上線也拿到引人注目的風險投資，但只是到達大資料部署和早期成熟階段。

其中最能代表Hadoop發展軌跡的莫過於商業公司推出的Hadoop發行版了。自從2008年Cloudera成為第一個Hadoop商業化公司，並在2009年推出第一個Hadoop發行版後，很多大公司也加入了做Hadoop產品化的行列。

1. “發行版”這個詞是開源文化特有的符號，看起來任何一個公司只要將開原始碼打個包，再多多少少加個佐料就能有一個“發行版”，然而背後是對海量生態系統元件的價值篩選、相容和整合保證以及支撐服務。

2. 2012年以前的發行版基本為對Hadoop打補丁為主，出現了好幾個私有化Hadoop版本，所折射的是Hadoop產品在質量上的缺陷。同期HDFS、HBase等社群的超高活躍度印證了這個事實。

3. 而之後的公司更多是工具、整合、管理，所提供的不是“更好的Hadoop”而是如何更好的用好“現有”的Hadoop。

4. 2014年以後，隨著Spark和其他OLAP產品的興起，折射出來是Hadoop善長的離線場景等已經能夠很好的解決，希望通過擴大生態來適應新的硬體和拓展新的市場。

對於開源產品，一直有擁抱開源和提供私有化這兩種流派，商業模式要麼是提供技術支援服務，要麼是提供私有化的增強版本。對於Hadoop的產品化也不例外。

但就目前的情況看，曾經私有化Hadoop版本的代表Pivotal和Intel都已經放棄，IBM幾乎事實上放棄了自有Hadoop，再考慮到之前Taobao放棄私有Hadoop路線，似乎證明了在像Hadoop這樣生態龐大、發展迅速的產品，與區域性私有增強帶來的好處相比，長期獨立站在世界的對立面並不斷地與整體社群版本做程式碼合併似乎是越來越不可承受之痛。

如今，主要的Hadoop產品化廠商只剩下了三家廠商，並且使用了三種截然不同的商業模式。過去幾年，雖然尚無任何資料現實三家廠商實現財務盈利，但在資本市場都名聲赫赫，且不斷收購擴張。從另外一個角度說明，Hadoop市場仍然再初級發展階段。

Cloudera提出了Hybrid Open Source的架構：核心元件名稱叫CDH(Cloudera’s Distribution including Apache Hadoop)，開源免費並與Apache社群同步，使用者無限制使用，保證Hadoop基本功能持續可用，不會被廠家繫結;資料治理和系統管理元件閉源且需要商業許可，支援客戶可以更好更方便的使用Hadoop技術，如部署安全策略等。

Cloudera也在商業元件部分提供在企業生產環境中執行Hadoop所必需的運維功能，而這些功能並不被開源社群所覆蓋，如無宕機滾動升級、非同步災備等。

Hortonworks採用了100%完全開源策略，產品名稱為HDP(Hortonworks Data Platform)。所有軟體產品開源，使用者免費使用，Hortonworks提供商業的技術支援服務。與CDH相比，管理軟體使用開源Ambari，資料治理使用Atlas，安全元件使用Ranger而非Sentry，SQL繼續緊抱Hive大腿。

MapR採用了傳統軟體廠商的模式，使用私有化的實現。使用者購買軟體許可後才能使用。其OLAP產品主推Drill，又不排斥Impala。

不過，三家廠商的處境有所不相同。Hortonworks雖然業績不斷進步，但直到現在仍未能實現盈利。上市後市值未能走高，可見市場對於Hadoop純服務公司的未來價值增值期望不高。而另廂Cloudera估值近50億美金，最後一輪收到的來自Intel的7.8億美元已經超過Hortonworks最近6.8億的估值，被譽為2016年最有希望上市的高科技軟體公司。

現在，Cloudera和Hortonworks的定位已經不是Hadoop發行版軟體開發商了，而是現代化的資料管理和分析平臺建設廠家，足見其“狼子野心”。

另一方面，傳統企業資料管理軟體巨頭仍然對即有格局信心滿滿，對於Hadoop產品還是觀望態度，通常OEM發行版廠商而非自己研發Hadoop產品，如Oracle、Dell，Teradata公司的大資料一體機都是採用OEM化Cloudera的企業版本產品。

現在主流的公有云如AWS、Azure等都已經在原有提供虛擬機器的IaaS服務之外，提供基於Hadoop的PaaS雲端計算服務。未來這塊市場的發展將超過私有Hadoop部署。

作為大資料基礎設施平臺的Hadoop雖然是技術上是核心，但商業上還只是整個大資料生態系統中非常小的部分，如最新的大資料版圖所示：

應用篇

Hadoop平臺釋放了前所未有的計算能力，同時大大降低了計算成本。底層核心基礎架構生產力的發展，必然帶來的是大資料應用層的迅速建立。

對於Hadoop上的應用大致可以分為這兩類：

IT優化36大資料（http://www.36dsj.com/）

將已經實現的應用和業務搬遷到Hadoop平臺，以獲得更多的資料、更好的效能或更低的成本。通過提高產出比、降低生產和維護成本等方式為企業帶來好處。

這幾年Hadoop在數個此類應用場景中已經被證明是非常適合的解決方案，包括：

1. 歷史日誌資料線上查詢：傳統的解決方案將資料存放在昂貴的關係型資料庫中，不僅成本高、效率低，而且無法滿足線上服務時高併發的訪問量。以HBase為底層儲存和查詢引擎的架構非常適合有固定場景(非ad hoc)的查詢需求，如航班查詢、個人交易記錄查詢等等。現在已經成為線上查詢應用的標準方案，中國移動在企業技術指導意見中明確指明使用HBase技術來實現所有分公司的清賬單查詢業務。

2. ETL任務：不少廠商已經提供了非常優秀的ETL產品和解決方案，並在市場中得到了廣泛的應用。然而在大資料的場景中，傳統ETL遇到了效能和QoS保證上的嚴重挑戰。多數ETL任務是輕計算重IO型別的，而傳統的IT硬體方案，如承載資料庫的小型計算機，都是為計算類任務設計的，即使使用了最新的網路技術，IO也頂多到達幾十GB。採用分散式架構的Hadoop提供了完美的解決方案，不僅使用share-nothing的scale-out架構提供了能線性擴充套件的無限IO，保證了ETL任務的效率，同時框架已經提供負載均衡、自動FailOver等特性保證了任務執行的可靠性和可用性。

3. 資料倉庫offload：傳統資料倉庫中有很多離線的批量資料處理業務，如日報表、月報表等，佔用了大量的硬體資源。而這些任務通常又是Hadoop所善長的

經常被問到的一個問題就是，Hadoop是否可以代替資料倉庫，或者說企業是否可以使用免費的Hadoop來避免採購昂貴的資料倉庫產品。

資料庫界的泰斗Mike Stonebroker在一次技術交流中說：資料倉庫和Hadoop所針對的場景重合型非常高，未來這兩個市場一定會合並。我們相信在資料倉庫市場Hadoop會遲早替代到現在的產品，只不過，那時候的Hadoop已經又不是現在的樣子了。就現在來講，Hadoop還只是資料倉庫產品的一個補充，和資料倉庫一起構建混搭架構為上層應用聯合提供服務。

業務優化36大資料（http://www.36dsj.com/）

在Hadoop上實現原來尚未實現的演算法、應用，從原有的生產線中孵化出新的產品和業務，創造新的價值。通過新業務為企業帶來新的市場和客戶，從而增加企業收入。

Hadoop提供了強大的計算能力，專業大資料應用已經在幾乎任何垂直領域都很出色，從銀行業(反欺詐、徵信等)、醫療保健(特別是在基因組學和藥物研究)，到零售業、服務業(個性化服務、智慧服務，如UBer的自動派車功能等)。

在企業內部，各種工具已經出現，以幫助企業使用者操作核心功能。例如，大資料通過大量的內部和外部的資料，實時更新資料，可以幫助銷售和市場營銷弄清楚哪些客戶最有可能購買。客戶服務應用可以幫助個性化服務; HR應用程式可幫助找出如何吸引和留住最優秀的員工等。

不過，網際網路以外的傳統行業內部，現在大資料的應用和業務普遍尚處在探索階段，雖然不少企業已經從資料和深度挖掘資料價值中得到的甜頭，但更多的企業在實現資料分析時缺少業務的指導和支撐，可量化可規模化的大資料業務閉環尚未建立，更多是站在改善使用者體驗等角度改善現有運營效率。

雖然行業性的大資料新興業務解決方案尚未出現，但很多新興的公司信心滿滿的進入這個市場，並收到資本市場的熱捧，或提供輔助工具，或提供Big Data-as-a-Service服務，或提供基於大大資料的商業設計諮詢。

它們的目的是適應大資料以及分析專家和需要他們所服務客戶的需求，包括大資料準備評估、路線圖、預測操作介面、演算法和一些針對特定市場和企業消費分析解決方案等等。如Palantir、營銷的大資料分析工具 Qubit、針對CRM領域的人工智慧Neokami等等。

為什麼Hadoop如此成功?

這個問題似乎是個馬後炮，但當我們今天驚歎於Hadoop在短短10年時間取得如此統治性地位的時候，確實會自然而然地思考為什麼這一切會發生。基於與同期其他專案的比較，我們認為有很多因素的綜合作用造就了這一奇蹟：

技術架構：Hadoop推崇的本地化計算理念，其實現在可擴充套件性、可靠性上的優勢，以及有彈性的多層級架構等都是領先其他產品而獲得成功的內在因素。沒有其他任何一個這樣複雜的系統能快速的滿足不斷變化的使用者需求。

硬體發展：摩爾定律為代表的scale up架構遇到了技術瓶頸，不斷增加的計算需求迫使軟體技術不得不轉到分散式方向尋找解決方案。同時，PC伺服器技術的發展使得像Hadoop這樣使用廉價節點組群的技術變為可行，同時還具有很誘人的價效比優勢。

工程驗證：Google發表GFS和MapReduce論文時已經在內部有了可觀的部署和實際的應用，而Hadoop在推向業界之前已經在Yahoo等網際網路公司驗證了工程上的可靠性和可用性，極大的增加了業界信心，從而迅速被接納流行。而大量的部署例項又促進了Hadoop的發展喝成熟。

社群推動：Hadoop生態一直堅持開源開放，友好的Apache許可基本消除了廠商和使用者的進入門檻，從而構建了有史以來最大最多樣化最活躍的開發者社群，持續地推動著技術發展，讓Hadoop超越了很多以前和同期的專案。

關注底層：Hadoop 的根基是打造一個分散式計算框架，讓應用程式開發人員更容易的工作。業界持續推動的重點一直在不斷夯實底層，並在諸如資源管理和安全領域等領域不斷開花結果，為企業生產環境部署不斷掃清障礙。

下一代分析平臺

過去的十年中Apache Hadoop社群以瘋狂的速度發展，現在儼然已經是事實上的大資料平臺標準。我們經歷了Hadoop實現這一願景的巨大進步，見證了Hadoop 如何從一個儲存和批處理架構慢慢轉變為一個現代化的、模組化的資料平臺。三年前，Hadoop通過Impala等分析型SQL引擎實現了互動的資料發現。

兩年前，Cloudera迎來了Apache Spark，並將其視為Hadoop生態系統的下一代資料處理層，能同時處理各種批次和流工作負載，為開發人員提供更好的易用性和更高的效能。

但仍有更多的工作要做!36大資料（http://www.36dsj.com/）

大資料應用未來的價值在於預測，而預測的核心是分析。下一代的分析平臺會是什麼樣呢?它必定會面臨、同時也必須要解決以下的問題：

1. 更多更快的資料。未來的大資料來源更多的是來自物聯網(IoT，Internet of Things)，將有超過160億的裝置聯網並不斷產生資料。資料量更大，而且對資料處理的實時性要求的更高。

2. 更新的硬體特性及架構。Hadoop、Spark等技術興起的重要推動原因都是硬體的發展。現在摩爾定律已經退出歷史舞臺，未來硬體架構可能呈現多樣化發展，可靠性越來越高，儲存和計算成本繼續降低，記憶體的容量和速度越來越快，持久化或非揮發性儲存的發展會對現有的儲存設計帶來新的技術和架構。

3. 更高階的分析。技術的發展背後總是業務需求的驅動。但現在的大資料專案多是初級階段的IT系統，目的是解決目前IT有限的能力限制和成本壓力，並非針對業務創造新的價值，甚至沒有對業務有直接互動和反饋。未來的需求是要使用實時資料建立更好的模型，使用機器學習等高階資料分析技術，能夠改善使用者體驗、優化業務運營，實現大資料業務的閉環。

4. 更安全。隨著企業希望能把手裡的資料資源開放變現，但頻發的安全事故又讓企業駐足不前，很少有人敢冒風險進行開放嘗試。需要通過安全機制實時地保護使用者和企業的資產;通過行為分析和稽查保證流程的正確性和結果的可信性。

因此，未來的幾年，我們會繼續見證“後Hadoop時代”的下一代企業大資料平臺：

1. 記憶體計算時代的來臨。隨著高階分析和實時應用的增長，對處理能力提出了更高的要求，資料處理重點從IO重新回到CPU。以記憶體計算為核心的Spark將代替以IO吞吐為核心的MapReduce成為分散式大資料處理的預設通用引擎。做為既支援批處理有支援準實時流處理的通用引擎，Spark將能滿足80%以上的應用場景。Cloudera公司近日公佈了One Platform的倡議，推動Spark成為Hadoop的預設資料處理引擎。為了最終取代MapReduce，Cloudera集中力量推動解決Spark現在企業大規模應用時在四個關鍵領域仍然存在的短板：管理，安全，規模和流。

然而，Spark畢竟核心還是批處理，擅長迭代式的計算，但並不能滿足所有的應用場景。其他為特殊應用場景設計的工具會對其補充，包括：

a) OLAP。OLAP，尤其是聚合類的線上統計分析應用，對於資料的儲存、組織和處理都和單純離線批處理應用有很大不同。以Impala為代表的SQL-on-Hadoop引擎借鑑了傳統資料處理和MPP等技術，底層使用HDFS儲存，是傳統BI系統很好的替代方案候選。

b) 知識發現。與傳統應用解決已知問題不同，大資料的價值在於發現並解決未知問題。因此，要最大限度地發揮分析人員的智慧，將資料檢索變為資料探索。Apache Solr專案是一個功能豐富的可擴充套件的搜尋解決方案，內包括了Apache Lucene和Apache Tika。Cloudera的Search將Solr整合到了Hadoop，並使用高度自動化的流水線為Hadoop上的資料建立索引，在提高部署效率的同時，提供了更加直觀方便的大資料平臺搜尋引擎。

2. 統一資料訪問管理。現在的資料訪問由於資料儲存的格式不同、位置不同，使用者需要使用不同的介面、模型甚至語言。同時，不同的資料儲存粒度都帶來了在安全控制、管理治理上的諸多挑戰。未來的趨勢是將底層部署運維細節和上層業務開發進行隔離，因此，平臺需要系統如下的功能保證：

a) 安全。能夠大資料平臺上實現和傳統資料管理系統中相同口徑的資料管理安全策略，包括跨元件和工具的一體化的使用者權利管理、細粒度訪問控制、加解密和審計。

b) 統一資料模型。通過抽象定義的資料描述，不僅可以統一管理資料模型、複用資料解析程式碼，還可以對於上層處理遮蔽底層儲存的細節，從而實現開發/處理與運維/部署的解偶。

Cloudera最近釋出的RecordService正是為此而生。Apache Sentry是Hadoop生態中負責跨元件統一訪問控制的安全解決方案。RecordService和Sentry等元件結合，提供了跨整個平臺的細粒度的統一訪問控制策略，消除了Hive、HBase等元件分散而差異的訪問粒度控制。

DFS執行的新的核心服務。同時RecordService遮蔽了底層儲存細節，向上暴露基於記錄的面向物件的資料描述，為程式設計人員提供了更好的封裝和抽象。

3. 簡化實時應用。現在使用者不僅關心如何實時的收集資料，而且關心同時儘快的實現資料可見和分析結果上線。無論是以前的delta架構還是現在lambda架構等，都希望能夠有一種解決快速資料的方案，使用HDFS和HBase的混合體，在快速更新資料的同時進行快速分析，然而結果複雜的架構令人望而卻步，無論開發還是運維都不勝其繁。

Cloudera最新公開的Kudu雖然還沒有進入產品釋出，但卻是現在解決這個問題可能的最佳方案：採用了使用單一平臺簡化了快速資料的“存取用”實現，是未來日誌類資料分析的新的解決方案。

最近新面世的這些專案將徹底改變Hadoop的儲存架構,進一步鞏固其安全基礎，推動Hadoop不斷髮展和擴大，成為新一代的現代分析的領先平臺。

下一個十年

Hadoop的未來是什麼樣的?10年以後大資料是不是已經進博物館了?會不會有一個新公司成為資料管理界的新的巨頭，猶如今日的Oracle?會不會有高富帥的企業已經有百萬、千萬甚至更多機器組成的資料中心?

有許多的可能，但我們相信Hadoop所“發明”的分散式計算框架仍然會是大資料的核心標誌。

10 年前誰也沒有料想到 Hadoop 能取得今天這樣的成就，而如今一切均在眼前。Hadoop 之父 Doug Cutting 則認為 Hadoop 正處於蓬勃的發展期，而且這樣的蓬勃發展至少還可以持續幾十年。

10年以後的Hadoop應該只是一個生態和標準的“代名詞”了，下層的儲存層不只是HDFS、HBase和Kudu等現有的儲存架構，上層的處理元件更會像app store裡的應用一樣多，任何第三方都可以根據Hadoop的資料訪問和計算通訊協議開發出自己的元件，使用者在市場中根據自己資料的使用特性和計算需求選擇相應的元件自動部署。

當然，有一些明顯的趨勢必然影響著Hadoop的前進：

雲端計算36大資料（http://www.36dsj.com/）

現在50%的大資料任務已經執行在雲端，在3年以後這個比例可能會上升到80%。Hadoop在公有云的發展要求更加有保障的本地化支援。

硬體36大資料（http://www.36dsj.com/）

快速硬體的進步會迫使社群重新審視Hadoop的根基。回顧歷史，任何一次硬體的革新都會翻開軟體業的新篇章。現在CPU發展摩爾定律已經退出歷史舞臺，但新型的硬體，如3D point等即將登場企業資料中心。現在雖然尚未有與之相應的軟體產品，但必然會出現，而Hadoop社群也絕不會袖手旁觀。

物聯網

物聯網的發展會帶來海量的、分佈的和分散的資料來源。Intel CEO預測2020年將有500億裝置聯網，會帶來50萬億GB的資料;世界經濟論壇預測2022年將有1萬億感測器入網;按照梅特卡夫定律，5年後全球IoT自動服務網的總體價值將是現在的517倍。Hadoop將適應這種發展。

以後的十年會發生什麼?以下是筆者的一些猜想：

1. SQL和NoSQL市場會合並，NewSQL和Hadoop技術相互借鑑而最終走向統一，Hadoop市場和資料倉庫市場會合並，然而產品碎片化會繼續存在。

2. Hadoop與其他資源管理技術和雲平臺整合，融合docker和unikernal等技術統一資源排程管理，提供完整多租戶和QoS能力，企業資料分析中心合併為單一架構。

3. 企業大資料產品場景化。以後直接提供產品和技術的公司趨於成熟並且轉向服務。越來越多的新公司提供的是行業化、場景化的解決方案，如個人網路徵信套件以及服務。

4. 大資料平臺的場景“分裂”。與現在談及大資料言必稱Hadoop以及某某框架不同，未來的資料平臺將根據不同量級的資料(從幾十TB到ZB)、不同的應用場景(各種專屬應用叢集)出現細分的階梯型的解決方案和產品，甚至出現定製化一體化產品。

無論10年或20年後的Hadoop看起來像什麼樣，無可質疑的是由於資料量、資料種類和資料速度的提升會帶來更強大的使用用例。

如何把原始資料轉化為可執行的洞察力將是最清晰最有力的推動力量。

正如Cloudera的首席科學家、Hadoop的創始人Doug Cutting所說：“我們在本世紀取得的大部分進展將來自於對所產生的資料的理解的增加。”

後記

筆者水平有限，加之時間緊迫，膚淺粗糙之處，還請各位讀者原諒和指教。文中有些內容引自網路，某些出處未能找到，還請原作者原諒。

Hadoop的元件生態元件太多，參加Cloudera的全套Hadoop課程就需要花費1個月以上的時間，讓人“累覺不愛”。本文中只是蜻蜓點水，很多東西尚未詳述，請參見相關產品手冊。