赞
踩
出品社区|DataFun
分享嘉宾|张永翔 网易数帆 资深平台开发工程师
湖仓一体的发展经历了从数据仓库到数据湖,最终到湖仓一体的过程。传统的数仓针对的是结构化数据,面向特定的分析或者报表场景,提供标准的 SQL 与标准的服务。随着业务规模的扩大,复杂性提升,对于半结构化、非结构化的数据存储和处理的需求涌现,催生了数据湖技术的发展。数据湖是在廉价的存储系统上,使用各种工具,满足各种数据类型的业务需求。这种非标准化的处理带来了管理成本和开发成本的上升。湖仓一体顺应而生,它是基于数据服务技术开发的廉价的系统,同时能够构建结构化数据的处理能力。
湖仓一体的主要特点满足了人们对它的期望,可以归纳为四点:
基于云构建湖仓一体 的 主要优势 有两大方面:
构建湖仓一体也面临着 诸多挑战,比如:
Apache Iceberg 是数据湖上的 开放表格式,它具有以下特点:
Apache Iceberg 本身的特性贴合云原生。
首先,Apache Iceberg 使用去中心化的元数据组织。采用 Metadata file
索引数据文件,并且在元数据文件中记录了数据文件的 Metric 信息,以提供高效的 File Skip
。不同于传统 Hive 采用一个中心化的方式来去处理这些元数据。Metadata 文件和数据文件一起存储到数据湖中,这使得 Iceberg 可以轻松地弹性扩展。
其次,Iceberg 不依赖于 HDFS 的存储层抽象。Iceberg 对于数据文件和 Metadata 文件的访问进行了抽象,使其避免依赖于某种存储系统(比如 Hadoop)的实现,这使得 Iceberg 可以轻松对接各种云商的对象存储系统。
lceberg 定义了一套开放的 Catalog 接口。通过标准的 Catalog 接口对接外部的元数据,使得 Iceberg 可以轻易对接 Hive 以及各种云上的元数据服务。
Iceberg 还定义了标准的 Rest Catalog API,提供了 Rest Catalog API 的服务可以零成本地接入 Iceberg。
Amoro 定位为 基于开放湖表格式的湖仓一体管理系统。首先,它是基于开放的数据库表格式,Amoro 本身并不是一种表格式,而是构建在 Iceberg 等数据湖格式之上的 管理系统。其次,Amoro 提供了很多可插拔的组件,如 元数据中心、调度管理系统、pipeline 优化 等。构建了与基础设施无关的一种服务,底层也并不去绑定某种特定的技术或者云厂商。Amoro 是为了在云上提供一种与基础设施无关的标准化的湖仓一体化管理系统。
Amoro 的 核心功能 是 Catalog Services
。
0.5
0.5
0.5 版本里面提供了 internal Catalog
和 external Catalog
两种类型。符合 Iceberg Rest Catalog API 接口的 Internal Catalog 服务,在云上部署时可以直接使用 Amoro 服务作为元数据中心。同时具有对接外部 catalog 服务的能力。如果业务有集成 EMR 的需求,业务根据需要将 Iceberg 表注册到任意外部元数据中心,Amoro 均可与其对接,并进行 Iceberg 表的管理。
Amoro 另一个核心功能是 Self-Optimizing。流计算场景下,数据湖表的治理成为核心需求。随着流式写入,它必然带来小文件问题,进而带来查询的性能问题,甚至有可能因为小文件或者 delete 文件太多,造成表不可用。Amoro 数据湖表提供了开箱即用的治理的能力。Amoro 会自动发现注册在 Catalog 中的数据湖表,自动地持续地去监测数据服务表的小文件以及 data 文件的数量,然后对整个表中的文件数据量进行评估,自动根据优先级优化任务调度,达到开箱即用的对数据湖表的文件治理。
Self-Optimizing 的机制如下图所示,依据 iceberg 表,将文件划分为 fragment
区域和 segment
区域。Amoro 根据 target-size
和 fragment-ratio
将文件划分为 fragment files
和 segment files
。
当 target-size
为
128
m
b
128mb
128mb 时,fragment-ratio
设置为
8
8
8,就认为是
128
m
b
128mb
128mb 的
1
/
8
1 / 8
1/8,也就是
16
m
b
16mb
16mb。小于
16
m
b
16mb
16mb 的文件,我们认为它是属于 fragment file
,而大于
16
m
b
16mb
16mb 的则认为是 segment file
。在流式写入的场景中,频繁写入的文件通常都是比较小,需要频繁的 commit,这些都属于 fragment files
。下面是两种文件的特点:
Fragment files
eq-delete
文件Segement files
pos-delete
文件Amoro 中,Self Optimizing 分成三种类型:Minor optimize
,Major optimize
和 Full optimize
。
Minor optimize
是从 fragment file
到 segment file
的转换,把碎片化的小文件转换成非碎片化的文件,合并成大于 16mb 的文件,同时最重要的是做出了这种 eq-delete
操作,它会使 segment file
上面只关联 pos-delete
。大幅提升了 Iceberg 表的查询效率。Major optimize
是做 segment file
内部的转化,部分消除 pos-delete
文件,进一步去碎片化。Full optimize
是一种特殊的 optimize 类型,它根据用户的配置,比如一天执行一次,会直接把表上的文件合并成期望的 target-size
设置的大小,最终会消除所有的 delete
文件,全部转成 data file
。Self Optimizing 是自动的、异步的、长期存在的操作,必然会牵涉到资源的管理问题。Optimizing 资源管理是 基于 Group 的资源隔离和共享。Amoro 本身有一个角色 AMS(Amoro Management Service
),会对 Optimizing 计算资源进行管理,Amoro 将 Optimizing 的计算资源通过 Optimizer group 划分。通过设置表上 properties self-optimizing.group
,每个 Iceberg 表均属于某个 group。Group 间计算资源相互隔离,互不影响。Group 内部,通过 Quota 分配每个表可以占有的计算资源比例,达到计算资源在不同表之间的隔离或者共享。
Self Optimizing 定义了插件式的 Optimizer Container
,轻松扩展各种类型的计算集群。它本身是一个抽象框架,内置实现了 Local Container
和 Flink Container
。
Local Container
是本地的基于 JVM 进程的一个 optimize 的进程。Flink Container
是以 Flink 任务的方式去提交,可以当作一个 Flink 集群来使用。External Container
,可以通过外部注册的方式,向 AMS 直接注册用户自定义的计算集群类型。Amoro 提供了可视化的 Web 管理平台,方便管理员轻松管理 Table、Resource 等资源和 Optimizing 任务。
最后,针对前文中提到的建设云原生湖仓的挑战,总结出了 Amoro 和 Apache Iceberg 解决方案的优势。
下面介绍网易的一个实践案例,它是网易内部的一个出海业务,出于合规性的要求,需要上 AWS。对原本基于 Hive 的湖仓体系进行改造上云。在改造前为典型的 Hadoop + Hive 架构,计算依赖于 Hive SQL,Yarn 作为整个平台的计算集群,数据存储在 HDFS 集群中,HMS 为元数据中心。
改造完成了原有 Hive SQL 任务到 Spark SQL 任务的迁移。将计算集群从 Yarn 迁移到了 AWS EKS 集群,通过 Spark 适配 K8s 集群,充分利用弹性计算资源,并在 S3 上搭建 Alluxio 集群适配 HDFS 接口。新接入业务使用了 Iceberg 表,并使用 HMS 充当元数据中心。同时,使用 Amoro 负责对 Iceberg 湖表进行持续优化,并通过 Flink Optimizer 适配 K8s 集群。
第二个案例为某外企,基于 AWS S3 + Iceberg 构建湖仓一体。原有架构是基于 Iceberg + S3 直接构建湖仓一体,采用 AWS Glue 为元数据中心,融合 AWS EMR 系统。AWS EKS 为计算集群,构建弹性计算集群。在这里使用 Amoro 的AMS 对湖表进行管理和持续优化,通过发挥 Iceberg 直接对接 S3 的优势,减少了 Hadoop 体系的维护成本。
第三个案例使用 Amoro AMS 做元数据中心,采用 S3 + Iceberg 构建湖仓一体。在这个案例中通过 Iceberg Rest Catalog 与 Amoro AMS 对接。计算集群保持不变继续使用 AWS EKS 构建弹性计算集群。Amoro 既作为湖仓的元数据中心,也实现了对 optimizer 的管理。
最后,分享一下 Amoro 的未来规划。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。