《Hudi 数据湖在顺丰的应用实践.pdf》由会员分享,可在线阅读,更多相关《Hudi 数据湖在顺丰的应用实践.pdf(30页珍藏版)》请在三个皮匠报告上搜索。
1、Hudi 数据湖在顺丰的应用实践演讲人:唐尚文-顺丰科技-数据湖技术负责人应用场景010203未来展望目录实践与优化数据湖在顺丰的应用Part 01顺丰集团业务概览快递物流快递快运同城即时配送国际冷链医药仓配一体增值服务供应链综合物流其他业务丰巢顺丰房托丰泰产业园顺丰数科更多.顺丰科技业务全景数据中台AI中台大数据平台顺丰云平台DevOps一站式研发平台智能运维平台信息安全运营平台数字化全流程管理数字化企业经营智能化升级,助力管理效率提升大网数字化贯穿收转运派全生命周期的数字化科技能力供应链数字化自研一体化的供应链系统及平台,实现多元供应链生态科技服务标准科技产品基于科技能力的标准化标杆对外应
2、用产品行业解决方案提供端到端基于泛物流场景的多行业一体化解决方案数字化物流开放平台基于Lass 对外提供数字化物流服务能力运筹大数据区块链人工智能无人XGIS隐私计算数据湖 Hudi 具备怎样的能力?离线批计算实时流计算优势:技术成熟稳定、可应对复杂逻辑缺点:时效性低(天级/小时级)优势:时效性高(秒级)缺点:开发成本、稳定性低,复杂度有限近实时计算Hudi优势时效性高(分钟级)支持流批写入,增量查询等能力优秀的局部更新能力支持 ACID支持多版本.在某些场景下,兼顾时效性和数据复杂度,对原有数仓架构进行能力补充数据湖在顺丰的应用可视化监控与分析经营热力图件量、客户、产品、收派比可视化分析中转
3、/流向预测件量预测参考对件量进行预测将结果给到场地进行参考,对人力和资源进行安排运单/运力异常监控对运力进行实时/准实时监控,快速识别运力异常,干预并降低损失异常风险识别航空资源动态调整资源缺口识别近实时识别航空资源的动态缺口,调整资源分配数据湖在顺丰的实践和优化Part 02数据湖在顺丰的实践和优化01实时数据入湖实践02离线数据开发实践顺丰实时数据接入发展历程201720192021JStorm+CanalFlink+CanalFlink+CDCFlink+Canal 实现数据入湖存在的问题Binlog采用不锁表的方式进行数据采集,容易导致数据状态的变化时序无法和数据库保持一致数据一致性难
4、保障数据需要经过多个组件才能实现数据入湖、维护起来复杂、稳定性难保障架构复杂、加工链路长全量canal.Flink写入 binlog读取 binlog全量查询实时数据入湖的需求和技术选型增量同步Flink CDC断点续传无锁读取全量+增量分布式数据转换能力强能够保障数据一致全量增量数据同步自动切换,并能够保障数据的一致对源数据库影响最低尽量不使用锁,同时避免一个表一个同步任务,尽量降低对源数据库造成影响具有较好的同步性能能够支持分布式采集,具有很好的稳定性去保障数据的同步效率核心需求技术选型基于开源的 Flink CDC 实现数据入湖步骤实时计算平台1.SQL/JAR大数据集群2.提交作业用户
5、数据管理员1.数据源申请数据库2.权限维护数据地图1.数据资产注册2.数据查找能够满足基本需求但也存在一些问题!步骤1:申请数据源权限用户用户用户步骤2:实时数据入湖任务开发/调试步骤3:数据资产注册和维护易用性问题稳定性问题易用性问题:开源方式接入门槛高、难度大接入用户需要了解较多的 Flink、Hudi等 使用方法、数据库等配置信息,对于小白用户或者数据接入放来说,使用门槛较高接入门槛高数据库连接信息维护难、没有统一的数据源管理、权限控制等,数据源管理员工作量大,并且这种管理方式也存在一定的安全问题维护难度大解决方案:通过产品化降低数据入湖门槛顺丰实时数据直通车通过数据源管理授权用户访问、
6、避免密码泄漏,方便用户进行数据管理和数据共享安全可控、易维护用户只需勾选待同步的表及相关信息,就能自动生成对应的数据同步任务,完成敏感字段数据自动加密等工作,无需了解 Flink、Hudi 相关配置就能够实现数据快速数据入湖高效接入、零门槛数据安全加密数据源管理无需保留敏感信息根据用户量级匹配自动生成对应的接入参数,提高接入的效率实时接入产品应用架构数据源管理数据应用2.数据源授权1.申请数据源实时数据直通车MySQL4.同步 Schema 等信息3.创建作业实时计算平台数据地图5.提交数据同步作业6.新建资产用户数据开发平台数据接入数据使用大数据集群元数据获取7.提交作业提交作业简要步骤数据
7、源授权:用户申请数据源读取权限并获得管理员授权作业创建:直通车根据用户勾选的相关信息生成对应的同步作业元数据同步:直通车根据待同步的表信息在数据资产创建对应的元数据数据使用:用户根据数据资产上面的信息,通过查询引擎使用同步后的数据应用架构简图稳定性问题:实时数据入湖链路稳定性差MySQL 1数据源MySQL 2MySQL N数据计算数据湖 Hudi Flink CDC实时数据采集upsert实时数据入湖数据采集阶段数据入湖阶段源端系统影响大全量采集阶段成功率低增量采集阶段效率低数据质量问题超过物理内存被 YARN KILLTM 的资源利用率不高TM 容易发生 Timeout资源占用较大等等.解
8、决方案:采集阶段全/增量读取性能优化全量采集阶段成功率低增量采集阶段效率低TM 容易发生 Timeout资源占用较大MySQL 1MySQL NCDC APP分库分表多实例生成 snapshot 任务snapshot 同步binlog 任务分配binlog 采集Binlog 同步阶段 Task 分配倾斜在分库分表场景下 Binlog 阶段同步 Task 默认都分配到 SubTask-0,导致采集倾斜,内存消耗大,容易造成长时间的 GC 停顿和效率低的问题Snapshot 阶段切分逻辑缺陷在生成 snapshot 任务时,在字符串为主键的大表场景下,因为不同字符集存在大小写不区分的情况,导致 s
9、plit 过早结束,造成某个split 过大,同步效率低,任务不稳定的问题缺乏重连机制,影响作业稳定性在写入造成任务存在反压的情况下容易导致链接数据库出现异常,影响作业稳定性原因分析解决方案:提高全增量同步稳定性优化 Binlog 同步阶段 Task 分配算法将 Task 打散到不支持随机分发采集任务策略,避免所有binlog采集任务分配到 Subtask-0增加重连机制,提高任务的稳定性通过增加重连机制,避免任务因为下游反压导致的异常问题,提高任务的稳定性完善 Snapshot 阶段切分逻辑在进行 chunk 切分时,同时判断返回的数据条数,如果符合预设条件,证明后续可能还存在数据,这样可以
10、避免因为数据库的设置导致切分倾斜的问题解决方案:采集阶段读取限流和任务合并MySQL 1CDC APPFlink CDCFlink CDC存储端存储端Binlog 被反复拉取多次多个任务同时采集相同数据库实例,导致数据源的 binlog 数据被反复拉取,容易造成源数据库压力过高无流量限制读取突发的采集高峰可能会导致源数据库流量过大,增加服务的负载容易造成系统不稳定对源端系统影响大优化前CDC APP解决方案:任务合并、限流,降低源库负载读取限流通过全量、增量阶段限流降低对原数据库的影响任务合并通过对满足合并条件的数据同步任务,由实时计算平台发起合并任务请求,将任务进行合并后重新拉起,降低重复同
11、步 Binlog 数据对源数据库带来的性能开销MySQL 1CDC APP存储端存储端优化后CDC APP实时计算平台存储端存储端上报消费进度MySQL 1合并启动CDC APP流量控制解决方案:数据入湖阶段 Bucket 策略优化超过物理内存被 YARN KILLTM 的资源利用率不高资源占用较大小文件过多的问题CDC APPTask 1 Task 100MySQL 1MySQL N分库分表多实例Task 2 Task 60.Task 1 DataBucketDataBucketDataBucketTask10102030Task 1-10Task 20-10Task 30-60Task 6
12、0-100DataBucket 分布情况原因分析解决方案:完善 Bucket 适用场景、提升写入性能原生 Bucket 算法存在一定的缺陷原生的 Bucket 分配算法存在一定的缺陷,会导致 Databucket 在Task 分配不均的问题,很多 Task 存在空跑的情况,实际的资源利用率较低Bucket 数量无法按需指定Bucket 数量为全局配置选项,无法适应实际业务中,某些分区数据倾斜的场景,设置过大容易造成小文件过多,设置过小在倾斜的分区写入也会到写入性能inline compaction 容易导致作业不稳定flink 内部进行 compaction 需要合理设置 overhead 参
13、数,否则会容易造成物理内存超过 YARN 的限制被 KILL,影响作业的稳定性优化 Bucket 算法分配策略对 Bucket 算法进行优化,让 DataBucket 能够相对均匀的分布到不同的 Task 上,提高任务的内存利用率,详情参考:HUDI-5671分区级别 Bucket 数量设置针对业务数据倾斜的场景,允许用户按照分区数据量等方式设置bucket 数量,提高数据入湖的效率异步 Compaction 配置异步 compaction 能够避免 overhead 设置不合理导致内存的任务不稳定的问题,还能预留内存长期占用,降低资源消耗达成效果:亿级表数据实时入湖MySQL 1MySQL
14、2MySQL NFlink CDCUPSERT实时采集日志数据数据写入数据源数据应用QUERY实时查询日志分析数据读取BI 报表数据湖 Hudi(T+10 min 延时)数据计算全量70+亿,每天增量1亿数据社区方案无法完成该量级的数据同步,服务稳定性差达成效果稳定正常运行实时数据入湖整体回顾读取限流分库分表敏感字段识别任务合并顺丰实时直通车MySQLMySQLOracle.PG表结构同步数据源端资产注册数据加密数据源管理Kafka.数据湖数据目标端数据地图权限管理资产查询.Kafka用户 A实时接入数据同步数据同步数据同步数据同步表结构同步数据湖在顺丰的实践和优化01实时数据入湖实践02离线
15、数据开发实践数据湖开发当前存在的一些痛点Kafka 1Kafka 2日志服务fetchUPSERT实时数据采集数据写入数据源数据应用QUERY实时查询日志分析数据读取BI 报表数据湖 Hudi(增量数据)数据计算数据湖 Hudi(底表数据)MERGE常见数据的加工链路痛点1:什么时候应该触发下游离线开始计算?痛点2:全局索引模式下更新很慢,无法满足业务时效需求解决方案:支持数据水位识别,支持流转批场景WriteTask 1WriteTask 2WriteTask 3Coordinatort1=min(ts)t2=min(ts)t3=min(ts)eventTime=min(t1,t2,t3)h
16、udi-wm-check下游任务1下游任务22023 01-0200:05:002023 01-0123:55:00commit获取写入这一批中的数据最小的数据时间汇报到CoordinatorCoordinator 收集来自所有 Task 汇报上来的数据时间,取最小值并将它写入到hudi表的目录中(这里考虑到一个场景,因为在没有数据的情况下,不会提交commit,可能就会导致下游永远无法识别数据进度,但是实际今天的数据已经写完)如果没有实际的数据时间,就用当前的checkpoint时间下游通过检测工具检测数据水位进度,符合条件则触发下游计算解决方案:记录级别索引加速更新效率更新效率低下优化前解
17、决方案:通过记录级别索引提高更新效率优化后大数据集 Bloomfilter 假阳性问题由于bloomfilter的误判特性,需要将这些纪录在文件中进行精准匹配查找以得到实际需要更新的纪录及其对应的location,且在大数据集的情况下定位 Record 的性能非常差HBase 索引维护工作量大、成本高由于 HBase 索引也支持类似全局索引的能力,但是需要维护第三方服务成本较大,可能还会引入别的问题,不够轻量级Hudi Mata TableRecordLevelIndexbucket 1bucket 2bucket NHFileKey1-path1,file1Key2-path2,file2K
18、ey3-path3,file3Key4-path4,file4Key5-path5,file5Key6-path6,file6Key7-path7,file7索引信息收集数据写入元数据提交文件定位更新数据集主表数据更新Hudi TableParquet File 1获取文件位置更新数据集主表数据更新FooterParquet File 2Footer支持记录级别索引在 Hudi metadata 表上新增一种类型 RecordLevelIndex 用来记录主键和文件的位置,并用 HFile 文件格式进行存储加速文件定位的效率,提高大表场景下的更新性能,同时能够避免维护第三方组件,做到轻量级同时
19、易维护达成效果:千万级数据更新提效Kafka 1Kafka 2日志服务fetchUPSERT实时数据采集数据写入数据源数据应用QUERY实时查询日志分析数据读取BI 报表数据湖 Hudi(增量数据)数据计算底表数据100+亿,每天千万级数据更新数据湖 Hudi(底表数据)MERGE社区方案全局 Boolm 索引,超过5小时任务都没法完成达成效果记录级别索引,完成该场景数据更新在同样的资源耗时40min未来展望Part 04未来展望数据湖内核增强查询优化支持 Presto 等计算引擎使用MDT下推的能力,加速查询统一元数据构建统一的元数据服务、表管理服务的能力更新能力支持分区变更,非主键更新,多流更新等能力,适用更多的业务场景稳定性提高数据入湖,数据处理的能力,保障业务时效感谢观看!