/ 实时数据数仓链路

/ Flink数仓问题与挑战

/ 目标与愿景

/ 存储实时数仓架构

/ 存储实时数仓架构生态

/ 一站式研发平台

/ 调度引擎挑战

实时生态系统非常复杂，实践中会遇到一些困难。

实时场景核心有两套引擎：调度引擎和OLAP引擎。

调度引擎面临的挑战主要有以下三方面：

针对T+0调度中的三个难题，我们采取了相应的解决方案：

● 首先，支持了T+0参数替换功能，提供了高级的运算法则，可以进行秒级或分钟级的时间偏移。

针对任务跑的时间长于调度间隔的问题，我们提出了MisFire处理策略，这个策略源自于Quartz的一些思想。针对不同的情况，有多种处理方式。最简单的是任务并行，这也是离线开发的默认方式。

另外一种方式是任务串行，特别适用于实时数据场景，避免数据乱序导致数据不准确。

还有一种方式是数据跳过，如果出现任务积压的情况，系统会自动跳过一些任务实例，以确保任务能够相对健康地运行。比如说，当任务积压了几百个实例时，下一次运行时会将相应的实例Kill掉，然后继续运行最新的实例。具体的处理方式需要根据业务场景来确定。

/ Doris引擎挑战

前面介绍了调度引擎面临的挑战和解决方案，接下来看一下OLAP引擎。OLAP引擎主要面临以下三方面挑战：

● 跨机房容灾能力：准实时领域跟服务端的一些情况有些类似，即在稳定性方面有着高的要求。一旦出现主播跟播时在线人数突然跳零，就会导致主播的一些话术无法及时组织和应变，进而产生严重的资损。

因此，我们需要跨机房容灾的能力，来应对单机房故障带来的整体服务不可用，以及实时数据无法对外提供的问题。

针对上述问题，一一进行解决。

● 首先，关于多机房容灾能力的问题，在三个机房中每个机房都有一张表的情况下，每张表有三个副本，其中一个副本分摊在一个机房，从生产端的MQ数据写入到Doris后，经过中间加工端再到消费端，最终形成了数据服务的全链路高可用性。在单个机房挂掉时，无论是生产还是消费，都会有同机房优先和跨机房降级策略来保障高效性和稳定性。

接下来简要介绍一些实际的应用场景。

/ Flink链路

/ 实时榜单解决方案

另一个是实时榜单解决方案。

针对这种场景，我们进行了解决方案的抽象，并在存储数仓中实施了一个方案。

最初的方案是基于Flink的，出现了一些问题，于是后期迁移到了基于Doris的存储数仓方案。这套方案的特点是元数据定义比较清晰。

元数据由实时表从MQ中的字段解析而来，解析后对其进行了一些元数据定义，即对榜单场景业务逻辑进行抽象，比如会定义周期、原子指标以及如何加工这些原子指标。

另外，还定义了榜单如何进行分区，分区可以根据实体类型来确定，例如对商家、视频或直播进行排名。通过简单的配置，能够快速创建出相应的Flink任务。

在业务实际运营中，有许多类似的榜单场景，这样的榜单场景过多导致出现了两个问题。

首先，榜单场景过多导致任务量激增，这会给资源治理带来较多困难。特别是对于实时流处理，需要24小时全天候运行，任务量增加会让资源治理问题变得更加严峻。

其次，报警运维也是一个挑战，实时任务报警频率高，甚至一个任务可能随时都会产生警报。而随着任务数量的增加，报警更加频繁。此外，由于大量任务消费同一个消息队列，会放大流量，给HDFS带来额外负担。

另外，电商领域的大型促销活动常常伴随着长周期状态，这种长周期计算会对Flink的大状态稳定性产生影响，同时也使回溯变得困难。为应对这些问题，运维人员经常需要在零点进行操作，只有在这个时间点才重新计算，相对来说状态比较小，回溯压力也比较小。

基于上述痛点，我们将Flink架构迁移到了存储数仓架构，使得运维工作变得更加高效。相比Flink，在榜单场景下资源量和报警量都有下降。并且解决了长周期计算的难题。由于状态保存在Doris的表中，长周期计算变得更加灵活。

最后分享我们在未来要做的一些工作。

首先是对解决方案的封装。我们已经封装了一个榜单业务场景，还有许多其他场景，比如DMP、标签和中间层数据等，这些场景都可以被打包成解决方案。除了模式和方法论的封装之外，还有存储架构的封装。

在存储架构方面，不断演进自研的数据湖产品，扩展更多的存储架构。

另外是智能化运维整合，实时数据的稳定性对开发和运维人员压力是非常大的，我们希望整合一些规则和算法，实现自动化处理部分场景，剩下的做推荐化预案，从而提升MTTR，提升故障恢复的时效性并降低成本。

以上就是本次分享的内容，谢谢大家。