江苏龙网

  1. 首页 > 资讯 > 资讯 > >

业务|滴滴基于 Flink 的实时数仓建设实践( 三 )


该层主要的工作是把实时汇总数据写入应用系统的数据库中，包括用于大屏显示和实时 OLAP 的 Druid 数据库中，用于实时数据接口服务的 Hbase 数据库，用于实时数据产品的 MySQL 或者 Redis 数据库中。
命名规范：基于实时数仓的特殊性不做硬性要求。
3. 顺风车实时数仓建设成果
截止目前，一共为顺风车业务线建立了增长、交易、体验、安全、财务五大模块，涉及 40+ 的实时看板，涵盖顺风车全部核心业务过程，实时和离线数据误差<0.5%，是顺风车业务线数据分析方面的有利补充，为顺风车当天发券动态策略调整，司乘安全相关监控，实时订单趋势分析等提供了实时数据支持，提高了决策的时效性。
同时建立在数仓模型之上的实时指标能根据用户需求及时完成口径变更和实时离线数据一致性校验，大大提高了实时指标的开发效率和实时数据的准确性，也为公司内部大范围建设实时数仓提供了有力的理论和实践支持。
4. 实时数仓建设对数据平台的强依赖
目前公司内部的实时数仓建设，需要依托数据平台的能力才能真正完成落地，包括 StreamSQL 能力，数据梦工程 StreamSQL IDE 环境和任务运维组件，实时数据源元数据化功能等。
业务|滴滴基于 Flink 的实时数仓建设实践
文章图片
4.1 基于StreamSQL的实时数据需求开发
StreamSQL 是滴滴大数据引擎部在 Flink SQL 基础上完善后形成的一个产品。
使用 StreamSQL 具有多个优势：
描述性语言：业务方不需要关心底层实现，只需要将业务逻辑描述出来即可。
接口稳定：Flink 版本迭代过程中只要 SQL 语法不发生变化就非常稳定。
问题易排查：逻辑性较强，用户能看懂语法即可调查出错位置。
批流一体化：批处理主要是 HiveSQL 和 Spark SQL，如果 Flink 任务也使用 SQL 的话，批处理任务和流处理任务在语法等方面可以进行共享，最终实现一体化的效果。
StreamSQL 相对于 Flink SQL 的完善：
完善 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 等多种方式。
【 业务|滴滴基于 Flink 的实时数仓建设实践】4.2 基于数据梦工厂的 StreamSQL IDE 和任务运维
StreamSQL IDE：
提供常用的SQL模板：在开发流式 SQL 时不需要从零开始，只需要选择一个 SQL 模板，并在这个模板之上进行修修改改即可达到期望的结果
提供 UDF 的库：相当于一个库如果不知道具有什么含义以及如何使用，用户只需要在 IDE 上搜索到这个库，就能够找到使用说明以及使用案例，提供语法检测与智能提示
提供代码在线DEBUG能力：可以上传本地测试数据或者采样少量 Kafka 等 source 数据 debug，此功能对流计算任务非常重要。提供版本管理功能，可以在业务版本不断升级过程中，提供任务回退功能。
任务运维：任务运维主要分为四个方面
日志检索：Flink UI 上查询日志体验非常糟糕，滴滴将 Flink 任务日志进行了采集，存储在 ES 中，通过 WEB 化的界面进行检索，方便调查。
指标监控：Flink 指标较多，通过 Flink UI 查看体验糟糕，因此滴滴构建了一个外部的报表平台，可以对指标进行监控。
报警：报警需要做一个平衡，如重启报警有多类如 ，通过设置一天内单个任务报警次数阈值进行平衡，同时也包括存活报警 、延迟报警、重启报警和 Checkpoint 频繁失败报警等。
血缘追踪：实时计算任务链路较长，从采集到消息通道，流计算，再到下游的存储经常包括 4-5个环节，如果无法实现追踪，容易产生灾难性的问题。例如发现某流式任务流量暴涨后，需要先查看其消费的 topic 是否增加，topic 上游采集是否增加，采集的数据库 DB 是否产生不恰当地批量操作或者某个业务在不断增加日志。这类问题需要从下游到上游、从上游到下游多方向的血缘追踪，方便调查原因。


推荐阅读


上一篇： 公司|女子上班吃了2颗葡萄，被辞退！

下一篇： 澜沧江|在澜沧江搜救4天后，知名旅游博主遗体被找到！