最近如果拉过austin
项目代码的同学,可能就会发现多了一个austin-stream
模块。其实并不会意外,因为这一切都在计划当中进行。
这个模块主要是接入流式处理平台(flink),用于实时计算清洗数据给到业务以及系统维护者更方便去使用消息推送平台austin
。
这篇文章主要来聊聊接入的背景以及我浅薄的经验吧
01、为什么流式处理平台
我在老东家有过处理数据相关的经验,也看到过站内广告「效果数据」的发展历程。
所谓效果数据,说白了则是商家在平台上投放了广告,我们需要给商家看到广告带来的效果,最核心的是「曝光」「点击」「订单」,基于这几项数据再聚合些类roi
的指标。
下面来聊聊这个「发展历程」,看完这个过程或许可以更好地了解为什么需要流式处理平台
1、PHP阶段:在最初时业务以及系统结构都比较简单,把「点击」和「订单」都存入数据库表,一把梭通过定时任务全量聚合,得到最终的效果数据,而「曝光」数据则是次日再写入效果数据表中。
在这个阶段里,由于数据量不大,通过定时任务全量来聚合数据也不是不可以,那时候商家都能接受该业务的延迟性
2、Java阶段:随着业务的发展,逐渐摒弃PHP化并且广告三层结构成型、数据量日益提升、站内中间件服务平台也发展起来。通过中间件团队提供的消费binlog
框架,从架构上改变聚合模式,并这个阶段可以更快地给商家展示效果数据,大概1min出效果数据
3、流式处理平台阶段:流式处理平台是对「计算」或者说处理数据时的抽象,在这抽象基础上它更能充分利用系统的资源(一个大的任务被拆分多个小任务,然后分发到不同的机器上执行)
4、广告效果数据是先用的Storm
作为流式处理平台,数