滴滴实时数仓逐层剖解：实时与离线数据误差<0.5%

DBAplus社群 · 公众号 · 数据库 · 2020-10-30 07:15

正文

请到「今天看啥」查看全文

从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构；比如ODS层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但仔细比较不难发现，两者有很多区别：

1）与离线数仓相比，实时数仓的层次更少一些：

从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离；
应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟；
汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10再统计，确保 00:00 前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。

2）与离线数仓相比，实时数仓的数据源存储不同：

在建设离线数仓的时候，目前滴滴内部整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在 Kafka 里面，但是像城市、渠道等维度信息需要借助Hbase，mysql或者其他KV存储等数据库来进行存储。

接下来，根据顺风车实时数仓架构图，对每一层建设做具体展开：

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、DWD明细层建设

根据顺风车业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表；结合顺风车分析师在离线侧的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，完成宽表化处理，之后基于当前顺风车业务方对实时数据的需求重点，重点建设交易、财务、体验、安全、流量等几大模块；该层的数据来源于ODS层，通过大数据架构提供的Stream SQL完成ETL工作，对于binlog日志的处理主要进行简单的数据清洗、处理数据漂移和数据乱序，以及可能对多个ODS表进行Stream Join，对于流量日志主要是做通用的ETL处理和针对顺风车场景的数据过滤，完成非结构化数据的结构化处理和数据的分流；该层的数据除了存储在消息队列Kafka中，通常也会把数据实时写入Druid数据库中，供查询明细数据和作为简单汇总数据的加工数据源。

命名规范：DWD层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过40个字符，并且应遵循下述规则：realtime_dwd_{业务/pub}_{数据域缩写}_[{业务过程缩写}]_[{自定义表命名标签缩写}]

{业务/pub}：参考业务命名
{数据域缩写}：参考数据域划分部分
{自定义表命名标签缩写}：实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称，该名称应该准确表述实体所代表的业务含义

样例： realtime_dwd_trip_trd_order_base

3、DIM层

公共维度层，基于维度建模理念思想，建立整个业务过程的一致性维度，降低数据计算口径和算法不统一风险；
DIM 层数据来源于两部分：一部分是Flink程序实时处理ODS层数据得到，另外一部分是通过离线任务出仓得到；

DIM 层维度数据主要使用 MySQL、Hbase、fusion(滴滴自研KV存储) 三种存储引擎，对于维表数据比较少的情况可以使用 MySQL，对于单条数据大小比较小，查询 QPS 比较高的情况，可以使用 fusion 存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用HBase 存储。

命名规范：DIM层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过30个字符，并且应遵循下述规则：dim_{业务/pub}_{维度定义}[_{自定义命名标签}]：

{业务/pub}：参考业务命名