随着滴滴业务的高速倒退，业务对于数据时效性的需要越来越高，而随同着实时技术的一直倒退和成熟，滴滴也对实时建设做了大量的尝试和实际。本文次要以逆风车这个业务为引子，从引擎侧、平台侧和业务侧各个不同方面，来论述滴滴所做的工作，分享在建设过程中的教训。

1. 实时数仓建设目标

随着互联网的倒退进入下半场，数据的时效性对企业的精细化经营越来越重要，商场如战场，在每天产生的海量数据中，如何能实时无效的挖掘出有价值的信息，对企业的决策经营策略调整有很大帮忙。

其次从智能商业的角度来讲，数据的后果代表了用户的反馈，获取后果的及时性就显得尤为重要，疾速的获取数据反馈可能帮忙公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可代替的作用。

1.1 解决传统数仓的问题

从目前数仓建设的现状来看，实时数仓是一个容易让人产生混同的概念，依据传统教训剖析，数仓有一个重要的性能，即可能记录历史。通常，数仓都是心愿从业务上线的第一天开始有数据，而后始终记录到当初。但实时流解决技术，又是强调以后解决状态的一个技术，联合以后一线大厂的建设教训和滴滴在该畛域的建设现状，咱们尝试把公司内实时数仓建设的目标定位为，以数仓建设实践和实时技术，解决因为以后离线数仓数据时效性低解决不了的问题。

现阶段咱们要建设实时数仓的次要起因是：

• 公司业务对于数据的实时性越来越迫切，须要有实时数据来辅助实现决策
• 实时数据建设没有标准，数据可用性较差，无奈造成数仓体系，资源大量节约
• 数据平台工具对整体实时开发的反对也日渐趋于成熟，开发成本升高

1.2 实时数仓的利用场景

• 实时 OLAP 剖析 ：OLAP 剖析自身就是数仓畛域重点解决的问题，基于公司大数据架构团队提供的基于 Flink 计算引擎的 stream sql 工具，Kafka 和 ddmq (滴滴自研) 等消息中间件，druid 和 ClickHouse 等 OLAP 数据库，晋升数仓的时效性能力，使其具备较优的实时数据分析能力。
• 实时数据看板：这类场景是目前公司实时侧次要需要场景，例如“全民拼车日”订单和券花销实时大屏曲线展现，逆风车新开城当日分钟级订单侧外围指标数据展现，增长类我的项目资源投入和收益实时成果展现等。
• 实时业务监控：滴滴出行大量外围业务指标须要具备实时监控能力，比方平安指标监控，财务指标监控，投诉进线指标监控等。
• 实时数据接口服务：因为各业务线之间存在很多业务壁垒，导致数仓开发很难相熟公司内全副业务线，须要与各业务线相干部门在数据加工和数据获取方面进行合作，数仓通过提供实时数据接口服务的形式，向业务方提供数据反对。

2. 滴滴逆风车实时数仓建设举例

在公司外部，咱们数据团队有幸与逆风车业务线深刻单干，在满足业务方实时数据需要的同时，不断完善实时数仓内容，通过屡次迭代，根本满足了逆风车业务方在实时侧的各类业务需要，初步建设起逆风车实时数仓，实现了整体数据分层，蕴含明细数据和汇总数据，对立了 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+ 的实时看板，涵盖逆风车全副外围业务过程，实时和离线数据误差 <0.5%，是逆风车业务线数据分析方面的无利补充，为逆风车当天发券动静策略调整，司乘平安相干监控，实时订单趋势剖析等提供了实时数据反对，进步了决策的时效性。

同时建设在数仓模型之上的实时指标能依据用户需要及时实现口径变更和实时离线数据一致性校验，大大提高了实时指标的开发效率和实时数据的准确性，也为公司外部大范畴建设实时数仓提供了无力的实践和实际反对。

4. 实时数仓建设对数据平台的强依赖

