基于大数据的舆情分析系统架构（架构篇）
|
计算系统这里选用阿里云实时流计算产品 Blink，Blink 是一款支持流计算和批计算一体的实时计算产品。并且类似 Tablestore 可以很容易的做到分布式水平扩展，让计算资源随着业务数据增长弹性扩容。使用 Tablestore + Blink 的优势有以下几点： Tablestore 已经深度和 Blink 进行整合，支持源表，维表和目的表，业务无需为数据流动开发代码。 整套架构大幅降低组建个数，从开源产品的 6～7 个组建减少到 2 个，Tablestore 和 Blink 都是全托管 0 运维的产品，并且都能做到很好的水平弹性，业务峰值扩展无压力，使得大数据架构的运维成本大幅降低。 业务方只需要关注数据的处理部分逻辑，和 Tablestore 的交互逻辑都已经集成在 Blink 中。 开源方案中，如果数据库源希望对接实时计算，还需要双写一个队列，让流计算引擎消费队列中的数据。我们的架构中数据库既作为数据表，又是队列通道可以实时增量数据消费。大大简化了架构的开发和使用成本。 流批一体，在舆情系统中实时性是至关重要的，所以我们需要一个实时计算引擎，而 Blink 除了实时计算以外，也支持批处理 Tablestore 的数据， 在业务低峰期，往往也需要批量处理一些数据并作为反馈结果写回 Tablestore，例如情感分析反馈等。那么一套架构既可以支持流处理又可以支持批处理是再好不过。这里我们可以参考之前的一篇文章《实时计算最佳实践：基于表格存储和 Blink 的大数据实时计算》。一套架构带来的优势是，一套分析代码既可以做实时流计算又可以离线批处理。 整个计算流程会产生实时的舆情计算结果。重大舆情事件的预警，通过 Tablestore 和函数计算触发器对接来实现。Tablestore 和函数计算做了增量数据的无缝对接，通过结果表写入事件，可以轻松的通过函数计算触发短信或者邮件通知。完整的舆情分析结果和展示搜索利用了 Tablestore 的新功能多元索引，彻底解决了开源 Hbase+Solr 多引擎的痛点： 运维复杂，需要有运维 hbase 和 solr 两套系统的能力，同时还需要维护数据同步的链路。 Solr 数据一致性不如 Hbase，在 Hbase 和 Solr 数据语意并不是完全一致，加上 Solr/Elasticsearch 在数据一致性很难做到像数据库那么严格。在一些极端情况下会出现数据不一致的问题，开源方案也很难做到跨系统的一致性比对。 查询接口需要维护两套 API，需要同时使用 Hbase client 和 Solr client，索引中没有的字段需要主动反查 Hbase，易用性较差。 【凡本网注明来源非中国IDC圈的作品，均转载自其它媒体，目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。】 延伸阅读：
（编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
