DLA Lakehouse实时入湖方案利用数据湖技术,重构数仓语义;分析数据湖数据,实现数仓的应用。本文以RDS MySQL数据源为例介绍了RDS MySQL从入湖到分析的操作步骤。
背景信息
数据湖分析(Data Lake Analytics)是⽬前炙⼿可热的⽅向,主要是以对象存储系统为核心,构建海量、低成本的结构化、半结构化、⾮结构化对象⽂件的入湖、存储和分析业务。⽬前各⼤云⼚商都在积极跟进,布局相关的业务能力,阿⾥云数据湖分析团队在这个⽅向也很早就投⼊相关产品的研发。随着数据湖的应⽤越来越多,⼤家发现依赖数据湖最原始的能力,仅仅做简单的存储和分析,往往会遇到很多的问题。比较典型的痛点如下:
- 多源头数据需要统⼀存储管理,并需要便捷的融合分析。
- 源头数据元信息不确定或变化大,需要⾃动识别和管理;简单的元信息发现功能时效性不够。
- 全量建仓或直连数据库进行分析对源库造成的压⼒较大,需要卸载线上压⼒规避故障。
- 建仓延迟较⻓(T+1天),需要T+10m的低延迟入湖。
- 更新频繁致小文件多,分析性能差,需要Upsert⾃动合并。
- 海量数据在事务库或传统数仓中存储成本高,需要低成本归档。
- 源库⾏存储格式或非分析型格式,分析能力弱,需要⽀持列式存储格式。
- ⾃建⼤数据平台运维成本高,需要产品化、云原生、⼀体化的⽅案。
- 常见数仓的存储不开放,需要⾃建能力、开源可控。
Lakehouse是一种更先进的范式(Paradigm)和方案,用来解决上述简单入湖分析遇到的各种痛点问题。在Lakehouse技术中,⾮常关键的技术就是多版本的⽂件管理协议,它提供⼊湖和分析过程中的增量数据实时写⼊、ACID事务和多版本、小⽂件⾃动合并优化、元信息校验和⾃动进化、⾼效的列式分析格式、⾼效的索引优化、超⼤分区表存储等能⼒。⽬前开源社区有Hudi、Delta、Iceberg等数据湖方案,阿⾥云数据湖分析团队选择了比较成熟的Hudi作为DLA Lakehouse的湖仓⼀体化格式。关于Lakehouse的更多介绍,请参见Lakehouse介绍。
DLA Lakehouse核心概念和相关约束说明
- Lakehouse(湖仓)有两重含义:
- 范式:即解决简单⼊湖分析所遇到的痛点问题的⼀种解决⽅案。
- 存储空间:⽤来提供⼀个从其他地⽅入湖写⼊数据的空间,后续所有相关操作都围绕着这个湖仓来进行。
- 不同的Lakehouse有完全不同的路径,路径之间不可以相互有前缀关系(防止数据覆盖)。
- Lakehouse不能轻易进行修改。
- Workload(⼯作负载)是围绕湖仓⼀体化而展开的核心工作的编排调度(由DLA Lakehouse统⼀调度),包括如下功能特点:
- 入湖建仓
- 为了将其他源头的数据,汇总到整个湖仓内构建⼀个统⼀的数据平台,例如有DB类型的⼊湖建仓,也有Kafka的入湖建仓,还有OSS的数据转换建仓。
- 不同的入湖建仓,涉及到全量、增量等多个阶段,会统⼀编排并统⼀协调调度,简化⽤户管理成本。
- 查询优化
为了提升分析能力,构建各种查询优化方面的工作负载,比如自动构建索引、自动清理历史数据、自动构建物化视图等。
- 管理
- 成本优化:⾃动⽣命周期、冷热分层存储等。
- 数据互通:跨域建仓等。
- 数据安全:备份恢复等能力。
- 数据质量:DQC自动校验等。
- 入湖建仓
- Job作业对于Workload的实际作业拆分和执行,以及调度到不同的计算平台上执行,对⽤户不可见;目前DLA只⽀持调度作业到DLA Serverless Spark上执行。核心单元概念如下:
- 全量作业(从某个Workload中拆分出来)
- 增量作业(从某个Workload中拆分出来)
- Clustering:小文件聚合
- Indexing:自动索引构建
- Compaction:自动日志合并
- Tier:自动分层存储
- Lifecycle:自动生命周期管理
- MaterializedView:物化视图
- DB(库):DLA的库
- Table(表):DLA的表
- Partition(分区):DLA的分区
- Column(列):DLA的列
DLA Lakehouse方案介绍
DLA Lakehouse实时入湖是分钟级近实时的数据入湖方案,它能够构建统一、低成本、海量数据、自动元信息同步的湖仓平台,并支持高性能的DLA Spark计算和DLA
Presto分析。DLA Lakehouse实时入湖方案的存储与计算完全分离,写、存、读完全弹性,它的方案架构如下图所示:
准备工作
您需要在DLA中进行以下操作:
- 开通云原生数据湖分析服务
- 创建虚拟集群说明 DLA基于Spark引擎来运行DLA Lakehouse,因此创建虚拟集群的时候需要选择Spark引擎。
您需要在RDS中进行以下操作:
- 创建RDS MySQL实例说明 由于DLA Lakehouse只支持专有网络,故创建RDS MySQL实例时,网络类型请选择专有网络。
- 创建数据库和账号
- 通过DMS登录RDS数据库
- 在SQLConsole窗口中执行SQL语句创建库表并插入数据。
您需要在DTS中进行以下操作:
说明 目前DLA中RDS数据源的入湖分析工作负载,会先利用RDS做数据的全量同步,然后依赖DTS数据订阅功能做增量同步,最终实现完整的RDS数据入湖。
- 创建RDS MySQL数据订阅通道说明
- 由于DLA Lakehouse只支持专有网络,故订阅任务的网络类型请选择专有网络。
- 由于DLA Lakehouse无法自动更新元数据信息,故需要订阅的数据类型请选择数据更新和结构更新。
- 新增消费组
- 查看订阅Topic和消费者ID。后续的创建RDS入湖负载的增量同步配置中需要使用这2个参数。
- 在订阅任务的订阅配置中可以查看订阅Topic。
- 在订阅任务的数据消费中可以查看消费者ID。
确保您的数据流在RDS中部署的区域与DTS、DLA、OSS的区域相同。