基于大数据的舆情分析系统架构前言互联网的飞速发展促进了很多新媒体的发展，不论是知名的大V，明星还是围观群众都可以通过手机在微博，朋友圈或者点评网站上发表状态，分享自己的所见所想，使得“人人都有了麦克风”。

不论是热点新闻还是娱乐八卦，传播速度远超我们的想象。

可以在短短数分钟内，有数万计转发，数百万的阅读。

如此海量的信息可以得到爆炸式的传播，如何能够实时的把握民情并作出对应的处理对很多企业来说都是至关重要的。

大数据时代，除了媒体信息以外，商品在各类电商平台的订单量，用户的购买评论也都对后续的消费者产生很大的影响。

商家的产品设计者需要汇总统计和分析各类平台的数据做为依据，决定后续的产品发展，公司的公关和市场部门也需要根据舆情作出相应的及时处理，而这一切也意味着传统的舆情系统升级成为大数据舆情采集和分析系统。

分析完舆情场景后，我们再来具体细化看下大数据舆情系统，对我们的数据存储和计算系统提出哪些需求：∙海量原始数据的实时入库：为了实现一整套舆情系统，需要有上游原始输出的采集，也就是爬虫系统。

爬虫需要采集各类门户，自媒体的网页内容。

在抓取前需要去重，抓取后还需要分析提取，例如进行子网页的抓取。

∙原始网页数据的处理：不论是主流门户还是自媒体的网页信息，抓取后我们需要做一定的数据提取，把原始的网页内容转化为结构化数据，例如文章的标题，摘要等，如果是商品点评类消息也需要提取有效的点评。

∙结构化数据的舆情分析：当各类原始输出变成结构化的数据后，我们需要有一个实时的计算产品把各类输出做合理的分类，进一步对分类后的内容进行情感打标。

根据业务的需求这里可能会产生不同的输出，例如品牌当下是否有热点话题，舆情影响力分析，转播路径分析，参与用户统计和画像，舆论情感分析或者是否有重大预警。

∙舆情分析系统中间和结果数据的存储，交互分析查询：从网页原始数据清洗到最终的舆情报表这中间会产生很多类型的数据。

这些数据有的会提供给数据分析同学进行舆情分析系统的调优，有的数据会提供给业务部门根据舆情结果进行决策。

这些查询可能会很灵活，需要我们的存储系统具备全文检索，多字段组合灵活的交互分析能力。

∙重大舆情事件的实时预警：对于舆情的结果除了正常的搜索和展示需求以外，当有重大事件出现我们需要能做到实时的预警。

我们计划分两篇介绍完整的舆情新架构，第一篇主要是提供架构设计，会先介绍时下主流的大数据计算架构，并分析一些优缺点，然后引入舆情大数据架构。

第二篇会有完整的数据库表设计和部分示例代码。

大家敬请期待。

系统设计需求分析结合文章开头对舆情系统的描述，海量大数据舆情分析系统流程图大体如下：图 1 舆情系统业务流程∙原始网页存储库，这个库需要能支持海量数据，低成本，低延时写入。

网页数据写入后，要做实时结构化提取，提取出来的数据再进行降噪，分词，图片ocr 处理等。

对分词文本，图片进行情感识别产生舆情数据结果集。

传统的离线全量计算很难满足舆情系统的时效性需求。

∙计算引擎在做数据处理时，可能还需要从存储库中获取一些元数据，例如用户信息，情感词元数据信息等。

∙除了实时的计算链路，对存量数据定期要做一些聚类，优化我们的情感词识别库，或者上游根据业务需要触发情感处理规则更新，根据新的情感打标库对存量数据做一次舆情计算。

∙舆情的结果数据集有不同类的使用需求。

对于重大舆情，需要做实时的预警。

完整的舆情结果数据展示层需要支持全文检索，灵活的属性字段组合查询。

业务上可能根据属性字段中的置信度，舆情时间，或者关键词组合进行分析。

根据前面的介绍，舆情大数据分析系统需要两类计算，一类是实时计算包括海量网页内容实时抽取，情感词分析并进行网页舆情结果存储。

另一类是离线计算，系统需要对历史数据进行回溯，结合人工标注等方式优化情感词库，对一些实时计算的结果进行矫正等。

所以在系统设计上，需要选择一套既可以做实时计算又能做批量离线计算的系统。

在开源大数据解决方案中，Lambda 架构恰好可以满足这些需求，下面我们来介绍下Lambda 的架构。

Lambda 架构（wiki）图 2 Lambda 架构图Lambda 架构可以说是Hadoop，Spark 体系下最火的大数据架构。

这套架构的最大优势就是在支持海量数据批量计算处理（也就是离线处理）同时也支持流式的实时处理（即热数据处理）。

具体是如何实现的呢，首先上游一般是一个队列服务例如kafka，实时存储数据的写入。

kafka 队列会有两个订阅者，一个是全量数据即图片中上半部分，全量数据会被存储在类似HDFS 这样的存储介质上。

当有离线计算任务到来，计算资源（例如Hadoop）会访问存储系统上的全量数据，进行全量批计算的处理逻辑。

经过map/reduce 环节后全量的结果会被写入一个结构化的存储引擎例如Hbase 中，提供给业务方查询。

队列的另一个消费订阅方是流计算引擎，流计算引擎往往会实时的消费队列中的数据进行计算处理，例如Spark Streaming 实时订阅Kafka 的数据，流计算结果也会写入一个结构化数据引擎。

批量计算和流计算的结果写入的结构化存储引擎即上图标注 3 的"Serving Layer"，这一层主要提供结果数据的展示和查询。

