灯塔是阿里大文娱旗下一站式宣发平台，同时也是阿里巴巴为数不多对外提供数据的数据平台。作为数据平台，数据的时效性和准确性一直技术需要突破的重点和难点。

一、技术挑战

灯塔数据系统（前身淘票票专业版）从 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 三个数据源来实现高写入，高并发、高可靠的数据系统，希望能给后续更多的业务系统提供参考和指导。

作者介绍：

阿里大文娱高级开发工程师奋氛

相关阅读

电影垂直行业的云智开放平台如何炼成？

阿里工程师带你了解 B 端垂类营销中心如何设计？

云智前端技术如何赋能场馆院线？

60 秒售出 5 万张票！电影节抢票技术揭秘

电影行业提升 DCP 传输效率，还能这样做！

超大型场馆的绘座选座解决方案

大型赛事稳定性保障：Dpath 为世界军人运动会护航

世界顶级赛事的票务支撑：百万座位与限时匹配

前端技术：Webpack 工程化最佳实践

创作场景

电影票房数据查询服务高性能与高可用实践