互联网的飞速发展，推动了很多新媒体的发展。无论是知名大V、明星还是围观群众，都可以用手机在微博、朋友圈或评论网站发布消息，分享自己的所见所思，让“人人都有话筒”。无论是热点新闻还是娱乐八卦，传播速度都远超我们的想象。一条消息可以在短短几分钟内被转发数万次，并被数百万人阅读。海量信息可以爆发式传播，那么如何实时掌握信息并做出相应处理呢？真的很难相处吗？今天阿里云智能事业群的宇衡就来和我们聊聊大数据舆情系统对数据存储的影响以及对计算系统有哪些要求，以及如何根据需求设计系统。在大数据时代，除了媒体信息，各类电商平台的商品订单量、用户购买评论等，都会对后续消费者产生很大的影响。商家的产品设计人员需要对各个平台的数据进行统计分析，作为决定后续产品开发的依据。公司公关和市场部也需要根据舆情及时处理，而这一切也意味着传统舆情系统升级为大数据舆情收集分析系统。详细看大数据舆情系统，对我们的数据存储和计算系统提出如下要求：海量原始数据的实时存储：要实现一套完整的舆情系统，需要有上游原始输出的集合，也就是爬虫系统。爬虫需要从各种门户网站和自媒体收集网页内容。爬取前需要去重，爬取后需要分析提取，比如爬取子网页。原始网页数据处理：无论是主流门户网站还是自媒体的网页信息，我们都需要在爬取后做一定的数据抽取，将原始网页内容转化为结构化数据，如文章标题、摘要等，如果是商品的评论留言也需要提取有效的评论。结构化数据的舆情分析：当各种原始输出变成结构化数据时，我们需要一个实时计算产品对各种输出进行合理分类，并进一步对分类后的内容进行情感标记。根据业务的需要，这里可能会产生不同的输出，比如品牌是否有当下热点话题、舆情影响力分析、播出路径分析、参与用户统计和画像、舆情情绪分析，或者是否有重大预警。舆情分析系统中间和结果数据的存储，交互分析和查询：从原始网页数据清洗到最终的舆情表，会产生多种类型的数据。其中一部分数据将提供给数据分析师，用于优化舆情分析系统，一部分数据将提供给业务部门，根据舆情结果进行决策。这些查询可能非常灵活，需要我们的存储系统具备全文搜索和交互式分析能力，多字段组合灵活。重大舆情事件实时预警：除了正常的舆情结果搜索和展示需求，我们还需要能够实现重大事件发生时的实时预警。本文主要提供架构设计。首先介绍目前主流的大数据计算架构，分析一些优缺点，然后介绍舆情大数据架构。系统设计需求分析结合文章开头对舆情系统的描述，海量大数据舆情分析系统流程图大致如下：图1民意调查业务流程原网页仓库舆论系统。这个库需要能够支持海量数据、低成本、低延迟的写入输入。网页数据写入后，需要进行实时结构化抽取，对抽取的数据进行降噪、分词、图像ocr处理等。对分词文本和图片进行情感识别，生成舆情数据结果集。传统的离线全量计算难以满足舆情系统的时效性要求。计算引擎在进行数据处理时，可能还需要从存储库中获取一些元数据，比如用户信息、情感词元数据信息等。除了实时计算环节，还需要定期对股票数据进行聚类优化我们的情感词识别库，或者上游根据业务需要触发更新情感处理规则，基于股票数据进行一次舆情计算关于新的情感标签库。舆情结果数据集有不同的使用需求。对于重大舆情，需要实时预警。完整的舆情结果数据展示层需要支持全文检索和灵活的属性字段组合查询。在业务中，可能会根据属性字段的置信度、舆情时间、关键词组合等进行分析。根据前面的介绍，舆情大数据分析系统需要进行两类计算，一类是实时计算，包括海量网页内容的实时提取、情感词分析和网页舆情结果的存储。另一种是离线计算。系统需要回溯历史数据，结合人工标注优化情感词库，并对部分实时计算结果进行修正。因此，在系统设计方面，需要选择能够进行实时计算和批量离线计算的系统。在开源大数据解决方案中，Lambda架构可以满足这些需求。让我们介绍一下Lambda架构。Lambda架构(wiki)图2Lambda架构图Lambda架构可以说是Hadoop和Spark体系下最流行的大数据架构。这种架构最大的优势是支持海量数据的批量计算处理（即离线处理），也支持流式实时处理（即热点数据处理）。具体是如何实施的？首先，上游一般是Kafka之类的队列服务，实时存储和写入数据。kafka队列会有两个订阅者，一个是全量数据，也就是图片的上半部分，全量数据会存储在HDFS这样的存储介质上。当离线计算任务到来时，计算资源（如Hadoop）会访问存储系统上的全量数据，执行全批计算的处理逻辑。经过map/reduce链接后，会将全量结果写入Hbase等结构化存储引擎，提供给业务方查询。队列的另一个消费者和订阅者是流计算引擎。流计算引擎经常会实时消费队列中的数据进行计算和处理。比如SparkStreaming实时订阅Kafka数据，流计算结果也写入结构化数据引擎。写入批计算和流计算结果的结构化存储引擎就是上图中标为3的“ServingLayer”。该层主要提供结果数据的展示和查询。在这种架构中，批计算的特点是需要支持海量数据的处理，根据业务需要，关联一些其他业务指标进行计算。批量计算的好处是可以根据业务需要灵活调整计算逻辑，计算结果可以重复重新计算，多次计算后相同计算逻辑的计算结果不会改变。批计算的缺点是计算周期比较长，难以满足实时结果的需求。因此，随着大数据计算的演进，提出了实时计算的需求。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等搜索系统，因为搜索系统的实时数据写入能力和数据可靠性不如数据库。行业通常将数据库和搜索系统集成在一起，集成系统兼具数据库和搜索系统的优势，但是两个引擎之间的数据同步和跨系统查询给运营带来了很多额外的成本和发展。新的大数据架构Lambdaplus经过前面的分析，相信大家会有一个疑问。有没有简化的大数据架构，既能满足Lambda对计算需求的假设，又能减少存储计算和模块的数量？Linkedin的JayKreps提出了Kappa架构。Lambda和Kappa的对比可以参考文末的文献。此处不进行详细比较。总之，为了简化两个存储，Kappa取消了全量数据存储。对于较长的日志，当需要回溯和重新计算时，会再次从队头订阅数据，将所有存储在Kafka队列中的数据再次以流的方式进行处理。这样设计的好处是解决了维护两套存储和两套计算逻辑的痛点。美中不足的是队列所能保留的历史数据毕竟有限，没有时间限制很难回溯。分析到这里，我们沿用Kappa对Lambda的改进思路，稍微思考一下：如果有一种存储引擎，既能满足数据库的高效写入和随机查询，又能作为队列服务，满足第一个-in-first-out,是不是可以将Lambda和Kappa架构结合起来创建Lambdaplus架构？新架构在Lambda的基础上可以改进以下几点：在支持流计算和批计算的同时，计算逻辑可以复用。实现“一种代码，两种需求”。将全量历史数据和在线实时增量数据统一存储，实现“一种存储，两种计算”。为方便舆情结果查询需求，数据库中存储“批量查看”和“实时查看”，支持高通量实时撰写、多领域联合检索和全文检索。总结一下，整个新架构的核心就是解决存储的问题，以及如何灵活的连接计算。我们希望整个解决方案类似于以下架构：图4LambdaPlus架构数据流实时写入分布式数据库。借助数据库查询能力，全量数据可以轻松接入批量计算系统进行离线处理。数据库通过数据库日志接口支持增量读取，通过对接流计算引擎实现实时计算。批计算和流计算的结果回写到分布式数据库中。分布式数据库提供丰富的查询语义，实现计算结果的交互式查询。在整个架构中，存储层通过结合数据库主表数据和数据库日志来替代大数据架构中的队列服务。计算系统选择天然支持批流的计算引擎，比如Flink或者Spark。这样，我们既可以像Lambda一样进行自定义的历史数据回溯，又可以像Kappa架构一样用一套逻辑来存储和处理两类计算任务。我们将这样一套架构命名为“Lambdaplus”，下面将详细讲解如何在阿里云上搭建这样一套大数据架构。在阿里云的众多存储和计算产品中，云上舆情系统的架构满足了上述大数据架构的要求。我们选择两款产品来实现整个舆情大数据系统。存储层采用阿里云自研的分布式多模型数据库Tablestore，计算层采用Blink实现流批一体化计算。图5云上舆情大数据架构该架构在存储层面以Tablestore为基础，一个数据库解决不同的存储需求。根据之前的舆情系统介绍，网络爬虫数据在系统流程中会有四个阶段，即原始网页内容。、网页结构化数据、分析规则元数据和舆情结果、舆情结果索引。我们利用Tablestore的widerowandschemafree特性，将原始网页和网页结构化数据合并为一个网页数据。网页数据表和计算系统通过Tablestore新的功能通道服务连接起来。通道服务基于数据库日志，按照数据写入的顺序存储数据的组织结构。正是这个特性使得数据库具备了队列流消费的能力。这使得存储引擎既有对数据库的随机访问，也有对队列的按顺序访问，这也满足了上述集成Lambda和kappa架构的需求。分析规则元数据表由分析规则层和情感词库层组成，对应实时计算中的维度表。这里的计算系统采用了阿里云的实时流计算产品Blink，它是一款同时支持流计算和批计算的实时计算产品。并且类似于Tablestore，可以轻松实现分布式水平扩展，让计算资源随着业务数据的增长弹性扩展。使用Tablestore+Blink的优势在于：Tablestore已经与Blink深度融合，支持源表、维表、目的表，业务无需开发数据流转代码。整个架构大大减少了组件数量，从开源产品中的6-7个组件减少到2个组件。Tablestore和Blink都是全托管运维产品。压力大大降低了大数据架构的运维成本。业务端只需要关注数据处理逻辑，与Tablestore的交互逻辑已经集成在Blink中。在开源方案中，如果数据库源要连接实时计算，还需要双写一个队列，让流计算引擎消费队列中的数据。在我们的架构中，数据库不仅仅是一个数据表，更是一个实时增量数据消费的队列通道。大大简化了框架的开发和使用成本。流批一体化，实时性在舆情系统中至关重要，所以我们需要一个实时计算引擎，而除了实时计算，Blink还支持对Tablestore数据进行批处理，而批处理过程中经常需要业务淡季，一些数据作为反馈结果回写到Tablestore，比如情感分析反馈等，那么一套既能支持流处理又能支持批处理的架构就完善了。一套架构带来的好处是，一套分析代码既可以进行实时流计算，也可以进行离线批处理。整个计算过程会产生实时的舆情计算结果。通过表格存储与函数计算触发器的对接实现重大舆情事件的预警。表格存储和函数计算无缝对接增量数据。可以通过结果表写入事件，通过函数计算可以轻松触发短信或邮件通知。完整的舆情分析结果和展示搜索利用Tablestore的新功能多索引，彻底解决了开源Hbase+Solr多引擎的痛点：运维复杂，需要运维能力hbase和solr两个系统，以及数据同步的维护Link。Solr的数据一致性不如Hbase。Hbase和Solr的数据语义并不完全一致。另外，Solr/Elasticsearch在数据一致性方面也很难像数据库一样严格。在某些极端情况下，会出现数据不一致的问题，开源方案很难实现跨系统的一致性比较。查询接口需要维护两套API。需要同时使用Hbase客户端和Solr客户端。不在索引中的字段需要主动查看Hbase，不好用。参考Lambda大数据架构：https://mapr.com/tech-briefs/stream-processing-mapr/Kappa大数据架构：https://www.oreilly.com/ideas/questioning-the-lambda-architectureLambda和Kappa架构比较：https://www.ericsson.com/en/blog/2015/11/data-processing-architectures--lambda-and-kappa
