摘要：本文轉(zhuǎn)載自微信公眾號賬號，作者為海航生態(tài)科技技術(shù)研究院大數(shù)據(jù)開發(fā)工程師高顏。文章介紹了海航生態(tài)科技輿情大數(shù)據(jù)平臺的容器化改造經(jīng)驗，包括初期技術(shù)架構(gòu)應(yīng)用容器化架構(gòu)遷移持續(xù)發(fā)布與部署。

本文轉(zhuǎn)載自微信公眾號Docker（賬號：dockerone），作者為海航生態(tài)科技技術(shù)研究院大數(shù)據(jù)開發(fā)工程師高顏。
文章介紹了海航生態(tài)科技輿情大數(shù)據(jù)平臺的容器化改造經(jīng)驗，包括初期技術(shù)架構(gòu)、應(yīng)用容器化、架構(gòu)遷移、持續(xù)發(fā)布與部署。

海航輿情監(jiān)控系統(tǒng)能夠為海航集團內(nèi)部提供監(jiān)控網(wǎng)絡(luò)輿情信息，對負面信息、重大輿情及時預(yù)警，研判具體輿情或者某一輿情專題事件的發(fā)展變化趨勢，生成圖標報告和各種統(tǒng)計數(shù)據(jù)，提高輿情工作效率和輔助領(lǐng)導(dǎo)決策。然而，隨著項目的持續(xù)運行，許多問題逐漸暴露出來，為了解決這些難題，對整個項目重新規(guī)劃設(shè)計，遷移到Hadoop、Spark大數(shù)據(jù)平臺，引進持續(xù)化Docker容器部署和發(fā)布，開發(fā)和運營效率得到顯著提升。

輿情平臺項目的初衷是為了加強海航集團及其下屬各成員企業(yè)的品牌效應(yīng)，并且減少關(guān)鍵信息傳播的成本，及時洞悉客戶評價和輿論走向，以及指導(dǎo)輿論引導(dǎo)工作，加快對緊急事件的響應(yīng)速度。

需要完成工作包括分析及預(yù)測敏感內(nèi)容在互聯(lián)網(wǎng)、社交網(wǎng)絡(luò)等載體的傳播狀況，包括數(shù)據(jù)采集， 情感分析，爆發(fā)預(yù)測，敏感預(yù)警等

目前的規(guī)模：

微博類：

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

新聞、論壇、博客：

主流媒體30個；

大型論壇20個；

科技行業(yè)70個；

財經(jīng)行業(yè)30個；

旅游行業(yè)33個；

航空行業(yè)30個；

其他如微信公眾號、自媒體類，同行業(yè)票價網(wǎng)站等，一共300多家站點，數(shù)據(jù)維度達到30多個，每天數(shù)據(jù)量達150w條，數(shù)據(jù)量接近10G；

主要功能如下：

數(shù)據(jù)爬?。?每天定時計劃爬取指定微博，新聞媒體最新發(fā)布信息，存儲以供分析

數(shù)據(jù)存儲：存儲微博、新聞內(nèi)容、圖片等，以及中間分析結(jié)果、計算結(jié)果

微博輿情：統(tǒng)計分析、信息監(jiān)測、信息檢索

新聞輿情：統(tǒng)計分析、信息監(jiān)測、信息檢索

熱詞統(tǒng)計：高頻度熱詞統(tǒng)計

情感分析：文本分析、根據(jù)文字內(nèi)容定位情感傾向

輿情監(jiān)測：根據(jù)指定敏感詞進行信息過濾，并提供通知功能

數(shù)據(jù)接口服務(wù)：提供對外的Rest的API數(shù)據(jù)服務(wù)

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

圖像識別和內(nèi)容分析：（這部分正在做）

一些展示效果如下所示：

加入項目的時候，項目架構(gòu)比較簡單，作為一個驗證階段，就是一個傳統(tǒng)的Web應(yīng)用，采用的 Spring Web MVC + MySQL，再加上數(shù)據(jù)采集功能爬蟲系統(tǒng)+文本分析模型（CNN），代碼審查使用Git + GitLab。

爬蟲部分：