在这套架构中，批量计算的特点是需要支持处理海量的数据，并根据业务的需求，关联一些其他业务指标进行计算。

批量计算的好处是计算逻辑可以根据业务需求灵活调整，同时计算结果可以反复重算，同样的计算逻辑多次计算结果不会改变。

批量计算的缺点是计算周期相对较长，很难满足实时出结果的需求，所以随着大数据计算的演进，提出了实时计算的需求。

实时计算在Lambda 架构中是通过实时数据流来实现，相比批处理，数据增量流的处理方式决定了数据往往是最近新产生的数据，也就是热数据。

正因为热数据这一特点，流计算可以满足业务对计算的低延时需求，例如在舆情分析系统中，我们往往希望舆情信息可以在网页抓取下来后，分钟级别拿到计算结果，给业务方充足的时间进行舆情反馈。

下面我们就来具体看一下，基于Lambda 架构的思想如何实现一套完整的舆情大数据架构。

开源舆情大数据方案通过这个流程图，让我们了解了整个舆情系统的建设过程中，需要经过不同的存储和计算系统。

对数据的组织和查询有不同的需求。

在业界基于开源的大数据系统并结合Lambda 架构，整套系统可以设计如下：图3 开源舆情架构图1.系统的最上游是分布式的爬虫引擎，根据抓取任务抓取订阅的网页原文内容。

爬虫会把抓取到的网页内容实时写入Kafka 队列，进入Kafka 队列的数据根据前面描述的计算需求，会实时流入流计算引擎（例如Spark 或者Flink），也会持久化存储在Hbase，进行全量数据的存储。

全量网页的存储可以满足网页爬取去重，批量离线计算的需求。

2.流计算会对原始网页进行结构化提取，将非结构化网页内容转化为结构数据并进行分词，例如提取出网页的标题，作者，摘要等，对正文和摘要内容进行分词。

提取和分词结果会写回Hbase。

结构化提取和分词后，流计算引擎会结合情感词库进行网页情感分析，判断是否有舆情产生。

3.流计算引擎分析的舆情结果存储Mysql 或者Hbase 数据库中，为了方便结果集的搜索查看，需要把数据同步到一个搜索引擎例如Elasticsearch，方便进行属性字段的组合查询。

如果是重大的舆情时间，需要写入Kafka 队列触发舆情报警。

4.全量的结构化数据会定期通过Spark 系统进行离线计算，更新情感词库或者接受新的计算策略重新计算历史数据修正实时计算的结果。

开源架构分析上面的舆情大数据架构，通过Kafka 对接流计算，Hbase 对接批计算来实现Lambda 架构中的“batch view”和“real-time view”，整套架构还是比较清晰的，可以很好的满足在线和离线两类计算需求。

但是把这一套系统应用在生产并不是一件容易的事情，主要有下面一些原因。

∙整套架构涉及到非常多的存储和计算系统包括：Kafka，Hbase，Spark，Flink，Elasticsearch。

数据会在不同的存储和计算系统中流动，运维好整套架构中的每一个开源产品都是一个很大的挑战。

任何一个产品或者是产品间的通道出现故障，对整个舆情分析结果的时效性都会产生影响。

∙为了实现批计算和流计算，原始的网页需要分别存储在Kafka 和Hbase 中，离线计算是消费hbase 中的数据，流计算消费Kafka 的数据，这样会带来存储资源的冗余，同时也导致需要维护两套计算逻辑，计算代码开发和维护成本也会上升。

∙舆情的计算结果存储在Mysql 或者Hbase，为了丰富组合查询语句，需要把数据同步构建到Elasticsearch 中。

查询的时候可能需要组合Mysql 和Elasticsearch 的查询结果。

这里没有跳过数据库，直接把结果数据写入Elasticsearch 这类搜索系统，是因为搜索系统的数据实时写入能力和数据可靠性不如数据库，业界通常是把数据库和搜索系统整合，整合下的系统兼备了数据库和搜索系统的优势，但是两个引擎之间数据的同步和跨系统查询对运维和开发带来很多额外的成本。

新的大数据架构Lambda plus通过前面的分析，相信大家都会有一个疑问，有没有简化的的大数据架构，在可以满足Lambda 对计算需求的假设，又能减少存储计算以及模块的个数呢。

Linkedin 的Jay Kreps 提出了Kappa 架构，关于Lambda 和Kappa 的对比可以参考" 云上大数据方案" 这篇，这里不展开详细对比，简单说下，Kappa 为了简化两份存储，取消了全量的数据存储库，通过在Kafka 保留更长日志，当有回溯重新计算需求到来时，重新从队列的头部开始订阅数据，再一次用流的方式处理Kafka 队列中保存的所有数据。

这样设计的好处是解决了需要维护两份存储和两套计算逻辑的痛点，美中不足的地方是队列可以保留的历史数据毕竟有限，难以做到无时间限制的回溯。

分析到这里，我们沿着Kappa 针对Lambda 的改进思路，向前多思考一些：假如有一个存储引擎，既满足数据库可以高效的写入和随机查询，又能像队列服务，满足先进先出，是不是就可以把Lambda 和Kappa 架构揉合在一起，打造一个Lambda plus 架构呢？新架构在Lambda 的基础上可以提升以下几点：1.在支持流计算和批计算的同时，让计算逻辑可以复用，实现“一套代码两类需求”。

2.统一历史数据全量和在线实时增量数据的存储，实现“一份存储两类计算”。

3.为了方便舆情结果查询需求，“batch view”和“real-time view”存储在既可以支持高吞吐的实时写入，也可以支持多字段组合搜索和全文检索。