海量数据下的舆情分析，该如何搭建？

实时计算在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对计算需求的假设，又能减少存储计算以及模块的个数呢?

（编辑：宿州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!