实时抓取网页数据(全网舆情分析系统设计中可能会遇到的的问题？)

　　实时抓取网页数据(全网舆情分析系统设计中可能会遇到的的问题？)

　　摘要： 前言 在当前的互联网信息浪潮下，信息传播的速度远远超出我们的想象。一条微博大V的帖子，一条朋友圈的动态，一条热门论坛的新闻，或者购物平台的一条购物评论，都可能产生数以万计的转发、关注和点赞。如果是一些不合理的负面评论，就会激起人们的负面情绪，甚至影响消费者对企业品牌的认可。如果不能及时采取正确的措施，将会造成不可估量的损失。

　　前言

　　在当前的互联网信息浪潮下，信息传播的速度远远超出我们的想象。一条微博大V的帖子，一条朋友圈的动态，一条热门论坛的新闻，或者购物平台的一条购物评论，都可能产生数以万计的转发、关注和点赞。如果是一些不合理的负面评论，就会激起人们的负面情绪，甚至影响消费者对企业品牌的认可。如果不能及时采取正确的措施，将会造成不可估量的损失。因此，我们需要一个高效的全网舆情分析系统来帮助我们实时观察舆情。

　　这个全网舆情分析系统可以存储百亿网页数据，实时抓取和存储新网页，并为新网页实时提取元数据。随着提取结果，我们还需要进行进一步的挖掘分析，包括但不限于

　　舆情影响力诊断，从传播的幅度和传播趋势进行预测，判断舆情最终是否会形成。

　　传播路径分析，分析舆情传播的关键路径。

　　用户画像为舆论参与者提供了一个共同特征的轮廓，例如性别、年龄、地区和感兴趣的话题。

　　情绪分析，分析新闻或评论是正面还是负面。在情感分类之后进行统计聚合。

　　预警设置，我们支持设置舆情讨论量阈值，达到阈值后通知推送业务方，避免错过舆论的黄金参与时间。

　　这些挖掘出来的舆情结果会被推送到需求方，同时也提供了一个接口供各业务方搜索查询。接下来，我们将讨论系统设计中可能遇到的问题。我们将重点关注系统设计中与存储相关的话题，并为这些问题找到最优的解决方案。

　　系统设计

　　一个舆情系统，首先需要一个爬虫引擎去采集各大主流门户、购物网站、社区论坛、微博的原创页面内容、朋友圈的各种新闻资讯. 采集对于海量的网页，消息数据（上百亿）需要实时存储。在根据网站url获取网页之前，需要判断是否是之前爬过的页面，避免不必要的重复爬取。采集网页之后，我们需要提取网页，去除不必要的标签，提取标题、摘要、正文内容、评论等，提取的内容进入存储系统，方便后续查询。同时，新增的抽取结果需要推送到计算平台进行统计分析、报表生成或后续舆情检索等功能。根据算法，计算内容可能需要新数据或完整数据。舆论本身的时间敏感性决定了我们的系统必须能够高效地处理这些新内容。最好延迟几秒后检索新的热搜。

　　我们可以将整个数据流总结如下：

　　根据上图不难发现，要设计一个全网舆情的存储分析平台，我们需要处理爬取、存储、分析、搜索和展示。具体来说，我们需要解决以下问题：

　　如何高效存储百亿原创网页信息，为了提高舆情分析的全面性和准确性，我们往往希望尽可能多的抓取网页信息，然后按照我们设定的权重进行聚合。因此，整个网页的历史数据库会比较大，积累了数百亿的网页信息，数据量可以达到数百TB甚至数PB。在数据量如此之大的情况下，我们还需要做到读写毫秒级的低延迟，这使得传统数据库难以满足需求。

　　在爬虫爬取网页之前，如何判断之前是否被爬过？对于普通的网页，舆论关心的是时效性。或许我们只想爬取同一个网页一次，那我们就可以用网页地址来爬取Heavy，减少不必要的网页资源浪费。所以我们需要分布式存储来提供基于网页的高效随机查询。

