实时文章采集(第二版:性能提升第一版的性能瓶颈在统计结果持久化上)

优采云 发布时间: 2021-11-06 17:29

  实时文章采集(第二版:性能提升第一版的性能瓶颈在统计结果持久化上)

  有赞使用storm近3年,稳定支持实时统计、数据同步、账户对账、监控、风控等服务。实时订单统计是典型的业务之一。它对数据的准确性和性能有很高的要求。它也是在线时间最长的实时计算应用程序。通过实时订单统计,描述使用Storm时遇到的准确性、性能、可靠性问题。

  实时订单统计进化第一版:流程经过

  在使用 Storm 之前,显示实时统计数据一般有两种方案:

  既要业务与统计解耦,又要满足指标的快速查询。基于Storm的实时计算解决方案可以满足这两个需求。

  Storm应用程序的基本结构分为三部分:数据源、Storm应用程序和结果集。Storm应用程序从数据源读取数据,计算后将结果持久化或发送消息给其他应用程序。

  

  第一版的实时订单统计结构如​​下图所示。数据来源方面,最早尝试登录业务代码,但总有业务分支无法覆盖,采集的数据不完整。我们的业务数据库是mysql,然后我们尝试使用基于mysql binlog的数据源,使用阿里开源的canal,可以完成业务数据变化的采集。

  在对结果数据的处理中,我们将统计结果持久化到mysql中,并通过另一个后台应用的RESTful API对外提供服务。一个mysql可以满足数据读写要求。

  

  为了提高实时统计应用的吞吐量,需要提高消息的并发性。消息缓冲区设置在 spout 中。只要消息缓冲区未满,就会不断地从消息源通道中拉取数据并分发到多个螺栓上。

  第二版:性能提升

  第一个版本的性能瓶颈是统计结果的持久性。为了保证数据的准确性,所有统计指标都持久化在一个数据库事务中。订单状态更新后,交易中会有两种操作:

  为此,数据库事务已被精简:

  最后,第二版的实时订单统计结构如​​下。主要的变化是引入了MQ,使用redis作为消息状态的存储。从最初的一个应用程序,它被拆分成多个应用程序。

  

  第三版:精度提升

  第二版优化后,实时统计的吞吐量不再是问题,但仍然遇到大数据最重要的精度问题:

  为了解决这个问题,所有与两天前相关的数据都将通过离线计算提供。最终呈现给用户的数据是历史离线统计数据,会上传今天和昨天的实时统计数据。为什么是今天和昨天的实时统计?因为离线统计有数据准备、建模、统计的过程,需要几个小时,而且有可能每天凌晨都没有前一天的离线统计结果。

  一旦统计口径发生变化,只需重新运行离线统计任务即可修复历史数据,实现冷热数据分离。

  

  实时计算的常见问题

  通过实时订单统计的案例,可以抽象出一些基于Storm实时计算的常见问题。

  消息状态管理

  Storm 不提供消息状态管理,为了实现横向扩展,消息之间最好不要有状态。对于数据量大、精度低的应用,需要无状态。但是,在数据量不是太大的场景,比如实时订单统计,但是精度要求极高的场景下,就需要记录消息的处理状态。为了应对重启和分布式扩容场景,往往需要额外的媒体来存储状态。状态信息通常以kv的形式进行读写。在实际应用中,我们使用了redis和HBase作为存储。

  消息不丢失、不重复、不乱序

  对于精度要求较高的场景,需要保证数据正确且只消费一次。Storm 有三种消息处理模式:

  对于消息重复、乱序的场景,不是简单的消息幂等可以解决的,有以下处理思路:

  对于时序判断,尽量不要使用时间戳,因为在分布式系统中,服务器时间不一致是一个常见的问题。

  我们会在运行过程中尝试重启消息源、storm应用、storage/MQ等下游系统,或造成网络丢包、延迟等异常,并手动触发可能的消息丢失、重复、乱序场景来验证我们的应用性能. 是否对应这些异常情况。

  复杂拓扑

  在storm文档中,有很多类似下图的复杂应用。

  

  对于需要可靠消息处理的场景,不适合这种复杂的拓扑结构。如何回滚一些失败,以及所有的bolt都处理完后是否ack,是一个需要面对的问题。太长的拓扑链接,里面的慢逻辑会降低整体性能。

  您可以考虑使用更简化的拓扑结构来尽可能地解耦不同的逻辑。当需要使用bolt的结果时,可以将数据持久化或推送到MQ。

  

  监视器

  监控在生产环境中是必不可少的。除了对服务器的基本监控外,还增加了很多针对storm的监控:

  另外,会有针对各种应用的监控,一般将离线计算的结果与实时计算的结果进行比较。对于数据同步应用,数据量比较大,可以采用抽样进行验证。

  后记

  最近,Spark Streaming、Flink等其他实时计算框架也很火。由于技术栈的维护成本,我们没有使用太多的新技术。将太多的框架维护在一起并不容易。

  基于Storm的实时计算应用开发有几个痛点:

  未来我们会考虑将实时计算平台化,解决或缓解上述痛点,降低开发和维护成本。

0 个评论

要回复文章请先登录注册


官方客服QQ群

微信人工客服

QQ人工客服


线