本篇文章只是对自己的一些实时数仓经验的一些总结,就架构和数据流向而言其实和离线数据仓库大同小异,但是实时处理有自己的特殊性
我们已经有利离线数仓,数仓目的就是复用,但是离线是T+1的,在我们大量的实时需求,之前的离线计算不能复用,大量新的重复性实时代码开发,开发和计算资源的成本不断增加
ODS 原始数据,包含日志和业务数据
DWD
DIM
DWM
DWS
ADS
每个表对应一个Topic,把订单流水等业务数据重新写回kafka,另外日志数据进行测输出流输出(sql就是多个insert +filter),主要有启动退出日志、页面(仅包含页面也就是pv日志)日志、行为日志等,不同的数据有完全不同的数据结构,所以要拆分处理
同时做一些非法值过滤,比如时间戳,uid校验(主要是正则匹配,我们是13位数字),另外ODS的数据除了事实数据外还会有维度数据,需要写到DIM而不是DWD
DWD层主要的核心是数据分流以及状态识别
像刚才说的,一些ODS的维度数据Flink拿到之后一般是直接写入Hbase了,方便我们做维流join
DWM层主要是因为实时计算开发运维成本都较高,但是在DWD -> DWS的计算中还是有很多重复的计算,主要是抽取这部分进行公用
比如订单宽表,需要订单表和订单明细表以及各个维度表关联,那我们可以只处理一次作为宽表,在DWS各个行为或成单等用到直接从DWM拿数据关联即可
这一层往往会设计到较多的流流join和流维join
轻度聚合,应对各种实时查询,并缓解查询的压力
将更多的实时数据以主题的方式组合起来便于管理,同时也能减少维度查询的次数
那如何让设计DWS的表,主要是靠维度+度量(事实数据)
度量比如 uv、pv、跳出次数、进入页面次数(session_count)、连续访问时长等
维度主要是主要的即可,渠道、地去、版本、国内外、新老用户、系统(ios,安卓,电脑)这些
接受各个明细数据,合并成相同数据格式的流,然后窗口聚合后输出到数据库(我们是clickhouse)
实时数据大盘
告警监控
实时推荐