乐趣区

关于程序员:基于MRSHudi构建数据湖的典型应用场景介绍

jiezi

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

传统数据湖解决方案中，罕用 Hive 来构建 T + 1 级别的数据仓库，通过 HDFS 存储实现海量数据的存储与程度扩容，通过 Hive 实现元数据的治理以及数据操作的 SQL 化。尽管可能在海量批处理场景中获得不错的成果，但仍然存在如下现状问题：

问题一：不反对事务

因为传统大数据计划不反对事务，有可能会读到未写实现的数据，造成数据统计谬误。为了躲避该问题，通常管制读写工作顺序调用，在保障写工作实现后能力启动读工作。但并不是所有读工作都可能被调度零碎束缚住，在读取时仍存在该问题。

问题二：数据更新效率低

业务零碎库的数据，除流水表类的数据都是新增数据外，还有很多状态类数据表须要更新操作（例如：账户余额表，客户状态表，设施状态表等），而传统大数据计划无奈满足增量更新，常采纳拉链形式，先进行 join 操作再进行 insert overwrite 操作，通过笼罩写的形式实现更新操作，该操作往往须要 T + 1 的批处理模式，从而导致端到端数据时延 T +1，存在效率低、老本低等问题。

问题三：无奈及时应答业务表变动

上游业务系统对数据 schema 产生变更后，会导致数据无奈入湖，须要数据湖的表 schema 进行同步调整。从技术实现上采纳数据表重建的形式来满足该场景，导致数据湖的数据表的治理与保护计划简单，实现老本高。另外该种场景通常须要业务部门与数据团队相配合，通过治理流程来实现表构造的同步。

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

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

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

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

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

二、MRS 云原生数据湖 Hudi 的要害个性

Apache Hudi 是数据湖的文件组织层，对 Parquet 等格式文件进行治理提供数据湖能力，反对多种计算引擎，提供 IUD 接口，在 HDFS/OBS 的数据集上提供了插入更新和增量拉取的流原语，具备如下特点：

反对 ACID

  1. 反对 SnapShot 数据隔离，保证数据读取完整性，实现读写并发能力
  2. 数据 commit，数据入湖秒级可见

疾速 Upsert 能力

  1. 反对可插拔索引进制实现新增更新数据疾速入湖
  2. 扩大 Merge 操作，实现新增、更新、删除混合数据同时入湖
  3. 反对写入同步小文件合并能力，写入数据主动依照预设文件大小进行文件合并

Schema Evolution

  1. 反对湖内数据 schema 的同步演进
  2. 反对多种常见 schema 变更操作

多种视图读取接口

  1. 反对实时快照数据读取形式
  2. 反对历史快照数据读取形式
  3. 反对以后增量和历史增量数据读取形式
  4. 反对疾速数据摸索剖析

多版本

  1. 数据依照提交版本存储，保留历史操作记录，不便数据回溯
  2. 数据回退操作简略，速度快。

三、MRS-Hudi 的典型利用场景

基于 MRS-CDL 组件实现数据实时入湖

场景阐明：

  • 能够从业务数据库中间接抽取数据
  • 数据入湖须要高实时性，秒级提早
  • 数据表变更须要与数据湖表构造实时同步

计划介绍：

该计划基于 MRS-CDL 组件构建，由 CDL 组件实现业务库的操作事件捕捉并写入的基于 MRS-Hudi 的数据湖存储。

MRS-CDL 是 FusionInsight MRS 推出的一种数据实时同步服务，旨在将传统 OLTP 数据库中的事件信息捕获并实时推送到数据湖中去。该计划有以下个性反对：

  • MRS-CDL 反对捕捉业务零碎库的 DDL 和 DML 事件。
  • 反对将 MRS-Hudi 作为数据指标端。
  • 可视化操作，采集工作、入湖工作以及工作治理都是可视化操作。
  • 入湖工作反对多租户，保证数据权限与湖内权限保持一致。
  • 全程工作开发零代码，节俭开发成本。

计划收益：

  • 入湖操作简略，全程零代码开发。
  • 入湖时效快，从业务零碎数据调整到入湖，可在分钟内实现。

基于 Flink SQL 入湖

场景阐明：

  • 无需间接对接数据库，数据由已有采集工具发送到 Kafka 或者由业务零碎间接发送到 Kafka。
  • 不须要实时同步 DDL 操作事件。

计划阐明：

MRS 的 FlinkSQL 入湖链路是基于 Flink+Hudi 成的。MRS-Flink 以下个性反对该计划：

  • 减少了 Flink 引擎与 Hudi 的对接能力。反对了对 Hudi 中 COW 表以及 MOR 表的读写操作。
  • FlinkServer（Flink 开发平台）减少了对 Hudi 的流量表反对。
  • 作业开发与作业保护可视化操作。

计划收益：

  • 入湖代码开发简略。

通过 FlinkSQL 实现入湖的语句如下：

Insert into table_hudi select * from table_kafka;

  • 入湖时效快，最快可达秒级数据入湖。

