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

前言

互联网的飞速发展促进了不少新媒体的发展，不管是知名的大V，明星仍是围观群众均可以经过手机在微博，朋友圈或者点评网站上发表状态，分享本身的所见所想，使得“人人都有了麦克风”。不管是热点新闻仍是娱乐八卦，传播速度远超咱们的想象。能够在短短数分钟内，有数万计转发，数百万的阅读。如此海量的信息能够获得爆炸式的传播，如何可以实时的把握民情并做出对应的处理对不少企业来讲都是相当重要的。大数据时代，除了媒体信息之外，商品在各种电商平台的订单量，用户的购买评论也都对后续的消费者产生很大的影响。商家的产品设计者须要汇总统计和分析各种平台的数据作为依据，决定后续的产品发展，公司的公关和市场部门也须要根据舆情做出相应的及时处理，而这一切也意味着传统的舆情系统升级成为大数据舆情采集和分析系统。 分析完舆情场景后，咱们再来具体细化看下大数据舆情系统，对咱们的数据存储和计算系统提出哪些需求：

• 海量原始数据的实时入库：为了实现一整套舆情系统，须要有上游原始输出的采集，也就是爬虫系统。爬虫须要采集各种门户，自媒体的网页内容。在抓取前须要去重，抓取后还须要分析提取，例如进行子网页的抓取。
• 原始网页数据的处理：不管是主流门户仍是自媒体的网页信息，抓取后咱们须要作必定的数据提取，把原始的网页内容转化为结构化数据，例如文章的标题，摘要等，若是是商品点评类消息也须要提取有效的点评。
• 结构化数据的舆情分析：当各种原始输出变成结构化的数据后，咱们须要有一个实时的计算产品把各种输出作合理的分类，进一步对分类后的内容进行情感打标。根据业务的需求这里可能会产生不一样的输出，例如品牌当下是否有热点话题，舆情影响力分析，转播路径分析，参与用户统计和画像，舆论情感分析或者是否有重大预警。
• 舆情分析系统中间和结果数据的存储，交互分析查询：从网页原始数据清洗到最终的舆情报表这中间会产生不少类型的数据。这些数据有的会提供给数据分析同窗进行舆情分析系统的调优，有的数据会提供给业务部门根据舆情结果进行决策。这些查询可能会很灵活，须要咱们的存储系统具有全文检索，多字段组合灵活的交互分析能力。
• 重大舆情事件的实时预警：对于舆情的结果除了正常的搜索和展现需求之外，当有重大事件出现咱们须要能作到实时的预警。

咱们计划分两篇介绍完整的舆情新架构，第一篇主要是提供架构设计，会先介绍时下主流的大数据计算架构，并分析一些优缺点，而后引入舆情大数据架构。第二篇会有完整的数据库表设计和部分示例代码。你们敬请期待。 了解更多详细内容可点击加关注

系统设计

需求分析 结合文章开头对舆情系统的描述，海量大数据舆情分析系统流程图大致以下：

• 原始网页存储库，这个库须要能支持海量数据，低成本，低延时写入。网页数据写入后，要作实时结构化提取，提取出来的数据再进行降噪，分词，图片ocr处理等。对分词文本，图片进行情感识别产生舆情数据结果集。传统的离线全量计算很难知足舆情系统的时效性需求。
• 计算引擎在作数据处理时，可能还须要从存储库中获取一些元数据，例如用户信息，情感词元数据信息等。
• 除了实时的计算链路，对存量数据按期要作一些聚类，优化咱们的情感词识别库，或者上游根据业务须要触发情感处理规则更新，根据新的情感打标库对存量数据作一次舆情计算。
• 舆情的结果数据集有不一样类的使用需求。对于重大舆情，须要作实时的预警。完整的舆情结果数据展现层须要支持全文检索，灵活的属性字段组合查询。业务上可能根据属性字段中的置信度，舆情时间，或者关键词组合进行分析。 根据前面的介绍，舆情大数据分析系统须要两类计算，一类是实时计算包括海量网页内容实时抽取，情感词分析并进行网页舆情结果存储。另外一类是离线计算，系统须要对历史数据进行回溯，结合人工标注等方式优化情感词库，对一些实时计算的结果进行矫正等。因此在系统设计上，须要选择一套既能够作实时计算又能作批量离线计算的系统。在开源大数据解决方案中，Lambda架构刚好能够知足这些需求，下面咱们来介绍下Lambda的架构。

