Flink X Hologres构建企业级Streaming Warehouse

摘要：本文整理自阿里云资深技术专家，阿里云Hologres负责人姜伟华，在FFA实时湖仓专场的分享。点击查看>>本篇内容主要分为四个部分：

一、实时数仓分层的技术需求

二、阿里云一站式实时数仓Hologres介绍

三、Flink x Hologres：天作之合

四、基于Flink Catalog的Streaming Warehouse实践

点击查看视频回放

一、实时数仓分层的技术需求

首先，我们讲一讲数仓的分层技术以及分层技术的现状。

1、实时数仓分层技术现状

大数据现在越来越讲究实时化，在各种场景下都需要实时，例如春晚实时直播大屏，双11 GMV实时大屏、实时个性化推荐等场景，都对数据的实时性有着非常高的要求。为了满足业务的实时性需求，大数据技术也开始逐步发展出实时数仓。

但如何构建实时数仓呢？

相比离线数仓，实时数仓没有明确的方法论体系。因此在实践中，有各种各样的方法，但没有一个方法是万能。最近行业内提出了Streaming Warehouse的概念。Streaming Warehouse的本质是分层之间能够做到实时数据的流动，从而解决实时数仓分层的问题。

下面，我们先来了解下实时数仓的主流分层方案。

2、实时数仓主流分层方案

实时数仓的主流分层方案主要有4个。

方案1：流式ETL

ETL（Extract- Transform-Load）是比较传统的数据仓库建设方法，而流式ETL就是指：实时数据经过Flink实时ETL处理之后，将结果写入到KV引擎中，供应用查询。而为了解决中间层不方便排查的问题，也需要将中间层数据同步到实时数仓中供分析之用。最常见的做法就是数据通过Flink清洗后，写到Kafka形成ODS层。再从Kafka消费，经过加工形成DWD层。然后Flink加工成DWS层，最后通过加工形成ADS层的数据写到KV引擎并对接上层应用。因为直接使用Kafka数据进行分析和探查很麻烦，所以也会同步一份Kafka数据到实时数仓，通过实时数仓进行分析和探查。

这个方案的优势是层次明确，分工明确。但劣势是需要有大量的同步任务、数据资源消耗很大、数据有很多冗余、处理链路较复杂需要很多的组件。除此之外，这个方案构建的实时数仓分层，尤其是Kafka分层，复用性非常差，也没办法响应schema的动态变化。

方案2：流式ELT

而流式ELT则是将计算后置，直接将明细数据写进实时数仓（EL），不需要严格的数仓分层，整个架构只需要一层，上层应用查询的时候进行数据的变换（T）或者分层。常见的做法就是把数据加工清洗后，写到实时数仓里，形成DWD层，所有的查询都基于DWD层的明细数据进行。

这个方案的好处在于，没有ETL，只有一层；数据修订很方便。但它的弊端有两个方面：

• 在查询性能方面，由于是明细数据查询，所以在某些场景下不能满足QPS或延迟的要求。
• 因为没有严格的数仓分层，所以数据复用很困难，很难兼顾各方面的诉求。

方案3：定时调度

既然实时流式无法完成数据的实时数仓分层，我们可以将数据实时写入实时数仓的DWD层。DWS层、ADS层用离线的高频调度方法，实现分钟级的调度，从而借用离线数仓，进行分层构造。这个也就是业界常用的方案3。

这个方案的好处在于可以复用很多离线经验，方案成本低且成熟。但方案也存在如下缺点：

• 延迟大：每一层的延迟都跟调度相关，随着层次越多，调度延迟越大，实时数仓也变成了准实时数仓。
• 不能完全复用离线方案：离线调度一般是小时级或天级，我们可以使用全量计算。但在分钟级调度时，必须做增量计算，否则无法及时调度。

方案4：实时物化视图

第4种方案就是通过实时数仓的物化视图能力实现数仓分层。常见的做法就是Flink实时加工后，将数据写到实时数仓形成DWD层，DWS层或ADS层的构造依赖于实时数仓的实时物化视图能力。

现在主流实时数仓都开始提供物化视图的能力，但本质上都是提供了一些简单的聚合类物化视图。如果物化视图的需求比较简单，可以利用实时数仓里的实时物化视图能力，将DWS层到ADS层的构建自动化，从而让物化视图的查询保证较高的QPS。但这个方案最大的缺点在于&#