文章介紹了海航生態(tài)科技輿情大數(shù)據(jù)平臺(tái)的容器化改造經(jīng)驗(yàn)，包括初期技術(shù)架構(gòu)、應(yīng)用容器化、架構(gòu)遷移、持續(xù)發(fā)布與部署。

[[179672]]

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

輿情平臺(tái)介紹

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

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

目前的規(guī)模：

微博類：

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

新聞、論壇、博客：

• 主流媒體30個(gè);
• 大型論壇20個(gè);
• 科技行業(yè)70個(gè);
• 財(cái)經(jīng)行業(yè)30個(gè);
• 旅游行業(yè)33個(gè);
• 航空行業(yè)30個(gè);

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

主要功能如下：

1. 數(shù)據(jù)爬?。?每天定時(shí)計(jì)劃爬取指定微博，新聞媒體***發(fā)布信息，存儲(chǔ)以供分析
2. 數(shù)據(jù)存儲(chǔ)：存儲(chǔ)微博、新聞內(nèi)容、圖片等，以及中間分析結(jié)果、計(jì)算結(jié)果
3. 微博輿情：統(tǒng)計(jì)分析、信息監(jiān)測(cè)、信息檢索
4. 新聞?shì)浨椋航y(tǒng)計(jì)分析、信息監(jiān)測(cè)、信息檢索
5. 熱詞統(tǒng)計(jì)：高頻度熱詞統(tǒng)計(jì)
6. 情感分析：文本分析、根據(jù)文字內(nèi)容定位情感傾向
7. 輿情監(jiān)測(cè)：根據(jù)指定敏感詞進(jìn)行信息過(guò)濾，并提供通知功能
8. 數(shù)據(jù)接口服務(wù)：提供對(duì)外的Rest的API數(shù)據(jù)服務(wù)
9. 熱點(diǎn)事件梳理：提供檢索，優(yōu)先列出熱度高的新聞、微博記錄
10. 圖像識(shí)別和內(nèi)容分析：(這部分正在做)

一些展示效果如下所示：

初期架構(gòu)

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

爬蟲部分：

Java語(yǔ)言實(shí)現(xiàn)，基于WebMagic框架二次開發(fā)。由于各個(gè)網(wǎng)站的頁(yè)面布局沒有一個(gè)統(tǒng)一的格式，所以開發(fā)人員需要針對(duì)每個(gè)網(wǎng)站單獨(dú)寫一個(gè)爬蟲程序用來(lái)做頁(yè)面數(shù)據(jù)解析。爬蟲在部署的時(shí)候是，手動(dòng)進(jìn)行編譯，并按照運(yùn)行計(jì)劃打多個(gè)可執(zhí)行jar包，分別部署到多個(gè)節(jié)點(diǎn)上執(zhí)行，數(shù)據(jù)存入MySQL數(shù)據(jù)庫(kù)(用一個(gè)專門的節(jié)點(diǎn)來(lái)部署)。支持最初的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ù)庫(kù)。

前端 + 后臺(tái)：

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

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

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

1. 不能支持大量的數(shù)據(jù)存儲(chǔ)(同時(shí)還保持不錯(cuò)的性能)
2. 不能較好地支持多種格式的數(shù)據(jù)存儲(chǔ)
3. 項(xiàng)目依賴庫(kù)文件也未代碼化管理，更新、升級(jí)、打包非常麻煩
4. 部署困難，手動(dòng)打包，tomcat部署運(yùn)行，不方便開發(fā)及測(cè)試人員，對(duì)新人極不友好
5. 性能差，很難進(jìn)行橫向擴(kuò)展

應(yīng)用容器化

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

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

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

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

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

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

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

首先是MySQL數(shù)據(jù)庫(kù)容器化，把默認(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í)啟動(dòng)新的鏡像實(shí)例運(yùn)行。

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

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

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

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

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

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

5) 本地鏡像倉(cāng)庫(kù)

Rancher提供了Registry管理功能，可以很方便地管理Registry。為了加速下載，我們?cè)诒镜夭渴鹆艘粋€(gè)Registry，方便鏡像更新和應(yīng)用遷移。

技術(shù)架構(gòu)遷移

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

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

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

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

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

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

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

持續(xù)部署和發(fā)布

這一塊使用GitLab + Gradle + Jenkins(Docker)+ Shell腳本

1. Gradle：執(zhí)行測(cè)試、構(gòu)建、應(yīng)用打包，本地調(diào)試和運(yùn)行;
2. GitLab： 代碼倉(cāng)庫(kù)、代碼審查;
3. 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&A

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

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

Q：請(qǐng)問(wèn)為什么Elasticsearch，而沒有選擇Solr呢?

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

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

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

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

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

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

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