懂车帝二手车基于Las DataLeap的流批一体准实时指标体系架构.pdf

《懂车帝二手车基于Las DataLeap的流批一体准实时指标体系架构.pdf》由会员分享，可在线阅读，更多相关《懂车帝二手车基于Las DataLeap的流批一体准实时指标体系架构.pdf（26页珍藏版）》请在三个皮匠报告上搜索。

1、DataFunSummitDataFunSummit#20232023基于Las+DataLeap的流批一体准实时指标体系架构连家漯-懂车帝-资深研发工程师业务背景及挑战了解二手车门店业务的背景及数仓面临的挑战技术架构如何应对业务挑战Bytelake准实时指标体系的详细介绍遇到的问题及解决办法Bytelake准实时指标体系落地过程中遇到的问题及解决办法成果及规划当前落地效果及未来规划目录 CONTENTDataFunSummitDataFunSummit#2023202301二手车门店业务背景及挑战懂车帝二手车业务介绍懂车帝二手车业务主要分为线上媒体和线下门店两块线下门店于2022年5月启动，

2、旨在通过自营门店为用户提供值得信赖的二手车交易服务，成为最受信赖的信息、交易、服务平台。使命：让消费者买到安心二手车愿景：成为中国最值得信赖的二手车全国购平台Slogan：真实好车源，全国放心买二手车门店数仓面临的挑战指标一致性差业务发展快业务系统迭代频繁数仓需求交付节奏快架构不统一实时离线两套架构、两套代码指标查询多套方案DataFunSummitDataFunSummit#2023202302技术架构如何应对业务挑战如何解决指标一致性问题？存储计算层的统一统一实时离线架构查询服务层的统一统一指标生产统一指标消费一致性如何统一实时离线架构当前，二手车门店数仓采用的离线、实时两套架构两套代码分

3、别支持离线实线计算。这样做有如下问题：需要维护两套不同的计算代码，维护开发成本高 在开发迭代过程中，非常容易出现指标口径不一致的问题如果想要实现离线、实时的统一(流批一体)，需要解决两个问题：实时/离线存储层的统一 实时/离线计算层的统一如何统一实时离线架构Las是基于Apache Hudi深度定制的湖仓一体存储引擎1.提供了湖仓一体可扩展、高可用、高性能的元数据服务，完全兼容Hive Metastore，支持多种计算引擎2.支持对海量数据的高效 Insert/Overwrite 能力，以及完全兼容 HSQL 的 OLAP 能力。3.支持对历史数据的 Update/Delete 能力。4.支持

4、对新增数据的 Upsert（主键）和 Append（非主键）能力。5.支持 Streaming Source/Sink，提供近实时分析能力，同时支持接入数据集看板。统一存储层Las表批量读取交互式查询流式消费流式更新流式写入批式更新批式更新如何统一实时离线架构统一存储层Las借助Catalog Service为所有查询计算引擎提供了统一的元数据视图，站在使用者的角度与使用Hive表没有区别统一元数据如何统一实时离线架构统一存储层表类型适用场景存储方式写入方式查询方式COPY_ON_WRITE更适合离线场景（写少读多）列存（Parquet）每次写入数据，会先读取已有数据文件，然后与更新数据合并后

5、写入新的文件支持与 Hive 表类似的 HSQL 查询MERGE_ON_READ更适合近实时/实时场景（写多读少）行存（Delta Log）+列存（Base File）每次写入数据，更新数据会先写入行存（Delta Log），写入指定次数后，行存（Delta Log）文件会与列存（Base File）文件进行合并生成新的列存（Base File）文件，即 Compaction 过程。RealTime（RT）查询：读取行存（Delta Log）+列存（Base File），数据延迟低 ReadOptimized（RO）查询：仅读取 列存（Base File）数据，查询性能高 Incrementa

6、l 查询：适用于增量消费场景Las表存储类型如何统一实时离线架构统一存储层索引类型适用场景说明HIVE_BUCKET_INDEX有主键数据会基于主键进行去重（Upsert），支持 CRUD 能力注：对于主键表，使用insert overwrite时引擎不会做去重，需要由业务侧增加去重逻辑，insert into 时为Upsert 语义，写入数据会按照主键进行去重NON_INDEX无主键数据不会基于主键进行去重（Insert），支持高效的 Append 能力Las表索引类型如何统一实时离线架构统一存储层 多流列拼接支持按优先级保障不同列的产出海量数据场景下快速更新大表的的部分列解决实时多流 Jo

