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

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

輿情平臺項(xiàng)目的初衷是為了加強(qiáng)海航集團(tuán)及其下屬各成員企業(yè)的品牌效應(yīng)，并且減少關(guān)鍵信息傳播的成本，及時(shí)洞悉客戶評價(jià)和輿論走向，以及指導(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個(gè)；

大型論壇20個(gè)；

科技行業(yè)70個(gè)；

財(cái)經(jīng)行業(yè)30個(gè)；

旅游行業(yè)33個(gè)；

航空行業(yè)30個(gè)；

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

主要功能如下：

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

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

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

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

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

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

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

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

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

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

一些展示效果如下所示：

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

爬蟲部分：

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

文本分析模型：

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

前端 + 后臺：

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

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

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

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

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

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

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

性能差，很難進(jìn)行橫向擴(kuò)展

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

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

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

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

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

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

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

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

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

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

容器編排我們使用的是Rancher平臺，使用默認(rèn)Cattle編排引擎。我們大概有40多個(gè)長時(shí)運(yùn)行的實(shí)例，分為3類：

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

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

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

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

5） 本地鏡像倉庫

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

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

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

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

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

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

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

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

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

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

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

Jenkins： 容器中運(yùn)行，持續(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)建；由于已做了代碼和配置文件分開映射到本地，部署時(shí)復(fù)制打包代碼到部署節(jié)點(diǎn)替換代碼文件，重啟容器實(shí)例完成服務(wù)部署。

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

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

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

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

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

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

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

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

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

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