| 滴滴基于 Flink 的实时数仓建设实践 | 您所在的位置：网站首页 › 实时数仓有哪些 › 滴滴基于 Flink 的实时数仓建设实践 |
滴滴基于 Flink 的实时数仓建设实践
|
随着滴滴业务的高速发展，业务对于数据时效性的需求越来越高，而伴随着实时技术的不断发展和成熟，滴滴也对实时建设做了大量的尝试和实践。本文主要以顺风车这个业务为引子，从引擎侧、平台侧和业务侧各个不同方面，来阐述滴滴所做的工作，分享在建设过程中的经验。 1.实时数仓建设目的随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要，商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息， 对企业的决策运营策略调整有很大帮助。 其次从智能商业的角度来讲，数据的结果代表了用户的反馈，获取结果的及时性就显得尤为重要，快速的获取数据反馈能够帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可替代的作用。 1.1 解决传统数仓的问题从目前数仓建设的现状来看，实时数仓是一个容易让人产生混淆的概念，根据传统经验分析，数仓有一个重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时流处理技术，又是强调当前处理状态的一个技术，结合当前一线大厂的建设经验和滴滴在该领域的建设现状，我们尝试把公司内实时数仓建设的目的定位为，以数仓建设理论和实时技术，解决由于当前离线数仓数据时效性低解决不了的问题。 现阶段我们要建设实时数仓的主要原因是： 公司业务对于数据的实时性越来越迫切，需要有实时数据来辅助完成决策 实时数据建设没有规范，数据可用性较差，无法形成数仓体系，资源大量浪费 数据平台工具对整体实时开发的支持也日渐趋于成熟，开发成本降低 1.2 实时数仓的应用场景 实时 OLAP 分析：OLAP 分析本身就是数仓领域重点解决的问题，基于公司大数据架构团队提供的基于 Flink 计算引擎的 stream sql 工具，Kafka 和 ddmq (滴滴自研)等消息中间件，druid 和 ClickHouse 等 OLAP 数据库，提升数仓的时效性能力，使其具有较优的实时数据分析能力。 实时数据看板：这类场景是目前公司实时侧主要需求场景，例如“全民拼车日”订单和券花销实时大屏曲线展示，顺风车新开城当日分钟级订单侧核心指标数据展示，增长类项目资源投入和收益实时效果展示等。 实时业务监控：滴滴出行大量核心业务指标需要具备实时监控能力，比如安全指标监控，财务指标监控，投诉进线指标监控等。 实时数据接口服务：由于各业务线之间存在很多业务壁垒，导致数仓开发很难熟悉公司内全部业务线，需要与各业务线相关部门在数据加工和数据获取方面进行协作，数仓通过提供实时数据接口服务的方式，向业务方提供数据支持。
在公司内部，我们数据团队有幸与顺风车业务线深入合作，在满足业务方实时数据需求的同时，不断完善实时数仓内容，通过多次迭代，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓，完成了整体数据分层，包含明细数据和汇总数据，统一了 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 数据库中。 命名规范：基于实时数仓的特殊性不做硬性要求。 3. 顺风车实时数仓建设成果截止目前，一共为顺风车业务线建立了增长、交易、体验、安全、财务五大模块，涉及 40+ 的实时看板，涵盖顺风车全部核心业务过程，实时和离线数据误差 |
【本文地址】