![]()
本文导读：随着网络直播规模的不断扩大，在线知识服务在直播行业中迎来了广阔的发展机遇。小鹅通作为一家以用户服务为核心的技术服务商，通过多平台直播与推流服务吸引和转化潜在用户，同时通过直播数据分析平台，帮助商家分析直播指标数据、分析用户观看情况、构建精准用户画像。然而，随着直播用户数量的激增，平台在写入和查询方面的支持逐渐无法满足业务需求，为了应对挑战，小鹅通开启了架构升级之旅。本文将详细介绍小鹅通直播数据分析平台的优化过程，分享小鹅通基于 Apache Doris 优化写入与查询性能、完善用户标签功能和保障平台稳定性等实践经验，为商家提供了更精细化的用户经营支持。（作者｜小鹅通 大数据开发工程师 宫贺）
深圳小鹅网络技术有限公司，是一家以知识产品与用户服务为核心的技术服务商，创始至今已累计生产了 2000 万个知识产品，已服务的商家规模达 160 万，其中不乏腾讯学堂、华夏基金、西贝、吴晓波频道、十点读书、凯撒旅游等各行业一线知名品牌。作为私域运营的一站式工具，针对商家业务痛点，小鹅通提供了多方面的闭环解决方案，包括产品与服务交付、营销获客、用户运营、组织角色管理、品牌价值输出等以实现业务升级。
![]()
随着“直播带货”消费模式的兴起，网络直播规模的持续上升，在线知识服务开始在直播行业中开拓广袤发展领域，借助直播工具的力量能够有效吸引和转化潜在用户，借助直播分析平台能够实现对 C 端用户数据留存与分析，助力 B 端商家客户的精细化用户运营。
在这一背景下，小鹅通直播为商家提供了多平台的直播与推流服务，以及多种直播带货的营销玩法，不仅能将公私域流量引导至直播间，实现商家引流目标，还提供了多维度的分析平台。商家可以通过直播数据分析平台导出和分析各项直播数据指标，生成用户标签，以了解用户观看直播的情况和动态、构建精准的用户画像。
目前，小鹅通直播场次已累积达 600 万次，终端用户数近 8 亿，最高同时在线观看人数超过 1000 万。然而，面对直播用户数量激增，直播数据分析平台在数据写、查方面的支持逐渐无法满足业务需求，我们希望能够借助分析平台掌握直播间在线人数、在线时长、商品转化率、交易额等数据，并在直播间波峰波谷时期记录以上数据的流量趋势图。为了满足上述的业务需求，小鹅通对于平台架构提出更高的性能要求：
-
写入性能：需具备海量数据实时写入的能力，确保在直播过程中高吞吐场景下数据稳定导入；
-
数据更新：为了应对直播期间交易状态和用户数据的变化，我们需要架构具备高效准确的更新机制，确保业务人员及时掌握最新数据；
-
查询性能：能够支持高并发点查，也能满足联邦查询的需求，保证不同查询场景下数据分析的时效性；
-
平台运维：由于直播业务具有明显的波峰波谷时段，分析平台需要确保在直播高峰时段保持稳定的运行状态。同时，在波谷时段，平台应该支持节点弹性缩容，以提高资源利用率并控制运维成本。此外，为了避免系统运行故障导致站点破坏、为了保持系统高可用性，架构还需要提供可靠的灾备方案，以确保业务连续。
在遭遇系统业务瓶颈后，小鹅通开启了平台基础建设重构之旅，在经过业务调研、选型对比和内测应用后，基于 Apache Doris 对最初 Elasticsearch 与 HBase 的架构进行了迭代升级，并于今年 5 月份正式上线 Apache Doris 版本的直播数据分析平台。
本文将详细介绍小鹅通直播数据分析平台的优化过程，分享小鹅通如何基于 Apache Doris 提升平台查询性能、完善用户标签功能、保障平台稳定性等实践经验，最终赋能商家精细化用户经营。
基于 Elasticsearch 与 HBase 早期架构
![]()
直播数据分析平台的原始数据主要来源于 MySQL 的业务数据库、学习 SDK、埋点 SDK，平台架构主要分为离线与实时链路：
两类数据依据业务需求，将用户基本信息与直播相关业务指标关联，形成直播参与用户大宽表，其中当权益、订阅等主业务数据发生变更时，需要与 HBase 中的用户维表进行关联补全数据。数据每次更新都会在宽表补全后，将所有字段一起发送至下游 Elasticsearch 来承载业务人员的查询需求，避免并发修改的情况。
随着直播用户规模的扩大，我们对于数据时效性、查询性能等方面要求逐渐升高，而原架构的局限性也逐渐影响业务分析需求：
-
数据流转时效性低：由于组件过多，导致计算链路过长、节点过多，写入与查询的时效性也必然会受到影响，无法支撑直播波峰时段的实时导入与极速分析。
-
数据更新链路复杂：直播数据每次发生变更时，都需要先将变更数据写入主表与维度表中，随后重新关联生成新的宽表以覆盖旧数据。这一过程涉及多个组件和长链路，更新机制的复杂度与低效也随之增加。
-
查询性能不足：在高并发查询场景下，Elasticsearch 需要处理大量的查询请求和数据访问，导致查询负载过重，分析效率低；在关联查询场景下，Elasticsearch 无法满足 Join 计算需求，查询灵活度低。
-
架构运维成本高：组件过多还会导致整体架构运维成本升高、开发人员学习成本加大、指标扩展较为局限等问题。
基于以上架构痛点，我们在 2022 年 7 月开启系统重构项目的调研工作，最终在众多数据仓库中选择了 Apache Doris 进行架构升级，并在同年 11 月开启长达 6 个月的内测工作，希望借助 Apache Doris 在实时写入、数据高效更新、极速查询性能和简易运维等方面的优势，在直播数据分析场景中强化直播用户数据挖掘，获取更多高价值的业务洞察。
基于 Apache Doris 的全新直播数据分析平台
![]()
在升级到全新架构后，我们统一了实时和离线两条数据处理链路，全部交由 Apache Doris 来进行处理。如图所示，原始数据经过 Flink 流处理计算后，会实时写入到 Apache Doris 的表模型中，根据场景我们分别选用了不同的数据模型进行查询加速，数据表与对应的查询需求具体如下：
-
用户维度表：借助 Apache Doris 的 Aggregate Key 模型将用户维度数据聚合，同时通过 replace_if_not_null 方式实现部分列更新；
-
标签表：为了更好地构建用户标签体系，实时更新用户画像，我们借助 Unique Key 将数据分为标签与标签版本两类表，通过 Merge on Write 更新数据，并借助 Doris 关联查询性能，使商家获取最新版本的用户标签。
-
学习数据表：同样借助 Aggreagte Key 模型将用户在平台中的学习数据进行聚合，支持后续直播用户分析需求。
在 Apache Doris 引入后为我们提供了全新的数据流转，满足写入与查询时效性的需求，有效解决了原架构链路痛点。目前，我们基于 Doris 十余台集群规模为直播数据分析平台提供实时写入与极速分析，并带来了以下具体收益：
01 写查接口统一、写入效率更高
Flink-Doris-Connector 内置了 Flink CDC ，支持从业务数据库中全量和增量抽取数据，同时 Doris 也可以通过 Routine Load 来订阅 Kafka 中的数据、一流多表秒级写入，大幅提升了数据集成同步的效率。
利用 Apache Doris 替换原架构中 HBase 、Elasticsearch 等多个组件，减少了中间数据在不同链路中的流转，解决了链路过长、组件过多的问题，通过 Apache Doris 一套系统实现统一对外数据服务。
02 数据写时合并、高效更新
在 Apache Doris 聚合后，单表最大达数十亿的情况下，可以支撑每秒 20 万的数据 Upsert 与 Insert Overwrite，满足了直播高峰时期高吞吐写入需求。
在数据更新时，无需将字段补全后再重新开发宽表，可以直接利用 Merge On Write 功能进行轻量级 Merge，通过写时合并，实现微批高频实时写入与部分列更新。
03 多场景下的查询加速
在高并发点查时，我们高频使用 Doris 分区分桶裁剪功能，在查询时过滤非必要的数据，使数据扫描快速定位，加速查询响应时间。
在关联查询时，Apache Doris 支持对多张 10 亿级表进行 Join，满足分析人员将用户基础信息与学习、标签数据等关联查询需求。更重要的是，Doris 在标签检索、模糊查询、排序、分页等场景下都可以达到秒级甚至毫秒级的查询响应。
04 开发周期缩短、运维成本降低
Apache Doris 自身架构简单，FE 和 BE 两节点能够灵活扩缩容，易于部署、迁移与运维。在架构升级后，通过简化链路我们的运维成本相较于之前降低近 2/ 3。
同时 Doris 兼容 MySQL，使开发操作简单、使用门槛低，研发成本也随之降低。现在指标开发时间大幅度缩短，由原来单个指标耗时一个月缩短至现在仅需一周即可完成，加速指标迭代周期。
接下来，我们将从查询加速、容灾备份、数据可视化分析三方面分享 Apache Doris 在直播数据分析场景中应用实践，希望通过分享为读者提供更多关于 Doris 应用洞察。
用户画像场景查询加速实践
对于直播业务，用户标签是构成用户画像的核心因素，能够将用户在直播过程中所产生的行为数据分析提炼，生成具有差异性特征的标签词，以更好地掌握用户属性、用户偏好、直播习惯等信息。 在小鹅通直播分析平台中，商家可以自行定义规则生成标签，例如 “观看直播超过一分钟” 的用户为一类标签，“最近一分钟访问直播间”的用户为另一类标签。在这个过程中，商家会频繁不断地对用户“贴标签”（插入数据）或者“撕标签”（删减数据），与此同时每位用户也可能会存在多个自动或者手动标签。基于此，数仓需要具备以下能力：
我们以下面的 SQL 为例，介绍基于 Apache Doris 在标签场景如何快速抽取数据、如何通过主键模型创建标签表与标签版本表、如何对字符串开启模糊查询解析，实现用户信息的快速检索，加速用户行为与经营业务分析。
创建标签表：
create table db.tags (
u_id string,
version string,
tags string
) with (
'connector' = 'doris',
'fenodes' = '',
'table.identifier' = 'tags',
'username' = '',
'password' = '',
'sink.properties.format' = 'json',
'sink.properties.strip_outer_array' = 'true',
'sink.properties.fuzzy_parse' = 'true',
'sink.properties.columns' = 'id,u_id,version,a_tags,m_tags,a_tags=bitmap_from_string(a_tags),m_tags=bitmap_from_string(m_tags)',
'sink.batch.interval' = '10s',
'sink.batch.size' = '100000'
);
创建标签版本表：
create table db.tags_version (
id string,
u_id string,
version string
) with (
'connector' = 'doris',
'fenodes' = '',
'table.identifier' = 'db.tags_version',
'username' = '',
'password' = '',
'sink.properties.format' = 'json',
'sink.properties.strip_outer_array' = 'true',
'sink.properties.fuzzy_parse' = 'true',
'sink.properties.columns' = 'id,u_id,version',
'sink.batch.interval' = '10s',
'sink.batch.size' = '100000'
);
两类表写入：
insert into db.tags
select
u_id,
last_timestamp as version,
tags
from db.source;
insert into rtime_db.tags_version
select
u_id,
last_timestamp as version
from db.source;
Bitmap 索引加速标签查询：
在写入完成后，业务人员开始对用户相关数据进行查询分析。以常见查询场景为例，我们需要查找某位姓张用户在最新版本中的标签数据，首先会在用户主表中使用 LIKE 匹配符合要求的用户名，其次在分页查询中对标签字段分别创建 Bitmap 索引，如 “123”、“124”、“125”、“126”、“333”，最后通过三表关联快速找到标签信息。
with t_user as (
select
u_id,
name
from db.user
where partition_id = 1
and name like '%张%'
),
t_tags as (
select
u_id,
version
from db.tags
where (
bitmap_and_count(a_tags, bitmap_from_string("123,124,125,126,333")) > 0
)
),
t_tag_version as (
select id, u_id, version
from db.tags_version
)
select
t1.u_id
t1.name
from t_user t1
join t_tags t2 on t1.u_id = t2.u_id
join t_tag_version t3 on t2.u_id = t3.u_id and t2.version = t3.version
order by t1.u_id desc
limit 1,10;
在直播数亿用户规模、每位用户存在上千个标签的场景下，使用 Bitmap 索引来查询用户相关数据后，查询时间均能够在 1 秒内响应并准确地为业务人员提供所需结果，大大加速了标签查询速度。
双集群高可用方案
在直播课程大促期间，为了带动直播间的下单氛围，提升用户秒抢积极性与下单率，平台会在直播间开启抽奖等活动。在引入 Doris 之前，我们将每日备份数据到对象存储中。当直播过程中优惠券领取、下单等出现故障时，从用户反馈、层层上报，再到故障恢复，需要花费数个小时。
然而，在这数小时中，成百上千的用户会因此流失，我们则需要承受用户退出直播间、寻找其他替代产品等巨大风险与损失。因此，平台面对海量用户访问的冲击，数据恢复与解决故障的速度成为了直播间业务效益的关键。
为了保障短期指数级业务波峰下平台的稳定运行，我们决定采取全新容灾方案。基于 Apache Doris 主备双集群的方式，实现热备；使用 Airflow 通过 Backup 与 Freeze 策略将每日数据备份至对象存储，以实现冷备，其中热备具体流程如下：
-
数据双写：改造 Flink Doris Connector，通过配置将数据写到两个集群或单个集群，在处理某个集群需要升级的场景时，先停止写一个集群后再去改造另外一个集群，有效保证集群的稳定性。
-
负载均衡：通过反向代理来切换查询请求到指定集群。当某一集群出现了问题，我们可以及时把请求接到另外一个集群上面。
-
监控校验：定期校验主从集群的数据及表结构的一致性，以便及时发现数据性不一致的情况。
我们还将进一步引入 Doris 2.0 版本中推出的 CCR 跨集群数据复制功能，尝试使用该功能减少开发运维成本，降低人工储备集群双写所导致两个集群 DDL 不一致的风险。
自研数据可视化平台，统一实时查询出口
![]()
数据可视化分析平台主要用于离线报表、即席查询、实时数据大屏（Dashboard）三大场景，为商家业务人员、管理层等提供可视化分析功能。在引入 Doris 之后，我们将 MySQL、Elasticseach、本地文件等多种数据源统一交给 Apache Doris 实现。
同时，为了更好地将数据呈现给商家，我们还增加了数据源管理与数据集创建功能，业务人员可以直接在平台中选择数据源进行配置、测试等操作，形成可视化列表。除此之外，平台结合了 BI 工具中丰富的图表样式，满足商家配置数据看板的个性化需求。
在引入 Apache Doris 之后，通过数据集的配置实现了数据管理、权限管理等功能，并利用 Apache Doris 极速多维分析、联邦查询的能力加速了数字化平台的查询展示性能，摒弃了原来的 T+1 报表，在 Apache Doris 之上实现即时查询。
未来规划
目前，基于 Apache Doris 构建的分析平台主要用于小鹅通直播业务，为用户相关数据提供服务。在 Apache Doris 引入后，平台架构实现了写查出口统一、时效性大幅提升、用户数据多维分析场景拓展，同时 Doris 的加持还使后台系统具备稳定性、可扩展性、安全性等关键优势。这些突破促使平台基础技术能力进一步提高，也促进了用户数量、直播效益进一步增长。
后续我们希望继续拓展 Apache Doris 的使用场景，将课程分析、用户日志分析等交由 Apache Doris 对外提供统一的数据分析服务。同时，我们也希望继续探索 Apache Doris 2.0 版本的新特性，进一步提升集群稳定性能，包括：
-
Pipeline 执行引擎和基于成本的查询优化器：在做用户直播列表时有许多复杂的售后场景需要人工优化，当有了 Pipeline 执行引擎和查询优化器后，不再需要人工调 SQL ，使执行性能更优；
-
CCR 跨集群数据同步：通过用户多集群的数据库表自动同步以提升在线服务数据的可用性；
-
倒排索引：利用 Apache Doris 2.0 版本的倒排索引功能，对现有的索引结构进行丰富，实现模糊查询、等值查询和范围查询等能力，进一步加速查询响应速度。
在此特别感谢 SelectDB 技术团队在使用过程中遇到任何问题都能及时响应，为我们降低了许多试错成本。未来，我们也会更积极参与 Apache Doris 社区贡献及活动，与社区共同进步和成长！
