共计 4558 个字符，预计需要花费 12 分钟才能阅读完成。
导读： 斗鱼是一家弹幕式直播分享网站，为用户提供视频直播和赛事直播服务。随着斗鱼直播、视频等业务的高速倒退，用户增长和营收两大主营业务线对精细化经营的需要越发地迫切，各个细分业务场景对用户的差异化剖析诉求也越发的强烈。为更好满足业务需要，斗鱼在 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 进行预计算的加工链路，逐渐替换应用难度和运维难度绝对较高的 ClickHouse；
- 上游利用的数据存储从之前的 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~100 TB，每天增量写入到 Doris 的数据约 900GB，其中查问 QPS 在 120 左右，Apache Doris 应答起来毫不费力，轻松自如。
因文章篇幅限度，该局部利用不再赘述，后续有机会与大家进行具体分享。
将来瞻望
将来随着 Apache Doris 在斗鱼更宽泛业务场景的落地，咱们将在可视化运维、问题疾速定位排查等方面进行更多实际和深耕。咱们关注到，Apache Doris 1.2.0 版本曾经对 Multi Catalog 性能进行了反对，咱们也打算对其进行摸索、解锁更多应用场景，同时也期待行将公布 Apache Doris 2.x 版本的行列混存性能，更好的反对 Data Serving 场景。
