前言
在时下互联网信息的浪潮下，信息的传播速度远超我们的想象。微博里一条大V的帖子，朋友圈的一个状态更新，热门论坛的一条新闻，购物平台的购物评价，可能会产生数以万计的转发，关注，点赞。如果是一些非理性负面的评论会激发人们的负面感，甚至影响到消费者对企业品牌的认同，如果不能及时的采取正确的应对措施，会造成难以估计的损失。所以我们需要一个高效的全网舆情分析系统，帮助我们实时的观测舆情。
这个全网舆情分析系统，可以实现百亿条网页数据的存储、实时新增网页的抓取和存储并能对新增网页做实时的元数据提取。有了提取结果，我们还需要进行进一步的挖掘分析，这些分析包括但不限于
- 舆情的影响力诊断，从传播量级和扩散趋势来做预测，确定是否最终形成舆情。
- 传播路径分析，分析舆情传播的关键路径。
- 用户画像，对舆情的参与者提供共性特征勾勒，如性别，年龄，地域和感兴趣话题。
- 情感分析，分析新闻或者评价是正面还是负面。情感分类后进行统计聚合。
- 预警设置，我们支持舆情讨论量阈值设置，达到阈值后通知推送业务方，避免错过舆情的黄金参与时间。
这些挖掘后的舆情结果会被推送至需求方，同时也提供接口给各业务方搜索，查询使用。下面我们就展开讨论系统设计中可能会遇到的问题，我们会重点关注系统设计中存储相关的话题，针对这些问题找到一个最优化的方案。
系统设计
对于一个舆情系统，首先需要一个爬虫引擎，去采集各大主流门户，购物网站，社区论坛原始页面内容，微博，朋友圈的各类消息信息。采集到的海量网页，消息数据（百亿级别）需要实时存储下来。再根据网站url获取网页之前还需要判断一下是否是之前爬过的页面，避免不必要的重复爬取。采集网页后我们需要对网页进行萃取，去除不必要的标签，提取标题，摘要，正文内容，评论等。萃取后的内容进入存储系统方便后续查询，同时还需要把新增的抽取结果推送至计算平台进行统计分析，出报表，或者后续提供舆情检索等功能。计算的内容根据算法不同可能需要新增数据，也可能需要全量数据。而舆情本身的时效敏感性决定了我们系统一定要能高效处理这些新增内容，最好是秒级别延时后就可以检索到新热搜。
我们可以总结下整个数据流如下：
根据上图我们不难发现，设计一个全网舆情的存储分析平台，我们需要处理好抓取，存储，分析，搜索和展示。具体我们需要解决如下问题:
- 如何高效存储百亿级别的网页原始信息，为了提高舆情分析的全面性，准确性，我们往往希望可以尽可能多的爬取网页信息，再根据我们设置的权重聚合。所以网页的历史全库会比较大，积累数百亿的网页信息，数据量可以达到百TB甚至数PB。在数据量如此之大的情况下，我们还需要做到读写毫秒级别的低延时，这使得传统数据库难以满足需求。
- 如何在爬虫爬取网页之前判断是否之前已经爬取过，针对普通网页，舆情在意他们的时效性，可能我们对同一个网页只希望爬取一次，那我们就可以利用网页地址做爬取前去重，减少不必要的网页资源浪费。所以我们需要分布式存储提供基于网页的高效随机查询。
- 如何新增原始网页存储完成后进行实时的结构化提取，并存储提取结果。这里我们原始的网页可能是包括各种html的标签，我们需要去除这些html的标签，提取出文章的标题，作者，发布时间等。这些内容为后续舆情情感分析提供必要的结构化数据。
- 如何高效的对接计算平台，流式新增提取后的结构化数据进行实时的计算。这里我们需要根据网页，消息描述的内容做分类，进行情感识别，识别后的结果统计分析。由于全量分析时效性差，加上舆情往往关注最新的新闻，评论，所以我们必须做增量分析。
- 如何提供高效的舆情搜索，用户除了订阅固定关键词的舆情以外，做一些关键词搜索。例如希望了解竞争公司新产品的一些舆情分析。
- 如何实现新增舆情的实时推送，为了保证舆情的时效性，我们不仅需要持久化舆情分析结果，同时也要支持推送舆情结果。推送的内容通常是我们实时分析出来的新增舆情。
系统架构
针对上面介绍这些问题，我们下面来介绍下如何基于阿里云上的各类云产品来打造全网百亿级别的舆情分析平台，我们会重点关注存储产品的选型和如何高效的对接各类计算，搜索平台。
爬虫引擎我们选用ECS，可以根据爬取量决定使用ECS的机器资源数，在每天波峰的时候也可以临时扩容资源进行网页爬取。原始网页爬取下来后，原始网页地址，网页内容写入存储系统。同时如果想避免重复爬取，爬虫引擎抓取之前要根据url列表进行去重。存储引擎需要支持低延时的随机访问查询，确定当前url是否已经存在，如果存在则无需重复抓取。
为了实现网页原始内容的实时抽取，我们需要把新增页面推送至计算平台。之前的架构往往需要做应用层的双写，即原始网页数据入库同时，我们重复写入一份数据进入计算平台。这样的架构会需要我们维护两套写入逻辑。同样的在结构化增量进入舆情分析平台中，也有类似的问题，抽取后的结构化元数据也需要双写进入舆情分析平台。舆情的分析结果也需要一份写入分布式存储，一份推送至搜索平台。到这里我们可以发现，图中的三根红线会带来我们对三个数据源的双写要求。这会加大代码开发工作量，也会导致系统实现，维护变的复杂。每一个数据源的双写需要感知到下游的存在，或者使用消息服务，通过双写消息来做解耦。传统数据库例如mysql支持订阅增量日志binlog，如果分布式存储产品在可以支撑较大访问，存储量的同时也可以提供增量订阅就可以很好的简化我们的架构。
网页数据采集入库后，增量流入我们的计算平台做实时的元数据抽取，这里我们可以选用函数计算，当有新增页面需要提取时触发函数计算的托管函数进行网页元数据抽取。抽取后的结果进入存储系统持久化后，同时推送至MaxCompute进行舆情分析，例如情感分析，文本聚类等。这里可能会产生一些舆情报表数据，用户情感数据统计等结果。舆情结果会写入存储系统和搜索引擎，部分报表，阈值报警会被推送给订阅方。搜索引擎的数据提供给在线舆情检索系统使用。
在介绍完整体架构后，下面我们看下在阿里云上如何做存储选型。
存储选型
通过架构介绍我们再总结一下对存储选型的要求：
- 可以支撑海量数据存储（TB/PB级别），高并发访问(十万TPS～千万TPS)，访问延时低。
- 业务随着采集订阅的网页源调整，采集量会动态调整。同时一天内，不同时间段爬虫爬下来的网页数也会有明显波峰波谷，所以数据库需要可以弹性扩展，缩容。
- 自由的表属性结构，普通网页和社交类平台页面的信息我们需要关注的属性可能会有较大区别。灵活的schema会方便我们做扩展。
- 对老数据可以选择自动过期或者分层存储。因为舆情数据往往关注近期热点，老的数据访问频率较低。
- 需要有较好的增量通道，可以定期把新增的数据导出至计算平台。上面的图中有三段红色虚线，这三部分都有个共同的特点需要可以实时的把增量导至对应的计算平台做计算，计算后的结果再写入对应的存储引擎。如果数据库引擎本身就支持增量，则可以很大程度简化架构，减少之前需要全量读区筛选增量，或者客户端双写来实现得到增量的逻辑。
- 需要可以有较好的搜索解决方案（本身支持或者可以数据无缝对接搜索引擎）。
有了这些需求后，我们需要使用一款分布式的NoSQL数据来解决海量数据的存储，访问。多个环节的增量数据访问的需求，业务的峰值访问波动进一步确定弹性计费的表格存储是我们在这套架构中的最佳选择。表格存储的架构介绍可以参考表格存储数据模型
TableStore(表格存储)相比同类数据库一个很大的功能优势就是TableStore(表格存储)有较完善的增量接口，即Stream增量API。场景介绍可以参考Stream应用场景介绍，具体API使用可以参考JAVA SDK Stream。有了Stream接口，我们可以很方便的订阅TableStore(表格存储)的所有修改操作，也就是新增的各类数据。同时我们基于Stream打造了很多数据通道，对接各类下游计算产品，用户甚至不需要直接调用Stream API，使用我们的通道直接在下游订阅增量数据，自然的接入了整个阿里云的计算生态。针对上面架构中提到的函数计算，MaxCompute，ElasticSearch和DataV，TableStore(表格存储)都已经支持，具体使用可以参考:
TableStore(表格存储)在属性列上，是自由的表结构。针对舆情分析这个场景，随着舆情分析算法的升级我们可能会新增属性字段，同时针对普通网页和微博这类社交页面的属性也可能不尽相同。所以自由表结构相比传统数据库可以很好的匹配我们这个需求。
在架构中，我们有三个存储库需求。分别是原始页面库，结构化元数据库和舆情结果库。前两者一般是一个离线存储分析库，最后一个是一个在线数据库。他们对访问性能，存储成本有着不同的需求。表格存储有两种类型的实例类型支持存储分层，即高性能和容量型。高性能适用于写多读多的场景也就是做为在线业务存储使用。容量型适合写多读少的场景，也就是离线业务存储用。他们的写入单行延时都可以控制在10毫秒内，读取高性能可以保持在毫秒级别。TableStore(表格存储)同时支持TTL，设置表级别数据过期时间。根据需求，舆情结果我们可以设置TTL，只提供近期数据的查询，较老的舆情自动过期删除。
有了TableStore(表格存储)的这些功能特性，系统对存储选型的六项要求就可以得到很好的满足，基于TableStore(表格存储)可以完美的设计和实现全网舆情存储分析系统。
后记
本文对实现海量数据舆情分析这一场景中会遇到的存储和分析问题进行了总结，介绍了如何通过使用阿里云自研的TableStore(表格存储)在满足业务基本数据量的前提下，通过Stream接口和计算平台的对接实现架构简化。TableStore(表格存储)是阿里云自主研发的专业级分布式NoSQL数据库，是基于共享存储的高性能、低成本、易扩展、全托管的半结构化数据存储平台，舆情数据存储分析是TableStore在大数据处理领域的重要应用之一。其他场景使用可以参考TableStore进阶之路。
更多的应用场景和技术探讨，欢迎加入我们的钉钉交流群（群号：11789671）。
