一篇文看懂Hadoop

咱們很榮幸可以見證Hadoop十年從無到有，再到稱王。感動於技術的突飛猛進時，但願經過這篇內容深刻解讀Hadoop的昨天、今天和明天，憧憬下一個十年。

• 本文分爲技術篇、產業篇、應用篇、展望篇四部分

　　技術篇

　　

　　2006年項目成立的一開始，「Hadoop」這個單詞只表明了兩個組件——HDFS和MapReduce。到如今的10個年頭，這個單詞表明的是「核心」（即Core Hadoop項目）以及與之相關的一個不斷成長的生態系統。這個和Linux很是相似，都是由一個核心和一個生態系統組成。

　　如今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等等

　　

　　存儲層

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

　　隨着HDFS愈來愈穩定，社區的活躍度也愈來愈低，同時HDFS的使用場景也變得成熟和固定，而上層會有愈來愈多的文件格式封裝：列式存儲的文件格式，如Parquent，很好的解決了現有BI類數據分析場景；之後還會出現新的存儲格式來適應更多的應用場景，如數組存儲來服務機器學習類應用等。將來HDFS會繼續擴展對於新興存儲介質和服務器架構的支持。

　　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市場向傳統數據倉庫市場靠攏。

　　Apache Arrow項目爲列式內存存儲的處理和交互提供了規範。目前來自Apache Hadoop社區的開發者們致力於將它制定爲大數據系統項目的事實性標準。

　　

　　Arrow項目受到了Cloudera、Databricks等多個大數據巨頭公司支持，不少committer同時也是其餘明星大數據項目（如HBase、Spark、Kudu等）的核心開發人員。再考慮到Tachyon等彷佛尚未找到太多實際接地氣的應用場景，Arrow的高調出場可能會成爲將來新的內存分析文件接口標準。

　　管控層

　　管控又分爲數據管控和資源管控。

　　隨着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。

• 同一月，IBM開源SystemML併成爲Apache官方孵化項目。

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

• 2015年12月，Facebook開源針對神經網絡研究的服務器「Big Sur」，配有高性能圖形處理單元（GPUs），轉爲深度學習方向設計的芯片。

　　產業篇

　　如今使用Hadoop的企業以及靠Hadoop賺錢的企業已經成千上萬。幾乎大的企業或多或少的已經使用或者計劃嘗試使用Hadoop技術。就對Hadoop定位和使用不一樣，能夠將Hadoop業界公司劃分爲四類：

• 第一梯隊：這類公司已經將Hadoop看成大數據戰略武器。

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

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

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

　　

　　時至今日，Hadoop雖然在技術上已經獲得驗證、承認甚至已經到了成熟期。其中最能表明Hadoop發展軌跡的莫過於商業公司推出的Hadoop發行版了。自從2008年Cloudera成爲第一個Hadoop商業化公司，並在2009年推出第一個Hadoop發行版後，不少大公司也加入了作Hadoop產品化的行列。

　　「發行版」這個詞是開源文化特有的符號，看起來任何一個公司只要將開源代碼打個包，再多多少少加個佐料就能有一個「發行版」，然而背後是對海量生態系統組件的價值篩選、兼容和集成保證以及支撐服務。

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

• 而以後的公司更可能是工具、集成、管理，所提供的不是「更好的Hadoop」而是如何更好的用好「現有」的Hadoop。

• 2014年之後，隨着Spark和其餘OLAP產品的興起，折射出來是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。

　　

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

　　應用篇

　　Hadoop平臺釋放了史無前例的計算能力，同時大大下降了計算成本。底層核心基礎架構生產力的發展，必然帶來的是大數據應用層的迅速創建。

　　對於Hadoop上的應用大體能夠分爲這兩類：

　　IT優化

　　將已經實現的應用和業務搬遷到Hadoop平臺，以得到更多的數據、更好的性能或更低的成本。經過提升產出比、下降生產和維護成本等方式爲企業帶來好處。

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

• 歷史日誌數據在線查詢：傳統的解決方案將數據存放在昂貴的關係型數據庫中，不只成本高、效率低，並且沒法知足在線服務時高併發的訪問量。以HBase爲底層存儲和查詢引擎的架構很是適合有固定場景（非ad hoc）的查詢需求，如航班查詢、我的交易記錄查詢等等。如今已經成爲在線查詢應用的標準方案，中國移動在企業技術指導意見中明確指明使用HBase技術來實現全部分公司的清帳單查詢業務。

