本文分享自华为云社区《MRS大企业ERP流程实时数据湖加工最佳实践》，作者：晋红轻 。
本文将以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计算资源能够满足实际业务需求 |
方案三：双写+双流关联+补偿 | 较为完整的方案，可以满足较低数据时延以及较低的资源消耗，但是加工的逻辑比较复杂 | 实际场景使用较多 |
标签：ERP,加工,实时,关联,lookup,时延,MRS,数据,宽表 From： https://blog.51cto.com/u_15214399/7016852