CSDN雲計算俱樂部：Hadoop技術開發與應用實踐分享

大資料的火爆已不容置疑，在本次Hadoop技術開發與應用實踐分享會上，加座、站票已經完全解決不了問題，工作人員不得不臨時設立兩個會場，滿足更多參會人員與講師面對面溝通的機會。

本次CSDN雲計算俱樂部邀請到了Hadoop大資料紅象雲騰公司創始人童小軍、上海寶信高級工程師汪振平及智聯招聘高級工程師李尤，對Hadoop與大資料上的實踐做出了深度分享。

童小軍：Hadoop原理、適用場景及核心思想

童小軍，EasyHadop 社區創始人、原暴風影音平臺研發經理；國內首位獲得美國Cloudera公司Apache Hadoop開發工程師（CCDH）認證考試）；中科院、工信部外聘Hadoop專家講師；RedHadoop 紅象雲騰 創始人&首席架構師；多次在中國CIO年會、阿裡雲大會、北大CIO論壇發表大資料演講，更是Data Wis 大資料Hadoop專家。 在本次的大資料沙龍上，第一個發表了演講。

Hadoop使用原理

Hadoop市場正在快速的發展，甚至在銀行、電信各方面已經開始嘗試。 而童小軍則主要從以下3個方面對Hadoop進行了剖析：

Hadoop原理、工作原理和工作機制

已證實及有待測試和探索的場景

實際用例

童小軍集合了EasyHadop社區與RedHadoop（初創公司）的實踐，描述了Hadoop、大資料、雲計算之間的緊密聯繫：

1.  誕生的新資料服務：類似百度、騰訊、阿裡雲等大公司，通過Hadoop這樣平臺構建更大的資料平臺，收集資料進行分析，並通過其它方式推送出去，也就是資料服務的理念。

2.  雲計算帶來競爭力：本質上其實是一種資料的開放。 對比傳統資料庫，可以更好的進行個體分析，而Hadoop也正是做到了這一點。

Hadoop與舊平臺的對比

大資料技術理念核心主要分為兩個部分：虛擬化技術和類似Hadoop的技術。 同樣也是兩個對立面，虛擬化更注重于將資源打造成一個大型機，而Hadoop恰恰相反，將各種資源池化。 非Hadoop平臺系統，均屬核心的業務系統，比如代表性IOE，下面將分說兩種系統的優劣：

大型機：穩定性、源質性高，IO能力極強，可以管理較多的磁片及資料資源，CPU數量也佔優勢。 當然這裡面，限制在於機器間傳輸，存儲和內核需要共同頻寬。 機器間的相互傳輸導致大量磁片IO，從而造成磁碟瓶頸，同樣頻寬也很成問題。 同時多CPU利用差的問題也暴露無遺，總體來說IO成為整個系統的瓶頸所在。

Hadoop：化整為零，檔被切開到不同層面，將計算移動到所在資料的節點上，通過節點實現並行化IO，因此需要掛很多層。 而Map Reduce任務的數量跟CPU核數捆綁，因此CPU核數越多，Map配置就越快。 通過移動計算取代移動資料，以獲得更高的IO，這正是大資料存在的意義。

在本節中，童小軍以求和等例子入手，更詳細剖析了MapReduce的運行機制，同時還講解了HBase的作用和功能。

Hadoop適用場景

童小軍認為當下Hadoop的主要應用場景在歸檔、搜尋引擎（老本家）及資料倉儲上面，各個機構使用Hadoop不同的元件來實現自己的用例。 而在這3個場景之外還有一個比較冷門的場景——流處理，這塊源于Hadoop 2.0可結合其他框架的特性，而在將來，Hadoop肯定會發展到連線資料處理。

Hadoop核心思想

Hadoop平臺是能夠推動企業內部的資料開放，能夠讓每個人參與到報表、資料的研發過程。 能夠實現企業的資料共用，特別是Hadoop佇列，資源池，佇列，任務調度器的機制，能讓整個機型切換成多個資源，而不是以前的資料庫，一層層的隔離去使用。 最後，童小軍還從實際出發，對多個實踐進行了講解。

汪振平：基於Hadoop日誌交易平臺的架構及挑戰

上海寶信高級工程師汪振平從金融行業入手，從背景、需求與目標、問題、系統架構及其它Hadoop相關知識5個方面對基於Hadoop的日誌交易平臺進行深度分享：

背景

使用場景：信用卡消費的延時、交易失敗和失敗的原因及類型、不規範交易機構和商戶的尋找與產生原因。

資料特徵：在資料量上，每天近3億筆交易日誌；在資料狀態上，目前僅存儲擬合後的交易，對原始交易日誌不可用。

