這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】海航輿情監控系統能夠為海航集團內部提供監控網路輿情資訊，對負面資訊、重大輿情及時預警，研判具體輿情或者某一輿情專題事件的發展變化趨勢，產生表徵圖報告和各種統計資料，提高輿情工作效率和輔助領導決策。然而，隨著項目的持續運行，許多問題逐漸暴露出來，為瞭解決這些難題，對整個項目重新規劃設計，遷移到Hadoop、Spark大資料平台，引進持續化Docker容器部署和發布，開發和運營效率得到顯著提升。
一、 輿情平台介紹
輿情平台項目的初衷是為了加強海航集團及其下屬各成員企業的品牌效應，並且減少關鍵資訊傳播的成本，及時洞悉客戶評價和輿論走向，以及指導輿論引導工作，加快對緊急事件的響應速度。
需要完成工作包括分析及預測敏感內容在互連網、社交網路等載體的傳播狀況，包括資料擷取， 情感分析，爆發預測，敏感預警等
目前的規模：
微博類：
通過設定微博種子賬戶（一部分通過搜尋，一部分是公司微博帳號），挖掘粉絲的粉絲深層次挖掘，爬取資料每天資訊條目目前有20w 左右，逐漸會加入更多 的種子賬戶，也在溝通購買新浪的開放API；
新聞、論壇、部落格：
主流媒體30個；
大型論壇20個；
科技行業70個；
財經行業30個；
旅遊行業33個；
航空行業30個；
其他如公眾號、自媒體類，同行業票價網站等，一共300多家網站，資料維度達到30多個，每天資料量達150w條，資料量接近10G；
主要功能如下：
- 資料爬取： 每天定時計劃爬取指定微博，新聞媒體最新發行資訊，儲存以供分析
- 資料存放區：儲存微博、新聞內容、圖片等，以及中間分析結果、計算結果
- 微博輿情：統計分析、資訊監測、資訊檢索
- 新聞輿情：統計分析、資訊監測、資訊檢索
- 熱詞統計：高頻度熱詞統計
- 情感分析：文本分析、根據文字內容定位情感傾向
- 輿情監測：根據指定敏感詞進行資訊過濾，並提供通知功能
- 資料介面服務：提供對外的Rest的API資料服務
- 熱時間點事件梳理：提供檢索，優先列出熱度高的新聞、微博記錄
- Image Recognition和內容分析：（這部分正在做）
一些展示效果如下所示：
二、 初期架構
加入項目的時候，項目架構比較簡單，作為一個驗證階段，就是一個傳統的Web應用，採用的 Spring Web MVC + MySQL，再加上資料擷取功能爬蟲系統+文本分析模型（CNN），代碼審查使用Git + GitLab。
爬虫部分：
Java語言實現，基於WebMagic架構二次開發。由於各個網站的頁面配置沒有一個統一的格式，所以開發人員需要針對每個網站單獨寫一個爬蟲程式用來做頁面資料解析。爬蟲在部署的時候是，手動進行編譯，並按照運行計劃打多個可執行jar包，分別部署到多個節點上執行，資料存入MySQL資料庫（用一個專門的節點來部署）。支援最初的30幾個網站和微博的資料，資料量每天大概有不到20w。
文本分析模型：
Python實現，使用結巴分詞工具和CNN（卷積神經網路）模型，支援矩陣批量運算。運行方式是Python web（用架構是Tornado）提供API，由爬蟲調用調用，並回填結果，增加情感傾向、熱度、關鍵詞等欄位，後存入資料庫。
前端 + 後台：
典型的Spring MVC應用，採用Spring MVC + MyBatis + MySQL，前端使用ECharts產生圖形和報表；統計資料是提前計算好，存入MySQL資料庫中，並通過Quartz調度運算作業和資料更新 。
很顯然，MySQL無法應對資料的大量增長，這個平台對於資料的增長和擴張是無法適應的， 應用的介面回應時間從開始的幾秒甚至延長到幾分鐘，無法令人接受。
總結一下，這個架構有多個顯而易見的弊端（也算是初期作為驗證使用，另一方面也是因為開始資源不足）：
- 不能支援大量的資料存放區（同時還保持不錯的效能）
- 不能較好地支援多種格式的資料存放區
- 項目依賴庫檔案也未代碼化管理，更新、升級、打包非常麻煩
- 部署困難，手動打包，tomcat部署運行，不方便開發及測試人員，對新人極不友好
- 效能差，很難進行橫向擴充
三、 應用程式容器化
為瞭解決上述問題，我們就嘗試去做首先確定的是需要遷往大資料平台。在這同時，我們做了一些容器化的工作。做這些工作的目的是，方便部署和遷移，容易進行伸縮控制，能夠藉助工具向著自動化的方向進行。
1） 引入Gradle+Jenkins持續構建工具
採用Gradle構建工具，使用了Gretty外掛程式，去除代碼依賴 jar包，依賴代碼化，配置一鍵調試和運行；採用Jenkins持續構建工具，給每一個模組搭建了一條流水線代碼測試、打包和部署，目前部署是shell指令碼實現。
2） 代碼結構整理
爬蟲代碼中每個網站的資料抓取是一條流水線，每條流水線有著相同的流程，我們把配置部分代碼抽出來，改寫啟動入口接收配置參數，由配置來決定啟動哪些網站的流水線；修改Spring Web改為前後端分離；
3） 應用程式容器化
首先是MySQL資料庫容器化，把預設的/var/lib/mysql資料目錄和設定檔目錄掛載到了本地，把之前的資料做了遷移；接著是Web服務，使用Tomcat鏡像，掛載了WebApps目錄，Gradle打war包複製到本地掛載目錄；
然後是文本分析模型，由於文本分析模型需要安裝大量依賴檔案（pip），我們重新構建了鏡像提交到本地Registry；周期執行的計算任務打成jar包，運行時啟動新的鏡像執行個體運行。
4） 使用Rancher容器管理監控平台
容器編排我們使用的是Rancher平台，使用預設Cattle編排引擎。我們大概有40多個長時啟動並執行執行個體，分為3類：
爬蟲執行個體，接近40個執行個體調度到20多個宿主節點上。我們資料放在在CDH平台上，這些容器間並不發生通訊，只與文本分析模型進行通訊，最後資料發送到CDH叢集的Kafka，對這些執行個體只進行代碼替換、更新及營運工作；
目前部署了3個文本分析模型的執行個體，由爬蟲根據名字隨機請求。
批處理任務類，使用rancher提供的crontab工具，周期性的運行。
現在可以做到自動的代碼更新和部署，時間大概不到一個小時，之前部署一次至少半天。
5） 本地鏡像倉庫
Rancher提供了Registry管理功能，可以很方便地管理Registry。為了加速下載，我們在本地部署了一個Registry，方便鏡像更新和應用遷移。
四、 技術架構遷移
隨著爬蟲爬取的資料逐日增加，現在這個系統肯定是支撐不了的。 我們經過討論，確定了基本架構。使用HBase + Elasticsearch作為資料存放區，Kafka作訊息佇列，由HBase負責儲存爬蟲資料，ES則負責建立索引（我們的一致性目前要求不高）。由Rancher管理分布式爬蟲將爬取的資料送往Kakfa叢集，在這之前向文本分析模型（容器中）發送http請求，回填相應欄位。然後再由兩個Kafka Consumer將資料分別傳輸到HBase和ES中完成資料儲存。
爬蟲現在經過容器化，由Rancher進行管理。
統計工作交由Spark SQL讀寫HBase完成，目前還沒有做到即時的。我們的做法是按天統計存到表中，服務要求時根據請求條件選擇計算範圍進行即時計算。這個算是離即時性前進了一步，接下來會繼續改造成即時的。
這裡有一個細節，由於我們的資料是有時間要求的，有根據時間排序的需求，而且我們處理的資料也主要是在近期範圍的（最近一天/周/月/年），所以我們希望HBase能根據記錄的發布時間來排倒序，於是我們將時間戳記作為HBase的rowkey拼接的第一段，但這樣又引入了新的問題，記錄在HBase叢集上會“紮堆”，於是為了緩解這個問題，我們把發布時間的小時拿出來放在這個時間戳記之前，這樣局部還是根據時間排序的，暫時也不會影響到HBase節點的伸縮。
後端使用Spring Data （ES + HBase）操作資料，暫時未加入緩衝機制；前端還是用AngularJS，但是做了前後端分離。現在總資料量已經達到之前的數十倍，資料請求基本在1S以內，檢索查詢由ES提供資料，請求基本在300ms至1s。離線批次工作執行時間由先前的8min縮減到平均2.5分鐘。
目前大資料平台未實現容器化，運行在一套CDH叢集上，叢集配置了高可用。Kafka和ES使用的是開源版（Spring Data的版本原因），通過使用Supervisord提高其服務的可靠性。
在這一塊兒，我們下一步的目標是將大資料平台的計算部分如spark、模型演算法這一塊兒分離出來實現容器化，方便我們實現計算能力根據計算量進行彈性自動調整，我們有一套基於Mesos管理Docker鏡像的測試叢集，包括Spark應用和分布式的機器學習演算法，這一部分正在測試中。
五、 持續部署和發布
這一塊使用GitLab + Gradle + Jenkins（Docker）+ Shell指令碼
- Gradle：執行測試、構建、應用打包，本地調試和運行；
- GitLab： 代碼倉庫、代碼審查；
- Jenkins： 容器中運行，持續構建管理，和定期執行構建和部署；
Gitlab中設定提交觸發，Jenkins設定接收觸發執行Pipeline，Jenkins執行構建，調用Gradle和Shell命令執行構建；由於已做了代碼和設定檔分開映射到本地，部署時複製打包代碼到部署節點替換代碼檔案，重啟容器執行個體完成服務部署。
Q&A
Q：Spark直接運行在Mesos不是很方便麼，容器化優勢是否明顯？主要考慮點在哪？
A：容器化主要考慮兩點:一 解決海量資料計算的Resource Orchestration Service問題 ，未來也會基於CaaS雲提供服務 , 二 研發體系的敏捷化與標準化問題。我們正在考慮根據計算需要實現Auto Scaling，容器化是一個助力。
Q：請問為什麼Elasticsearch，而沒有選擇Solr呢？
A：在有索引下，ES效能會要好一些，而且它原生分布式支援，安裝配置也簡單。
Q：代碼沒有打包進鏡像中是出於什麼原因？
A：這樣部署運行會更靈活，我可以代碼放到本地，也可以上傳到執行個體中。代碼提交比較頻繁，執行環境變化卻不大，只替換變換的部分部署會更快速。主要是為了適應目前這種部署方式。
Q：爬蟲容器如何調度，是分布式嗎？
A：是分布式的，這個是按時間定時啟動並執行，Rancher提供的crontab，爬蟲程式提供執行入口。
Q：HBase主鍵設計依然沒有解決熱點問題？
A：確實未完全解決，基於時間序列的暫時未找到更好的rowkey設計方法；把他分成24小段，加入時間，單獨對每段來說，它是按時間排序的，也算是一種折中。
以上內容根據2016年12月13日晚群分享內容整理。分享人
高顏，就職于海航生態科技技術研究院，任職大資料開發工程師，從事大資料平台應用開發年，負責大資料平台技術選型，架構設計及代碼開發工作。DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
