Hudi 数据湖在顺丰的应用实践

演讲人：唐尚文-顺丰科技-数据湖技术负责人 目录 实践与优化 应用场景 Par t 01 数据湖在顺丰的应用 顺丰集团业务概览 顺丰科技业务全景 数字化全流程 科技服务 数据湖Hudi具备怎样的能力？ 离线批计算 近实时计算 在某些场景下，兼顾时效性和数据复杂度，对原有数仓架构进行能力补充 优势：技术成熟稳定、可应对复杂逻辑缺点：时效性低（天级/小时级） 优势 实时流计算 •时效性高（分钟级）•支持流批写入，增量查询等能力•优秀的局部更新能力•支持ACID•支持多版本•.... 优势：时效性高（秒级）缺点：开发成本、稳定性低，复杂度有限 数据湖在顺丰的应用 中转/流向预测 可视化监控与分析 经营热力图 件量预测参考 件量、客户、产品、收派比可视化分析 对件量进行预测将结果给到场地进行参考，对人力和资源进行安排 运单/运力异常监控 异常风险识别 航空资源动态调整 资源缺口识别 对运力进行实时/准实时监控，快速识别运力异常，干预并降低损失 近实时识别航空资源的动态缺口，调整资源分配 Par t 02 数据湖在顺丰的实践和优化 数据湖在顺丰的实践和优化 01实时数据入湖实践 02离线数据开发实践 顺丰实时数据接入发展历程 Flink + Canal实现数据入湖存在的问题 数据一致性难保障 架构复杂、加工链路长 采用不锁表的方式进行数据采集，容易导致数据状态的变化时序无法和数据库保持一致 数据需要经过多个组件才能实现数据入湖、维护起来复杂、稳定性难保障 实时数据入湖的需求和技术选型 核心需求 对源数据库影响最低 能够保障数据一致 具有较好的同步性能 全量增量数据同步自动切换，并能够保障数据的一致 能够支持分布式采集，具有很好的稳定性去保障数据的同步效率 尽量不使用锁，同时避免一个表一个同步任务，尽量降低对源数据库造成影响 技术选型 基于开源的Flink CDC实现数据入湖步骤 易用性问题：开源方式接入门槛高、难度大 接入门槛高 接入用户需要了解较多的Flink、Hudi等使用方法、数据库等配置信息，对于小白用户或者数据接入放来说，使用门槛较高 维护难度大 数据库连接信息维护难、没有统一的数据源管理、权限控制等，数据源管理员工作量大，并且这种管理方式也存在一定的安全问题 解决方案：通过产品化降低数据入湖门槛 安全可控、易维护 通过数据源管理授权用户访问、避免密码泄漏，方便用户进行数据管理和数据共享 高效接入、零门槛 用户只需勾选待同步的表及相关信息，就能自动生成对应的数据同步任务，完成敏感字段数据自动加密等工作，无需了解Flink、Hudi相关配置就能够实现数据快速数据入湖 实时接入产品应用架构 简要步骤 •数据源授权：用户申请数据源读取权限并获得管理员授权•作业创建：直通车根据用户勾选的相关信息生成对应的同步作业•元数据同步：直通车根据待同步的表信息在数据资产创建对应的元数据•数据使用：用户根据数据资产上面的信息，通过查询引擎使用同步后的数据 稳定性问题：实时数据入湖链路稳定性差 解决方案：采集阶段全/增量读取性能优化 解决方案：提高全增量同步稳定性 完善Snapshot阶段切分逻辑 在进行chunk切分时，同时判断返回的数据条数，如果符合预设条件，证明后续可能还存在数据，这样可以避免因为数据库的设置导致切分倾斜的问题 优化Binlog同步阶段Task分配算法 将Task打散到不支持随机分发采集任务策略，避免所有binlog采集任务分配到Subtask-0 原因分析 Snapshot阶段切分逻辑缺陷 在生成snapshot任务时，在字符串为主键的大表场景下，因为不同字符集存在大小写不区分的情况，导致split过早结束，造成某个split过大，同步效率低，任务不稳定的问题 增加重连机制，提高任务的稳定性 通过增加重连机制，避免任务因为下游反压导致的异常问题，提高任务的稳定性 Binlog同步阶段Task分配倾斜 在分库分表场景下Binlog阶段同步Task默认都分配到SubTask-0，导致采集倾斜，内存消耗大，容易造成长时间的GC停顿和效率低的问题 缺乏重连机制，影响作业稳定性 在写入造成任务存在反压的情况下容易导致链接数据库出现异常，影响作业稳定性 解决方案：采集阶段读取限流和任务合并 优化后 对源端系统影响大 解决方案：任务合并、限流，降低源库负载 Binlog被反复拉取多次 任务合并 多个任务同时采集相同数据库实例，导致数据源的binlog数据被反复拉取，容易造成源数据库压力过高 通过对满足合并条件的数据同步任务，由实时计算平台发起合并任务请求，将任务进行合并后重新拉起，降低重复同步Binlog数据对源数据库带来的性能开销 无流量限制读取 突发的采集高峰可能会导致源数据库流量过大，增加服务的负载容易造成系统不稳定 读取限流 通过全量、增量阶段限流降低对原数据库的影响 解决方案：数据入湖阶段Bucket策略优化 解决方案：完善Bucket适用场景、提升写入性能 原因分析 原生Bucket算法存在一定的缺陷 优化Bucket算法分配策略 原生的Bucket分配算法存在一定的缺陷，会导致Databucket在Task分配不均的问题，很多Task存在空跑的情况，实际的资源利用率较低 对Bucket算法进行优化，让DataBucket能够相对均匀的分布到不同的Task上，提高任务的内存利用率，详情参考：HUDI-5671 Bucket数量无法按需指定 分区级别Bucket数量设置 Bucket数量为全局配置选项，无法适应实际业务中，某些分区数据倾斜的场景，设置过大容易造成小文件过多，设置过小在倾斜的分区写入也会到写入性能 针对业务数据倾斜的场景，允许用户按照分区数据量等方式设置bucket数量，提高数据入湖的效率 inline compaction容易导致作业不稳定 异步Compaction配置 flink内部进行compaction需要合理设置overhead参数，否则会容易造成物理内存超过YARN的限制被KILL，影响作业的稳定性 异步compaction能够避免overhead设置不合理导致内存的任务不稳定的问题，还能预留内存长期占用，降低资源消耗 达成效果：亿级表数据实时入湖 数据湖在顺丰的实践和优化 01实时数据入湖实践 02离线数据开发实践 数据湖开发当前存在的一些痛点 痛点2：全局索引模式下更新很慢，无法满足业务时效需求 解决方案：支持数据水位识别，支持流转批场景 解决方案：记录级别索引加速更新效率 更新效率低下 解决方案：通过记录级别索引提高更新效率 支持记录级别索引 大数据集Bloomfilter假阳性问题由于bloomfilter的误判特性，需要将这些纪录在文件中进行精准匹配 查找以得到实际需要更新的纪录及其对应的location，且在大数据集的情况下定位Record的性能非常差 在Hudimetadata表上新增一种类型RecordLevelIndex用来记录主键和文件的位置，并用HFile文件格式进行存储加速文件定位的效率，提高大表场景下的更新性能，同时能够避免维护第三方组件，做到轻量级同时易维护 HBase索引维护工作量大、成本高 由于HBase索引也支持类似全局索引的能力，但是需要维护第三方服务成本较大，可能还会引入别的问题，不够轻量级 达成效果：千万级数据更新提效 •记录级别索引，完成该场景数据更新在同样的资源耗时40min Par t 04 未来展望 未来展望 查询优化 更新能力 稳定性 感谢观看！