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

为什么要有实时数仓？

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

实时数仓分层

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

DWD

DIM

DWM

DWS

ADS

DWD

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

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

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

DIM

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

DWM

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

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

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

比较常见流流join就是订单和支付

比如流维join，在点赞，关注，点击包括下单时都需要关联商品的维度信息还有品类等等

DWS

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

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

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

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

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

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

实时数仓应用落地

我们主要就是以下3个场景：

实时数据大盘告警监控实时推荐

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。