实时抓取网页数据( 大数据舆情系统对数据存储和计算系统会有哪些需求)

　　实时抓取网页数据(

大数据舆情系统对数据存储和计算系统会有哪些需求)

　　海量数据下如何构建舆情分析？

　　互联网的快速发展促进了许多新媒体的发展。无论是知名大V、明星还是围观者，都可以在微博、朋友圈发布动态，或者通过手机评论网站，分享自己的经历。想一想，“每个人都有一个麦克风”。无论是热点新闻还是娱乐八卦，传播速度都远超我们的想象。一条消息可以在短短几分钟内被数万人转发，数以百万计的人阅读。海量信息可以爆炸式传播，如何实时掌握信息并进行相应处理？真的很难对付吗？今天，

　　在大数据时代，除了媒体信息外，各种电商平台的产品订单量和用户购买评论都会对后续消费者产生很大影响。商家的产品设计师需要汇总统计和分析各个平台的数据，作为决定后续产品开发的依据。公司公关和营销部门也需要及时处理舆情，而这一切也意味着传统舆情系统升级为大数据舆情采集分析系统。细看大数据舆情系统，对我们的数据存储和计算系统提出以下要求：

　　海量原创数据的实时存储：要实现一套完整的舆情系统，需要有上游采集的原创输出，即爬虫系统。爬虫需要采集 各种门户，自媒体 网页内容。爬取前需要去重，爬取后需要分析提取，比如爬取子页面。网页原创数据的处理：无论是主流门户还是自媒体网页信息，爬取后都需要做一定的数据提取，将原创网页内容转化为结构化数据，比如文章的标题，摘要等。如果是产品评论消息，还需要提取有效评论。结构化数据舆情分析：当各种原创输出变成结构化数据时，我们需要一个实时计算产品来对各种输出进行合理的分类，并对分类的内容进行进一步的情感化标记。根据业务的需要，这里可能会产生不同的输出，比如品牌是否有当下的热点话题、舆情影响力分析、播出路径分析、参与用户统计和画像、舆情情绪分析或是否有是一个重大警告。舆情分析系统中的中间数据和结果数据的存储，交互分析和查询：从网页原创数据的清洗到最终的舆情表，会产生多种类型的数据。其中部分数据将提供给数据分析学生，优化舆情分析系统，并将部分数据提供给业务部门，根据舆论结果作出决策。这些查询可能非常灵活，需要我们的存储系统具备全文检索和交互式分析能力，以实现灵活的多字段组合。重大舆情事件实时预警：除了对舆情结果的正常搜索和展示需求外，还需要能够在重大事件发生时做到实时预警。

　　本文主要提供架构设计。首先介绍当前主流的大数据计算架构，分析一些优缺点，然后介绍舆情大数据架构。

　　系统设计

　　需求分析

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

　　图1 舆情系统业务流程

　　原创网页存储库，这个库需要能够支持海量数据、低成本、低延迟的写入。网页数据写入后，进行实时结构化提取，然后对提取的数据进行降噪、分词、图像OCR处理。对分词文本和图片进行情感识别，生成舆情数据结果集。传统的线下全量计算难以满足舆情系统的时效性要求。计算引擎在做数据处理时，可能还需要从存储库中获取一些元数据，比如用户信息、情感词元数据信息等。除了实时计算环节，我们需要定期对*敏*感*词*做一些聚类，优化我们的情感词识别库，或者根据业务需求触发上游情感处理规则的更新，根据新的情感标注库对*敏*感*词*进行舆情计算. . 由此产生的舆论数据集具有不同类型的使用需求。对于重大舆论，需要实时预警。完整的舆情结果数据展示层需要支持全文检索和灵活的属性字段组合查询。在业务上，可以根据属性字段的置信度、舆论的时间、或者关键词的组合来分析。并根据新的情感标签库对*敏*感*词*进行舆情计算。. 由此产生的舆论数据集具有不同类型的使用需求。对于重大舆论，需要实时预警。完整的舆情结果数据展示层需要支持全文检索和灵活的属性字段组合查询。在业务上，可以根据属性字段的置信度、舆论的时间、或者关键词的组合来分析。并根据新的情感标签库对*敏*感*词*进行舆情计算。. 由此产生的舆论数据集具有不同类型的使用需求。对于重大舆论，需要实时预警。完整的舆情结果数据展示层需要支持全文检索和灵活的属性字段组合查询。在业务上，可以根据属性字段的置信度、舆论的时间、或者关键词的组合来分析。完整的舆情结果数据展示层需要支持全文检索和灵活的属性字段组合查询。在业务上，可以根据属性字段的置信度、舆论的时间、或者关键词的组合来分析。完整的舆情结果数据展示层需要支持全文检索和灵活的属性字段组合查询。在业务上，可以根据属性字段的置信度、舆论的时间、或者关键词的组合来分析。

