海航生態科技輿情大數據平臺容器化改造

本文轉載自微信公衆號Docker（帳號：dockerone），做者爲海航生態科技技術研究院大數據開發工程師高顏。

文章介紹了海航生態科技輿情大數據平臺的容器化改造經驗，包括初期技術架構、應用容器化、架構遷移、持續發佈與部署。

海航輿情監控系統可以爲海航集團內部提供監控網絡輿情信息，對負面信息、重大輿情及時預警，研判具體輿情或者某一輿情專題事件的發展變化趨勢，生成圖標報告和各類統計數據，提升輿情工做效率和輔助領導決策。然而，隨着項目的持續運行，許多問題逐漸暴露出來，爲了解決這些難題，對整個項目從新規劃設計，遷移到Hadoop、Spark大數據平臺，引進持續化Docker容器部署和發佈，開發和運營效率獲得顯著提高。

輿情平臺介紹

輿情平臺項目的初衷是爲了增強海航集團及其下屬各成員企業的品牌效應，而且減小關鍵信息傳播的成本，及時洞悉客戶評價和輿論走向，以及指導輿論引導工做，加快對緊急事件的響應速度。

須要完成工做包括分析及預測敏感內容在互聯網、社交網絡等載體的傳播情況，包括數據採集， 情感分析，爆發預測，敏感預警等

目前的規模：

• 微博類：

經過設置微博種子帳戶（一部分經過搜索，一部分是公司微博帳號），挖掘粉絲的粉絲深層次挖掘，爬取數據天天信息條目目前有20w 左右，逐漸會加入更多 的種子帳戶，也在溝通購買新浪的開放API；

• 新聞、論壇、博客：

主流媒體30個；

大型論壇20個；

科技行業70個；

財經行業30個；

旅遊行業33個；

航空行業30個；

其餘如微信公衆號、自媒體類，同行業票價網站等，一共300多家站點，數據維度達到30多個，天天數據量達150w條，數據量接近10G；

主要功能以下：

• 數據爬取： 天天定時計劃爬取指定微博，新聞媒體最新發布信息，存儲以供分析

• 數據存儲：存儲微博、新聞內容、圖片等，以及中間分析結果、計算結果

• 微博輿情：統計分析、信息監測、信息檢索

• 新聞輿情：統計分析、信息監測、信息檢索

• 熱詞統計：高頻度熱詞統計

• 情感分析：文本分析、根據文字內容定位情感傾向

• 輿情監測：根據指定敏感詞進行信息過濾，並提供通知功能

• 數據接口服務：提供對外的Rest的API數據服務

• 熱點事件梳理：提供檢索，優先列出熱度高的新聞、微博記錄

• 圖像識別和內容分析：（這部分正在作）

一些展現效果以下所示：

初期架構

加入項目的時候，項目架構比較簡單，做爲一個驗證階段，就是一個傳統的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：容器化主要考慮兩點:一 解決海量數據計算的資源編排問題 ，將來也會基於CaaS雲提供服務 , 二 研發體系的敏捷化與標準化問題。咱們正在考慮根據計算須要實現彈性伸縮，容器化是一個助力。

Q：請問爲何Elasticsearch，而沒有選擇Solr呢？

A：在有索引下，ES性能會要好一些，並且它原生分佈式支持，安裝配置也簡單。

Q：代碼沒有打包進鏡像中是出於什麼緣由？

A：這樣部署運行會更靈活，我能夠代碼放到本地，也能夠上傳到實例中。代碼提交比較頻繁，執行環境變化卻不大，只替換變換的部分部署會更快速。主要是爲了適應目前這種部署方式。

Q：爬蟲容器如何調度，是分佈式嗎？

A：是分佈式的，這個是按時間定時運行的，Rancher提供的crontab，爬蟲程序提供執行入口。

Q：HBase主鍵設計依然沒有解決熱點問題？

A：確實未徹底解決，基於時間序列的暫時未找到更好的rowkey設計方法；把他分紅24小段，加入時間，單獨對每段來講，它是按時間排序的，也算是一種折中。