实时数仓项目架构分层
共 3897字,需浏览 8分钟
· 2022-04-09
一、滴滴实时数仓项目
在公司内部,我们数据团队有幸与顺风车业务线深入合作,在满足业务方实时数据需求的同时,不断完善实时数仓内容,通过多次迭代,基本满足了顺风车业务方在实时侧的各类业务需求,初步建立起顺风车实时数仓,完成了整体数据分层,包含明细数据和汇总数据,统一了DWD层,降低了大数据资源消耗,提高了数据复用性,可对外输出丰富的数据服务。
数仓具体架构如下图所示:
从数据架构图来看,顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构;比如ODS层,明细层,汇总层,乃至应用层,他们命名的模式可能都是一样的。但仔细比较不难发现,两者有很多区别:
与离线数仓相比,实时数仓的层次更少一些
从目前建设离线数仓的经验来看,数仓的数据明细层内容会非常丰富,处理明细数据外一般还会包含轻度汇总层的概念,另外离线数仓中应用层数据在数仓内部,但实时数仓中,app应用层数据已经落入应用系统的存储介质中,可以把该层与数仓的表分离。
应用层少建设的好处:实时处理数据的时候,每建一个层次,数据必然会产生一定的延迟。
汇总层少建的好处:在汇总统计的时候,往往为了容忍一部分数据的延迟,可能会人为的制造一些延迟来保证数据的准确。举例,在统计跨天相关的订单事件中的数据时,可能会等到 00:00:05 或者 00:00:10再统计,确保 00:00 前的数据已经全部接受到位了,再进行统计。所以,汇总层的层次太多的话,就会更大的加重人为造成的数据延迟。* 与离线数仓相比,实时数仓的数据源存储不同
在建设离线数仓的时候,目前滴滴内部整个离线数仓都是建立在 Hive 表之上。但是,在建设实时数仓的时候,同一份表,会使用不同的方式进行存储。比如常见的情况下,明细数据或者汇总数据都会存在 Kafka 里面,但是像城市、渠道等维度信息需要借助Hbase,mysql或者其他KV存储等数据库来进行存储。 接下来,根据顺风车实时数仓架构图,对每一层建设做具体展开:
2.1 ODS 贴源层建设
根据顺风车具体场景,目前顺风车数据源主要包括订单相关的binlog日志,冒泡和安全相关的public日志,流量相关的埋点日志等。这些数据部分已采集写入kafka或ddmq等数据通道中,部分数据需要借助内部自研同步工具完成采集,最终基于顺风车数仓ods层建设规范分主题统一写入kafka存储介质中。
命名规范:ODS层实时数据源主要包括两种。
一种是在离线采集时已经自动生产的DDMQ或者是Kafka topic,这类型的数据命名方式为采集系统自动生成规范为:cn-binlog-数据库名-数据库名 eg:cn-binlog-ihap_fangyuan-ihap_fangyuan
一种是需要自己进行采集同步到kafka topic中,生产的topic命名规范同离线类似:ODS层采用:realtime_ods_binlog_{源系统库/表名}/ods_log_{日志名} eg: realtime_ods_binlog_ihap_fangyuan
2.2 DWD 明细层建设
根据顺风车业务过程作为建模驱动,基于每个具体的业务过程特点,构建最细粒度的明细层事实表;结合顺风车分析师在离线侧的数据使用特点,将明细事实表的某些重要维度属性字段做适当冗余,完成宽表化处理,之后基于当前顺风车业务方对实时数据的需求重点,重点建设交易、财务、体验、安全、流量等几大模块;该层的数据来源于ODS层,通过大数据架构提供的Stream SQL完成ETL工作,对于binlog日志的处理主要进行简单的数据清洗、处理数据漂移和数据乱序,以及可能对多个ODS表进行Stream Join,对于流量日志主要是做通用的ETL处理和针对顺风车场景的数据过滤,完成非结构化数据的结构化处理和数据的分流;该层的数据除了存储在消息队列Kafka中,通常也会把数据实时写入Druid数据库中,供查询明细数据和作为简单汇总数据的加工数据源。
命名规范:DWD层的表命名使用英文小写字母,单词之间用下划线分开,总长度不能超过40个字符,并且应遵循下述规则:realtime_dwd_{业务/pub}{数据域缩写}[{业务过程缩写}]_[{自定义表命名标签缩写}]
{业务/pub}:参考业务命名
{数据域缩写}:参考数据域划分部分
{自定义表命名标签缩写}:实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称,该名称应该准确表述实体所代表的业务含义
样例:realtime_dwd_trip_trd_order_base
2.3 DIM 层
公共维度层,基于维度建模理念思想,建立整个业务过程的一致性维度,降低数据计算口径和算法不统一风险;
DIM 层数据来源于两部分:一部分是Flink程序实时处理ODS层数据得到,另外一部分是通过离线任务出仓得到;
DIM 层维度数据主要使用 MySQL、Hbase、fusion(滴滴自研KV存储) 三种存储引擎,对于维表数据比较少的情况可以使用 MySQL,对于单条数据大小比较小,查询 QPS 比较高的情况,可以使用 fusion 存储,降低机器内存资源占用,对于数据量比较大,对维表数据变化不是特别敏感的场景,可以使用HBase 存储。
命名规范:DIM层的表命名使用英文小写字母,单词之间用下划线分开,总长度不能超过30个字符,并且应遵循下述规则:dim_{业务/pub}{维度定义}[{自定义命名标签}]:
{业务/pub}:参考业务命名
{维度定义}:参考维度命名
{自定义表命名标签缩写}:实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称,该名称应该准确表述实体所代表的业务含义 样例:dim_trip_dri_base
2.4 DWM 汇总层建设
在建设顺风车实时数仓的汇总层的时候,跟顺风车离线数仓有很多一样的地方,但其具体技术实现会存在很大不同。
第一:对于一些共性指标的加工,比如pv,uv,订单业务过程指标等,我们会在汇总层进行统一的运算,确保关于指标的口径是统一在一个固定的模型中完成。对于一些个性指标,从指标复用性的角度出发,确定唯一的时间字段,同时该字段尽可能与其他指标在时间维度上完成拉齐,例如行中异常订单数需要与交易域指标在事件时间上做到拉齐。
第二:在顺风车汇总层建设中,需要进行多维的主题汇总,因为实时数仓本身是面向主题的,可能每个主题会关心的维度都不一样,所以需要在不同的主题下,按照这个主题关心的维度对数据进行汇总,最后来算业务方需要的汇总指标。在具体操作中,对于pv类指标使用Stream SQL实现1分钟汇总指标作为最小汇总单位指标,在此基础上进行时间维度上的指标累加;对于uv类指标直接使用druid数据库作为指标汇总容器,根据业务方对汇总指标的及时性和准确性的要求,实现相应的精确去重和非精确去重。
第三:汇总层建设过程中,还会涉及到衍生维度的加工。在顺风车券相关的汇总指标加工中我们使用Hbase的版本机制来构建一个衍生维度的拉链表,通过事件流和Hbase维表关联的方式得到实时数据当时的准确维度
命名规范:DWM层的表命名使用英文小写字母,单词之间用下划线分开,总长度不能超过40个字符,并且应遵循下述规则:realtime_dwm_{业务/pub}{数据域缩写}{数据主粒度缩写}[{自定义表命名标签缩写}]{统计时间周期范围缩写}:
{业务/pub}:参考业务命名
{数据域缩写}:参考数据域划分部分
{数据主粒度缩写}:指数据主要粒度或数据域的缩写,也是联合主键中的主要维度
{自定义表命名标签缩写}:实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称,该名称应该准确表述实体所代表的业务含义
{统计时间周期范围缩写}:1d:天增量;td:天累计(全量);1h:小时增量;th:小时累计(全量);1min:分钟增量;tmin:分钟累计(全量)
样例:realtime_dwm_trip_trd_pas_bus_accum_1min
2.5 APP 应用层
该层主要的工作是把实时汇总数据写入应用系统的数据库中,包括用于大屏显示和实时OLAP的Druid数据库(该数据库除了写入应用数据,也可以写入明细数据完成汇总指标的计算)中,用于实时数据接口服务的Hbase数据库,用于实时数据产品的mysql或者redis数据库中。
命名规范:基于实时数仓的特殊性不做硬性要求
二、美团OneData数仓项目
OneData: 阿里巴巴提出的数仓建设标准
![](https://filescdn.proginn.com/d66efdf7fb2ac01b5b40b2cdf2e5c5e8/80870358be9c18e49289d78947f1f92f.webp)
摘要
美团基于OneData思想和现有业务架构情况,提出了新的标准和目标:
![](https://filescdn.proginn.com/8e708e2f84d219739d5084302e83d722/46c6dcfabe8897b7cff37a5e191bc691.webp)
实现方法:统一归口和出口 统一归口:业务归口统一、设计归口统一和应用归口统一,从底层保证了数仓建设的三特性和三效果
统一出口:
交付标准化
数据资产管理:统一维度,指标元数据出口等
![](https://filescdn.proginn.com/271bae4eb89e18ba99c633a7ceadf224/6bd2c9e5d7a1ea7731486b23fad90cce.webp)
基于此,实现了分层模型:
![](https://filescdn.proginn.com/d1c987af3c9468e4550b9b52c1ab20fe/7e1555abf9675eae6e9df0dcbca683bd.webp)
正常开发应遵循ODS-DWD—DWT-DWA-APP的流程,同时根据架构做出 开发规范:
![](https://filescdn.proginn.com/ec57458c135227e33af11cfb178f0bee/44e96d8f47fa4ea9863097664c530242.webp)
![](https://filescdn.proginn.com/e66bf55c12e81dc822d9c3a729592e95/730b61f761409f45f94c5ae541bbb68f.webp)
正常流向:ODS>DWD->DWT->DWA->APP,当出现ODS >DWD->DWA->APP这种关系时,说明主题域未覆盖全。应将DWD数据落到DWT中,对于使用频度非常低的表允许DWD->DWA。尽量避免出现DWA宽表中使用DWD又使用(该DWD所归属主题域)DWT的表。
同一主题域内对于DWT生成DWT的表,原则上要尽量避免,否则会影响ETL的效率。
DWT、DWA和APP中禁止直接使用ODS的表,
ODS的表只能被DWD引用。
禁止出现反向依赖,例如DWT的表依赖DWA的表。
![](https://filescdn.proginn.com/df2965d925a20f9ca5de874127e8c263/caffeb524e1a4b95a221bc8b15f19dbe.webp)