目前公司外部的实时数仓建设，须要依靠数据平台的能力能力真正实现落地，包含 StreamSQL 能力，数据梦工程 StreamSQL IDE 环境和工作运维组件，实时数据源元数据化性能等。

4.1 基于 StreamSQL 的实时数据需要开发

StreamSQL 是滴滴大数据引擎部在 Flink SQL 根底上欠缺后造成的一个产品。

应用 StreamSQL 具备多个劣势：

• 描述性语言：业务方不须要关怀底层实现，只须要将业务逻辑形容进去即可。
• 接口稳固：Flink 版本迭代过程中只有 SQL 语法不发生变化就十分稳固。
• 问题易排查：逻辑性较强，用户能看懂语法即可考察出错地位。
• 批流一体化：批处理次要是 HiveSQL 和 Spark SQL，如果 Flink 工作也应用 SQL 的话，批处理工作和流解决工作在语法等方面能够进行共享，最终实现一体化的成果。

StreamSQL 绝对于 Flink SQL（1.9 之前版本）的欠缺：

• 欠缺 DDL：包含上游的音讯队列、上游的音讯队列和各种存储如 Druid、HBase 都进行了买通，用户方只须要构建一个 source 就能够将上游或者上游形容进去。
• 内置音讯格局解析：生产数据后须要将数据进行提取，但数据格式往往非常复杂，如数据库日志 binlog，每个用户独自实现，难度较大。StreamSQL 将提取库名、表名、提取列等函数内置，用户只需创立 binlog 类型 source，并内置了去重能力。对于 business log 业务日志 StreamSQL 内置了提取日志头，提取业务字段并组装成 Map 的性能。对于 json 数据，用户无需自定义 UDF，只需通过 jsonPath 指定所需字段。
• 扩大 UDX：丰盛内置 UDX，如对 JSON、MAP 进行了扩大，这些在滴滴业务应用场景中较多。反对自定义 UDX，用户自定义 UDF 并应用 jar 包即可。兼容 Hive UDX，例如用户原来是一个 Hive SQL 工作，则转换成实时工作不须要较多改变，有助于批流一体化。

Join 能力扩大：

• 基于 TTL 的双流 join：在滴滴的流计算业务中有的 join 操作数据对应的跨度比拟长，例如逆风车业务发单到接单的时间跨度可能达到一个星期左右，如果这些数据的 join 基于内存操作并不可行，通常将 join 数据放在状态中，窗口通过 TTL 实现，过期主动清理。
• 维表 join 能力：维表反对 HBase、KVStore、Mysql 等，同时反对 inner、left、right、full join 等多种形式。

4.2 基于数据梦工厂的 StreamSQL IDE 和工作运维StreamSQL IDE：

• 提供罕用的 SQL 模板：在开发流式 SQL 时不须要从零开始，只须要抉择一个 SQL 模板，并在这个模板之上进行修修改改即可达到冀望的后果
• 提供 UDF 的库：相当于一个库如果不晓得具备什么含意以及如何应用，用户只须要在 IDE 上搜寻到这个库，就可能找到应用阐明以及应用案例，提供语法检测与智能提醒
• 提供代码在线 DEBUG 能力：能够上传本地测试数据或者采样大量 Kafka 等 source 数据 debug，此性能对流计算工作十分重要。提供版本治理性能，能够在业务版本一直降级过程中，提供工作回退性能。

工作运维：工作运维次要分为四个方面

