赋能直播行业精细化运营，斗鱼基于Apache Dor i s的应用实践
鱼是一家弹幕式直播分享网站，为用户提供视频直播和赛事直播服务。随着斗鱼直播、视频等业务的高速发展，用户增长和营收两大主营业务线对精细化运营的需求越发地迫切，各个细分业务场景对用户的差异化分析诉求也越发的强烈。为更好满足业务需求，斗鱼在2022年引入了Apache Doris构建了一套比较相对完整的实时数仓架构，并在该基础上成功构建了标签平台以及多维分析平台，在此期间积累了一些建设及实践经验通过本文分享给大家。
作者：韩同阳，斗鱼资深大数据工程师、OLAP平台负责人
斗鱼是一家弹幕式直播分享网站，为用户提供视频直播和赛事直播服务。斗鱼以游戏直播为主，也涵盖了娱乐、综艺、体育、户外等多种直播内容。随着斗鱼直播、视频等业务的高速发展，用户增长和营收两大主营业务线对精细化运营的需求越发地迫切，各个细分业务场景对用户的差异化分析诉求也越发的强烈，例如增长业务线需要在各个活动（赛事、专题、拉新、招募等）中针对不同人群进行差异化投放，营收业务线需要根据差异化投放的效果及时调整投放策略。
根据业务场景的诉求和精细化运营的要求，我们从金字塔自下而上来看，需求大致可以分为以下几点：
· 分析需求更加复杂、精细化，不再满足简单的聚合分析；数据时效性要求更高，不满足于T+1的分析效率，期望实现近实时、实时的分析效率。
· 业务场景多，细分业务场景既存在独立性、又存在交叉性，例如：针对某款游戏进行专题活动投放（主播、用户），进行人群圈选、AB实验等，需要标签/用户画像平台支持。
· 多维数据分析的诉求强烈，需要精细化运营的数据产品支持。
为更好解决上述需求，我们的初步目标是：
· 构建离线/实时数仓，斗鱼的离线数仓体系已成熟，希望此基础上构建一套实时数仓体系；
· 基于离线/实时数仓构建通用的标签中台（用户画像平台），为业务场景提供人群圈选、AB实验等服务；
· 在标签平台的基础上构建适用于特定业务场景的多维分析和精细化运营的数据产品。
在目标驱动下，斗鱼在原有架构的基础上进行升级改造、引入Apache Doris构建了实时数仓体系，并在该基础上成功构建了标签平台以及多维分析平台，在此期间积累了一些建设及实践经验通过本文分享给大家。
原有实时数仓架构
斗鱼从2018年开始探索实时数仓的建设，并尝试在某些垂直业务领域应用，但受制于人力的配置及流计算组件发展的成熟度，直到2020年第一版实时数据架构才构建完成，架构图如下图所示：
原有实时数仓架构是一个典型的Lambda架构，上方链路为离线数仓架构，下方链路为实时数据仓架构。鉴于当时离线数仓体系已经非常成熟，使用Lambda架构足够支撑实时分析需求，但随着业务的高速发展和数据需求的不断提升，原有架构凸显出几个问题：
· 在实际的流式作业开发中，缺乏对实时数据源的管理，在极端情况下接近于烟囱式接入实时数据流，无法关注数据是否有重复接入，也无法辨别数据是否可以复用。
· 离线、实时数仓完全割裂，实时数仓没有进行数仓分层，无法像离线数仓按层复用，只能面向业务定制化开发。
· 数据仓库数据服务于业务平台需要多次中转，且涉及到多个技术组件，ToB应用亟需引入OLAP引擎缓解压力。
· 计算引擎和存储引擎涉及技术栈多，学习成本和运维难度也很大，无法进行合理有效管理。
新实时数仓架构
技术选型
带着以上的问题，我们希望引入一款成熟的、在业内有大规模落地经验的OLAP引擎来帮助我们解决原有架构的痛点。我们希望该OLAP引擎不仅要具备传统OLAP的优势（即Data Analytics），还能更好地支持数据服务（Data Serving）场景，比如标签数据需要明细级的查询、实时业务数据需要支持点更新、高并发以及大数据量的复杂Join。除此之外，我们希望该OLAP引擎可以便捷、低成本的的集成到Lambda架构下的离线/实时数仓架构中。立足于此，我们在技术选型时对比了市面上的几款OLAP引擎，如下图所示：
根据对选型的要求，我们发现Apache Doris可以很好地满足当前业务场景及诉求，同时也兼顾了低成本的要求，因此决定引入Doris进行升级尝试。
架构设计
我们在2022年引入了Apache Doris，并基于Apache Doris构建了一套比较相对完整的实时数仓架构，如下图所示。
总的来说，引入Doris后为整体架构带来几大变化：
· 统一了计算平台（玄武计算），底层引擎支持Flink、Spark等组件，接入层支持统一SQL和JAR包接入。
· 引入Doris后，我们将实时数仓分为ODS、DWD、DWS、ADS层，部分中间层实时数据直接使用Doris进行存储；
· 构建了基于Doris的HOLAP多维分析平台，直接服务于业务；简化了原来需要通过Hive进行预计算的加工链路，逐步替换使用难度和运维难度相对较高的Click House；
· 下游应用的数据存储从之前的MySQL和HBase更换为Doris，可以在数据集市和大宽表的数据服务场景下直接查询Doris。
· 支持混合IDC（自建和云厂商）。
Overwrite语义实现
Apache Doris支持原子替换表和分区，我们在计算平台（玄武平台）整合Doris Spark Connector时进行了定制，且在Connector配置参数上进行扩展、增加了“Overwrite”模式。
当Spark作业提交后会调用Doris的接口，获取表的Schema信息和分区信息。
· 如果为非分区表：先创建目标表对应的临时表，将数据导入到临时表中，导入后进行原子替换，如导入失败则清理临时表；
· 如果是动态分区表：先创建目标分区对应的临时分区，将数据导入临时分区，导入后进行原子替换，如导入失败则清理临时分区；
· 如果是非动态分区：需要扩展Doris Spark Connector参数配置分区表达式，配完成后先创建正式目标分区、再创建其临时分区，将数据导入到临时分区中，导入后进行原子替换，如导入失败则清理临时分区。
架构收益
通过架构升级及二次开发，我们获得了3个明显的收益：
· 构建了规范、完善、计算统一的实时数仓平台。
· 构建了统一混合OLAP平台，既支持MOLAP，又支持ROLAP，大部分多维分析需求均由该平台实现。
· 面对大批量数据导入的场景，任务吞入率和成功率提升了50%。
Doris在标签中台的应用
标签中台（也称用户画像平台）是斗鱼进行精准运营的重要平台之一，承担了各业务线人群圈选、规则匹配、A/B实验、活动投放等需求。接下来看下Doris在标签中台是如何应用的。
原标签中台架构
上图为斗鱼原来的标签中台架构，离线标签在数仓中加工完成后合入宽表，将最终数据写入HBase中，实时标签使用Flink加工，加工完直接写入到HBase中。
终端APP在使用标签中台时，主要解决两种业务需求：
· 人群圈选，即通过标签和规则找到符合条件的人。
· 规则匹配，即当有一个用户，找出该用户在指定的业务场景下符合哪些已配置的规则，也可以理解是“人群圈选“的逆方向。
在应对这两种场需求中，原标签中台架构出现了两个问题：
· 实时标签链路：Flink计算长周期实时指标时稳定性较差且耗费资源较高，任务挂掉之后由于数据周期较长，导致Checkpoint恢复很慢；
· 人群圈选：Spark人群圈选效率较低，特别是在实时标签的时效性上。
新标签中台架构
引入Apache Doris之后，我们对标签中台架构的进行了改进，主要改进集中在实时链路和标签数据存储这两个部分：
· 实时标签链路：仍然是通过实时数据源到Kafka中，通过Flink进行实时加工；不同的是，我们将一部分加工逻辑迁移到Doris中进行计算，长周期实时指标的计算从单一的Flink计算转移到了Flink + Doris中进行；
· 标签数据存储：从HBase改成了Doris，利用Doris聚合模型的部分更新特性，将离线标签和实时标签加工完之后直接写入到Doris中。
1.离线/实时标签混合圈人
· 简化存储：原存储在HBase中的大宽表，改为在Doris中分区存储，其中离线标签T+1更新，实时标签T更新、T+1采用离线数据覆盖矫正。
· 查询简化：面对人群圈选场景，无需利用Spark引擎，可直接在标签中台查询服务层，将圈选规则配置解析成SQL在Doris中执行、并获得最终的人群，大大提高了人群圈选的效率。面对规则匹配场景，使用Redis缓存Doris中的热点数据，以降低响应时间。
2.长周期实时标签计算原链路
长周期实时标签：计算实时标签时所需的数据周期较长，部分标签还需要采用历史数据（离线）合并实时数据流一起进行计算的场景。
使用前：
从原来的计算链路中可知，计算长周期的实时标签时会涉及到维度补充、历史数据Merge，在经过几步加工最终将数据写入到HBase中。
在实际使用中发现，在这个过程中Merge离线聚合的数据会使链路变得很复杂，往往一个实时标签需要多个任务参与才能完成计算；另外聚合逻辑复杂的实时标签一般需要多次聚合计算，任意一个中间聚合资源分配不够或者不合理，都有可能出现反压或资源浪费的问题，从而使整个任务调试起来特别困难，同时链路过长运维管理也很麻烦，稳定性也比较低。
使用后：
我们在长周期指标计算实时链路中加入了Apache Doris，在Flink中只做维度补充和轻度加工汇总，只关注短的实时数据流，对于需要Merge的离线数据，Merge的计算逻辑转移到Doris中进行计算，另外Doris中的轻度汇总/明细数据有助于问题排查，同时任务稳定性也能提升。
使用收益
目前标签中台底层有近4亿+条用户标签，每个用户标签300+，已有1W+用户规则人群，每天定时更新的人群数量达到5K+。标签中台引入Apache Doris之后，单个人群平均圈选时间实现了分钟级到秒级的跨越，实时标签任务稳定性有所提高，实时标签任务的产出时间相较于之前约有40%的提升，资源使用成本大大降低。
Doris在多维数据分析平台的应用
除以上所述应用及收益之外，Apache Doris也助力内部多维数据分析平台——斗鱼360取得了较大的发展，受益于Apache Doris的Rollup、物化视图以及向量化执行引擎，使原来需要预计算的场景可以直接导入明细数据到Doris中，简化了业务数据开发流程，提升了分析效率；Doris兼容MySQL协议，并具有独立简单的分布式架构，使得业务开发人员入门使用也更容易，缩短了业务开发周期，有效降低了开发成本；同时我们原来基于ClickHouse的查询目前也全部切换到了Doris中进行。
目前我们用于多维分析场景的Doris集群共有两个，节点规模约120个，存储数据量达90~100TB，每天增量写入到Doris的数据约900GB，其中查询QPS在120左右，Apache Doris应对起来毫不费力，轻松自如。
文章篇幅限制，该部分应用不再赘述，后续有机会与大家进行详细分享。
未来展望
未来随着Apache Doris在斗鱼更广泛业务场景的落地，我们将在可视化运维、问题快速定位排查等方面进行更多实践和深耕。我们关注到，Apache Doris 1.2.0版本已经对Multi Catalog功能进行了支持，我们也计划对其进行探索、解锁更多使用场景，同时也期待即将发布Apache Doris 2.x版本的行列混存功能，更好的支持Data Serving场景。