基于MRS-Hudi构建数据湖的典型应用场景介绍

一、传统数据湖存在的问题与挑战

传统数据湖解决方案中，常用Hive来构建T+1级别的数据仓库，通过HDFS存储实现海量数据的存储与水平扩容，通过Hive实现元数据的管理以及数据操作的SQL化。虽然能够在海量批处理场景中取得不错的效果，但依然存在如下现状问题：

问题一：不支持事务

由于传统大数据方案不支持事务，有可能会读到未写完成的数据，造成数据统计错误。为了规避该问题，通常控制读写任务顺序调用，在保证写任务完成后才能启动读任务。但并不是所有读任务都能够被调度系统约束住，在读取时仍存在该问题。

问题二：数据更新效率低

业务系统库的数据，除流水表类的数据都是新增数据外，还有很多状态类数据表需要更新操作（例如：账户余额表，客户状态表，设备状态表等），而传统大数据方案无法满足增量更新，常采用拉链方式，先进行join操作再进行insert overwrite操作，通过覆盖写的方式完成更新操作，该操作往往需要T+1的批处理模式 ，从而导致端到端数据时延T+1，存在效率低、成本高等问题。

问题三：无法及时应对业务表变化

上游业务系统对数据schema发生变更后，会导致数据无法入湖，需要数据湖的表schema进行同步调整。从技术实现上采用数据表重建的方式来满足该场景，导致数据湖的数据表的管理与维护方案复杂，实现成本高。另外该种场景通常需要业务部门与数据团队相配合，通过管理流程来实现表结构的同步。

问题四：历史快照表数据冗余

传统数据湖方案需要对历史的快照表进行存储，采用全量历史存储的方式实现，例如：天级历史快照表，每天都会全量存储全表数据。这样就造成了大量的数据存储冗余，占用大量的存储资源。

问题五：小批量增量数据处理成本高

传统数据湖为了实现增量ETL，通常将增量数据按照分区的方式进行存储，若为了实现T+0的数据处理，增量数据需要按照小时级或者分钟级的分区粒度。该种实现形式会导致小文件问题，大量分区也会导致元数据服务压力增大。

基于以上问题，华为FunsionInsight MRS集成Apache Hudi组件，希望通过Hudi组件来改善传统数据湖存在的问题。

二、