一、传统数据湖存在的问题与挑战
传统数据湖解决方案中,罕用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
- 反对SnapShot数据隔离,保证数据读取完整性,实现读写并发能力
- 数据commit,数据入湖秒级可见
疾速Upsert能力
- 反对可插拔索引进制实现新增更新数据疾速入湖
- 扩大Merge操作,实现新增、更新、删除混合数据同时入湖
- 反对写入同步小文件合并能力,写入数据主动依照预设文件大小进行文件合并
Schema Evolution
- 反对湖内数据schema的同步演进
- 反对多种常见schema变更操作
多种视图读取接口
- 反对实时快照数据读取形式
- 反对历史快照数据读取形式
- 反对以后增量和历史增量数据读取形式
- 反对疾速数据摸索剖析
多版本
- 数据依照提交版本存储,保留历史操作记录,不便数据回溯
- 数据回退操作简略,速度快。
三、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能够构建分钟级数据处理计划,实现较大数据量的简单计算实时处理能力,大大晋升数据时效性,让数据价值近在眼前!
本文由华为云公布