編者按：Hadoop於2006年1月28日誕生，至今已有10年，它改變了企業對數據的存儲、處理和分析的過程，加速了大數據的發展，形成了自己的極其火爆的技術生態圈，並受到非常廣泛的應用。在2016年Hadoop十歲生日之際，InfoQ策劃了一個Hadoop熱點系列文章，爲大家梳理Hadoop這十年的變化，技術圈的生態狀況，回顧以前，激勵以後。本文整理自去年4月份的QCon大會演講“以Hadoop爲核心的大數據開放平臺建設”。
大數據發展趨勢
大概在08年左右，Hadoop從Nuch裏的一個package開始的獨立出來，不斷的被大家所關注，它本身不斷的進化，包括對壓縮算法的Native實現，Checksum機制的優化，還有ShortCircuit Read（支持直接文件的內置的短讀），這算是讀取性能的優化。在這些不斷的優化下，Hadoop逐漸變得健壯。Hadoop的2.3版本，是一個架構上的根本變化，把資源管理提到了一個很高的高度，就是我們新一代的Yarn&Mapreduce2.0。還有一個HDFS上的架構優化，就是NameNode Federation。NameNode分佈式管理，可以極大的增進機羣的可擴展性。
Hadoop本身不斷完善，圍繞着Hadoop的生態系統也在不斷的完善，像Oozie，就是與Hadoop結合非常緊密的一個工作流引擎；Flume是圍繞Hadoop的日誌收集類的ETL工具；Hive是一個SQL On Hadoop的實現，也是最早的一個實現，現在已經有很多了；Pig類似Hive，但是是一個內置腳本、有自己獨立語法，相對來說是一個優化版的Hive實現。但是它的語法，相對來說要比Hive性能高一些，在Facebook內部使用比較多。另外Cloudera推出了SQL On Hadoop的Impala的實現。另外還有Spark 也是新興的一個內存計算模型的技術。
大數據技術應用，困難何在？
圍繞着Hadoop的周邊的生態系統在不斷的完善，運維管理工具上也得到了極大的進展。因爲在早期，大家部署一個Hadoop系統會非常麻煩；從08年到現在，我經歷過大大小小的系統，自建的，內建的，包括公司各種平臺項目裏面建的，不計其數，特別的辛苦。包括腳本，權限設置，一些目錄權限的設置，安裝一個系統大概要半天左右到一天左右時間。非常熟練之後也要半天左右時間。現在像Apache Ambari，Cloudera Manager，已經把整個機羣的部署變得非常簡單，基本上幾分鐘就能把我們需要花幾十分鐘的機羣部署起來，甚至是一個幾十臺機器規模的機羣。
大數據技術在不斷的發展，但是它還是有些天生的不足。首先是技術本身在百花齊放，生態系統裏面的技術在不斷的完善，包括Hadoop，Hive，Spark等等，那麼就會存在選擇上的困難--如何應用好每一項技術，就是一個難題。另外，大數據技術本身內部的融合性也是不太夠的。現在有一種趨勢，每一個開源工具都在強調自己的性能有多好，都想圍繞着自己去建立生態系統。另外就是怎麼合理的使用這些技術。比如說我們以前的系統是圍繞着一種技術建立的，然後又引入了一個新的技術，兩個技術怎麼實現融合，這就是一個很大的難題。
另外一個就是大數據技術與其他傳統技術的融合性不夠。傳統技術，比如以前使用的數據庫，一些其他的服務，Solr檢索服務什麼的，也沒有成熟的融合方案。在實踐中會比較陌生，沒有一套成熟的體系支撐。你可能需要去翻很多的文檔，自己做很多開發，才能實現這些功能。那麼我們現在缺少什麼呢？缺少一個能融合現有大數據技術的技術，這個真的是非常非常關鍵的。
技術領域是怎麼來面對這個問題的？
大概在13年，Doug cutting做過一次技術分享，The State of the Apache，這個文檔大家可以在百度百庫上可以檢索到。他當時提出了一個概念叫Apache Hadoop Ecosystem。Ecosystem，E應該是代表Easy，CO是Cross，System系統平臺。這在他的論文裏面摘錄的幾句關鍵的話。
文檔本身的介紹非常簡單，寥寥幾頁，但很經典。我覺得他說得非常在點子上。我的解讀，這個總體來說應該是這樣一個思想：以Hadoop爲核心，融合其他技術的平臺級系統，Avro將是實現融合技術的關鍵技術。
在行業內，Cloudera應該是Hadoop就是圍繞着大數據Big Data這種解決方案的一個國外很有影響力的一個公司。Cloudera是在做Hadoop的應用體現，想讓Hadoop越來越容易被大家所應用。他提供了兩個解決方案。首先，建立了Hue這套系統，提出Use Hadoop with Hue。另外就是Administer Hadoop，就是運維管理Hadoop。建立了叫Cloudera Manager這一整套的工具。像Hue和Administer已經是說解決了兩方面的問題，Hue用來調度管理任務。Administer是管理和運維平臺。
這是Cloudera給出的答案，在科大訊飛的實際開發過程中，我們是怎麼應付和解決這些難題的呢？我們圍繞着Doug Cutting提出的ECoSystem的思想上，我們也開始逐漸建立自己的大數據開放平臺Maple。
我們的實現以數據導向爲理念。數據導向爲理念是一個思想。以前我們在做一件事情的時候都會考慮，做這件事情要使用什麼樣的技術。因爲首先大數據是圍繞着數據去做的，很多時候會偏離數據，而去考慮很多技術的細節問題。但是在做實際業務開發的過程中，我們需要圍繞着數據去想問題，而不是圍繞着技術去想問題，這就是需要數據導向爲理念。我們所有的業務開發圍繞着數據，數據是什麼樣的，我們就怎麼處理。整個系統平臺是以Hadoop爲核心，這也是符合Doug Cutting提出的EcoSystem的思想。
最後我們提出了以EcoSystem設計理念，以Hadoop爲核心，融合優秀的技術，因地制宜的使用技術。綜合來看，每個技術都有它的特長，因地制宜的使用技術，才能讓這個技術得到更好的發揮。我們還需提升大數據的應用體驗。如果你是早期接觸的話，在它上面開發任務，提交任務，整個的流程管理是相當複雜的。
科大訊飛的大數據平臺
我們大數據開放平臺分成三部分。1.基礎機羣，圍繞着Cloudera發行版本CDH來構建的。2.我們上層構建了自己的Maple SDK，是面向開發者提供的開發包。3.是Maple BDWS。
大數據平臺的整個的架構。
從上層的應用層到ETL層，到我計算和存儲層，這是整個的數據流。以這個上面的這些設計爲基礎開展大數據開放平臺的工作。非常的值得去借鑑是我們架構上不僅定義了數據流向，也定義了開發的過程，Maple BDWS應該是我們整個大數據開放平臺的一個門戶，解決代碼託管，編譯部署，工作流設計，任務調度，數據和任務信息瀏覽。特性：支持多集羣管理，支持多版本Hadoop，支持多項目管理，在線編譯部署（one button to use）。整個平臺是用Python去做的，支持了Python擴展。可以在線的測試和運行Python的代碼。
Maple BDWS是我們整個大數據開放平臺的一個門戶，Maple SDK就是我們整個大數據開放平臺的靈魂。
在設計SDK的時候，我們的目標是爲了實現Integration Technical，就是融合技術，希望能把各種技術都提供一種標準的開發方式，開發模板。通過在實踐中應用成熟以後，把開發模式，融合的編碼規範分享出去。圍繞着SDK，我們融合了Hbase，oozie，Flume、Avro這樣的技術。SDK裏面包含一套數據建模的功能，基於Avro的Mapreduce編程庫。還有一套Flume-ng的擴展組件。統計分析也是一個常見的業務，Maple-Report是一個統計分析解決方案。另外還含有一個分佈式索引的庫，叫Maple-Index。大數據建模系統Data Source，適用於大數據的動態自動建模系統。
實現技術融合的關鍵
用大數據的眼光看數據，會跟平常我們看數據會有什麼不同呢？用大數據的眼光看數據，會發現數據會分成兩種基本屬性。一個是Schema，一個是Partition。在Partition和Scheam下應該支持多種文件的數據存儲格式，包括文本格式，Avro格式，列存儲，數據庫文件。
Avro是融合整個技術的關鍵，在我們內部大量使用了Avro的數據存儲格式。我們要圍繞着DataSource去建立數據導向的API，提供一個清洗過程的API。另外提供兩個DataSource實現Merg和Join的功能。還圍繞DataSource實現跟外部數據這種交互。建立了HiveQL On Datasource這樣的API，支持Spark去Load處理，Impala On Datasource，Pig On Datasource等。
瞭解Avro可以看官網的Introduction。Avro經常會被跟Thrift和Protobuf這兩個序列化系統做比較。因爲Avro本身也是一個序列化系統。那麼我們就要提出一個問題，在Thrift和Protobuf已經很成熟的這種基礎上，爲什麼要選擇Avro？在08年，10年左右，我關注這個項目，後來發現所有的代碼的提交修改記錄，全是Doug Cutting，裏面有90%的工作都是Doug Cutting本人去做的。Doug Cutting早期是Lucene的項目的創始人，也是Hadoop的創始人，一手把Hadoop開源項目帶起來，甚至都是他親身去開發的。他花費那麼多精力去搞Avro，必有其獨到之處。
Avro開發中代碼生成是可選的，這是一個跟其他系統，就是跟Thrift和Protobuf有很大區分的一個特性。另外Avro支持通用數據讀取，不依賴於代碼生成。有了這兩個特性，Avro就更能適應大數據變化的特性。Doug Cutting當時是在Thrift和Protobuf很成熟的基礎上開始着手建立Avro的，是非常有想法的。
Avro在訊飛大數據開放平臺的應用
首先我們有一套Avro-Mapreduce編程框架，圍繞Avro這種Mapreduce開發。Avro爲整個Mapreduce過程提供了高性能的數據系列化，是在整個Mapreduce生命週期裏面一個非常關鍵的環節，也是非常影響性能的。Avro-Mapreduce是一個簡化的，面向對象的，富於設計的Mapreduce編程庫。支持Generic、Specific、Reflect三種模式。
Avro還用在整個大數據的數據存儲上，這種數據存儲是支持通用數據讀寫，支持多語言讀取，內置了很多的壓縮算法。因爲它內置了很多壓縮算法，我們可選，如果適當選擇壓縮算法，它與傳統的文本相比，同樣的內容可以節省10倍的空間，這個也是非常關鍵的。它還有更高的讀取性能，因爲它有內置的壓縮，比較精簡，它的序列化性能又很高，所以這個數據讀取的性能非常高，這是我們現在目前Avro在數據存儲上的應用。我們Avro還用在數據收集的環節。我們在數據收集上也支持多語言的開發，因爲前端的應用有很多，包括PHP，Java，還有C等各種語言。
另外，我們以Flume-ng融合，實現了結構化的日誌收集。Avro提供了這種對結構化數據格式的支持，可以更高效的傳輸數據。
下面說一些我們融合技術的一些具體案例。我們依賴於Flume+Avro實現了內部的ETL方案，分佈式結構化日誌收集。目前我們部署的節點已經超過了一千個，每天數據的收集超過上千億。我們用Avro封裝了FlumeEvent，實現了結構化日誌收集。以前在Log中大部分日誌都是文本，但是現在支持Log自定義的數據結構體。另外也支持一些通用的Array或者Map等這種數據類型。我們得益於Avro，它傳輸數據更簡潔，速度更快。現在我們每天的千億數據都通過這種方式實時收集。在數據收集階段，我們還要注意一些流處理與其他系統去做對接。Flume-ng提供了一個支持二次開發的SDK，方便業務類功能擴展。
圍繞Flume-ng的優化
圍繞着Flume-ng還做了很多的優化工作，其實我們在一開始做技術選型的時候，Flume-ng當時還不太成熟，也遇到了很多問題。我們沒有放棄，比如說我們以AvroFile爲緩存，實現了一個新的File ChannelPlus，極大的提升了速度和穩定性。它本身的File ChannelPlus，出於安全和可靠性的保障，性能比較差，並且經常出問題。後來我們就重寫了一個File ChannelPlus。現在FileChannelPlus吞吐基本上達到每秒鐘6萬左右的TPS。
我們還改進了HDFS的端的存儲接口，支持了Stable。我們數據收集上來要跟後面的數據處理流程要做對接。如果數據在接收並且在寫一個文件的過程中，後面永遠不會知道這個數據什麼時候該處理。所以我們在這個Sink上實現了一個Stable的機制，數據會定時的被放到一個Stable的目錄，讓這些數據變成可處理的狀態。後面就會寫觸發條件去處理Stable的數據，就跟傳輸層能做一個很好的隔離。
另外我們還實現了分佈式的節點監控和智能的配置管理服務，就是因爲Flume-ng配置非常靈活，在上千個節點的部署上管理起來是非常麻煩的，那麼我們實現了一個整個的配置管理中心服務，然後彌補了Flume-ng配置管理複雜上的這些問題。如果大家在實際開發過程中應用Flume的話，應用層應該是沒有什麼問題的，如果大家遇到什麼樣的問題，可以按照我們的思路，嘗試着對它進行擴展。
日誌收集系統Loglib，用了Flume、Avro和Solr技術，實現了我們的分佈式的實時日誌檢索的。我們每天的日誌的索引量超過15個億，一天的獨立的索引記錄數超過15個億，支持幾個月的記錄，最近又改成了兩個月。我們每天保證15億的索引的穩定。另外我們做到了即用即搜。
開放平臺統計分析
接下面來介紹核心的語音項目Sunflower，語音雲統計分析平臺，和開放統計分析平臺，是用什麼技術來融合去做的呢？我們用了Datasource + Avro-Mapreduce + Spark，來實現了語音雲統計分析系統和開放統計分析系統。最一開始，我們面臨的問題是日兩億次PV，現在語音的服務量大概在兩億次左右。我們要每天在這個數據量上做大概7大類，50多個小的類的統計工作，綜合指標大概有上千個左右。最開始，我們嘗試基於Hive去實現這樣的統計分析工作，後來我們發現通過分解所有的需求，分解出來的Sql語句都有上千句，運行非常緩慢。我們又嘗試基於Pig，但是Pig的腳本也有幾百行，執行速度也非常慢。我們開始對分佈式技術進行一些思考，爲什麼Hive和Pig會這麼慢？根本點在什麼？因爲我們有很多的指標，很多緯度。在指標和維度分解出來以後會形成很多的Pig和Hive語句。每個語句在執行的時候，都要對數據進行Load，進行分佈式處理。同一份數據被反覆的Load，非常耗費時間。對同一份數據的不同緯度和指標的統計分析，能否一次完成任務？計算結果的中間數據是否能夠被重複利用？根據小時報表，其實可以重新計算出來日報表。我們圍繞這些優化方向，形成了我們新的一個Maple-Report，全新的統計分析解決方案。
我們通過報表定義與計算的分離，實現了多引擎的支持。Report Engine目前支持Avro-MapReduce，依賴於Mapreduce這樣分佈式計算的實現，還有Spark這樣的更高速的實現，依賴於內存的實現。我們也真正的實現了同數據源的多維度，多指標，一次性計算完成，小時日週數據可以循環依次利用。20分鐘左右就能得到日誌報表，同樣週報表得到的時間也非常短，月報表，甚至半年報表也沒有什麼困難。Maple-Report綜合解決方案，我們上線運行很長時間了。語音雲統計分析系統，和開放統計分析系統，都是依賴於我們這套方案去做的。
整個Maple承載着公司級的大數據戰略，像現在整個雲平臺
、研究院、平嵌、移動互聯和智能電視，都通過我們的Maple平臺進行數據和技術的共享。另外，我們面向互聯網的好多產品，包括訊飛開放平臺、語音輸入法、靈犀、酷音鈴聲，所有的數據均彙集到了Maple開放平臺。然後很多小組都使用這個系統去分享挖掘數據。整個系統還在不斷的發展中，公司整個戰略是要把所有的產品線上的數據都彙集到一個平臺上，將來能夠都提供技術&數據分享，能夠深入的挖掘數據的價值。
總結致敬
最後我想發表一些感慨，向那些以Doug Cutting爲代表的，依然耕耘在技術前線，勤於Coding的前輩表示敬意。他們的分享和貢獻精神，帶給了我們實實在在的大數據技術。國內有一個很不好的一個想法，我也聽過很多人講，就是我多少多少歲以後就不做開發了。其實這個思想，我覺得大家應該適當的有些改變，應該以前輩爲表率，去學習他們那種無論到什麼時候，都能埋頭去Coding這種精神！我到現在也在做Coding的一些事情，這是我們需要在整個技術上面需要形成這種風氣。
演講嘉賓
孫利兵,科大訊飛雲平臺研發部資深大數據架構師，早期就曾接觸Hadoop分佈式計算技術，對Mapreduce分佈式計算亦有很深刻的理解。精通Avro技術，在2008年曾編寫了應用於實際環境的AvroMapreduce編程庫，對Doug Cutting的以Hadoop爲核心，Avro爲關鍵技術的EcoSystem構想非常向往，並推進在科大訊飛雲計算組工作中進行實踐，打造了Maple（大數據開放平臺）。
感謝杜小芳對本文的策劃和審校。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至[email protected]。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關注我們。