Java語言實現(xiàn)，基于WebMagic框架二次開發(fā)。由于各個網(wǎng)站的頁面布局沒有一個統(tǒng)一的格式，所以開發(fā)人員需要針對每個網(wǎng)站多帶帶寫一個爬蟲程序用來做頁面數(shù)據(jù)解析。爬蟲在部署的時候是，手動進行編譯，并按照運行計劃打多個可執(zhí)行jar包，分別部署到多個節(jié)點上執(zhí)行，數(shù)據(jù)存入MySQL數(shù)據(jù)庫（用一個專門的節(jié)點來部署）。支持最初的30幾個網(wǎng)站和微博的數(shù)據(jù)，數(shù)據(jù)量每天大概有不到20w。

文本分析模型：

Python實現(xiàn)，使用結(jié)巴分詞工具和CNN（卷積神經(jīng)網(wǎng)絡(luò)）模型，支持矩陣批量運算。運行方式是Python web（用框架是Tornado）提供API，由爬蟲調(diào)用調(diào)用，并回填結(jié)果，增加情感傾向、熱度、關(guān)鍵詞等字段，后存入數(shù)據(jù)庫。

前端 + 后臺：

典型的Spring MVC應(yīng)用，采用Spring MVC + MyBatis + MySQL，前端使用ECharts生成圖形和報表；統(tǒng)計數(shù)據(jù)是提前計算好，存入MySQL數(shù)據(jù)庫中，并通過Quartz調(diào)度運算作業(yè)和數(shù)據(jù)更新。

很顯然，MySQL無法應(yīng)對數(shù)據(jù)的大量增長，這個平臺對于數(shù)據(jù)的增長和擴張是無法適應(yīng)的， 應(yīng)用的接口響應(yīng)時間從開始的幾秒甚至延長到幾分鐘，無法令人接受。

總結(jié)一下，這個框架有多個顯而易見的弊端（也算是初期作為驗證使用，另一方面也是因為開始資源不足）：

不能支持大量的數(shù)據(jù)存儲（同時還保持不錯的性能）

不能較好地支持多種格式的數(shù)據(jù)存儲

項目依賴庫文件也未代碼化管理，更新、升級、打包非常麻煩

部署困難，手動打包，tomcat部署運行，不方便開發(fā)及測試人員，對新人極不友好

性能差，很難進行橫向擴展

為了解決上述問題，我們就嘗試去做首先確定的是需要遷往大數(shù)據(jù)平臺。在這同時，我們做了一些容器化的工作。做這些工作的目的是，方

便部署和遷移，容易進行伸縮控制，能夠借助工具向著自動化的方向進行。

1） 引入Gradle+Jenkins持續(xù)構(gòu)建工具

采用Gradle構(gòu)建工具，使用了Gretty插件，去除代碼依賴 jar包，依賴代碼化，配置一鍵調(diào)試和運行；采用Jenkins持續(xù)構(gòu)建工具，給每一個模塊搭建了一條流水線代碼測試、打包和部署，目前部署是shell腳本實現(xiàn)。

2） 代碼結(jié)構(gòu)整理

爬蟲代碼中每個站點的數(shù)據(jù)抓取是一條流水線，每條流水線有著相同的流程，我們把配置部分代碼抽出來，改寫啟動入口接收配置參數(shù)，由配置來決定啟動哪些站點的流水線；修改Spring Web改為前后端分離；

3） 應(yīng)用容器化

首先是MySQL數(shù)據(jù)庫容器化，把默認的/var/lib/mysql數(shù)據(jù)目錄和配置文件目錄掛載到了本地，把之前的數(shù)據(jù)做了遷移；接著是Web服務(wù)，使用Tomcat鏡像，掛載了WebApps目錄，Gradle打war包復(fù)制到本地掛載目錄；

然后是文本分析模型，由于文本分析模型需要安裝大量依賴文件（pip），我們重新構(gòu)建了鏡像提交到本地Registry；周期執(zhí)行的計算任務(wù)打成jar包，運行時啟動新的鏡像實例運行。

4） 使用Rancher容器管理監(jiān)控平臺

容器編排我們使用的是Rancher平臺，使用默認Cattle編排引擎。我們大概有40多個長時運行的實例，分為3類：

爬蟲實例，接近40個實例調(diào)度到20多個宿主節(jié)點上。我們數(shù)據(jù)放在在CDH平臺上，這些容器間并不發(fā)生通信，只與文本分析模型進行通信，最后數(shù)據(jù)發(fā)送到CDH集群的Kafka，對這些實例只進行代碼替換、更新及運維工作；

目前部署了3個文本分析模型的實例，由爬蟲根據(jù)名字隨機請求。

批處理任務(wù)類，使用Rancher提供的crontab工具，周期性的運行。

