滴滴基于Flink的实时数仓建设

随着滴滴业务的高速发展，业务对于数据时效性的需求越来越高，而伴随着实时技术的不断发展和成熟，滴滴也对实时建设做了大量的尝试和实践。本文主要以顺风车这个业务为引子，从引擎侧、平台侧和业务侧各个不同方面，来阐述滴滴所做的工作，分享在建设过程中的经验。

1. 实时数仓建设目的

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

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

▍1.1 解决传统数仓的问题

从目前数仓建设的现状来看，实时数仓是一个容易让人产生混淆的概念，根据传统经验分析，数仓有一个重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时流处理技术，又是强调当前处理状态的一个技术，结合当前一线大厂的建设经验和滴滴在该领域的建设现状，我们尝试把公司内实时数仓建设的目的定位为，以数仓建设理论和实时技术，解决由于当前离线数仓数据时效性低解决不了的问题。

现阶段我们要建设实时数仓的主要原因是：

  公司业务对于数据的实时性越来越迫切，需要有实时数据来辅助完成决策

  实时数据建设没有规范，数据可用性较差，无法形成数仓体系，资源大量浪费

  数据平台工具对整体实时开发的支持也日渐趋于成熟，开发成本降低

▍1.2 实时数仓的应用场景

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

在公司内部，我们数据团队有幸与顺风车业务线深入合作，在满足业务方实时数据需求的同时，不断完善实时数仓内容，通过多次迭代，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓，完成了整体数据分层，包含明细数据和汇总数据，统一了DWD层，降低了大数据资源消耗，提高了数据复用性，可对外输出丰富的数据服务。

数仓具体架构如下图所示：

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

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

▍2.5 APP 应用层

该层主要的工作是把实时汇总数据写入应用系统的数据库中，包括用于大屏显示和实时OLAP的Druid数据库(该数据库除了写入应用数据，也可以写入明细数据完成汇总指标的计算)中，用于实时数据接口服务的Hbase数据库，用于实时数据产品的mysql或者redis数据库中。

命名规范：基于实时数仓的特殊性不做硬性要求

3. 顺风车实时数仓建设成果

截止目前，一共为顺风车业务线建立了增长、交易、体验、安全、财务五大模块，涉及40+的实时看板，涵盖顺风车全部核心业务过程，实时和离线数据误差<0.5%，是顺风车业务线数据分析方面的有利补充，为顺风车当天发券动态策略调整，司乘安全相关监控，实时订单趋势分析等提供了实时数据支持，提高了决策的时效性。同时建立在数仓模型之上的实时指标能根据用户需求及时完成口径变更和实时离线数据一致性校验，大大提高了实时指标的开发效率和实时数据的准确性，也为公司内部大范围建设实时数仓提供了有力的理论和实践支持。

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

目前公司内部的实时数仓建设，需要依托数据平台的能力才能真正完成落地，包括StreamSQL能力，数据梦工程StreamSQL IDE环境和任务运维组件，实时数据源元数据化功能等。

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

Join 能力扩展：

① 基于 TTL 的双流 join：在滴滴的流计算业务中有的 join 操作数据对应的跨度比较长，例如顺风车业务发单到接单的时间跨度可能达到一个星期左右，如果这些数据的 join 基于内存操作并不可行，通常将 join 数据放在状态中，窗口通过 TTL 实现，过期自动清理。

② 维表 join 能力：维表支持 HBase、KVStore、Mysql 等，同时支持 inner、left、right、full join 等多种方式。

 

▍4.2 基于数据梦工厂的StreamSQL IDE和任务运维

▍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 是表还是流，来区分批处理任务和流处理任务，从产品层面上实现批流一体化效果。

作者：滴滴技术团队

互联互通社区

互联互通社区专注于IT互联网交流与学习，关注公众号：互联互通社区，每日获取最新报告并附带专题内容辅助学习。方案打造与宣讲、架构设计与执行、技术攻坚与培训、数据中台等技术咨询与服务合作请+微信：hulianhutongshequ