网站网页制作公司,福田专门做网站推广公司,mvc5网站开发实战详解,鄢陵网站建设电脑建站随着滴滴业务的高速发展#xff0c;业务对于数据时效性的需求越来越高#xff0c;而伴随着实时技术的不断发展和成熟#xff0c;滴滴也对实时建设做了大量的尝试和实践。本文主要以顺风车这个业务为引子#xff0c;从引擎侧、平台侧和业务侧各个不同方面#xff0c;来阐述…随着滴滴业务的高速发展业务对于数据时效性的需求越来越高而伴随着实时技术的不断发展和成熟滴滴也对实时建设做了大量的尝试和实践。本文主要以顺风车这个业务为引子从引擎侧、平台侧和业务侧各个不同方面来阐述滴滴所做的工作分享在建设过程中的经验。
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 里面但是像城市、渠道等维度信息需要借助 HbaseMySQL 或者其他 KV 存储等数据库来进行存储。
接下来根据顺风车实时数仓架构图对每一层建设做具体展开
2.1 ODS 贴源层建设
根据顺风车具体场景目前顺风车数据源主要包括订单相关的 binlog 日志冒泡和安全相关的 public 日志流量相关的埋点日志等。这些数据部分已采集写入 Kafka 或 ddmq 等数据通道中部分数据需要借助内部自研同步工具完成采集最终基于顺风车数仓ods层建设规范分主题统一写入 Kafka 存储介质中。
命名规范ODS 层实时数据源主要包括两种。
一种是在离线采集时已经自动生产的 DDMQ 或者是 Kafka topic这类型的数据命名方式为采集系统自动生成规范为cn-binlog-数据库名-数据库名 egcn-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 汇总层建设
在建设顺风车实时数仓的汇总层的时候跟顺风车离线数仓有很多一样的地方但其具体技术实现会存在很大不同。
第一对于一些共性指标的加工比如 pvuv订单业务过程指标等我们会在汇总层进行统一的运算确保关于指标的口径是统一在一个固定的模型中完成。对于一些个性指标从指标复用性的角度出发确定唯一的时间字段同时该字段尽可能与其他指标在时间维度上完成拉齐例如行中异常订单数需要与交易域指标在事件时间上做到拉齐。
第二在顺风车汇总层建设中需要进行多维的主题汇总因为实时数仓本身是面向主题的可能每个主题会关心的维度都不一样所以需要在不同的主题下按照这个主题关心的维度对数据进行汇总最后来算业务方需要的汇总指标。在具体操作中对于 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 是表还是流来区分批处理任务和流处理任务从产品层面上实现批流一体化效果。 原文链接 本文为阿里云原创内容未经允许不得转载。
