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

实时计算在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的基础上可以提升以下几点：

在支持流计算和批计算的同时，让计算逻辑可以复用，实现“一套代码两类需求”。

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

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

总结起来就是整套新架构的核心是解决存储的问题，以及如何灵活的对接计算。我们希望整套方案是类似下面的架构：

图4 Lambda Plus架构

数据流实时写入一个分布式的数据库，借助于数据库查询能力，全量数据可以轻松的对接批量计算系统进行离线处理。

数据库通过数据库日志接口，支持增量读取，实现对接流计算引擎进行实时计算。

批计算和流计算的结果写回分布式数据库，分布式数据库提供丰富的查询语意，实现计算结果的交互式查询。

整套架构中，存储层面通过结合数据库主表数据和数据库日志来取代大数据架构中的队列服务，计算系统选取天然支持批和流的计算引擎例如Flink或者Spark。这样一来，我们既可以像Lambda进行无限制的历史数据回溯，又可以像Kappa架构一样一套逻辑，存储处理两类计算任务。这样的一套架构我们取名为“Lambda plus”，下面就详细展开如何在阿里云上打造这样的一套大数据架构。

云上舆情系统架构

（编辑：核心网）

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