Lambda架构 （wiki）

Lambda架构能够说是Hadoop，Spark体系下最火的大数据架构。这套架构的最大优点就是在支持海量数据批量计算处理（也就是离线处理）同时也支持流式的实时处理（即热数据处理）。 具体是如何实现的呢，首先上游通常是一个队列服务例如kafka，实时存储数据的写入。kafka队列会有两个订阅者，一个是全量数据即图片中上半部分，全量数据会被存储在相似HDFS这样的存储介质上。当有离线计算任务到来，计算资源（例如Hadoop）会访问存储系统上的全量数据，进行全量批计算的处理逻辑。通过map/reduce环节后全量的结果会被写入一个结构化的存储引擎例如Hbase中，提供给业务方查询。队列的另外一个消费订阅方是流计算引擎，流计算引擎每每会实时的消费队列中的数据进行计算处理，例如Spark Streaming实时订阅Kafka的数据，流计算结果也会写入一个结构化数据引擎。批量计算和流计算的结果写入的结构化存储引擎即上图标注3的"Serving Layer"，这一层主要提供结果数据的展现和查询。 在这套架构中，批量计算的特色是须要支持处理海量的数据，并根据业务的需求，关联一些其余业务指标进行计算。批量计算的好处是计算逻辑能够根据业务需求灵活调整，同时计算结果能够反复重算，一样的计算逻辑屡次计算结果不会改变。批量计算的缺点是计算周期相对较长，很难知足实时出结果的需求，因此随着大数据计算的演进，提出了实时计算的需求。实时计算在Lambda架构中是经过实时数据流来实现，相比批处理，数据增量流的处理方式决定了数据每每是最近新产生的数据，也就是热数据。正由于热数据这一特色，流计算能够知足业务对计算的低延时需求，例如在舆情分析系统中，咱们每每但愿舆情信息能够在网页抓取下来后，分钟级别拿到计算结果，给业务方充足的时间进行舆情反馈。下面咱们就来具体看一下，基于Lambda架构的思想如何实现一套完整的舆情大数据架构。

开源舆情大数据方案

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

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”存储在既能够支持高吞吐的实时写入，也能够支持多字段组合搜索和全文检索。 总结起来就是整套新架构的核心是解决存储的问题，以及如何灵活的对接计算。咱们但愿整套方案是相似下面的架构：

1.数据流实时写入一个分布式的数据库，借助于数据库查询能力，全量数据能够轻松的对接批量计算系统进行离线处理。 2.数据库经过数据库日志接口，支持增量读取，实现对接流计算引擎进行实时计算。 批计算和流计算的结果写回分布式数据库，分布式数据库提供丰富的查询语意，实现计算结果的交互式查询。 3.整套架构中，存储层面经过结合数据库主表数据和数据库日志来取代大数据架构中的队列服务，计算系统选取自然支持批和流的计算引擎例如Flink或者Spark。这样一来，咱们既能够像Lambda进行无限制的历史数据回溯，又能够像Kappa架构同样一套逻辑，存储处理两类计算任务。这样的一套架构咱们取名为“Lambda plus”，下面就详细展开如何在阿里云上打造这样的一套大数据架构。

云上舆情系统架构

在阿里云众多存储和计算产品中，贴合上述大数据架构的需求，咱们选用两款产品来实现整套舆情大数据系统。存储层面使用阿里云自研的分布式多模型数据库Tablestore，计算层选用Blink来实现流批一体计算。

