海航生态科技舆情大数据平台容器化改造

本文转载自微信公众号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小段，加入时间，单独对每段来讲，它是按时间排序的，也算是一种折中。