数据源、storm应用、结果集。storm应用从数据源读

发布时间:2019-03-22   来源:未知

  有赞使用storm已经有将近3年时间,稳定支撑着实时统计、数据同步、对账、监控、风控等业务。订单实 时统计是其中一个典型的业务,对数据准确性、性能等 方面都有较高要求,也是上 线时间最久的一个实时计算应用。通过订单实时统计,描述使用storm时,遇到的准确性、性能、可靠性等方面的问题。

  订单实时统计的演进

  第一版:流程走通

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

  在数据库里执行count、sum等聚合查询,是简单 快速的实现方案,但容易出现慢查询。

  在业务 代码里对统计指标做累加,可以满 足指标的快速查询,但统计 逻辑耦合到业务代码,维护不方便,而且错 误数据定位和修正不方便。

  既要解耦业务和统计,也要满 足指标快速查询,基于storm的实时 计算方案可以满足这两点需求。

  一个storm应用的 基本结构有三部分:数据源、storm应用、结果集。storm应用从 数据源读取数据,经过计算后,把结果 持久化或发送消息给其他应用。

  第一版 的订单实时统计结构如下图。在数据源方面,最早尝 试在业务代码里打日志的方式,但总有 业务分支无法覆盖,采集的数据不全。我们的业务数据库是mysql,随后尝试基于mysql binlog的数据源,采用了阿里开源的canal,可以做 到完整的收集业务数据变更。

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

  为了提 升实时统计应用吞吐量,需要提 升消息的并发度。spout里设置了消息缓冲区,只要消息缓冲区不满,就会源 源不断从消息源canal拉取数据,并把分发到多个bolt处理。

  第二版:性能提升

  第一版 的性能瓶颈在统计结果持久化上。为了确 保数据的准确性,把所有 的统计指标持久化放在一个数据库事务里。一笔订单状态更新后,会在一 个事务里有两类操作:

  订单的 历史状态也在数据库里存着,要与历 史状态对比决定统计逻辑,并把最 新的状态持久化。storm的应用 本身是无状态的,需要使 用存储设备记录状态信息

  当大家 知道实时计算好用后,各产品 都希望有实时数据,统计逻辑越来越复杂。店铺、商品、用户等 多个指标的写操作都是在一个事务里commit,这一简 单粗暴的方式早期很好满足的统计需求,但是对于update操作持有锁时间过长,严重影响了并发能力。

  为此做 了数据库事务的瘦身:

  去除历史状态的mysql持久化,而是通过单条binlog消息的前后状态对比,决定统计逻辑,这样就 做到了统计逻辑上的无状态。但又产生了新问题,如何保 证消息有且只有处理一次,为此引入了一个redis用于保存最近24小时内 已成功处理的消息binlog偏移量,而storm的消息 分发机制又可以保证相同消息总是能分配到一个bolt,避免线程安全问题。

  统计业务拆分,先是线 上业务和公司内部业务分离,随后又 把线上业务按不同产品拆分。这个不仅仅是bolt级别的拆分,而是在spout就完全分开

  随着统计应用拆分,在canal和storm应用之 间加上消息队列。canal不支持多消费者,而实时 统计业务也不用关系数据库底层迁移、主从切换等维护工作,加上消 息队列能把底层数据的维护和性能优化交给更专业的团队来做。

  热点数据在mysql里做了分桶。比如,通常一 个店铺天级别的统计指标在mysql里是一行数据。如果这 个店铺有突发的大量订单,会出现多个bolt同时去update这行数据,出现数据热点,mysql里该行 数据的锁竞争异常激烈。我们把 这样的热点数据做了分桶,实验证 明在特定场景下可以有一个数量级吞吐量提升。

  最终,第二版 的订单实时统计结构如下,主要变化在于引入了MQ,并使用redis作为消息状态的存储。而且由 最初的一个应用,被拆成了多个应用。

  第三版:准确性提升

  经过第二版的优化,实时统 计的吞吐量已经不成问题,但还是 遇到了做大数据最重要的准确性的问题:

  统计口径是会变化的,同样是GMV,一年前 和现在的算法可能有变化。例如一 笔货到付款订单,是买家下单算成交,还是卖家发货成交,在不同 的时期可能使用不同的算法。

  实时统 计只能按照当时的算法来做计算。有可能 出现一段时间周期内的GMV,前一段 是按旧算法来计算,后一段 按新算法来计算,提供的 数据就不准确了。

  实时统计难免会出现bug,有不准确的结果,修复错 误数据是个难题。

  为了解决这个问题,凡是涉 及到两天以前数据的,一律由离线计算提供,最终展 示给用户的数据,就是历 史离线统计数据,并上今 日昨日实时统计数据。为什么 是今日昨日实时统计呢?因为离 线统计有数据准备、建模、统计的过程,要花费几个小时,每天的 凌晨很可能还得不到前一天的离线统计结果。

  一旦统计口径有变化,只需要 重跑离线统计任务就可修复历史数据,做到了冷热数据分离。

友情链接:    彩票平台科技网   时时彩手机版下载   cc手机网投登录中心   玩彩网彩票app手机版   北京pk10网址