• 日志检索：Flink UI 上查问日志体验十分蹩脚，滴滴将 Flink 工作日志进行了采集，存储在 ES 中，通过 WEB 化的界面进行检索，不便考察。
• 指标监控：Flink 指标较多，通过 Flink UI 查看体验蹩脚，因而滴滴构建了一个内部的报表平台，能够对指标进行监控。
• 报警：报警须要做一个均衡，如重启报警有多类如 (机器宕机报警、代码谬误报警)，通过设置一天内单个工作报警次数阈值进行均衡，同时也包含存活报警 (如 kill、start)、提早报警、重启报警和 Checkpoint 频繁失败报警 (如 checkpoint 周期配置不合理) 等。
• 血统追踪：实时计算工作链路较长，从采集到音讯通道，流计算，再到上游的存储常常包含 4- 5 个环节，如果无奈实现追踪，容易产生灾难性的问题。例如发现某流式工作流量暴涨后，须要先查看其生产的 topic 是否减少，topic 上游采集是否减少，采集的数据库 DB 是否产生不恰当地批量操作或者某个业务在一直减少日志。这类问题须要从上游到上游、从上游到上游多方向的血统追踪，不便考察起因。

4.3 基于数据梦工厂的实时数据源元数据化(meta 化表)

将 topic 引入成实时表，metastore 对立治理元数据，实时开发中对立治理 DDL 过程。对实时数仓来说，通过元数据化，能够积淀实时数仓的建设成绩，使数仓建模能更好的落地。

目前数据梦工厂反对的元数据化实时数据源包含 Postgre、DDMQ、MySQL、Druid、ClickHouse、Kylin、Kafka。

5. 面临的挑战和解决方案思考

尽管目前滴滴在实时数仓建设方面已初具规模，但其面临的问题也不容忽视。

5.1 实时数仓研发标准

问题：为了疾速响应业务需要，同时满足数仓的需要开发流程，迫切需要建设一套面向实时数据开发的标准白皮书，该白皮书须要波及需要对接、口径梳理、数据开发、工作公布、工作监控、工作保障。

目前解决方案：目前由数据 BP 牵头，制订了一套面向实时数据指标的开发标准：

惯例流程：需求方提出需要，分析师对接需要，提供计算口径，编写需要文档。之后由数仓 BP 和离线数仓同学 check 计算口径，并向实时数仓团队提供离线 Hive 表，实时数仓同学基于离线 Hive 表实现数据探查，基于实时数仓模型实现实时数据需要开发，通过离线口径实现数据自查，最终交付给分析师实现二次校验后指标上线。

口径变更 – 业务方发动：业务方发动口径变更，判断是否波及到实时指标，数仓 BP 对离线和实时口径进行拉齐，向离线数仓团队和实时数仓团队提供更口口径和数据源表，实时数仓团队先上测试看板，验收通过后切换到正式看板

存在的有余：

• 当针对某个业务进行新的实时数据建设时，会有一个比拟艰巨的初始化过程，这个初始化过程中，会和离线有较多耦合，须要确定指标口径，数据源，并进行大量开发测试工作 
• 在指标口径产生变更的时候，须要有一个较好的告诉机制，目前还是从人的角度来进行判断。

5.2 离线和实时数据一致性保障

目前解决办法：由业务、BP、离线数仓独特保障数据源、计算口径与离线统一，数据加工过程，逐层与离线进行数据比对，并对指标后果进行具体测试，数据校验通过并上线后，依据离线周期进行实时和离线数据的校验

待解决的问题：联合指标管理工具，保障指标口径上的一致性，扩大数据梦工厂性能，在指标加工过程中，减少实时离线比对性能，升高数据比对老本。

6. 将来瞻望：批流一体化

尽管 Flink 具备批流一体化能力，但滴滴目前并没有齐全批流一体化，心愿先从产品层面实现批流一体化。通过 Meta 化建设，实现整个滴滴只有一个 MetaStore，无论是 Hive、Kafka topic、还是上游的 HBase、ES 都定义到 MetaStore 中，所有的计算引擎包含 Hive、Spark、Presto、Flink 都查问同一个 MetaStore，实现整个 SQL 开发完全一致的成果。依据 SQL 生产的 Source 是表还是流，来辨别批处理工作和流解决工作，从产品层面上实现批流一体化成果。