海量数据下的舆情分析，该如何搭建？

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

图5 云上舆情大数据架构

这套架构在存储层面，全部基于Tablestore，一个数据库解决不同存储需求，根据之前舆情系统的介绍，网页爬虫数据在系统流动中会有四个阶段分别是原始网页内容，网页结构化数据，分析规则元数据和舆情结果，舆情结果索引。

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

计算系统这里选用阿里云实时流计算产品Blink，Blink是一款支持流计算和批计算一体的实时计算产品。并且类似Tablestore可以很容易的做到分布式水平扩展，让计算资源随着业务数据增长弹性扩容。使用Tablestore + Blink的优势有以下几点：

Tablestore已经深度和Blink进行整合，支持源表，维表和目的表，业务无需为数据流动开发代码。

整套架构大幅降低组建个数，从开源产品的6～7个组建减少到2个，Tablestore和Blink都是全托管0运维的产品，并且都能做到很好的水平弹性，业务峰值扩展无压力，使得大数据架构的运维成本大幅降低。

业务方只需要关注数据的处理部分逻辑，和Tablestore的交互逻辑都已经集成在Blink中。

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

流批一体，在舆情系统中实时性是至关重要的，所以我们需要一个实时计算引擎，而Blink除了实时计算以外，也支持批处理Tablestore的数据， 在业务低峰期，往往也需要批量处理一些数据并作为反馈结果写回Tablestore，例如情感分析反馈等。那么一套架构既可以支持流处理又可以支持批处理是再好不过。一套架构带来的优势是，一套分析代码既可以做实时流计算又可以离线批处理。

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

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

Solr数据一致性不如Hbase，在Hbase和Solr数据语意并不是完全一致，加上Solr/Elasticsearch在数据一致性很难做到像数据库那么严格。在一些极端情况下会出现数据不一致的问题，开源方案也很难做到跨系统的一致性比对。

查询接口需要维护两套API，需要同时使用Hbase client和Solr client，索引中没有的字段需要主动反查Hbase，易用性较差。

参考文献

Lambda大数据架构：

https://mapr.com/tech-briefs/stream-processing-mapr/

Kappa大数据架构：

https://www.oreilly.com/ideas/questioning-the-lambda-architecture

Lambda和Kappa架构对比：

https://www.ericsson.com/en/blog/2015/11/data-processing-architectures--lambda-and-kappa

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!