摘要：本文轉載自微信公眾號賬號，作者為海航生態科技技術研究院大數據開發工程師高顏。文章介紹了海航生態科技輿情大數據平臺的容器化改造經驗，包括初期技術架構應用容器化架構遷移持續發布與部署。

本文轉載自微信公眾號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：Spark直接運行在Mesos不是很方便么，容器化優勢是否明顯？主要考慮點在哪？

A：容器化主要考慮兩點:一 解決海量數據計算的資源編排問題 ，未來也會基于CaaS云提供服務 , 二 研發體系的敏捷化與標準化問題。我們正在考慮根據計算需要實現彈性伸縮，容器化是一個助力。

Q：請問為什么Elasticsearch，而沒有選擇Solr呢？

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

Q：代碼沒有打包進鏡像中是出于什么原因？

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

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

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

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

A：確實未完全解決，基于時間序列的暫時未找到更好的rowkey設計方法；把他分成24小段，加入時間，多帶帶對每段來說，它是按時間排序的，也算是一種折中。