　　如何在新的原创网页存储后进行实时结构化提取，并存储提取结果。这里我们的原创网页可能收录各种html标签，我们需要去掉这些html标签，提取出文章的标题、作者、发布时间等。这些内容为后续舆情情绪分析提供了必要的结构化数据。

　　如何高效连接计算平台，对新提取的结构化数据进行流式传输，进行实时计算。这里我们需要对网页内容和消息描述进行分类，进行情感识别，并对识别后的结果进行统计分析。由于全盘分析的时效性差，舆论往往关注最新的新闻和评论，所以必须做增量分析。

　　如何提供高效的舆情搜索，除了订阅固定的关键词舆情，用户还做一些关键词搜索。比如你想了解竞品公司新产品的一些舆情分析。

　　如何实现新舆论的实时推送？为了保证舆情的及时性，不仅要坚持舆情分析结果，还要支持舆情结果的推送。推送的内容通常是我们实时分析的新舆情。

　　系统结构

　　针对以上问题，我们来介绍一下如何基于阿里云上的各种云产品，搭建一个全网百亿级别的舆情分析平台。我们将重点关注存储产品的选择以及如何高效连接各类计算。，搜索平台。

　　我们使用ECS作为爬虫引擎，可以根据爬取的数量确定使用ECS的机器资源数量，也可以在每天的高峰期临时扩展资源用于网络爬取。抓取原创网页后，将原创网页地址和网页内容写入存储系统。同时，如果要避免重复爬取，爬虫引擎在爬取前要根据url列表去重。存储引擎需要支持低延迟的随机访问查询，判断当前url是否已经存在，如果存在，则无需再次爬取。

　　为了实现网页原创内容的实时提取，我们需要将新增的页面推送到计算平台。以前的架构往往需要应用层的双重写入，即原创网页数据存储在数据库中，我们反复将数据的副本写入计算平台。这样的架构需要我们维护两组编写逻辑。同样，结构化增量进入舆情分析平台也存在类似问题。提取的结构化元数据也需要双写入舆情分析平台。舆情分析结果也需要写入分布式存储，推送到搜索平台。在这里我们可以发现图中的三个红线会带来我们对三个数据源的双写需求。这会增加代码开发的工作量，也会导致复杂的系统实现和维护。每个数据源的双写需要知道下游的存在，或者使用消息服务通过双写消息做解耦。mysql等传统数据库支持增量日志binlog的订阅。如果分布式存储产品可以支持大的访问和存储容量，还可以提供增量订阅，可以大大简化我们的架构。每个数据源的双写需要知道下游的存在，或者使用消息服务通过双写消息做解耦。mysql等传统数据库支持增量日志binlog的订阅。如果分布式存储产品可以支持大的访问和存储容量，还可以提供增量订阅，可以大大简化我们的架构。每个数据源的双写需要知道下游的存在，或者使用消息服务通过双写消息做解耦。mysql等传统数据库支持增量日志binlog的订阅。如果分布式存储产品可以支持大的访问和存储容量，还可以提供增量订阅，可以大大简化我们的架构。

　　网页数据采集存储后，会增量流入我们的计算平台，实时提取元数据。这里我们可以使用函数计算。当有新的页面需要提取时，触发函数计算的托管函数执行网页元数据。提炼。提取出来的结果存入存储系统并持久化后，同时推送到MaxCompute进行舆情分析，如情感分析、文本聚类等。可能会有一些公共信息表数据、用户情绪数据统计等结果。舆情结果会写入存储系统和搜索引擎，部分报告和阈值告警会推送给订阅者。搜索引擎的数据提供给在线舆情检索系统。

　　介绍完完整的架构后，我们再来看看阿里云上如何进行存储选型。

　　存储选择

　　通过架构的介绍，我们总结一下存储选型的要求：

　　可支持海量数据存储（TB/PB级别）、高并发访问（10万到1000万TPS）、低访问延迟。

