灯塔是阿里大文娱旗下一站式宣发平台,同时也是阿里巴巴为数不多对外提供数据的数据平台。作为数据平台,数据的时效性和准确性一直技术需要突破的重点和难点。
一、技术挑战
灯塔数据系统(前身淘票票专业版)从 2017 年开始建设,最开始采用 MYSQL 作为数据存储,基础数据定时计算写入数据库,经过 2 年多的建设,产品已经基本成形,但对于数据的实效性有了更高的要求,由于影院单日售票在 3000W 张,预售将近 1 亿张票,计算量大,写入频次高,从感知影院售票到客户端呈现数据,采用什么样的方案,什么样的技术,能够通过最小的改动让数据最快的呈现出来,成了技术考虑的难点。
二、技术策略
首先是缩小数据量,找出数据规律,实现数据的实时计算,各维度数据汇总如图:
(图片:灯塔专业版数据汇总关系图)
各维度数据在业务应用的场景中,均可以按照时间、地区、业务主键进行检索,根据这个特征,我们生成了天然的 Key 组合,时间、地区、业务主键,并排列组合出三种 Key:时间_地区_业务主键,时间_业务主键_地区,地区_业务主键_时间。按照以上三种 Key 组合,在已知任何两个条件的情况下,均能实现对业务数据的检索。此时我们已经锁定了数据的存储平台 HBase。剩下的就是如何改造系统实现实时化。
三、落地方法
数据源有了,MYSQL 和 HBase,HBase 是实时数据,MYSQL 是离线数据,为了让上层业务无感知,特在底层数据做处理,实现离线数据和实时数据的结合,数据处理流程如图:
(图片:灯塔专业版数据处理流程图)
用户在请求票房数据的时候,先根据业务开关,决定请求实时数据还是离线数据,离线数据直接请求 MYSQL。实时数据,优先查询缓存,若缓存存在且不过期,直接返回缓存数据。缓存数据失效的情况下,查询 HBase,重新写入缓存。
系统日常还是有上千的 QPS,为了防止缓存击穿,对数据源造成压力,需要对热数据进行缓存预热。由于数据的特殊性,T 日为最热数据,占到总流量的 80%以上,这时候,缓存预热成了承受高并发访问的关键。定时任务每秒将 T 日数据整体刷入缓存,防止缓存失效击穿(因为都是 key-valu 存储,后续考虑热数据直接写入缓存,直接替代预热方案)。其实为了防止击穿,这部分数据是 24 小时不过期的,数据的更新是依赖定时任务的,一但数据链路故障、HBase 故障或算法异常,只需要停止定时任务,就能暂时止血,给技术留出处理时间不至于故障升级。同时 HBase 做了主备链路,而且主链路和备用链路的的算法略有不同,保证主备链路不会同时出问题。这样的架构,对于应用而言,就有了 4 套不同的数据源做保证的。架构上线至今,数据未曾出现一次问题。而且无形中解决了高 QPS 的问题,数据的提供主要依靠 TAIR,而缓存应对 QPS 就显得简单的多了。
(图片:灯塔专业版数据源关系图)
系统的难点在于实时数据和离线数据的结合。数据结合共分为以下几类:
T 日查询,非实时即离线,如查询今日大盘票房;系统首先定义了一个方法,根据日期判定数据应该查询实时还是查询离线,由于行业数据是按照 6 点到 6 点,即 T 日数据,在第二日 6 点后才变为离线数据,且由于专资办数据回刷的问题,防止数据回跳,会在数据回刷后才切换为离线数据。当查询单日数据时,针对查询日期,判定数据源,进行数据转换;
日期范围查询,即有实时又有离线,如查询影片每日票房情况;当查询日期范围时,由于日期范围时连续的,特将范围日期拆散成每一天,按照方法 1 中的判定规则,切分日期范围为离线日期和实时日期,然后数据源根究日期范围取最小日期和最大日期进行范围查询,查询后进行数据组合后返回数据;
范围统计,离线+实时,如本周票房;当进行范围统计查询时,首先去离线数据,然后根据日期判定,如果 T-1 数据还未回刷,则去 T-1 和 T 日数据,否则只去 T 日数据即可,将实时数据和离线数据进行加和,返回查询数据结果;
榜单查询,离线补实时,如影片榜单。榜单查询由于榜单数据范围不好确定,范围查询有可能查询数据太多,所以在查询排行榜时,先取离线数据 2 倍的数据量,然后根据离线数据返回业务主键,查询当前的实时数据,将实时数据覆盖到离线数据后,进行内存排序和截取,最终返回榜单数据。榜单数据略有不同,比如院线影片,由于全国院线一共 49 家,此时不做离线查询,直接查询所有实时数据进行排序。
针对以上数据整合的各种可能,参照以往出现的各种问题,封装代码如下:
(图片:示例代码 1)
(图片:示例代码 2)
通过以上处理,在上层业务无感知的情况下,下游数据实现了整体实时化的切换。而且通过 switch 开关控制针对数据源能够实现单业务主备切流,实时离线数据转换,使得数据的稳定性更可靠,为底层数据改造和升级留下了充足的扩展空间。
有了架构还不够,还需要感知能力,业务异常感知还是比较简单的,但是对于灯塔来说,有数不代表正常,数据到底对不对,这是问题感知的关键,这时候需要一个智能化的监控系统。针对票房数据,在不改造代码的情况下,我们设计了一个切面,引入脚本代码,针对特定数据来源做数据动态处理,将返回数据整合在一起,并提取出来,通过算法识别票房数据行为趋势,如图:
(图片:灯塔专业版票房监测趋势图)
针对数据的趋势做智能化监控,当数据异常变化或者超过业务限定范围,就会通知告警,以此来有效的规避数据异常的情况,并能及时感知问题。
四、总结沉淀
随着 B 端业务的发展,数据的作用越来越大,在海量数据存储和更新的需要下,关系型数据库已经越来越无力,各种类型的数据存储起到了不同的作用,多数据源的整合也越来越重要。本文介绍了灯塔为了做到实时的数据系统,是如何组合 Mysql、Hbase、Tair 三个数据源来实现高写入,高并发、高可靠的数据系统,希望能给后续更多的业务系统提供参考和指导。
作者介绍:
阿里大文娱高级开发工程师 奋氛
相关阅读
评论