《【字节跳动喻兆靖】高性能实时入湖在字节跳动的实践.pdf》由会员分享,可在线阅读,更多相关《【字节跳动喻兆靖】高性能实时入湖在字节跳动的实践.pdf(32页珍藏版)》请在三个皮匠报告上搜索。
1、高性能入湖在字节跳动的实践喻兆靖 字节跳动数据平台研发工程师PART ONELAS 介绍PART THREE生产落地与优化PART TWO 实时数仓场景PART FOUR未来规划LAS 介绍01ByteDanceByteDance流批一体架构批流一体存储一份存储同时支持流式的增量读写以及批量读写支持高效的 OLAP 查询支持高效的维表 Join湖仓分析引擎湖仓分析引擎湖仓开发工具湖仓开发工具SparkSparkPrestoPresto统一元数据统一元数据统一目录统一目录权限管控权限管控元数据发现元数据发现湖仓存储湖仓存储内置存储内置存储其他数据源TOSRDSEMRMQ分布式文件存储批流一体存储
2、引擎批流一体存储引擎弹性资源弹性资源VKE/VCIVKE/VCI湖湖仓仓存存储储湖湖仓仓分分析析引引擎擎队列管队列管理理数据数据管管理理查询分查询分析析作业管作业管理理权限管权限管理理生态连生态连接接湖湖仓仓分分析析平平台台ByteDance统一元数据ACID 支持企业级权限管控极致弹性引擎极致优化日志计算场景长周期计算场景全量计算场景ByteDance经典实时数仓架构实时存储不统一实时离线存储能够统一冷启动流程复杂且耗时回溯中间数据不可查ByteDance经典实时数仓架构流式低延迟写入/消费 RPS一致性语义批式分区并发更新Hive 表读写吞吐ByteDance批流一体存储-数据湖多引擎支持
3、落地场景0202ByteDance流式数据计算场景ByteDance多维分析场景ByteDance链路加速场景ByteDance现有方案存在的问题存储冗余数据计算链路长下游 OLAP 计算耗时长,且不稳定(核心问题是大数据量的 Shuffle)业务诉求ByteDance时效性:天级=小时级 场景诉求:提前就绪时间加速下游 去重、Join 等 OLAP 计算节省存储和计算资源场景特点:数据量大(一天千亿数据,存储百 TB 级别)有大字段且大小不均匀下游核心链路多基于 HUDI 的数据湖方案ByteDance时效性:天级=小时级 可支持分钟级近实时查询线上优势:入湖过程中直接按主键去重,省略了后续
4、流程中的去重操作,提前就绪时间按照主键进行了分桶,后续查询时可以使用 local join 进行 shuffle 消除,节省任务时间生产落地与优化03ByteDanceHudi Flink 入湖的实现方式ByteDancerow data to hoodie:负责将 table 的数据结构转成 HoodieRecordbucket assigner:负责新的文件 bucket(file group)分配write task:负责将数据写入文件存储coordinator:负责写 trasaction 的发起和 commitcleaner:负责数据清理 Flink 入湖落地问题ByteDance写
5、入性能差,能支持的 QPS 低写入资源占用较大,GC 严重写入稳定性差,Lag 毛刺严重,数据高峰期难以追平 LagCompaction 性能差,且资源占用较大不支持归档(流转批),后续批任务无法调度写入性能差,能支持的 QPS 低将 RowData 转为 HoodieRecord,带来了额外的序列化与反序列化的消耗多次 shuffle 导致数据频繁跨网络传输,导致性能较差在 checkpoint 的时候会阻塞式的 flush 所有数据到 HDFS,并且是阻塞式的,所以会出现长尾问题问题分析ByteDance写入稳定性差,Lag 毛刺严重,数据高峰期难以追平 Lag在 checkpoint 的
6、时候会阻塞式的 flush 所有数据到 HDFS,并且是阻塞式的,所以会出现长尾问题使用 append log file 的方式写入,追加写 Log 文件存在较多 HDFS 侧问题,维护成本较高(lease 超时问题,文件未关闭重新写入,客户端调用 close 但 NN 未响应,等等)问题分析ByteDance写入资源占用较大,GC 严重Write Function 和 HoodieAppendHandler 内部各有一层缓存,导致任务的内存占用比较大,GC 也比较严重Compaction 性能差,且资源占用较大由于写入的是 log file,所以为了保证读取效率还需要频繁进行 compact
7、ion,但是对于大任务的 compaction 有两难的问题。调度间隔时间短:消耗资源多,重复进行多次 compaction调度间隔时间长:任务读取速度慢,compaction 稳定性较差,log file 较大容易 OOM入湖优化方案ByteDance考虑到需要优化点较多且实现成本不低,我们初步制定了三步走的优化方向:1.Kafka-Hudi 非主键表,接 SparkSQL 去重写入 DWD Hive 表,相当于将 Kafka-HDFS 和 HDFS-Hive 两个任务进行了合并,减少任务链路2.Kafka-Hudi 非主键 Bucket 表,接 SparkSQL 去重写入 DWD Hive
8、 表,可以使用 bucket join 进行 shuffle 消除,提升第一步的性能3.Kafka-Hudi 主键 Bucket 表,一步完成去重和分桶第一步:Kafka-Hudi 非主键表ByteDance 支持 Append 写入 Hudi 非主键表第二步:Kafka-Hudi 非主键 Bucket 表ByteDanceAppend 写入支持 Bucket Index支持归档功能(流转批)ByteDanceFlink Checkpoint 与 ByteLake 的事务提交强相关,每次 CP 会触发一次 ByteLake 事务提交,提交后数据对下游可见。数据入湖逻辑如下:Flink SQL
9、实时消费上游数据,每条记录生成一个 Record(col_1,col_2,event_time,date,hour)Record 实时写入 ByteLake 对应分区数据文件(基于 Record 的分区值 date/hour 定位要写入的分区)Flink Checkpoint 触发 ByteLake 事务提交,每次提交会记录这一次 CP 新增的文件名,提交成功后下游对这一批数据才可见。归档标签生成,主要分为如下几个步骤:在数据实时入湖过程中会记录全局最小 event_time 每次触发 Flink CP 时,在事物提交阶段,会拿这次 CP 的最小 event_time 与上一次写入的分区时间求
10、差值,如果差值超过指定的等待时间,则认为上一次的分区,会在对应分区目录下创建 _SUCCESS 文件,完成这个分区的归档。Flink 支持非阻塞写入ByteDance感谢阿里云李少锋老师的分享图Flink 支持非阻塞写入ByteDance非阻塞方案本质上是将 instant 的创建从 checkpoint 完成修改到了只要一个 task 完成 checkpoint 就创建,并且在 Coordinator 维护多个正在写入的 instant,从而做到了部分慢的 task 不会拖累整体的消费速率,具体细节如下:1.启动的时候在 recommit 之后,rollback 掉 timeline 中所有
11、 pending instant2.每次触发 checkpoint 之后,在接收到第一个完成 checkpoint task 的 event,并且当前 pending instant Hudi 主键 Bucket 表(进行中)ByteDance通过 append bucket 模式写入 Hudi 表适配对应的 clustering 任务,在保留文件重分布的能力下加入 bucket merge 逻辑,使得 clustering 可以对 bucket 内的相同主键数据进行合并查询时相同 bucket 的数据先做一个本地去重,然后再将数据集返回查询引擎优化效果展示ByteDance入湖性能提升 20
12、0%300%可支持的 QPS 上限最高可到 800w/s,峰值提高 400%内存使用率降低 50%,GC 时常减少 80%消费时频繁高耸入云的 lag 消失,消费速率平稳未来规划未来规划04ByteDanceC Clustering lustering 扩展扩展ByteDanceClustering 分为两个大类FullClustering:全量合并所有文件PartialClustering:仅合并全部小文件+增量文件可配置多个 Clustering Strategy,且可同时存在多 Pending Clustering,仅在 Plan 生成时需进行文件级冲突检查非阻塞式 ClusterngTable Management ServiceByteDance自动采集数据变化自动生成数据分布优化计划自动执行优化操作谢 谢 观 看thanks