MRS大企业ERP流程实时数据湖加工最佳实践
【摘要】 本文介绍大企业erp流程中使用MRS流加工模型对比选型及最佳实践
本文将以ERP流程实践为例介绍MRS实时数据湖方案的演进
案例实践需求解析:
业务描述
- AE表:会计分录表,主要记录财务相关信息,可用于成本核算等业务计算。为业务最主要的表,称驱动表。
- 四通道表:实际为四个门店业务系统,主要记录销售记录信息。为成本核算、科目报表分析等业务提供信息佐证。可称为维表。
业务痛点
- 科目分析报表业务供数慢的痛点,数据时延高。
- 实际业务数据有内容更新,保证数据严格一致。
- 科目分析报表查询仅支持公司、科目、时段等少量查询条件。
实时数据湖方案优势
- 实时数据湖方案做增量加工,将传统供数压力卸载到每天、每小时、每分钟,100万数据查询只需要2min。
- 使用Hudi作为数据湖天然支持数据更新。
- 提供所有数据归档,可随时回溯。
- 支持科目、批名、凭证名、合同号等31个查询条件,大幅度减少用户导出数据后筛选过滤时间。支持用户基于页面直接分析。
实时数据湖方案实施挑战
- 流计算基于内存,峰值数据量过大会影响作业稳定性。
- 多流时延大,数据等待耗费大量内存资源,需考虑业务需求与使用资源的平衡。
流加工模型一:
模型一特点
•Hudi表流读能够减少整体内存开销,提高作业稳定性。
•以其中一条流为基准(左表),去比较另一条流(右表)
•会出现关联缺失的情况,以驱动表(AE表)的视角(新增&更新)
•1)四通道流早到,并且ttl到期后数据丢失
•2)四通道流晚到,AE流ttl到期后数据丢失
模型一局限:
•目标宽表数据会出现不准的情况
•源端新增因为关联不出有效结果造成目标宽表缺数 -> missing
•源端更改因为关联不出有效结果造成目标宽表延时 -> delay
流加工模型二:
补偿目的:
补偿目的:基于业务逻辑,对比源端流表和目的端宽表数据内容,发现目标宽表缺失数据主要字段,关联源表完整内容找出缺失数据,并写回源端表补偿层。
missing&delay补偿模拟:
模型二特点:比较方案一增加补偿机制,能够对比源表(AE表,四通道表)以及目标宽表,找出缺失数据missing, delay。
模型二局限:实际情况双流之间时延可能较大、对齐较难,虽然能够使用补偿机制找回缺失数据,但是这样流加工任务主要角色会被弱化,同时会对补偿任务造成更大压力,数据时延会变大 。
流加工模型三(最终):
双写目的:业务系统持续向Hudi表,HBase表双写数据。Hudi表流读,提供主要热关联数据,HBase存储所有历史数据,技术上就是维度表,为热关联失败之后进行快速点查补数(lookup join)得到有效关联。提高双流关联的命中率。减少流加工整体数据时延。
维表选型:
选型描述 |
选型特点 |
关键参数 |
|
选型一 |
维表数据放在HBase、Redis里,需要使用时点查(lookup join)关联 |
维表数据量大,能兼顾性能与资源的平衡 |
•'lookup.cache' = 'ALL'
•'lookup.cache.ttl' = '600000',
•'lookup.cache.partitioned' = 'false'
•'lookup.parallelism' = '20'
|
选型二 |
维表数据放在HBase、Redis、Hudi里,加工时全部加载到内存并定期刷新内容 |
维表数据量相对较少,能够达到最佳新能 |
模型总结:
方案特点 |
适用场景 |
|
方案一:双流关联 |
最基础的流加工方案,未考虑关联不上的情况 |
仅演示、实际场景使用较少 |
方案二:双流关联+补偿 |
补偿逻辑可以满足关联不上时定时手动补数、但是如果要达到较好数据时延对Flink资源要求较高 |
Flink计算资源能够满足实际业务需求 |
方案三:双写+双流关联+补偿 |
较为完整的方案,可以满足较低数据时延以及较低的资源消耗,但是加工的逻辑比较复杂 |
实际场景使用较多 |
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)