• ETL任務：很多廠商已經提供了很是優秀的ETL產品和解決方案，並在市場中獲得了普遍的應用。然而在大數據的場景中，傳統ETL遇到了性能和QoS保證上的嚴重挑戰。多數ETL任務是輕計算重IO類型的，而傳統的IT硬件方案，如承載數據庫的小型計算機，都是爲計算類任務設計的，即便使用了最新的網絡技術，IO也頂多到達幾十GB。

  　　採用分佈式架構的Hadoop提供了完美的解決方案，不只使用share-nothing的scale-out架構提供了能線性擴展的無限IO，保證了ETL任務的效率，同時框架已經提供負載均衡、自動FailOver等特性保證了任務執行的可靠性和可用性。

• 數據倉庫offload：傳統數據倉庫中有不少離線的批量數據處理業務，如日報表、月報表等，佔用了大量的硬件資源。而這些任務一般又是Hadoop所善長的

　　常常被問到的一個問題就是，Hadoop是否能夠代替數據倉庫，或者說企業是否可使用免費的Hadoop來避免採購昂貴的數據倉庫產品。數據庫界的泰斗Mike Stonebroker在一次技術交流中說：數據倉庫和Hadoop所針對的場景重合型很是高，將來這兩個市場必定會合並。

　　咱們相信在數據倉庫市場Hadoop會早晚替代到如今的產品，只不過，那時候的Hadoop已經又不是如今的樣子了。就如今來說，Hadoop還只是數據倉庫產品的一個補充，和數據倉庫一塊兒構建混搭架構爲上層應用聯合提供服務。

　　

　　業務優化

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

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

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

　　爲何Hadoop如此成功？這個問題彷佛是個馬後炮，但當咱們今天驚歎於Hadoop在短短10年時間取得如此統治性地位的時候，確實會天然而然地思考爲何這一切會發生。基於與同期其餘項目的比較，咱們認爲有不少因素的綜合做用造就了這一奇蹟：

• 技術架構：Hadoop推崇的本地化計算理念，其實如今可擴展性、可靠性上的優點，以及有彈性的多層級架構等都是領先其餘產品而得到成功的內在因素。沒有其餘任何一個這樣複雜的系統能快速的知足不斷變化的用戶需求。

• 硬件發展：摩爾定律爲表明的scale up架構遇到了技術瓶頸，不斷增長的計算需求迫使軟件技術不得不轉到分佈式方向尋找解決方案。同時，PC服務器技術的發展使得像Hadoop這樣使用廉價節點組羣的技術變爲可行，同時還具備很誘人的性價比優點。

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

• 社區推進：Hadoop生態一直堅持開源開放，友好的Apache許可基本消除了廠商和用戶的進入門檻，從而構建了有史以來最大最多樣化最活躍的開發者社區，持續地推進着技術發展，讓Hadoop超越了不少之前和同期的項目。

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

　　下一代分析平臺

　　過去的十年中Apache Hadoop社區以瘋狂的速度發展，如今儼然已是事實上的大數據平臺標準。但仍有更多的工做要作！大數據應用將來的價值在於預測，而預測的核心是分析。下一代的分析平臺會是什麼樣呢？它一定會面臨、同時也必需要解決如下的問題：

1. 更多更快的數據。

2. 更新的硬件特性及架構。

3. 更高級的分析。

4. 更安全。

　　所以，將來的幾年，咱們會繼續見證「後Hadoop時代」的下一代企業大數據平臺：

1. 內存計算時代的來臨。隨着高級分析和實時應用的增加，對處理能力提出了更高的要求，數據處理重點從IO從新回到CPU。之內存計算爲核心的Spark將代替以IO吞吐爲核心的MapReduce成爲分佈式大數據處理的缺省通用引擎。作爲既支持批處理有支持準實時流處理的通用引擎，Spark將能知足80%以上的應用場景。

   　　然而，Spark畢竟核心仍是批處理，擅長迭代式的計算，但並不能知足全部的應用場景。其餘爲特殊應用場景設計的工具會對其補充，包括：

   　　a) OLAP。OLAP，尤爲是聚合類的在線統計分析應用，對於數據的存儲、組織和處理都和單純離線批處理應用有很大不一樣。

   　　b) 知識發現。與傳統應用解決已知問題不一樣，大數據的價值在於發現並解決未知問題。所以，要最大限度地發揮分析人員的智能，將數據檢索變爲數據探索。

