实时数据仓库思考总结

前文：

只有核心业务才需要实时，一般有大屏报表/监控，一般只看当天，隔天数据以离线为准；

资源上，一条流就要占用几G数据，通用逻辑使用配置+服用流处理；

管理上，指标更改/质量监控难度大，通过上下游数据量或离线实时数据对比触发告警；

架构上，我们依旧使用Lambda架构；且实时的分层需要将链路尽量短，所以一般就三层，中间层沉淀部分指标，并引入 olap 更新数据/提速查询；

一、业务场景

大屏报表 (流量/订单) + 系统监控；

数据特点： 日志类：数据量大；业务类：多表关联

二、架构

分层	作用
ods	原始数据
dwd	整合明细宽表；输出部分指标流；
ads(olap)	1. 存结果表：flink 开窗聚合 2. 存明细数据：使用 olap 的 rollup

总结：

考虑是否使用 olap 聚合数据；

使用 rollup 可以多维分析去重指标，但olap负载加重；

三、相关知识

3.2 双流Join

	Window Join	Interval Join	Regular Join
使用	coGroup() 或 join() .where().equalTo()	.keyBy().intervalJoin().between().process()	SQL
特点	关联不上则丢失； 窗口越大，时效性越差，性能低；	需要评估双流延迟上下界情况	无界数据：无论是否关联直接下发；后续关联到回撤；
适用	窗口内的关联率高的场景；	双流相互延迟低且关联性较高(推荐)	sink源支持回撤/更新机制

总结：一般基于数据流延迟情况及sink组件选择合适的关联方式。

3.1 维度表Join

	预加载维表	distributed cache	热存储关联	广播维表	Temporal table function join/Lookup join
使用	定时加载数据库数据	启动时加载文件	异步 IO + Cache 机制
特点			实时流		实时流
数据量	小	小	大	小	大
更新频率	定时更新		允许维度更新一定延迟	无延迟	允许维度更新一定延迟
外部存储	是(数据库)	是(文件)	是	否

总结：

维度表数据大时，只能加载一部分数据并设置淘汰机制，导致维度数据必然有一定延迟。

维度表数据小时，可以无延迟。

四、其他

4.1 算子

算子	作用
map	处理数据
flatmap	输出零或若干个指标流
window + reduce	聚合累加

4.2 关联

关联
regular join + lookup join	拉宽业务明细表
异步 join	补充维度表(区域)

4.3 修复

订单宽表：

1. 使用 doris 的主键模型，可以对订单多次更新；

2. 设置2个流 (1分钟/5分钟) 更新覆盖

3. 离线 t+1 天修正最近30天数据，与离线对齐

4.4 监控

对比数据：定时作业查询olap数据与hive数据偏差值过大时触发企微告警；