　　根据前面的介绍，舆情大数据分析系统需要两种计算，一种是实时计算，包括海量网页内容的实时提取、情感词分析和网页舆情结果的存储。另一种是离线计算。系统需要对历史数据进行回溯，结合人工标注等方法优化情感词库，并对部分实时计算结果进行修正。因此，在系统设计中，需要选择一个既能进行实时计算又能进行批量离线计算的系统。在开源大数据解决方案中，Lambda架构正好可以满足这些需求。我们来介绍一下 Lambda 架构。

　　Lambda 架构（维基）

　　图2 Lambda架构图

　　Lambda架构可以说是Hadoop和Spark系统下最火的大数据架构。这种架构最大的优势在于，它既支持批量计算，又支持海量数据的处理（即离线处理）和实时流式处理（即热数据处理）。

　　它是如何实施的？首先，上游一般是kafka等队列服务，实时存储数据的写入。kafka队列会有两个订阅者，一个是全量数据，也就是图片的上半部分，全量数据会存储在HDFS这样的存储介质上。当离线计算任务到来时，计算资源（如Hadoop）将访问存储系统上的全量数据，执行全批量计算处理逻辑。

　　经过map/reduce链接后，将完整的结果写入Hbase等结构化存储引擎，提供给业务方查询。队列的另一个消费者订阅者是流计算引擎。流计算引擎经常会消耗队列中的数据进行实时计算和处理。例如，Spark Streaming 实时订阅 Kafka 数据，流计算结果也写入结构化数据引擎。批量计算和流计算的结果写入的结构化存储引擎就是上图中标为3的“Serving Layer”。该层主要提供结果数据的展示和查询。

　　在这个架构中，批量计算的特点是需要支持海量数据的处理，并根据业务的需要关联一些其他的业务指标进行计算。批量计算的优点是计算逻辑可以根据业务需要灵活调整，计算结果可以反复重新计算，相同的计算逻辑不会改变多次计算的结果。批量计算的缺点是计算周期比较长，难以满足实时结果的需求。因此，随着大数据计算的演进，提出了对实时计算的需求。

　　实时计算是通过 Lambda 架构中的实时数据流来实现的。与批处理相比，增量数据流的处理方式决定了数据往往是新生成的数据，即热点数据。由于数据热点的特性，流计算可以满足业务对计算的低延迟要求。例如，在一个舆情分析系统中，我们常常希望能在网页上抓取舆情信息，在分钟级得到计算结果。有足够的时间进行舆论反馈。下面我们来详细看看如何基于Lambda架构的思想来实现一套完整的舆情大数据架构。

　　开源舆情大数据解决方案

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

　　图3 开源舆情架构图

　　1. 系统最上游的是分布式爬虫引擎，根据爬虫任务抓取订阅网页的原创内容。爬虫会将抓取的网页内容实时写入Kafka队列，进入Kafka队列的数据会根据上述计算需求实时流入流计算引擎（如Spark或Flink），也将永久存储在 Hbase 中，用于完整存储数据。完整网页的存储可以满足网页爬取和去重以及批量离线计算的需求。

　　2. 流计算会对原创网页进行结构化提取，将非结构化的网页内容转化为结构化数据并进行分词，如提取网页的标题、作者、摘要等，对网页进行分词文本和抽象内容。提取和标记化结果写回 Hbase。经过结构化提取和分词后，流计算引擎会结合情感词库，对网页情感进行分析，判断是否有舆情。

　　3. 流计算引擎分析的舆情结果存储在Mysql或Hbase数据库中。为了方便结果集的搜索和查看，需要将数据同步到Elasticsearch等搜索引擎，方便属性字段的组合查询。如果是重大舆情时间，需要写入Kafka队列触发舆情警报。

　　4. 全量结构化数据将通过Spark系统定期离线计算，更新情感词库或接受新的计算策略重新计算历史数据，修正实时计算结果。

　　开源架构分析

　　上述舆情大数据架构使用Kafka连接流计算，Hbase连接批处理计算，实现Lambda架构中的“批处理视图”和“实时视图”。整个架构比较清晰，可以同时满足线上线下的需求。两种类型的计算要求。但是，将这个系统应用到生产中并不容易，主要有以下几个原因：

　　整套架构涉及到很多存储和计算系统，包括：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 队列中的数据。这种设计的好处是解决了需要维护两个存储和两组计算逻辑的痛点。美中不足的是队列可以保留的历史数据是有限的，没有时间限制很难追溯。