需求與目標：交易日誌的秒級查詢、交易失敗分析、不合規交易分析、使用者自助分析、與其它資料結合，找出交易失敗原因及分析報告、報表。

打造的挑戰：如何獲取日誌對生產系統影響最小、如何快速將每天3億+條交易日誌轉譯並存儲到Hadoop集群、大量的作業如何管理及如何實現秒級查詢。

系統的打造及架構

系統的打造就是一個發現問題和解決問題的過程，基於需求和背景，對問題逐個擊破，汪振平分享了他的寶貴經驗：

1. 將資料收集影響降到最低：總體上講，無非就是基於業務選擇合適的時間點和方式，這裡的實際情況是：每天上午1:00~5:00之間，由於資料以二進位方式存儲在本地檔中，且涉及多台機器，同時也為了能快速獲取資料， 採用了用戶端與同業務資料來源一一對應關係，每個用戶端可以依據配置，能同時獲取不同業務系統資料。

2. 快速將3億+條交易日誌轉譯並存儲到hadoop集群

在這裡汪振平棄用了MapReduce，選擇了自主研發主要是因為：HDFS對檔進行切割分佈，而檔又是以2進制形式進行存儲。 基於檔切割、報文之間分界、不完整報文等因素，而且對日誌在解析過程中可用性不可控，同時也由於日誌解析規範的複雜性決定。

3. 大量作業的管理

上圖為其公司內部的作業管理架構，主要涉及到4個元件：作業編排器，主要負責編排作業；作業管理器，主要負責作業調度；作業狀態管理員，用於審計併發現問題所在；作業觸發器，觸發作業，觸發依賴性作業或者是其它作業。

秒級查詢：汪振平通過Hbase存儲、二級索引、ParallelRegionQuery、支援資料區間查詢、針對HBase訪問API封裝，提高開發效率及對集群調優實現了妙級的查詢。

最後汪振平還分享了上海寶信的集群狀態、Hadoop相關知識以及Hadoop個人的使用及學習相關經驗，在使用經驗上他認為初期要做好規模、網路、伺服器硬體設定運行環境等的規劃，而使用過程中則要注重集群的監控、 運行日誌的收集和分析及作業系統的共同調優，其中應急流程更是必不可少的一環。 而在學習方面，他認為多讀源碼、深入瞭解系統運行原理是非常必要的，但無需在早期進行代碼修改。

李尤：Hadoop在智聯招聘的實踐，及相關注意點

智聯招聘高級工程師李尤表示公司集群中的資料節點已有數十台，並分享了Hadoop在智聯招聘中的使用方式：

Web日誌分析

不使用Ga的原因

日誌資料：使用者產生的日誌、cdn推送過來的日誌、負載均衡日誌

主要分析使用者產生的日誌： 5月30日的日誌（用gzip壓縮 ）遍歷一遍，用時 1分21秒， piggybank中的load函數 用了正則運算式，並將欄位區分開，同樣的資料用時2分18秒

日誌採集。

推薦系統（一種很容易理解的推薦演算法：排除噪音資料，或者有一定規則的成對次數）

如何解決推薦系統的冷啟動（採用了一種土辦法）

對未來推薦系統的規劃（機器學習）

隨後他就Hadoop在智聯的使用心得，分享了Hadoop在使用過程中幾個必須注意的地方：

單台cpu核數即為 map和reduce槽數（記憶體有限時，可以考慮降低reduce槽數）

Datanode的Jvm heap不要超過2gb。 Dn的磁片數=cpu核數，且不做raid

Namenode、snn最好做raid；namenode的heap看hdfs規模了，配8gb記憶體大概能保證800tb的資料量（排除極端情況，有很多小檔、因為不管檔的大小是多少，一個檔、目錄，block 就要佔用150位元組記憶體

如果集群比較小，可以考慮上傳之前對資料來源全部做壓縮處理。 目前智聯用的是gz（這是不可分割的格式，但是節省了大量磁碟空間，是很合算的）

Shuffle配置的snappy，可以節省網路頻寬

隨後李尤更結合代碼進行了深度的技術分享，期間還分享了Pig的主要使用者，分別為：

Yahoo!：90%以上的MapReduce作業是Pig生成的

Twitter：80%以上的MapReduce作業是Pig生成的

Linkedin：大部分的MapReduce作業是Pig生成的

其他主要使用者：Salesforce, Nokia, AOL, comScore

最後李尤還對Pig的主要開發者進行了講解，其中涉及Hortonworks、Twitter、Yahoo!及Cloudera。