基于大数据的舆情分析系统架构（架构篇）

通过这个流程图，让我们了解了整个舆情系统的建设过程中，需要经过不同的存储和计算系统。对数据的组织和查询有不同的需求。在业界基于开源的大数据系统并结合 Lambda 架构，整套系统可以设计如下：

图 3 开源舆情架构图 系统的最上游是分布式的爬虫引擎，根据抓取任务抓取订阅的网页原文内容。爬虫会把抓取到的网页内容实时写入 Kafka 队列，进入 Kafka 队列的数据根据前面描述的计算需求，会实时流入流计算引擎（例如 Spark 或者 Flink），也会持久化存储在 Hbase，进行全量数据的存储。全量网页的存储可以满足网页爬取去重，批量离线计算的需求。 流计算会对原始网页进行结构化提取，将非结构化网页内容转化为结构数据并进行分词，例如提取出网页的标题，作者，摘要等，对正文和摘要内容进行分词。提取和分词结果会写回 Hbase。结构化提取和分词后，流计算引擎会结合情感词库进行网页情感分析，判断是否有舆情产生。 流计算引擎分析的舆情结果存储 Mysql 或者 Hbase 数据库中，为了方便结果集的搜索查看，需要把数据同步到一个搜索引擎例如 Elasticsearch，方便进行属性字段的组合查询。如果是重大的舆情时间，需要写入 Kafka 队列触发舆情报警。 全量的结构化数据会定期通过 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 的基础上可以提升以下几点：

（编辑：西安站长网）

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