　　分析到这一步，我们沿用了Kappa对Lambda的改进思路，思考的更远一点：如果有存储引擎，既能满足数据库的高效写入和随机查询，又能充当队列，满足先进先出的要求。难道不能结合 Lambda 和 Kappa 架构来创建一个 Lambda plus 架构吗？

　　新架构可以在 Lambda 的基础上改进以下几点：

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

　　全量历史数据与在线实时增量数据统一存储，实现“一存两算”。

　　为了方便舆情结果的查询需求，“批量视图”和“实时视图”存储在高通量实时写作、多字段组合检索和全文检索中。

　　综上所述，整个新架构的核心是解决存储问题以及如何灵活对接计算。我们希望整个解决方案类似于以下架构：

　　图 4 Lambda Plus 架构

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

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

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

　　在整套架构中，存储层通过结合数据库主表数据和数据库日志来代替大数据架构中的队列服务，计算系统选择了天然支持批流的计算引擎，比如Flink或者Spark . 这样，我们不仅可以像 Lambda 一样进行精确的历史数据回溯，还可以像 Kappa 架构一样，用一套逻辑来存储和处理两类计算任务。我们称这样的一套架构为“Lambda plus”。下面详细讲解如何在阿里云上搭建这样一套大数据架构。

　　云舆情系统架构

　　在阿里云众多的存储和计算产品中，我们选择了两款产品来实现整个舆情大数据系统，以满足上述大数据架构的需求。存储层使用阿里云开发的分布式多模型数据库Tablestore，计算层使用Blink实现流批一体化计算。

　　图5 云舆情大数据架构

　　在存储层面，这个架构都是基于Tablestore，一个数据库来满足不同的存储需求。根据此前舆情系统的介绍，网络爬虫数据在系统流程中将有四个阶段：网页原创内容、网页结构化数据、分析规则。元数据与舆情结果、舆情结果指数。

　　我们利用 Tablestore 的宽行和无模式特性，将原创网页和网页结构化数据合并为一个网页数据。Web数据表和计算系统通过Tablestore新的功能通道服务连接起来。通道服务基于数据库日志，数据的组织结构按照数据写入的顺序存储。正是这个特性使数据库具备了队列流式消费能力。存储引擎既可以对数据库进行随机访问，也可以对队列进行顺序访问，这也满足了上面提到的集成Lambda和kappa架构的需求。分析规则元数据表由分析规则和情感词库组层组成，

　　计算系统采用阿里云实时流计算产品Blink。Blink 是一款同时支持流计算和批计算的实时计算产品。并且和Tablestore类似，可以轻松实现分布式横向扩展，让计算资源随着业务数据的增长而弹性扩展。使用 Tablestore + Blink 的优势如下：

　　Tablestore 与 Blink 深度集成，支持源表、维度表、目的表。企业不需要为数据流开发代码。

　　整套架构大大减少了组件数量，从开源产品的6个到7个组件减少到2个。Tablestore和Blink是全托管产品，零运维，可以实现很好的横向弹性，不存在业务高峰扩张。压力大大降低了大数据架构的运维成本。

　　业务侧只需要关注数据处理逻辑，与Tablestore的交互逻辑已经集成在Blink中。

　　在开源方案中，如果数据库源要连接实时计算，还需要双写一个队列，让流计算引擎消费队列中的数据。在我们的架构中，数据库既是数据表，也是实时增量数据消费的队列通道。大大简化了架构的开发和使用成本。

　　流和批处理的融合在舆情系统中至关重要，因此我们需要一个实时计算引擎。除了实时计算，Blink 还支持 Tablestore 数据的批处理，在业务低峰期往往需要批处理。一些数据作为反馈结果写回Tablestore，比如情感分析反馈等。那么一套可以同时支持流处理和批处理的架构是最好的。一套架构带来的好处是，一套分析代码既可以做实时流计算，也可以做离线批处理。

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

　　运维复杂，需要hbase和solr系统的运维能力，同时需要维护数据同步链路。

　　Solr的数据一致性不如Hbase，Hbase和Solr中数据的语义也不完全相同。此外，Solr/Elasticsearch 在数据一致性方面很难做到数据库那么严格。在某些极端情况下，会出现数据不一致的情况，开源解决方案很难实现跨系统的一致比较。

　　查询接口需要维护两套API，需要同时使用Hbase客户端和Solr客户端。索引中没有的字段需要针对Hbase主动搜索，不好用。

　　参考

　　Lambda大数据架构：

　　Kappa 大数据架构：

　　Lambda 和 Kappa 架构比较：