7、in 大状态问题带来的作业不稳定问题实时作业中维表 Join 对 KV 数据库的访问压力或者 Cache 的更新延迟问题归档能力流转批场景，MQ/MySQL Dump 从离线转为近实时，提升 ODS 数据就绪时间，且支持主键场景自定义聚合逻辑主键表默认的聚合逻辑为取最新一条数据，但部分场景需要对某些字段做 sum/min/max/count 等自定义聚合逻辑，复杂场景会取 Top20 等需求增量消费下游增量消费上游Las表变更Las其他重要特性 Time Travel查询历史任意时间戳全量数据如何统一实时离线架构统一计算层的本质是避免一套逻辑用两套代码来实现当前Las支持Spark SQL、F

8、link SQL直接读写，理论上可以通过Flink SQL完成离线实时场景的计算；但是现状是Flink SQL的语义完备性、与Bytelake的兼容性都还存在诸多问题，所以目前尚未真正实现计算层的统一。我们的解决办法是，由于存储层是统一的，我们可以针对同一份逻辑，只让一个任务，一种语言来实现，不同的任务可以使用不同的语言。统一计算层如何统一查询服务层统一指标生产明确指标定义方法建立指标生产SOP完成指标定义与模型绑定统一指标消费基于指标服务驱动开发指标查询元数据透传如何统一指标生产明确指标定义方法通过指标拆解流程，实现指标口径清晰准确定义如何统一指标生产建立指标生产SOP通过指标生产SOP，明

9、确指标口径负责人及生命周期管理，杜决指标同名不同义、同义不名的等问题如何统一指标生产将指标模型在Dataleap指标平台上进行指标定义和维度的绑定，解决解决指标检索与路由的问题，帮助下游使用方准确获取到所需指标指标1模型A模型B模型Capi查询码Aapi查询码Bapi查询码C结果值维度a、维度b维度b、维度c维度d、维度e维度a、维度c路由查询优化模型建设优化维度管理完成指标与模型的绑定如何统一指标消费基于指标服务驱动开发指标查询元数据透传最终架构当前架构优缺点对比与现有框架无缝集成分钟级延迟满足业务要求规范化了指标生产与消费学习开发运维成本低无法满足秒级实延功能完备性还有提升空间具有额外存储

10、开销不足优点DataFunSummitDataFunSummit#2023202303遇到的问题及解决办法遇到的问题及解决办法问题具体描述问题影响解决方案Las读写性能差Las1.0采用log和dat分开存储的方式，一个表的一个分区大概有4万多个文件；造成读取速度特别慢。在建表的时候，需要指定COW 或者 MOR存储方式；因存在大量的LOG文件，会额外的占用35%的空间。任务执行特别慢，升级后执行时长比原来节省60%以上。和平台同学一起从Las1.0升级到Las.0解决了碎文件的问题，读取速度会比之前提高3倍左右；基于 Las 2.0 的架构设计，底层不存在 log 文件，因此不再需要 Com

11、paction，业务无需关注 Compaction 相关信息。Las2.0 存在异步的 Clustering，用于合并小文件，由 Las 表优化服务（TMS）负责整体托管，异步执行，业务无需关注。insert into任务，比之前快了大约3倍左右；Flink SQL多表复杂JOIN场景下存在性能问题Flink大表、复杂子查询多表JOIN存在性能问题导致数据延迟无法直接在Flink SQL中完成多表Join并写入Las使用HSQL微批的方式或者Las多流列拼接微批场景下HSQL调度等待默认HSQL通过Spark执行，每次调度时才申请资源，执行结束之后会释放资源；申请资源是会有等待，最终产增加任务时延任务执行的时候，因为申请资源的耗时，占总执行时长的40%左右。将HSQL放到常驻进程的Spark集群上执行，避免申请资源时的等待。历史数据回溯Las1.0 ods表为全量表，只反映最新状态，下游快照表无法直接回溯影响快照表的历史数据回溯1、新增ods的hive数据分区表，用于异常回溯；2、升级到Las2.0，使用Time TravelDataFunSummitDataFunSummit#2023202304成果及规划成果及规划二手车门店所有指标(600+)分钟级准实时化二手车门店全面实现流批一体解决了二手车门店指标一致性问题二手车门店指标秒级实时化真正实现计算层统一规划成果感谢观看