为什么需要实时数仓

目前各大公司的产品需求和内部决策对于数据实时性的要求越来越迫切，需要实时数仓的能力来赋能。传统离线数仓的数据时效性是 T+1，调度频率以天为单位，无法支撑实时场景的数据需求。即使能将调度频率设置成小时，也只能解决部分时效性要求不高的场景，对于实效性要求很高的场景还是无法优雅的支撑。因此实时使用数据的问题必须得到有效解决。像某些常见的场景要求必须低延时，如：股票在线交易、实时风控、监控告警系统、实时看板、实时运营等。因此实时数仓的建设就成为了重中之重。

实时数仓的常见架构及演进

此架构的分层逻辑：

1. Flink CDC 能全量+增量的方式同步数据到 Kafka（ODS层），可进行 ETL 和双流 Join 等操作。
2. 对于其它外部存储的 DIM 层数据，可以根据数据体量和性能采取（定时加载、广播流、异步 IO + 缓存等方式）进行维表打宽操作。
3. 使用 Kafka 作为分层存储的介质，分别构建 DWD、DWS。基于 Flink 状态编程进行指标统计。纯流式计算。
4. 最终的 ADS 层通过 Flink 写入 Kudu，通过 Impala 进行 OLAP 分析，刷入 Superset 进行报表展示。（注意：此处 ADS 层也可以选择 Doris/StarRocks 作为 OLAP 查询，对接 BI 平台或报表系统）

此架构的优点：

1. 基于 Flink 纯流式的计算，延时低。

此架构的缺点：

1. 复杂性较高，链路较长。
2. 关联外部维表时，会和外部存储介质建立连接，影响性能。
3. 乱序数据的处理比较麻烦。
4. Kafka 会定期清理历史数据，无法直接满足批流一体的场景。

end