一、公司及业务介绍
猫耳FM是哔哩哔哩旗下专注于二次元ACG音频赛道的一款APP应用，对标喜马拉雅、网易云音乐、荔枝FM。平台内容包括中日广播剧、有声漫画、有声小说、电台、声优直播、配音活动等二次元及泛二次元音频内容。
其主要业务是与相关作品版权方合作，将国内市场火热的IP制作成广播剧、火山漫画等音频形式，最后由用户在平台上进行付费收听，完成商业闭环。
目前，该平台每月数据增长量将近8TB。平台通过数据为产品及运营决策提供支持。例如，运营部门需要客户活跃、留存率、 APP停留时长、付费转化率等指标指导日常运营决策；财务部门需要月度、年度的周期性支出及营收情况，用于对账、审计；产品部门则需要数据进行A/B测试，评估不同产品方案效果。
其次，搭建推荐系统需要基于用户的搜索、点击、收听、付费等行为构建用户画像，并向用户推荐广播剧、主播等。
最后，在业务运行过程中还会经常会遇到一些用户恶意行为，需要进行风控拦截，比如IOS用户充值退款问题，账号出租共享行为以及活动期间的刷榜行为等。
直接在业务路上进行分析会导致业务库CPU飙升，影响业务，造成请求响应超时，页面加载不出来等问题。
随着数据量的增长、报表需求的增多，直接在业务路上进行聚合分析的方式已经行不通，需要搭建专门的OA系统作为技术支撑。
二、历史架构及挑战
2018 年，该平台搭建了离线数仓，并使用该数仓进行实时在线分析。但由于是首次构建，技术能力有限，该数仓处于摸索阶段，暂时解决了短期爆款输出的问题。
该历史架构存在的问题比较明显，一是分析时效性差，部分离线ETL任务无法在T+1内运行完成，依赖这些任务的下游节点报表产出也发生滞后。另外一些日志数据导入到离线数仓的过程中，数据的拷贝超过24小时。
另外，资源无弹性。凌晨时段是任务运行高峰期，但由于机器人数量固定，大量任务推进等待程序调动，CPU处于满负荷运行状态，任务无法及时运行完成。统计用户年度收听报告期间，统计用户最长收音时段数据的任务运行超过24小时，产品验收测试进度滞后。
最后，运维成本高。服务故障时，需要进行数据排查报重并进行修复。其维护过程中数据开发及BI系统中断需要一个小时以上，遇到比较异常的主线问题时，系统不可用往往会持续一天以上的时间。
三、湖仓版架构及优势
将离线数仓迁移到ADB湖仓版主要基于以下几个优势。
首先，ADB湖仓版可以根据任务繁忙程度对资源进行弹性伸缩。离线ETL任务主要发生在0点到5点，这段时间资源需求高，资源弹性可以使资源更充足，避免任务因为等待资源而大量堆积。另外进行临时的修复数据时，可根据资源需求进行弹性伸缩，及时释放资源，降低使用成本。
另外，测试分析、收益统计，需要实时反映最新的收益情况。但由于合作方的分成模式比较复杂，会有按固定比例分成、按订单量梯度分成、按时间梯度分成等。使用离线数仓处理达不到实时要求，在线分析性能存在统计的瓶颈。
ADB通过DTS数据传输服务，数据入仓后可以实现一份数据同时在线分析和离线处理的需求，订单数据可以实现毫秒级增删改，面对查询时能在数秒内完成响应，极大提高时效性。
最后，ADB可根据数据扫描量自动优化执行模式，智能选择执行模式，加速任务的运行。
ADB时效性高，可用于在线特性。猫耳FM业务中，除收益统计后台需要实时分析反映最新的交易情况，在广播剧的打赏主板中也用到了这一特性。
在广播剧打赏主板，基于ADB应对复杂查询的特性，榜单的更新周期从小时级别提高到秒级，提高客户参与积极性，提升用户的停留时长及付费转化率。
另外，在直播业务中，平台可以对中奖概率进行实时监控。如果中奖的概率超出预设值，运营可以及时收到报警的通知，进行调整或下架，控制成本收益。
这一特性也用于监测活动期间的刷榜行为，直播间管理人员可以及时予以处置，避免榜单排名的异常变动。