2. 統一數據訪問管理。如今的數據訪問因爲數據存儲的格式不一樣、位置不一樣，用戶須要使用不一樣的接口、模型甚至語言。同時，不一樣的數據存儲粒度都帶來了在安全控制、管理治理上的諸多挑戰。將來的趨勢是將底層部署運維細節和上層業務開發進行隔離，所以，平臺須要系統以下的功能保證：

   　　a) 安全。可以大數據平臺上實現和傳統數據管理系統中相同口徑的數據管理安全策略，包括跨組件和工具的一體化的用戶權利管理、細粒度訪問控制、加解密和審計。

   　　b) 統一數據模型。經過抽象定義的數據描述，不只能夠統一管理數據模型、複用數據解析代碼，還能夠對於上層處理屏蔽底層存儲的細節，從而實現開發/處理與運維/部署的解偶。

3. 簡化實時應用。如今用戶不只關心如何實時的收集數據，並且關心同時儘快的實現數據可見和分析結果上線。不管是之前的delta架構仍是如今lambda架構等，都但願可以有一種解決快速數據的方案。Cloudera最新公開的Kudu雖然尚未進入產品發佈，但倒是如今解決這個問題可能的最佳方案：採用了使用單一平臺簡化了快速數據的「存取用」實現，是將來日誌類數據分析的新的解決方案。

　　翹首展望，下一個十年

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

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

• 雲計算

　　如今50%的大數據任務已經運行在雲端，在3年之後這個比例可能會上升到80%。Hadoop在公有云的發展要求更加有保障的本地化支持。

• 硬件

　　快速硬件的進步會迫使社區從新審視Hadoop的根基，Hadoop社區毫不會袖手旁觀。

• 物聯網

　　物聯網的發展會帶來海量的、分佈的和分散的數據源。Hadoop將適應這種發展。

　　之後的十年會發生什麼？如下是筆者的一些猜測：

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

2. Hadoop與其餘資源管理技術和雲平臺集成，融合docker和unikernal等技術統一資源調度管理，提供完整多租戶和QoS能力，企業數據分析中心合併爲單一架構。

3. 企業大數據產品場景化。之後直接提供產品和技術的公司趨於成熟而且轉向服務。愈來愈多的新公司提供的是行業化、場景化的解決方案，如我的網絡徵信套件以及服務。

4. 大數據平臺的場景「分裂」。與如今談及大數據言必稱Hadoop以及某某框架不一樣，將來的數據平臺將根據不一樣量級的數據（從幾十TB到ZB）、不一樣的應用場景（各類專屬應用集羣）出現細分的階梯型的解決方案和產品，甚至出現定製化一體化產品。

　　後記

　　如今Hadoop儼然已經成爲企業數據平臺的「新常態」。咱們很榮幸可以見證Hadoop十年從無到有，再到稱王。在咱們感動於技術的突飛猛進時，但願能經過本文能爲Hadoop的昨天、今天和明天作出一點本身的解讀，算是爲Hadoop慶祝10歲生日獻上的禮物。

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

　　大數據的明天是美好的，將來Hadoop必定是企業軟件的必備技能，但願咱們能一塊兒見證。

　　老司機介紹

　　陳飈，Cloudera售前技術經理、行業領域顧問、資深方案架構師，原Intel Hadoop發行版核心開發人員。2006年加入Intel編譯器部門從事服務器中間件軟件開發，擅長服務器軟件調試與優化，曾帶領團隊開發出世界上性能領先的 XSLT 語言處理器。2010 年後開始Hadoop 產品開發及方案顧問，前後負責Hadoop 產品化、HBase 性能調優，以及行業解決方案顧問，已在交通、通訊等行業成功實施並支持多個上百節點Hadoop 集羣。