实时数仓实战项目(数仓分层)

实时数仓如何做数据分层

我不喜欢搞什么花里胡哨的词汇,让粉丝听着挠头,我就想用大白话分享我自己的建设思路和方案。

在开始分享之前,我想给兄弟们说一下数仓建设的方法论:“因地制宜,以业务为中心”。

我们需要思考���:业务需求是什么?你该如何用最优的方式去支持?

我们需要明白:你的架构的好坏,不是你自己认为好就是好,也不是你同事认为好就是好,而是要经得起业务的考验,这点认知就是年薪30万的sqlboy(自嗨)和年薪100万+(业务口碑)的sqlboy的认知差别。尤其是到了互联网大仓。一个公司高p前100名,20%是技术,80%是业务,为什么会出现这种情况?大家自己思考���,业务才是爸爸,一定要认清现实,越往高p走,技术越菜,大部分走向了管理岗位,所以不管你做什么事情都要往业务的角度上思考,业务都不赚钱了,要你技术有啥用。

下面我就开始拿离线数仓和实时数仓的架构做个对比讲解,方便大家易懂。(所有的分层都是为了更高效的解决业务问题,不能说不这么玩就不合理,看业务场景吧

For业务实时数仓架构图

1.ODS:操作数据层 Operation Data Store

ODS层属于操作数据层,是直接从业务系统采集过来的最原始的数据,包含了所有业务的变更过程,数据粒度也是最细的。

离线:hive

实时:kafka(实时数仓,要求时效性,基本上都是读取kafka)

2.DWD: 明细数据层 Data Warehouse Detail

数据明细详情,去除空值,脏数据,超过极限范围的明细解析。
是在ODS层基础上,根据业务过程建模出来的实时事实明细层,对于访问日志这种数据,会回流到离线系统供下游使用,最大程度地保证实时和离线数据ODS层和DWD层一致。
对ODS层数据进行清洗(去除空值,脏数据,超过极限范围的数据,行式存储改为列存储,改压缩格式)

DWD层创建基础明细表

明细表用于存储ODS层原始表转换过来的明细数据。

离线:hive

实时:kafka(实时数仓,复杂的计算逻辑和脏数据提前在flink内部完成,还有纬度退化能在flink内完成尽量在flink内实现,当然也可以把纬度数据同步到doris内,在doris内部做实时join也可以,都可以,根据不同情况制定方案,比如:这个纬度多个报表都需要查询,个人建议同步到doris内,如果纬度不经常用到,可以直接通过flink关联。还有一种业务场景就是给算法同学提供模型训练数据:如果要求的指标就是简单的sum,count可以直接在flink内产出,关联纬度信息写入到kv,复杂的模型训练指标,可以直接从doris实时查询结果数据,然后再传输给模型,根据sla的要求制定技术方案。)

3.DWS:汇总数据层 data warehouse service

服务层—留存-转化-GMV-复购率-日活 、点赞、评论、收藏;
轻度聚合对DWD
订阅明细层数据后,会在实时计算任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的,则会放在实时通用汇总层,作为通用的数据模型使用。
目标:统计当日、当周、当月活动的每个设备明细

离线:hive

实时:doris(一般都是在doris内创建聚合表,创建rollup表或者物化视图,这样做的好处是在doris内部提前预聚合,查询的时候直接命中结果数据,提高实时查询性能,如果设置本地join,两个表按照join的字段提前创建colocate join,这样做的好处是相同的uuid分桶在一起,在join的时候可以减少网络传输,相同的key直接在本地磁盘拉取就可以了。

4.DIM 公共维度层

实时维表层的数据基本上都是从离线维表层导出来的,抽取到在线系统中供实时应用调用。

离线:hive

实时:doris/kv(个人建议doris和kv根据业务情况选择,如果你们的纬度数据只是你们本地业务报表使用,可以存在Doris内,因为方便制作报表数据,如果你们的纬度数据其他合作团队也想用,建议写入到kv中,或者给他们binlog日志,让他们自己解析也可以。

5.ADS:应用数据层 Application Data Store

做分析处理同步到RDS数据库里边
个性化维度汇总层,对于不是特别通用的统计维度数据会放在这一层中,这里计算只有自身业务才会关注的维度和指标。
目标:当日、当周、当月活跃设备数 

离线:hive/mysql

实时:doris (目前我接触的实时的场景,80%都是直接查询dws层,多个表join产出数据,基本3s内就可以产出结果,如果时间太长,我们在dws层做一个分钟级别调度,比如5分钟做个结果表,也就是ads层,实时查询的时候直接查询ads层,这样的好处是提升业务体验,不好的地方就是你要确保调度的稳定性还有就是数据的时效性问题。

你可能感兴趣的:(数据库)