湖内数据疾速 ETL

场景阐明：

湖内数据通常会采纳数仓分层存储，例如：贴源层（SDI）、汇总层（DWS）、集市层（DW），各家企业也会有不同的分层规范。数据在各层间接流转也会有相应的标准。传统数据湖通常采纳天级全量数据 ETL 解决以实现各层之间数据流转。

当初 Hudi 反对 ACID 个性、Upsert 个性和增量数据查问个性，能够实现增量的 ETL，在不同层之间疾速的流转。

增量 ETL 作业与传统 ETL 作业业务逻辑齐全一样，波及到的增量表读取采纳 commit_time 来获取增量数据，在作业逻辑中的多表关联能够使 Hudi 表与 Hudi 表关联，也能够是 Hudi 表与存量 Hive 表的关联。ETL 作业开发能够基于 SparkSQL、FlinkSQL 开发。基于增量视图的 ETL 语句样例如下：Upsert table_dws select * from table_SDI where commit_time >“2021-07-07 12:12:12”。

因为采纳了增量 ETL 形式，每次所解决的数据量也会降落，具体降落多少有赖于业务理论流量状况和增量的周期粒度。例如：物联网的业务数据，全天 24 小时流量稳固，采纳 10 分钟级别的增量 ETL，那么所解决的数量将全天数据量的 1 /（24*60/10）。因而在解决数据量大幅降落状况下，所需的计算资源也有相应的降落。

计划收益：

  • 单个 ETL 作业处理时延升高，端到端工夫缩短。
  • 耗费资源降落，单位 ETL 作业所解决数据量大幅降落，所需计算资源也会相应降落。
  • 原有湖内存储的模型无需调整。

反对交互式剖析场景

场景阐明：

数据湖存储的数据具备数据品种全、维度多、历史周期长的特点，业务所需数据在数据湖中根本都是存在的，因而间接交互式剖析引擎间接对接数据湖能够满足业务各类需要数据需要。

在数据摸索、BI 剖析、报表展现等业务场景须要具备针对海量数据查问秒级返回的能力，同时要求剖析接口简略 SQL 化。

计划阐明：

在该场景中能够采纳 MRS-HetuEngine 来实现该计划，MRS-HetuEngine 是分布式高性能的交互式剖析引擎，次要用于数据的疾速实时查问场景。MRS-HetuEngine 具备以下个性能够很好的撑持该场景：

  • MRS-HetuEngine 引擎曾经实现与 MRS-Hudi 的对接，可能疾速读取 Hudi 存储的数据。
  • 反对读取快照查问，查问以后最新快照数据和历史快照数据。
  • 反对增量查问，依据 commit_time，查问任一时间段内的增量数据。
  • 针对 MOR 存储模型，尤其在数据摸索场景能够通过读优化查问接口，疾速剖析 MOR 模型的 Hudi 表数据。
  • 反对多源异构协同，具备跨 Hudi 与其余 DB 的联结剖析能力，例如：维度数据存在 TP 库中，能够实现数据湖的事实表与 TP 维度表的关联剖析。
  • 查问语句 SQL 化，反对 JDBC 接口。

计划收益：

  • 联合 MRS-CDL 数据入湖，业务零碎库数据变更可在分钟内实现在数据湖内可见。
  • 对 TB 级到 PB 的数据量的交互式查问可达到秒级后果返回。
  • 可对湖内各层数据进行剖析。

基于 Hudi 构建批流一体

场景阐明：

传统解决架构中采纳 Lambda 或者 Kappa 架构。Lambda 应用比拟灵便，也能够解决业务场景，然而在该架构中须要两套零碎来实现，保护比较复杂。数据分流当前也很难再关联利用。例如：流解决场景应用批处理的后果。Kappa 架构是为实时处理的架构，该架构短少了批处理的能力。

计划阐明：

在很多实时场景中，对时延要求能够是分钟级的，这样能够通过 MRS-Hudi 和实时计算引擎 Flink 和 Spark-Streaming 进行增量计算实现数据的疾速解决，端到端实现分钟级提早。另外 MRS-Hudi 自身就是湖存储，能够存储海量数据，因而也能够反对批量计算，罕用的批处理引擎能够采纳 Hive 和 Spark。

计划价值：

  • 数据对立存储，实时数据与批量数据共用雷同的存储。
  • 同时反对实时计算与批量计算。雷同业务逻辑的处理结果复用。
  • 满足分钟级延时的实时处理能力和海量的批量解决。

五、总结

传统大数据因为不反对事务等痛点问题，造成 T + 1 时延，尽管可能基于 Flink 流式计算实现大量数据在简略场景的秒级数据处理能力，但仍然不足海量简单场景的实时更新、事务反对能力。当初基于华为云 FusionInsight MRS 的 Hudi 能够构建分钟级数据处理计划，实现较大数据量的简单计算实时处理能力，大大晋升数据时效性，让数据价值近在眼前！

本文由华为云公布

退出移动版