做网站 需要什么样的服务器,西安房产网最新楼盘,第3章营销型企业网站建设,seo怎么发文章 seo发布工具本文整理自曹操出行实时计算负责人林震基于 HologresFlink 的曹操出行实时数仓建设的分享#xff0c;内容主要分为以下六部分#xff1a; 曹操出行业务背景介绍曹操出行业务痛点分析HologresFlink 构建企业级实时数仓曹操出行实时数仓实践曹操出行业务成果分析未来展望 一、曹… 本文整理自曹操出行实时计算负责人林震基于 HologresFlink 的曹操出行实时数仓建设的分享内容主要分为以下六部分 曹操出行业务背景介绍曹操出行业务痛点分析HologresFlink 构建企业级实时数仓曹操出行实时数仓实践曹操出行业务成果分析未来展望 一、曹操出行业务背景介绍 曹操出行创立于 2015 年 5 月 21 日是吉利控股集团布局“新能源汽车共享生态”的战略性投资业务以“科技重塑绿色共享出行”为使命将全球领先的互联网、车联网、自动驾驶技术以及新能源科技创新应用于共享出行领域以“用心服务国民出行”为品牌主张致力于打造服务口碑最好的出行品牌。 作为一家互联网出行平台曹操主要提供了网约车、顺风车和专车等出行服务。其中打车是其核心业务之一。整体业务过程大致如下: 首先用户在我们的平台上下单然后曹操平台会给司机进行订单的派发司机接到订单后会进行履约服务。结束一次订单服务后乘客会在平台上进行支付。 在整个流程中涉及到的数据将会在我们的业务系统中流转主要包括有营销、订单、派单、风控、支付、履约这些系统。这些系统产生的数据将存储在 RDS 中并进一步流入实时数仓中以进行分析和处理。最终数据会进入到不同的使用场景中比如实时的标签实时大屏、多维 BI 分析还有实时业务监控以及实时算法决策。 二、曹操出行业务痛点分析 上图是一个传统 lambda 架构在这个架构中主要会分做实时数据流和离线数据流。在实时链路中业务数据是存放在 RDS 中并通过 Binlog 以 Canal 同步的方式进入 Kafka 同时应用的日志数据也会通过实时采集的方式进入到 Kafka 。数据准备工作完成后在 Kafka 中构建实时数据仓库。整个实时数仓基于数仓分层理念进行构建的主要包括原始数据层ODS、数据明细层DWD、数据汇总层DWS和应用数据层ADS。这些层次通过 Flink Streaming SQL 进行串联实现数据的流转和处理。 在离线链路中数据主要是通过 DataX 定时同步任务将 RDS 中的数据同步到 HDFS 。同时应用的日志会通过定时任务同步到 HDFS 整个离线数仓以 Spark Sql 定时调度任务去逐层执行。数据在离线数仓中会以不同的数据域去组织满足不同粒度的数据计算最终数据会通过 Flink Sink 以及离线同步工具写到不同的数据应用组件中。同时为了保证某些应用场景中数据的一致性可能需要对离线和实时两条链路的数据进行合并处理和加工。 基于曹操出行数据生产成本和研发诉求针对传统 lambda 架构中可以看到一些问题 为了适配不同应用场景我们在架构中使用了非常丰富的数据组件。研发成本非常高不仅在实时链路中进行研发和处理而且还需额外研发一套离线的数据链路。运维效率较低由于整个实时数仓是构建在 Kafka 上的因此在数据探查以及进行数据订正就会变得非常困难。资源成本较大主要体现在几方面组件多需要专门安排人员进行运维和管理一些需要精准一致性的场景需求需在两个数据链路中做数据的同步和合并计算在某些计算场景中需要 Flink 维护大状态进行处理也造成额外性能问题和资源的浪费。 另外从公司开发者使用的角度我们对实时数仓提出了以下几点诉求 统一的组件来满足不同数据应用场景。复杂的实时数据链路中保障高效的数据订正。能克服在 Flink 中一些大状态下的技术难点。 三、HologresFlink 构建企业级实时数仓 1. Hologres 能力分析 曹操出行作为 Hologres 的深度用户在前期调研与测试阶段我们对 Hologres 的相关能力做了比较详细的分析主要有以下优势 1.1 业务场景能力丰富 具备 OLAP 分析能力具备高并发点查能力具备半结构化日志分析能力具备基于 PostGIS 的扩展能力支持空间地理信息信息数据的分析与使用对于曹操出行的业务属性来说非常重要。 1.2 一站式实时开发能力 契合数仓分层结构理念可以像离线数仓一样去构建分层体系数据实时流动实时存储)Flink Streaming 生态高度融合 Flink CDC组件集成Flink Catalog集成统一的 Ad-hoc 能力能以外表加载离线数仓中数据进行湖仓加速和联邦分析 1.3 解决的痛点问题 全链路低时延多流 Join 场景很好的提供数据打宽的能力支持主键模型和行级局部字段更新的能力Count distinct 大状态精确去重场景的支持 2. Hologres 支持高并发更新 Hologres 的存储架构基于分布式存储系统并在其上构建了存储引擎。在底层Hologres 使用了分布式存储系统来管理数据的存储和分布。在此之上存储引擎包括一些关键组件如 Block Cache、Shard ,每个 Shard 中包含了多个 Tablet 和 Write-Ahead LogWAL。 市面上主流的数据湖产品通常采用 LSMLog-Structured Merge架构。 主流数据主键模型更新模式有 Copy On Write 和 Merge On Read。这两种场景都有各自的问题 l Copy On Write 具有写放大的问题数据的延迟会比较高。 l Merge On Read读时合并模式在读取数据时需要进行大量的数据合并操作因此读取性能可能较差。 在 Hologres 中行存使用 Merge On Read 方式列存主要基于 Merge On Write。 下面主要介绍下在基于 Merge On Write 这种模式时一条数据在进入 Hologres 中它首先到达 WAL ManagerWrite-Ahead Log 管理器同时也会进入到 Memtable内存表。在 Memtable 中主要存储三类数据数据文件、删除标志文件例如基于 RoaringBitmap 的文件和索引文件。当 Memtable 数据积累到一定阶段后会生成不可变的 Memtable并通过异步线程定期将其刷新flush到 Data File数据文件中。通过这种架构Hologres 能够兼顾行存和列存的优势并通过适当的数据合并策略来提高性能和存储效率。 3. Hologres Binlog 支持 在 Hologres 中 Binlog 也是一种物理表其跟原表的主要区别是内置的几种自身结构包含自身递增序列数据修改类型以及数据修改时间Binlog 本质上也是分 shard 进行存储所以也为一种分布式表并且在 WAL 之前生成因此在数据上可以与原表保证强一致性。 其次 Hologres Binlog 修改类型也还原了 Flink 中四种 RowKind 类型。在数据更新过程中会产生两条更新记录update_beforeupdate_after并且保证了更新记录是一个连续的存储。右边展示中写入一个数据一个 pk1然后再写入一个 pk2 数据pk2 的数据再做一次更新那么在 Binlog 中它会产生4条数据结果。 4. Hologres 数据模型介绍 Hologres 主要分做行存引擎以及列存引擎同时也支持行列共存场景。 在聚合场景中主要是用到列存的引擎适合 OLAP 场景复杂查询统计以及关联等场景。同时也提供了非常丰富的索引包括有聚簇索引位图索引字典以及基于时间序列的范围索引。在 KV 场景 中主要是用到行存的引擎主要支持高并发组件查询。包括在 Flink 中做维表反查也是非常适合。在订阅场景中主要是用到行存的引擎主要在表属性中进行声明比如说 Binlog 是否开启Binlog 的 TTL。在订阅方的话Hologres 支持 CDC 以及非 CDC 的模式。在日志场景中针对聚合场景主要是支持 JsonB 数据类型。JsonB 数据的写入过程中Hologres 能够将其自动地平铺成列式的存储结构同时它可以自动对数据内容做解析对数据类型做泛化处理数据格式的对齐非常适合这种非稀疏场景因此给聚合场景提供了分析的灵活性。 四、曹操出行实时数仓实践 1. 实时数仓架构设计 基于前面 Hologres 的能力介绍接下来是对于曹操内部实时数仓的架构设计最左边是 RDS 数据库最右边是应用系统最下边为元数据管理中间是实时数仓的部分。数据通过 Binlog 进入到 Kafka 的 ODS 层之后首先通过 Flink 写入到 Hologres 里的 DIM 层然后再通过 Flink 做 ODS 的多流汇聚写入到 Hologres 的 DWD 层。在 DWD 中可以做宽表打宽的实现。再下一层通过 Hologres Binlog 的订阅的方式进入到 Flink 进行处理加工再写入到 Hologres 的 DWS 层。完成实时数仓分层建设后再统一通过 OneService 的统一查询服务对外提供服务。 2. dwd 宽表构建实践 接下来介绍一下 Hologres DWD 宽表层的一个构建实践。基于之前提到的 Hologres 列更新能力能够很好实现宽表 Join 能力。在整个生产过程中还需重点关注维表的应用场景其应用场景包含几种情况一种是维表是不变的或者缓慢的变化另一种是维表频繁变化的。为了保障数据最终的一致通常的设计是像离线的方式去构建一个维表拉链的数据通过用过 Start Time 和 End Time 的方式去存储维度状态有效的一个周期。 其次需要关注维表延迟问题。在实际生产过程中维表链路与主表的链路通常是异步的可能会出现维表延迟导致主表关联数据为空或关联到过时的维度状态。为处理这种情况需要在 Hologres 中实施维度缺失记录的过滤并采取补偿机制进行维度补偿处理。同时还需要定时调度进行维度字段和维表对比检查以增量方式修正不一致的维度状态。 3. 聚合计算场景优化 接下来是我们对聚合场景的优化针对许多预聚合计算场景我们将其统一收敛到 Rollup 计算模型中主要解决以下问题 在 Flink 聚合场景中经常会出现状态兼容性的问题整个数据的复用性非常差研发人员收到新的需求例如新的指标或者新增维度粒度时为了不影响生产数据的稳定性新增需求需要构建新任务导致任务管理混乱。 因此曹操出行主要进行了两点优化 构建 MapSumAgg 算子MapSum 主要通过对 SumAgg 算子做了重新设计使之能够支持 Map 内部结构的求和逻辑对 Grouping Sets 进行动态配置化这样 Grouping Sets 动态增加维度粒度使整个任务在不重启的情况下也能自动去做自适应 结合这两点把已有的指标放入 map 结构中进行封装这样在不改变原有的算子状态也可以得到很好的处理。在下游中可以针对不同维度组合指标集合做好选择然后由同步工具做实时的数据路由为下游提供服务。 对于第二个聚合场景的优化是对精确去重场景的拆分。在前面例子中我们把 Count Distinct 的精确去重做了剥离主要解决两个问题 维度爆炸的问题。在 Flink 的回撤机制下使用精确去重时需要存储全量状态。然而在 Cube 场景中这种状态的爆炸式增长对于 Flink 的可扩展性是一个挑战。查询灵活性的问题。解决思路是通过 Hologres 去构建细粒度的 RoaringBitmap 存储方案。 具体流程如下首先 在 Hologres 中构建自身序列的 UID 维表然后在主表中通过反差逻辑将 UID 的自身序列反查出来。接下来在 Flink 中进行 Group by 操作并进行聚合计算得出 RoaringBitmap 的结果。最后将结果写入 Hologres 的 DWS 层形成轻度汇总表用于 UV 计算。这种方案既能解决应用端在灵活维度查询时的高效性需求又能解决 Flink 中维度爆炸的问题。 4. 链路中吞吐能力调优 整个流链路中吞吐能力的调优主要涉及两个部分 数据写入侧在将数据写入 Hologres 之前针对字段状态频繁变更的场景进行了优化。引入了一个 Union 层在 Union 层和 ODS 层中数据根据主键进行分区。在 Union 层中通过一个小窗口进行预聚合计算以减少对 Hologres 的写入压力从而提高整体数据吞吐量。然而这种方式的缺点是无法捕获中间状态的数据。数据读取侧在使用 Binlog 更新数据时会产生连续的变更前后数据。在这种场景下可以采用 lag 开窗的方式来获取一次变更中连续的上下游数据。通过比较这两个数据之间的差异可以过滤掉冗余的变更数据从而减轻整个处理下游数据的压力。这种方式可以提高读取数据的效率和吞吐量减少不必要的数据处理。 5. 元数据血缘的改造 元数据血缘的改造主要解决了以下问题 Schema 的演进提供了一个更便利的管控解决实时链路发布流程中的依赖链问题。对任务元数据信息进行有效的管理 曹操出行主要进行以下措施来实现上述目标 Flink Catalog 集成在元数据中去整合 Hologres 的 Catalog也支持 Kafka Topic 表中自定义 Catalog支持多版本 schema 和任务数据的多版本提供更灵活的数据处理能力。Kafka Source 和 Kafka Sink 的改造。结合整合整个上线发布的流程对于数据的版本信息是通过 Kafka Sink 对 Header 进行记录Kafka Source 对 header 的版本信息进行过滤从而把数据版本引入到整个上下游的链路提供上下游数据灵活的迭代。这种做法的好处是在整个链路中可以感知到下游数据的使用情况帮助用户快速定位是否还有任务依赖于某个版本的数据图片主要是展示一个开发流程中元数据的集成。 6. 链路保障体系 在日常开发过程中对于任务健康以及任务出现异常后的判断和检测都是通过异常检测诊断工具去做支持。主要体现四个方面 对于基础信息采集通过采集工具把 Flink 内置 Metric 、Yarn 的 Metric 以及 Kafka 信息进行采集提供基础数据包括作业信息Kafka 一些 Topic 信息作业最新指标情况。对于异常的判断通过内存以及 Topic 增长情况包括 CPU 使用情况以及任务有无出现反压任务有无倾斜做出异常的判断。对于异常原因的诊断-内部原因内部原因主要会看 CheckPoint 的失败情况Kafka LAG 具体是什么算子造成的反压Restart 的次数attempt 的次数。对于异常原因的诊断-外部原因外部原因主要是看 Job Manager 以及 Task Manager 所在节点自身的情况包括 CPU 使用率、IO 利用率、内存情况等然后做出综合判断帮助用户去快速定位具体问题的原因。 在链路保障体系中全链路的感知能力是非常重要的。曹操出行主要通过流量监控和延迟监控来实现全链路的感知能力 流量监控层面通过 Kafka Cueernt Offset 以及 Hologres 内置的 Offset 信息做定时的采集从而推算出 Kafka 以及 Hologres 表的生产速率。Latency 监控层面主要采集 Kafka Offset 以及 Flink Source 的 Offset 情况结合 Kafka Massage Timestamp 去推算出每个任务自身延迟情况再结合整个数据血缘进行一个串联可以得出端到任务自身整体的延迟时间。 通过任务上下游生产速率比以及任务自身延迟情况在整个生产链路中可以快速定位出具体异常和问题发生的节点以便及时处理和优化提高系统的性能和稳定性。 7. 数据订正能力建设 在传统的 Streaming 链路中数据订正方案一直是个复杂工程主要涉及以下两个方面的挑战 如何知晓订正的数据为正确数据验证其具有一定困难。在整个验证过程中如何保证对下游的透明如果丢状态去做重启的订正肯定会对下游造成很大的影响。 因此我们主要思路是基于 Hologres 去做实现。首先对于原始任务进行代码修正后并维持原有状态去做重启。第二步将对 Hologres 表做 Schema 的拷贝然后新建一个订正的临时表。第三步会将任务进行拷贝并将 Sink 调整到订正临时表去做无状态从头消费的重启。这样可以把订正的结果数据订正进 Hologres 订正表中。等待消费结束后停止订正任务然后通过修正脚本去对比原表以及订正表中关键信息去做数据的订正。由于数据的订正它处于数据终态对于下游来说不会造成大起大落。并且在整个链路中因为正确数据可以通过整个数据链路做回撤的传导因此整个下游就可以自动完成数据的订正。 五、曹操出行业务成果分析 1. 架构清晰简单 对比原有 Lamada 架构Hologres Flink 整体架构更加清晰使用数据组件大大减少整体技术复杂难度降低原先为了解决数据一致性问题数据需要在不同的异构存储和异构链路中来回传输和计算整个技术复杂度较高 2. 开发效率提高 整个开发模式变得简单易用大大缩短人力周期数据实时模型分层非常清晰整体下游复用性以及使用门槛大幅度降低 3. 运维体验提升 ​ 由于数据存储在 Hologres 之上因此数据探查更加便捷数据订正难易程度大幅度减少。 4. 成本减少 组件维护成本减少 数据的离线存储和实时存储从双份存储降低到一份存储以及降低了数据在异构存储之间的同步与计算成本 解决在 Flink 中各类计算场景中大状态的资源成本减少了计算开销并提升了处理性能。 六、未来展望 未来展望主要分为以下四个层面 当前 Flink 集群还是一个自建的集群对于这些集群我们业务最关心的是使用过程中其业务的稳定性和可靠性。特别是在高峰场景资源不足时怎么去做快速的缩扩容。在高峰期过去后怎么去做到无缝缩容降低业务风险包括减少业务的数据中断时间。在任务级别的动态感知和智能调控上。很多时候研发根据自己的经验去设置 Flink 的资源参数往往有很多资源其实是多设或者是额外设置的。通过动态感知能力的引入能够有效提升整体的资源使用情况包括未来也可能会引入智能算法包括自适应的机制去达到节约成本的目的。Flink CDC 来统一 ODS 入仓的方案。我们在离线使用 DataX 的入仓方案后来实时使用了 Flink CDC 的入仓方案其实本质上数据可以提供一个统一的解决思路来解决数据的一致性和灵活性的诉求。包括在 CDC 方案中也会有一些定制上的需求。比如说在 CDC 过程中数据加解密以及 RDS 数据归档一系列诉求。使用 Flink CDC 的过程中也会分阶段的做一些调整包括一些高频迭代的诉求也会在后续的规划中更优先的解决。关于曹操出行的数据服务规划。目前有很多数据服务场景包括了在线应用场景以及分析型的服务场景业务会比较关注数据服务的高可用以及服务的可扩展性那怎么样通过同一份数据来做到不同服务的扩展。这部分我们后续会考虑基于 Hologres 主从隔离的能力和结合数据存储计算隔离的一些特点优势构建一主多从的架构来支持和满足这些数据应用服务。