TikTok的主要收入来自直播和电商，这要求实时处理数据，比批处理更复杂，涉及多流连接和维度表更新，需要更多开发和维护资源，且为保障系统稳定，常导致资源浪费。本文邀请了TikTok数据平台团队分享他们如何利用Apache Doris构建实时数据架构，可作为高效实时数据仓库的范例学习。

在迁移到Apache Doris前，TikTok通过Flink传输实时数据，并使用Kafka在不同数据层间实现数据流动。由于Kafka本身没有逻辑表，因此在其上开发不如在Hive上那么容易。对于TikTok来说，实时数据与离线数据之间的数据量存在显著差距。由于与实时数据相关的开发、运营和资源成本，团队倾向于降低实时数据的要求，但这只是一种临时的解决方案。

基于Flink的架构在TikTok中已是一个成熟的解决方案。它主要用于成熟的业务应用。在数据存储方面，它利用Kafka提供的逻辑表格式。尽管缺乏字段、约束和高数据可追溯性，这种逻辑表方法仍支持了超过一半的实时数据开发。

新的架构基于Apache Doris，结构更简单，类似于离线Hive设置。这种基于Doris的架构的关键在于将亚秒级调度引擎与OLAP引擎相结合。这使得数据分层和重用离线开发成为可能。

为服务于TikTok的直播业务，OLAP引擎应在以下方面表现良好。

TikTok解决这些挑战的方式如下。

实时数据仓库如何支持TikTok的直播业务？

它构建了一个实时排行榜来监测其直播业务的表现。如前所述，它从Flink 迁移到了Apache Doris，新方案对元数据有明确的定义。元数据从实时表中的字段解析而来并给出定义。定义元数据是对排行榜业务逻辑的抽象。这还涉及实时排行榜的分区逻辑定义。通过简单的配置，可以快速创建相应的Flink任务。

然而，对这种实时排行榜的需求激增，对Flink架构带来了几方面的挑战。首先，过多的排行榜导致任务激增，使得资源管理更困难，尤其是需要24/7运行的实时流处理。其次，来自实时任务的警报越来越频繁。此外，大量任务共享同一消息队列，增加了流量，给HDFS带来了额外的负担。此外，由于电商中的大型促销活动往往持续较长时间，长周期计算对Flink的稳定性构成威胁，也使得回溯变得困难。为解决这些问题，维护人员通常需要在状态相对较小、回溯压力较轻的午夜进行操作。

与Flink的解决方案相比，基于Doris的数据仓库消耗的资源更少，产生的警报也更少。此外，由于状态存储在Doris表中，长周期计算变得更加灵活。