　　采集的数量会随着采集订阅的网页源的调整而动态调整。同时，爬虫在不同时间段爬取的网页数量在一天之内也会有明显的波峰和波谷，所以数据库需要能够灵活的扩缩容。

　　有了自由表属性结构，对于普通网页和社交平台页面的信息，我们需要注意的属性可能会有很大的不同。灵活的模式将有助于我们的扩展。

　　对于旧数据，您可以选择自动过期或分层存储。由于舆情数据往往集中在近期热点，旧数据的访问频率较低。

　　需要更好的增量通道，新增数据可以定期导出到计算平台。上图中有3条红色虚线。这三个部分有一个共同的特点。增量可以实时引导到相应的计算平台进行计算，并将计算结果写入相应的存储引擎。如果数据库引擎本身支持增量，可以大大简化架构，减少之前在全读区过滤增量，或者双写客户端实现增量的逻辑。

　　需要有更好的搜索解决方案（它支持自身或可以将数据无缝连接到搜索引擎）。

　　带着这些需求，我们需要使用分布式的NoSQL数据来解决海量数据的存储和访问。多链路增量数据访问的需求和业务高峰访问的波动进一步决定了灵活计费的表格存储是我们在这个架构中的最佳选择。表格存储的schema介绍请参考表格存储数据模型

　　与同类数据库相比，TableStore（表格存储）有一个很大的功能优势，就是TableStore（表格存储）有一个比较完整的增量接口，即Stream增量API。Stream的介绍请参考表格存储流概述。场景介绍可以参考Stream应用场景介绍，具体API使用可以参考JAVA SDK Stream。通过Stream接口，我们可以很方便的订阅TableStore（表存储）的所有修改操作，也就是各种新数据。同时，我们基于Stream构建了大量的数据通道，连接各种下游计算产品。用户甚至不需要直接调用Stream API，使用我们的channel直接订阅下游的增量数据，自然接入整个阿里云计算生态。上述架构中提到的函数计算，MaxCompute、ElasticSearch、DataV、TableStore（表存储）都支持。详情请参阅：

　　流与函数计算对接

　　Stream 和 MaxCompute

　　流和 Elasticsearch

　　通过DataV显示存储在表中的数据

　　TableStore（表存储）是属性列上的自由表结构。对于舆情分析的场景，随着舆情分析算法的升级，我们可能会增加新的属性字段，普通网页、微博等社交页面的属性也可能有所不同。因此，自由表结构与传统数据库相比，可以很好地满足我们的需求。

　　在架构中，我们有三个存储库需求。它们是原创页库、结构化元数据库和舆情结果库。前两个一般是离线存储和分析库，最后一个是在线数据库。它们对访问性能和存储成本有不同的要求。表格存储有两种支持存储分层的实例类型，高性能和容量。高性能适用于多写多读的场景，即作为在线业务存储。容量类型适用于写多读少的场景，即离线业务存储。它们的单线写入延迟可以控制在10毫秒以内，读取高性能可以保持在毫秒级。TableStore 还支持 TTL 并设置表级数据过期时间。根据需求，我们可以设置舆情结果的TTL，只提供最近数据的查询，旧的舆情会自动过期删除。

　　借助TableStore（表存储）的这些特性，可以很好地满足系统对存储选择的六大要求。基于TableStore（表存储），可以完美设计和实现全网舆情存储分析系统。

　　后记

　　本文总结了海量数据舆情分析场景中遇到的存储和分析问题，介绍了如何在满足业务基础数据量的前提下，使用阿里云自研的TableStore（表存储），通过Stream接口与计算平台的对接，实现了架构的简化。TableStore（表格存储）是阿里云自主研发的专业级分布式NoSQL数据库。它是一种基于共享存储的高性能、低成本、易扩展、全托管的半结构化数据存储平台。数据处理领域的重要应用之一。其他场景请参考TableStore进阶之路。