vivo湖仓一体-徐昱-datafun.pdf

1、vivovivo湖仓一体构建历程湖仓一体构建历程背景传统数仓的痛点组件选型及业务接入组件能力增强未来展望背景在增效降本的大背景下，vivo大数据基础团队引入数据湖技术为公司业务部门湖仓加速的场景进行赋能。主要应用在流批同源、实时链路优化及宽表拼接等业务场景。传统数仓的技术痛点链路冗余基于Lambda架构的数仓存在计算、存储冗余，输出口径不一致等缺陷传统数仓的痛点 不支持流批同源升级后的Kappa架构，完全基于实时链路的架构实现，相较于lambda节约资源成本，但是不可以流批复用传统数仓的痛点更新成本高离线更新合并增量文件后进行分区下全量合并，计算成本高、耗时长传统数仓的痛点实时写入的数据无法进

2、行批量查询传统数仓的痛点仅支持追加数据传统数仓的痛点并发场景需要多表多任务，不支持并发传统数仓的痛点组件选型及业务接入HudiHudi 0.14.0 0.14.0FlinkFlink 1.13.2 1.13.2Spark 3.2.0Spark 3.2.0组件选型统一链路湖上存储统一为湖上存储统一为HudiHudi存储，实时流式写入、存储，实时流式写入、流式读取，流式读取，DADA层层SLASLA提前一个小时以上提前一个小时以上业务场景离线更新从全量离线更新从全量joinjoin后覆盖升级为增量后覆盖升级为增量 更新，计算成本平均更新，计算成本平均下降下降30%30%以上，耗时以上，耗时节省节省

3、50%50%以上以上业务场景数据拼接多表多任务优多表多任务优化为单表单任化为单表单任务，小时级延务，小时级延迟提升为分钟迟提升为分钟级级业务场景CDC实时同步减去减去KafkaKafka中间中间存储，简化链存储，简化链路完成数据路完成数据cdccdc同步，进同步，进一步提高时效一步提高时效性性业务场景组件能力增强Hudi组件线上能力：支持单批次千亿级别数据稳定高效入湖，支持8000w/min数据体量实时入湖;vivo湖仓团队保障数据高效入湖，分别在流批计算、文件管理、物理成本优化等方面增强Hudi组件能力。数据积压严重的情况下，默认情况会消费所有未消费的commits，往往因消费的commit

4、s数目过大，导致任务频繁OOM，影响任务稳定性；优化后每次用户可以摄取指定数目的commits，很大程度上避免任务OOM，提高了任务稳定性。commits限流组件优化避免单并行度的clean算子最终阶段影响数据实时写入的性能；将clean单独剥离到 compaction/clustering执行。这样的好处是单个clean算子，不会因为其生成clean计划和执行导致局部某些Taskmanager出现热点的问题，极大程度提升了实时任务稳定性。clean算子外置组件优化部分大流量场景中，尽管已经对Hudi进行了最大程度的调优，但是JM的内存仍然在较高水位波动，还是会间隔性出现内存溢出影响稳定性。这

5、种情况下我们尝试对 state.backend.fs.memorystate.backend.fs.memory-threshold-threshold 参数进行调整；从默认的20KB调整到1KB，JM内存显著下降；同时运行至今state相关数据未产生小文件影响。JM参数优化组件优化0.14版本后支持了bucket表的bulkinsert，实际使用过程中发现分区数很大的情况下，写入延迟耗时与计算资源消耗较高；分析后主要是打开的句柄数较多，不断CPU IO 频繁切换影响写入性能。BulkInsert 性能瓶颈因此在hudi内核进行了优化，主要是基于partition path和bucket id

6、组合进行预排序，并提前关闭空闲写入句柄，进而优化cpu资源使用率。这样原先50分钟的任务能降低到30分钟以内，数据写入性能提高约30%40%。BulkInsert 性能优化0.14版本中，部分情况下分区裁剪会失效，从而导致条件查询往往会扫描不相关的分区，在分区数庞大的情况下，会导致driver OOM，对此问题进行了修复，提高了查询任务的速度和稳定性。查询优化组件优化此外，为了提高MOR表管理的效率，我们禁止了RO/RT表的生成；同时修复了原表的元数据不能正常同步到HMS的缺陷(这种情况下，OLAP引擎例如Star