实时数据仓库的一些分层和分层需要处理的事情，以及数据流向

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [www.tuicool.com](https://www.tuicool.com/articles/FJVjyyF)

本篇文章只是对自己的一些实时数仓经验的一些总结，就架构和数据流向而言其实和离线数据仓库大同小异，但是实时处理有自己的特殊性

为什么要有实时数仓？
----------

我们已经有利离线数仓，数仓目的就是复用，但是离线是 T+1 的，在我们大量的实时需求，之前的离线计算不能复用，大量新的重复性实时代码开发，开发和计算资源的成本不断增加

实时数仓分层
------

![](/media/202207/2022-07-26_195244_5806500.8226569073616015.png)

ODS 原始数据，包含日志和业务数据

DWD

DIM

DWM

DWS

ADS

![](/media/202207/2022-07-26_195300_8639800.6212926577011451.png)

### DWD

每个表对应一个 Topic，把订单流水等业务数据重新写回 kafka，另外日志数据进行测输出流输出（sql 就是多个 insert +filter），主要有启动退出日志、页面（仅包含页面也就是 pv 日志）日志、行为日志等，不同的数据有完全不同的数据结构，所以要拆分处理

同时做一些非法值过滤，比如时间戳，uid 校验（主要是正则匹配，我们是 13 位数字），另外 ODS 的数据除了事实数据外还会有维度数据，需要写到 DIM 而不是 DWD

DWD 层主要的核心是数据分流以及状态识别

### DIM

像刚才说的，一些 ODS 的维度数据 Flink 拿到之后一般是直接写入 Hbase 了，方便我们做维流 join

### DWM

DWM 层主要是因为实时计算开发运维成本都较高，但是在 DWD -> DWS 的计算中还是有很多重复的计算，主要是抽取这部分进行公用

比如订单宽表，需要订单表和订单明细表以及各个维度表关联，那我们可以只处理一次作为宽表，在 DWS 各个行为或成单等用到直接从 DWM 拿数据关联即可

![](/media/202207/2022-07-26_195313_9446760.057176410521161736.png)

这一层往往会设计到较多的流流 join 和流维 join

### DWS

轻度聚合，应对各种实时查询，并缓解查询的压力

将更多的实时数据以主题的方式组合起来便于管理，同时也能减少维度查询的次数

那如何让设计 DWS 的表，主要是靠维度 + 度量（事实数据）

度量比如 uv、pv、跳出次数、进入页面次数（session_count）、连续访问时长等

维度主要是主要的即可，渠道、地去、版本、国内外、新老用户、系统（ios，安卓，电脑）这些

接受各个明细数据，合并成相同数据格式的流，然后窗口聚合后输出到数据库（我们是 clickhouse）

实时数仓应用落地
--------

实时数据大盘

告警监控

实时推荐