現(xiàn)在可以做到自動的代碼更新和部署，時間大概不到一個小時，之前部署一次至少半天。

5） 本地鏡像倉庫

Rancher提供了Registry管理功能，可以很方便地管理Registry。為了加速下載，我們在本地部署了一個Registry，方便鏡像更新和應(yīng)用遷移。

隨著爬蟲爬取的數(shù)據(jù)逐日增加，現(xiàn)在這個系統(tǒng)肯定是支撐不了的。 我們經(jīng)過討論，確定了基本架構(gòu)。使用HBase + ElasticSearch作為數(shù)據(jù)存儲，Kafka作消息隊列，由HBase負責保存爬蟲數(shù)據(jù)，ES則負責建立索引（我們的一致性目前要求不高）。由Rancher管理分布式爬蟲將爬取的數(shù)據(jù)送往Kakfa集群，在這之前向文本分析模型（容器中）發(fā)送http請求，回填相應(yīng)字段。然后再由兩個Kafka Consumer將數(shù)據(jù)分別傳輸?shù)紿Base和ES中完成數(shù)據(jù)保存。

爬蟲現(xiàn)在經(jīng)過容器化，由Rancher進行管理。

統(tǒng)計工作交由Spark SQL讀寫HBase完成，目前還沒有做到實時的。我們的做法是按天統(tǒng)計存到表中，服務(wù)請求時根據(jù)請求條件選擇計算范圍進行實時計算。這個算是離實時性前進了一步，接下來會繼續(xù)改造成實時的。

這里有一個細節(jié)，由于我們的數(shù)據(jù)是有時間要求的，有根據(jù)時間排序的需求，而且我們處理的數(shù)據(jù)也主要是在近期范圍的（最近一天/周/月/年），所以我們希望HBase能根據(jù)記錄的發(fā)布時間來排倒序，于是我們將時間戳作為HBase的rowkey拼接的第一段，但這樣又引入了新的問題，記錄在HBase集群上會“扎堆”，于是為了緩解這個問題，我們把發(fā)布時間的小時拿出來放在這個時間戳之前，這樣局部還是根據(jù)時間排序的，暫時也不會影響到HBase節(jié)點的伸縮。

后端使用Spring Data （ES + HBase）操作數(shù)據(jù)，暫時未加入緩存機制；前端還是用AngularJS，但是做了前后端分離。現(xiàn)在總數(shù)據(jù)量已經(jīng)達到之前的數(shù)十倍，數(shù)據(jù)請求基本在1S以內(nèi)，檢索查詢由ES提供數(shù)據(jù)，請求基本在300ms至1s。離線批處理作業(yè)執(zhí)行時間由先前的8min縮減到平均2.5分鐘。

目前大數(shù)據(jù)平臺未實現(xiàn)容器化，運行在一套CDH集群上，集群配置了高可用。Kafka和ES使用的是開源版（Spring Data的版本原因），通過使用Supervisord提高其服務(wù)的可靠性。

在這一塊兒，我們下一步的目標是將大數(shù)據(jù)平臺的計算部分如spark、模型算法這一塊兒分離出來實現(xiàn)容器化，方便我們實現(xiàn)計算能力根據(jù)計算量進行彈性自動伸縮，我們有一套基于Mesos管理Docker鏡像的測試集群，包括Spark應(yīng)用和分布式的機器學(xué)習(xí)算法，這一部分正在測試中。

這一塊使用GitLab + Gradle + Jenkins（Docker）+ Shell腳本

Gradle：執(zhí)行測試、構(gòu)建、應(yīng)用打包，本地調(diào)試和運行；

GitLab： 代碼倉庫、代碼審查；

Jenkins： 容器中運行，持續(xù)構(gòu)建管理，和定期執(zhí)行構(gòu)建和部署；

Gitlab中設(shè)置提交觸發(fā)，Jenkins設(shè)置接收觸發(fā)執(zhí)行Pipeline，Jenkins執(zhí)行構(gòu)建，調(diào)用Gradle和Shell命令執(zhí)行構(gòu)建；由于已做了代碼和配置文件分開映射到本地，部署時復(fù)制打包代碼到部署節(jié)點替換代碼文件，重啟容器實例完成服務(wù)部署。

Q：Spark直接運行在Mesos不是很方便么，容器化優(yōu)勢是否明顯？主要考慮點在哪？

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

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

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

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

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

Q：爬蟲容器如何調(diào)度，是分布式嗎？

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

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

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