赞
踩
曹操出行创立于 2015 年 5 月 21 日,是吉利控股集团布局“新能源汽车共享生态”的战略性投资业务,以“科技重塑绿色共享出行”为使命,将全球领先的互联网、车联网、自动驾驶技术以及新能源科技,创新应用于共享出行领域,以“用心服务国民出行”为品牌主张,致力于打造服务口碑最好的出行品牌。
作为一家互联网出行平台,主要提供了网约车、顺风车、专车等一些出行服务。打车为其主要的一个业务场景。用户会在我们的平台中去进行下单,然后我们的系统会给司机进行派单,接到订单之后,进行履约服务。结束一次订单服务后,乘客会在平台做出支付。
曹操出行业务痛点分析
整个流程中这些数据会流转到我们的业务系统,主要会有营销、订单、派单、风控、支付、履约这些系统。这些系统的数据会进入到 RDS 数据库,流转到实时数仓中去做一个分析和处理。最终数据会进入到不同的使用场景中,比如实时的标签,实时大屏、多维 BI,还有业务监控以及算法决策。
在传统 lambda 架构中,架构主要会分做实时数据流和离线数据流。在实时链路中,业务数据库会在 RDS 中通过 Canal、Binlog 同步的方式进入 Kafka,同时 app 的 log 也会通过实时采集的方式进入到 Kafka。在这些数据准备完成之后,在 Kafka 中构建实时数仓。整个数仓也是基于数仓分层理念去构建,主要是 ODS、DWD、DWS 和 ADS,整个链路中会通过 Flink Streaming Sql 去做一个串联。
在离线链路中,数据主要是通过 DataX 定时同步的方式,将 RDS 数据同步到HDFS。同时App的log会通过定时任务同步到 HDFS,整个离线数仓会通过 Spark Sql 的定时调度任务去逐层执行。数据在离线数仓中会通过不同的数据域去组织不同粒度的计算,最终数据会通过 Flink Sink 以及离线同步工具写到不同的数据应用组件中。同时为了保证某些应用场景中数据的一致性,有可能会对离线和实时两条链路的数据做些合并处理加工。
基于曹操出行整体对于成本的诉求,对于传统 lambda 架构,从架构中可以看到一些问题:
另外从对于公司开发者使用的角度,我们对实时数仓提出了以下几点诉求:
Hologres 能力分析
曹操出行作为 Hologres 的深度用户,在前期调研与测试阶段,我们对 Hologres 的相关能力做了比较详细的分析,主要有以下优势:
1、业务场景能力丰富:
2、一站式实时开发能力
3、解决的痛点问题
Hologres 支持高并发更新
通过观察存储架构,我们发现 Hologres 在最底层是分布式存储系统,在此之上是一个存储引擎,主要是有 Block Cache,shard 是分多个 Tablet 与 WAL,市面上主流的这种服务产品大多数都是基于这种 LSM 架构。
主流数据主键模型更新模式也有 Copy On Write 和 Merge On Read。这两种场景都有各自的问题,Copy On Write 具有写放大的问题,数据的延迟会比较高。Merge On Read 由于在读的过程中需要做数据的大量合并,因此其读的性能会非常差。在 Hologres 中,行存使用 Merge On Read 方式,列存主要基于 Merge On Write。基于这种架构,一条数据在进入 Hologres 中,首先会到达 WAL Manager中,同时也会进入到 Memtable,在 Memtable 中主要会存储三类数据:数据文件、删除标志的文件、例如基于 RoaringBitmap、索引文件。当数据积累到一定阶段后会生成不可变的 Memtable,后面会通过异步的线程,定时做 flush 到 Data File。
Hologres Binlog 支持
Hologres Binlog 也是一种物理表的存储方式,其跟原表的主要区别是内置的几种自身结构,包含自身递增序列,数据修改类型以及数据修改的时间,Binlog 本质上也是分 shard 做存储,所以也为一种分布式表,并且在 WAL 之前生成,因此在数据上可以与原表保证强一致性。
其次 Hologres Binlog 修改类型也还原了 Flink 中四种 RowKind 类型。在数据更新过程中可以产生两条更新记录,并且保证更新记录是一个连续的存储。右边展示中,写入一个数据一个 PK1,然后再写入一个 PK2 数据,PK2 的数据再做更新,Binlog 中它会产生四个数据结果。
Hologres 数据模型介绍
Hologres 主要会分做行存引擎以及列存引擎,包括行列共存场景。
实时数仓架构设计
基于以上 Hologres 的能力,接下来是对于曹操内部实时数仓的架构设计,左边为RDS 数据库,最右边是应用系统,最下边为元数据管理,中间部分是实时数仓的部分。数据通过 Binlog 进入到 Kafka 的 ODS 层之后,再会通过 Flink 会写入到 Hologres 里的 DIM 层,然后再通过 Flink 做 ODS 的多流汇聚,再写入到 Hologres 的 DWD 层。在 DWD 中可以做宽表打宽的是实现。再下一层,通过 Binlog 的订阅的方式,再写入到 Hologres 的 DWS 层,后面会统一通过 One Service 的一个统一查询服务对外暴露这个服务。
dwd 宽表构建实践
接下来介绍一下Hologres DWD宽表层的一个构建实践。基于之前提到的Hologres列更新能力,能够很好实现宽表Join能力。在整个生产过程中,首先关注维表的应用场景,其应用场景可能含有多种:一种是维表是不变的,或者缓慢的变化,另一种是维表频繁变化的。因此需要像离线的方式去构建一个维表拉链的数据,通过用过Start Time和End Time的方式去存储维度状态有效的一个周期。
其次需要关注维表延迟的问题。在实际生产过程中,维表链路与主表的链路是一个异步的过程,有可能在维表延迟的情况下,主表关联的数据是空的,或者主表关联到的一个数据是过时的维度状态。在这种场景下,需要在 Hologres 做维度缺失记录的过滤,通过补偿机制再去做维度的补偿处理,同时也需要做定时的维度检查,然后增量地把不一致的状态做一个修正。
聚合计算场景优化
接下来介绍我们对聚合场景的优化,针对我们多预聚合计算场景,将其统一收敛到Rollup 计算模型中,主要解决以下问题:
因此曹操出行主要优化了两点:
结合这两点,把已有的指标放入 map 结构中进行封装,这样在不改变原有的算子状态,也可以得到很好的处理。在下游中可以针对不用维度,指标做好选择,然后通过同步工具做好数据路由,提供给下游的服务。
对于第二个聚合场景的优化,是对精确去重场景的拆分。在前面例子中,我们把 Count Distinct 的精确去重做了剥离,主要解决两个问题:
链路中吞吐能力调优
整个流链路中吞吐能力的调优主要分作两个部分:
元数据血缘的改造
元数据血缘的改造主要解决了以下问题:
曹操出行主要进行以下措施:
链路保障体系
在日常开发过程中,对于任务健康以及任务出现异常后的判断和检测,都是通过异常检测诊断工具去做支持。主要体现四个方面:
数据订正能力建设
在传统的 Streaming 链路中,数据订正是一个非常复杂的过程。主要要解决两个问题:
因此我们主要思路是基于 Hologres 去做实现。首先对于原始任务进行代码修正后,并维持原有状态去做重启。第二步将对 Hologres 表做 Schema 的拷贝,然后新建一个订正的临时表。第三步会将任务进行拷贝,并将Sink调整到订正临时表,去做无状态从头消费的重启。这样可以把订正的结果数据订正进 Hologres 订正表中。等待消费结束后停止订正任务,然后通过修正脚本去对比原表以及订正表中关键信息,去做数据的订正。由于数据的订正,它处于数据终态,对于下游来说,不会造成大起大落。并且在整个链路中,因为正确数据可以通过整个数据链路做回撤的传导,因此整个下游就可以完成数据的自动订正。
架构清晰简单:
开发效率提高:
运维体验提升:
成本减少:
未来展望主要分为以下几个层面:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。