这套架构在存储层面，所有基于Tablestore，一个数据库解决不一样存储需求，根据以前舆情系统的介绍，网页爬虫数据在系统流动中会有四个阶段分别是原始网页内容，网页结构化数据，分析规则元数据和舆情结果，舆情结果索引。咱们利用Tablestore宽行和schema free的特性，合并原始网页和网页结构化数据成一张网页数据。网页数据表和计算系统经过Tablestore新功能通道服务进行对接。通道服务基于数据库日志，数据的组织结构按照数据的写入顺序进行存储，正是这一特性，赋能数据库具有了队列流式消费能力。使得存储引擎既能够具有数据库的随机访问，也能够具有队列的按照写入顺序访问，这也就知足咱们上面提到整合Lambda和kappa架构的需求。分析规则元数据表由分析规则，情感词库组层，对应实时计算中的维表。 计算系统这里选用阿里云实时流计算产品Blink，Blink是一款支持流计算和批计算一体的实时计算产品。而且相似Tablestore能够很容易的作到分布式水平扩展，让计算资源随着业务数据增加弹性扩容。使用Tablestore + Blink的优点有如下几点：

1.Tablestore已经深度和Blink进行整合，支持源表，维表和目的表，业务无需为数据流动开发代码。 2.整套架构大幅下降组建个数，从开源产品的6～7个组建减小到2个，Tablestore和Blink都是全托管0运维的产品，而且都能作到很好的水平弹性，业务峰值扩展无压力，使得大数据架构的运维成本大幅下降。 3.业务方只须要关注数据的处理部分逻辑，和Tablestore的交互逻辑都已经集成在Blink中。 4.开源方案中，若是数据库源但愿对接实时计算，还须要双写一个队列，让流计算引擎消费队列中的数据。咱们的架构中数据库既做为数据表，又是队列通道能够实时增量数据消费。大大简化了架构的开发和使用成本。 5.流批一体，在舆情系统中实时性是相当重要的，因此咱们须要一个实时计算引擎，而Blink除了实时计算之外，也支持批处理Tablestore的数据， 在业务低峰期，每每也须要批量处理一些数据并做为反馈结果写回Tablestore，例如情感分析反馈等。那么一套架构既能够支持流处理又能够支持批处理是再好不过。这里咱们能够参考以前的一篇文章《实时计算最佳实践：基于表格存储和Blink的大数据实时计算》。一套架构带来的优点是，一套分析代码既能够作实时流计算又能够离线批处理。

整个计算流程会产生实时的舆情计算结果。重大舆情事件的预警，经过Tablestore和函数计算触发器对接来实现。Tablestore和函数计算作了增量数据的无缝对接，经过结果表写入事件，能够轻松的经过函数计算触发短信或者邮件通知。完整的舆情分析结果和展现搜索利用了Tablestore的新功能多元索引，完全解决了开源Hbase+Solr多引擎的痛点：

1.运维复杂，须要有运维hbase和solr两套系统的能力，同时还须要维护数据同步的链路。 2.Solr数据一致性不如Hbase，在Hbase和Solr数据语意并非彻底一致，加上3.Solr/Elasticsearch在数据一致性很难作到像数据库那么严格。在一些极端状况下会出现数据不一致的问题，开源方案也很难作到跨系统的一致性比对。 查询接口须要维护两套API，须要同时使用Hbase client和Solr client，索引中没有的字段须要主动反查Hbase，易用性较差。

总结

本文基于《百亿级全网舆情分析系统存储设计》并结合Tablestore的新功能作了现代大数据舆情系统的架构升级，实现了海量信息下的实时舆情分析存储系统。也介绍了开源方案，并和咱们的方案作了详细的对比。 点击了解更多详细内容 最高￥2000云产品通用代金券 promotion.aliyun.com/ntms/yunpar…

【助力企业上云】性能级主机2-5折 promotion.aliyun.com/ntms/act/en…

【全民云计算】云主机低至4折 promotion.aliyun.com/ntms/act/qw…

【HI拼购2折起】拼着买更便宜 www.aliyun.com/acts/hi-gro…