加入收藏 | 设为首页 | 会员中心 | 我要投稿 厦门网 (https://www.xiamenwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 创业 > 正文

基于大数据的舆情分析系统架构(架构篇)

发布时间:2019-06-14 18:54:28 所属栏目:创业 来源:InfoQ
导读:副标题#e# 互联网的飞速发展促进了很多新媒体的发展,不论是知名的大 V,明星还是围观群众都可以通过手机在微博,朋友圈或者点评网站上发表状态,分享自己的所见所想,使得人人都有了麦克风。不论是热点新闻还是娱乐八卦,传播速度远超我们的想象。可以在短

图 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 的基础上可以提升以下几点:

在支持流计算和批计算的同时,让计算逻辑可以复用,实现“一套代码两类需求”。 统一历史数据全量和在线实时增量数据的存储,实现“一份存储两类计算”。 为了方便舆情结果查询需求,“batch view”和“real-time view”存储在既可以支持高吞吐的实时写入,也可以支持多字段组合搜索和全文检索。

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

图 4 Lambda Plus 架构 数据流实时写入一个分布式的数据库,借助于数据库查询能力,全量数据可以轻松的对接批量计算系统进行离线处理。 数据库通过数据库日志接口,支持增量读取,实现对接流计算引擎进行实时计算。 批计算和流计算的结果写回分布式数据库,分布式数据库提供丰富的查询语意,实现计算结果的交互式查询。

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

云上舆情系统架构

(编辑:厦门网)

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

热点阅读