网站建设的目的和作用,网店推广软文范例,太原网页制作,wordpress界面英文摘要#xff1a;本文整理自字节跳动基础架构工程师李国君#xff0c;在 Streaming Lakehouse Meetup 的分享。幸福里业务是一种典型的交易、事务类型的业务场景#xff0c;这种业务场景在实时数仓建模中遇到了诸多挑战。本次分享主要介绍幸福里业务基于 Flink Paimon … 摘要本文整理自字节跳动基础架构工程师李国君在 Streaming Lakehouse Meetup 的分享。幸福里业务是一种典型的交易、事务类型的业务场景这种业务场景在实时数仓建模中遇到了诸多挑战。本次分享主要介绍幸福里业务基于 Flink Paimon 构建流式数仓的实践经验从业务背景、流批一体数仓架构、实践中遇到的问题和解决方案借助 Paimon 最终能拿到的收益以及未来规划方面进行介绍。 点击查看原文视频 演讲PPT 一、业务背景 幸福里业务是字节旗下关于房产的业务线围绕这个业务有很多针对 BP 支持的方向其中最重要的方向之一就是工单系统。工单系统面向的用户是幸福里业务线一线的经纪人和门店经理等。如下图所示我们可以看下通过工单系统数据是如何产生和流转的。 首先由经纪人将已完成的代看任务提交工单后续相应的门店经理会对该工单进行审核在这个过程中就产生了两条数据并将其更新到业务库的 Binlog 数据作为实时数仓的数据源进行计算后生成数据报表或直接用于一些考核系统。其中数据报表用于展示评估一线经纪人的工作是否达标等考核系统则用于门店经理为一线经纪人设定考核任务量的工作系统通过任务量标准自动反馈奖励等。因此在以上应用的实时数仓建模上我们发现房产类业务有两个典型的特点 准确性要求 100%不能有数据丢失和重复的情况发生。 需要全量计算增量数据在 MQ 留存时间有限需要拿到全量数据 View 进行计算。 实时数仓建模特点 在实际业务的实时数仓 Pipeline 中进入实时数仓前有多个数据源每个数据源的特点也都不同所以实时增量部分会存在 MQ 中全量数据则是存在 Hive 中。 上图实时数仓中的每一层都是由一个 Flink Streaming SQL 串联起来的DW 层的主要功能是把多个数据源进行 Join 打宽通过计算出来的宽表实现直接输出进 MQ 中。由于 MQ 的留存时间有限会形成一个小时级或天级的周期性任务在一个周期结束后 MQ 中的数据最终会落到 Hive 里。DWM 这一层主要的作用是聚合计算聚合计算的结果也会直接输出到 MQ 中。每一层的计算模式都和上一层相同实时数仓的计算结果会通过 Service 层服务于在线的数据应用比如上面提到的数据报表和考核系统。每层输出的 Hive 离线数据可以用于 BP 同学做数据排查/验证等离线查询工作。 回顾实时数仓的两个特点一是准确性要求 100%也就是说要求整个数仓的实时任务状态算子都要维护全量数据二是需要全量计算是指由于异构存储实时数据存在 MQ历史数据存在 Hive那么就使得每层消费的 MQ 都需要实时消费增量数据和 Hive 全量数据。从开发工程师的视角这套实时数仓模型存在如下痛点 在开发过程中需要时刻关注业务逻辑之外的逻辑比如在 SQL 中对数据的重复处理在数据去重过程中使用单一字段处理不够精准需要引入 Nanotime 做非确定性计算来解决问题等。之所以存在以上问题主要是因为在整个链路中实时数据和离线数据是分开存储的这种存储异构使得两部分的数据天然很难对齐。 这里的数据运维包含三个部分数据排查、数据验证和数据订正。存在的问题是在数据排查和数据验证的过程中如果发现某条链路上的某个 SQL 作业需要订正。订正完成的 SQL 的结果输出到 MQ 中需要再将 MQ 中的数据落盘到存储中的操作会产生 T1 的代价。另外在订正过程中的中间结果回退会直接暴露给用户。 第二个问题是如上图紫色部分是一个简化的链路而在实际生产过程中的复杂度很高体现在主链路上的是一些表和任务会被其他很多任务或表依赖使得订正过程会影响到很多不可预知的表或任务。造成以上问题的原因主要有两点一个是数据订正产生结果回退暴露给用户另外则是血缘关系复杂且需要人为维护。 在当前的这条链路上Flink 实时任务的状态维护是非常大的这就造成存储和计算资源的消耗非常大从这么大的状态中恢复作业的过程也会很慢。产生状态大问题的两大原因主要是去重算子维护全量数据状态和级联 Join 状态重复。 为什么选择 Paimon 基于以上存在的痛点我们考虑希望通过 Flink 生态搭建 Steaming Lakehouse 的组合来解决原始链路上的问题如上图所示原始链路存在的问题有 存储异构BaseDelta 数据难对齐 去重引入非确定性计算和大状态 血缘关系复杂 数据订正结果回退暴露给用户。 对应解决原始链路的问题我们选择了 Paimon 流批一体的存储可以以统一 Table 对外输出实时和离线数据可以存储到一张 Paimon 表中直接解决了对齐的问题 不需要去重Changelog Producer 代替状态算子同时支持在存储上产生完整的 Log并将其持久化代替原有链路上的状态算子 血缘管理 数据一致性管理支持无感知数据订正。 二、流式数仓实践 首先介绍流式数仓实践过程中的架构设计如下图所示 存储层选用了 HDFS 或 S3 的对象存储作为存储底座选用 Paimon 作为统一的 Table 抽象 计算层选用 Flink 同一的技术栈统一了流批计算 数据管理层实现了 Table 的血缘管理和数据的血缘管理基于这样的血缘管理可以做到数据一致性血缘管理可以用于数据溯源的需求为数据质量提供保障。 数据一致性管理流批一体 ETL 数据管理。在多表一致性联调的时候可以自动对齐数据不需要开发人员手动对齐。 如上图可见上层通过 Gateway 或 Service 层对外提供服务最终用户通过 SQL Client 或是 Rest API 访问整个系统。 上图是流式数仓 Pipeline。数据源和前面提到的一样离线数据存在 Hive 中实时数据存在 MQ 中。不同的是在进入 Streaming Lakehouse 的时候设置了一个 ODS 层这层会通过 Flink Streaming SQL 把每一个数据源沉淀到 Paimon Table 里。第二层是 DWD 层通过对多个数据源进行 Join 打宽的操作将输出的结果沉淀到 Paimon Table 里。再通过最后一层 APP 层做指标聚合以及透出的工作。 由于中间数据都沉淀在 Paimon Table 中所以开发人员在做数据排查和验证的时候可以直接操作。通过上图实时数仓的 Pipeline 可以看到存储上是流批一体的在计算上也是用 Flink 的技术栈统一了流批计算这样可以减少开发和运维的成本。而且中间数据沉淀也是可直接查询的不需要在运维的时候做更多繁琐的操作。 在完成上述 Streaming Lakehouse 实践落地后总结了如下收益 简化开发流程 流批一体存储可以解决实时和离线存储异构的问题 减少业务入侵移除去重算子解决非确定性计算。 提升运维体验 中间数据可查数据可追溯 血缘关系 多表一致性增强了多表关联调试能力并且可以做到数据订正无感知。 减少状态量 Changelog 持久化可以减少30%的状态量。 在实践过程中除了获得了不少收益也同样遇到了新的问题主要包括两个 数据新鲜度差端到端的延迟变化为分钟级数据新鲜度降低 小文件问题一些小文件可能会影响读写性能。 三、流式数仓的调优 端到端延迟调优 首先要分析下整个链路数据的可见性与什么相关。如上图所示Source 在收到数据之后会把这些 Records 源源不断的发给 Bucket然后 Bucket Writer 在收到数据后先把这些数据缓存到一个基于内存的 Buffer存满之后会触发一个 Flash 将这个 Buffer 里的数据全部都 Flash 到磁盘上。这个时候就生成了对外不可见的数据文件只有当上游触发了一个 Checkpoint 的时候整个链路中 Commit 算子生成一个 Snapshot 指向刚生成的数据文件才能对外可见。 分析整个流程可以得出两个结论 数据可见性与 Checkpoint 绑定。更严格的说是一个周期的数据可见性与 Checkpoint 周期严格绑定。 Checkpoint 周期 Checkpoint interval Checkpoint latency。Checkpoint interval 是 Checkpoint 触发的频率Checkpoint latency 是整个完成一个 Checkpoint 所需的耗时。 因此在我们在做端到端调优的时候是否只需要针对 Checkpoint 周期做相关调整就可以呢最简单的是不是将 Checkpoint interval 进行调小操作呢 在得出结论前我们先来看下写入流程。在 Paimon Sink 算子中Bucket Writer 会源源不断的把数据开放到磁盘的数据文件里另外 Paimon Sink 还包含另外一个组件 Compact Manager。这个组件主要是针对磁盘上的数据文件不断的做 Compaction。如上图右侧展示Compaction 在逻辑上是个 Bucket在存储上是一个目录目录下会存放很多数据文件这些文件是由 LSM 树组织的分为多个 Level。实际上 Compact Manager 在做 Compaction 的时候就是针对这些不同层的数据做的过程。 所以我们推断整个 Compaction 过程是一个 I/O 比较多的操作过程假设一味的调小 Checkpoint Interval会导致频繁的 Checkpoint比如原来 100 条数据本来是能分一个文件里的但是现在 Checkpoint 频率过高后这 100 条数据可能会被分到多个文件里那么每个文件里面的数据都会很小。其次小文件过多会让 Compaction 的整体代价变得更高也会影响写入的性能。其实这就是一个追求数据新鲜度的过程主要需要在数据的写入性能和数据新鲜度上做权衡。在经过多方实践验证后推荐将 Checkpoint Interval 设置为 1-2 分钟为优。 Checkpoint Latency 优化可以分为几个方向进行 Log-Based 增量 Checkpoint 利用 Flink 高版本的一些特性如 Log-based 增量 Checkpoint 的方式去优化上传阶段的耗时。 减少状态量 比如减少上传输数据量那么上传耗时就会减少。 Checkpoint 持续上传 持续上传本地状态文件。 搭建独立 HDFS 集群 减少遇到慢节点的概率。 经过以上四种方向的优化我们在实践中得到验证的结果是可以将端到端的延迟做到分钟级。 小文件优化 字节内部的实践是基于 HDFS 为存储底座的我们将小文件定义为明显小于 HDFS 上一个 Block 大小的文件。小文件引出最直接的问题就是文件数量太多导致需要更多的 Block比如 Create BlockDelete Block等直接的影响就是 I/O 操作频繁会导致 HDFS 上的 NamaNode 压力过大对稳定性产生影响另外无论文件本身有多大它的 Block 的元信息是固定的而这些元信息都是存在 NameNode 内存里的过多的 Block 元信息会造成内存 OOM 问题当数据太分散/文件数量太多时数据就有可能被分配到更多的 HDFS 的 DataNode 里就会造成 DataNode 的来回跳转增加频繁的随机读写使效率和性能变低并且分配的 DataNode 变多遇到慢节点的概率也会变大。 在小文件相关的问题中决定是否产生小文件的时机和因素有以下几点 文件生成。数据文件在磁盘上生成是有两个触发时机的一个是 Checkpoint 的时候它会强制把当前的 WriteBuffer 里的数据刷到磁盘上第二个是 WriteBuffer当它满了也会把内存里面的数据刷到磁盘上。如果把 Checkpoint Interval 调的过小或是把 WriteBuffer 容量设置的比较小那么数据就会更频繁的被刷到磁盘上而产生过量的小文件。 文件划分。通过设置一些 Partition key 或 Bucket key就决定了数据的走向它会落在哪些文件里。比如生产中实际数量非常小同时又设置了过多的 Bucket那么可以预见一个 Bucket 可以分到的数据量一定会比较小。这个过程中也会遇到小文件问题。另外如果设置 Partition key 或 Bucket key 不合理可能会产生一些文件倾斜的情况即热 Key 问题。 文件清理。Paimon 具有文件清理机制在 Compaction 过程中会删除一些无用的文件。另外数据由 Snapshot 管理如果 Snapshot 过期就会从磁盘上删除对应的数据文件。如果 Compaction 触发条件和 Snapshot 过期条件没有管理好也会造成冗余的文件留在磁盘上。 基于以上的介绍分享一下我们在实践过程中积累的一些小文件调优参数见下表所示。 Checkpoint interval:推荐在 1-2 min 比较合适 WriteBuffer 大小推荐使用默认值除非遇到相关问题需要调整 业务数据量可以根据业务数据量调节 Bucket 数调整依据为单个 Bucket 大小在 1G 左右比较合适 Key 的设置可以根据实际的业务 Key 特点设置合适的 Bucket-key、Partition以防产生热 Key 倾斜的问题 Compaction 管理和 Snapshot 管理相关参数推荐使用默认值除非遇到相关问题需要调整。 经历了整个架构改造之后我们将原有实时数仓链路做了对比如下图可见在很多指标上都获得了一定的收益。 端到端延迟在原始实时数仓开启 Mini-batch 的情况下端到端延迟没有明显退化可以支持 1-2 min 的近实时可见 数据排查时效性可以从小时级提升到分钟级 状态量节省了约 30% 开发周期缩短约 50%。 四、未来规划 当前主要规划了以下四个方向 首先秒级端到端延迟的尝试。可能会分几期来做计划引入 Embeded Log System 来解决这个问题。长期来看会把数据可见性与 Checkpoint 解绑 其次数据一致性管理。血缘关系管理和数据一致性管理这两个方面在实际数据运维中是很有价值的 第三状态复用。状态复用主要是解决 Join 状态复用的问题。另外我们希望可以做到中间状态可查 第四监控运维。未来当规模上去希望可以建立监控体系并做到指标可观测。 QA Q请问在数据源异构的情况下是否考虑过其他入湖的技术选型为何最终选择了 Paimon A在最初技术选型的时候主要考虑几个点一个是跟 Flink 生态的结合一个是 Streaming Warehouse 这种模型当时与这两点结合最好的是 Paimon另外在我们 Steaming upsert 的主流场景下情况更优。 另外对于中间存储层是 Plugin 的模式不是说一定要和 Paimon 做很深的绑定。 Q请问在做数据回溯、快照和回滚的时候有做过哪些考虑能够给一些可供参考的建议 A在这个方面我们主要是基于 Paimon 做了血缘管理的功能。血缘关系管理简单来讲分为两个部分第一部分是表的血缘关系管理第二部分是数据的血缘关系管理。 表的血缘关系管理比如在提交作业的时候通过任务可以提取出它上下游表的信息然后插入到引入的 System Database 里。数据血缘关系管理可以根据 Checkpoint 去划分数据版本一个 Checkpoint 完成之后就意味着一个版本数据的产生。然后再把具体消费了哪个版本的数据记录到 System Database 里。 基于这两种血缘关系管理既可以保持旧链路在线服务的状态也能保障新链路回溯数据或订正数据成为可能。在生产环境中由系统层面把表自动切换就可以完成一次数据回溯。 Q请问用流本身去处理数据如果数据量过大是否会造成获取数据源开口的环节拥堵以至于数据进不来 A这是一个写入性能优化的问题在 Paimon 官网上有专门针对这块的详细指导大家可以去了解下。 点击查看原文视频 演讲PPT Flink Forward Asia 2023 正式启动 点击查看活动详情