文章目录
官网及其他参考文档
阿里云 iceberg产品对比与快速使用
Iceberg概述 (aliyun.com)
iceberg核心特性与架构
【2】数据湖架构中 Iceberg 的核心特性_TRX1024的博客-CSDN博客_数据湖iceberg
Catalog理解
Flink、Iceberg和Hive的Catalog比较研究——《滴普科技程序员部落》 - 知乎 (zhihu.com)
Apache Iceberg是什么?
Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to compute engines including Spark, Trino, PrestoDB, Flink and Hive using a high-performance table format that works just like a SQL table.
理解:
从这个定义上来看,Iceberg是一个用于海量数据分析场景下的开源的表格式(其实笔者更愿意用Table Format),也就是说Iceberg本质上是一个表格式。
那什么是表格式?表格式和我们熟悉的文件格式(File Format)是一回事吗?表和表格式是两个概念。表是一个具象的概念,应用层面的概念,我们天天说的表是简单的行和列的组合。而表格式是数据库系统实现层面一个抽象的概念,它定义了一个表中包含哪些字段,表下面文件的组织形式、表索引信息、统计信息以及上层查询引擎读取、写入表中文件的接口。
Apache Iceberg 是一种用于跟踪超大规模表的新格式,是专门为对象存储(如S3)而设计的。
发展历史
Apache Iceberg 是由 Netflix 开发开源的,其于 2018年11月16日进入 Apache 孵化器,是 Netflix公司数据仓库基础。在功能上和我们熟悉的 Delta Lake 或者 Apache Hudi 类似,但各有优缺点。
在数据仓库生态中的位置
具体理解看该文:Apache Iceberg 你需要知道的原理与技术
与Metastore的对比
上图右侧是Iceberg在数据仓库生态中的位置,和它差不多相当的一个组件是Metastore。
不过Metastore是一个服务,而Iceberg就是一系列jar包。既然Metastore和Iceberg我们认为都是表格式,那可以将两者在schema、partition、metadata/index以及读写api这几个方面做个对比:
1.schema基本相同。
两者底层都依赖于Parquet/ ORC等文件格式,这些文件格式都支持复杂数据类型,因此上层只需要做一些适配工作就可以支持复杂数据类型。
2.partition实现完全不同。两者在partition上有很大的不同:
Iceberg中partition字段就是表中的一个字段。Iceberg中每一张表都有一个对应的文件元数据表
3.表统计信息实现粒度不同。
4.读写API实现不同。
就是Metastore表格式不支持增量拉取,而Iceberg表格式支持增量拉取,同时Iceberg表格式支持文件级别的谓词过滤,查询性能更佳。
Iceberg表格式可以解决业务什么问题?
Iceberg可以解决业务的几大问题:
1.降低NameNode的list请求压力。[新partition模式]
2.提高查询性能。[新partition模式&&新表统计信息]
3.T+1离线数仓进化为分钟级别的准实时数仓。[新API提供了准实时增量消费]
4.所有数据基于Parquet等通用开源文件格式,没有lambad架构,不需要额外的运维成本和机器成本。
5.高效低成本的表schema和partition字段变更。[基于snapshot的schema/partition变更]
Why Apache IceBerg?
Netflix 面临的问题包括:
1、不安全的操作随处可见;
2、和对象存储交互有时候会出现很大的问题;
3、无休止的可扩展性挑战。
iceberg 是一种可伸缩的表存储格式,内置了许多最佳实践。
什么?是一种存储格式?可使我们已经有 Parquet,Avro 以及 ORC 这些格式了,为什么还要设计一种新格式?
Hive的不足与优势:
iceberg 允许我们在一个文件里面修改或者过滤数据;当然多个文件也支持这些操作。为了展示这点,我们来看看一张 Hive 表。
Hive 表的核心思想是把数据组织成目录树,如上所述。
如果我们需要过滤数据,可以在 where 里面添加分区相关的信息。
带来的问题是如果一张表有很多分区,我们需要使用 HMS(Hive MetaStore)来记录这些分区,同时底层的文件系统(比如 HDFS)仍然需要在每个分区里面记录这些分区数据。
这就导致我们需要在 HMS 和 文件系统里面同时保存一些状态信息;因为缺乏锁机制,所以对上面两个系统进行修改也不能保证原子性。
当然 Hive 这样维护表也不是没有好处。这种设计使得很多引擎(Hive、Spark、Presto、Flink、Pig)都支持读写 Hive 表,同时支持很多第三方工具。简单和透明使得 Hive 表变得不可或缺的。
Iceberg 的目标包括:
1、成为静态数据交换的开放规范,维护一个清晰的格式规范,支持多语言,支持跨项目的需求等。
2、提升扩展性和可靠性。能够在一个节点上运行,也能在集群上运行。所有的修改都是原子性的,串行化隔离。原生支持云对象存储,支持多并发写。
3、修复持续的可用性问题,比如模式演进,分区隐藏,支持时间旅行、回滚等。
Iceberg 主要设计思想:
记录表在所有时间的所有文件,和 Delta Lake 或 Apache Hudi 一样,支持 snapshot,其是表在某个时刻的完整文件列表。每一次写操作都会生成一个新的快照。
读取数据的时候使用当前的快照,Iceberg 使用乐观锁机制来创建新的快照,然后提交。
Iceberg 这么设计的好处是:所有的修改都是原子性的;没有耗时的文件系统操作;快照是索引好的,以便加速读取;CBO metrics 信息是可靠的;更新支持版本,支持物化视图。
在Netflex的实践
Scale:Iceberg 在 Netflix 生产环境维护着数十 PB 的数据,数百万个分区。对大表进行查询能够提供低延迟的响应。
Concurrency:生产环境中使用 Flink 管道在 3 个 AWS regions 写数据。Lift 服务将数据移到一个 region。Merge 服务对小文件进行合并。
Usability: 可用性方面:回滚是家常便饭。
Hive 表面临的挑战:
apache iceberg - 搜索结果 - 知乎 (zhihu.com)
Hive 表挑战1:上云
- Write Path 依赖HDFS的多个文件Rename 原子性语义
- Read Path 先查MySQL 获取分区列表,再LIST 目录获取文件
- 中心化的Metastore 数据库,扩展性
要求:
- 支持多种对象存储
特点:弹性、低廉、稳定 - 统一的Table语义
抽象度高,ACID,多种文件格式 - 计算引擎互连互通
支持Hive,Spark,Flink,Presto读写
Hive 表挑战2:近实时数仓
Hive Table:小时级别时效性体验
Generic Table :分钟级别时效性体验
- 入仓:HMS( hive metastore) 受限于扩展性,难以做按分钟做分区
- 查询:先查MySQL找分区,再list分区目录找文件,元数据index效率低
- 查询:缺乏文件级全局统计信息
要求:
- 分钟级入湖入仓,数仓内数据更实时
- 更高效索引加速数据分析,查询相应更快
- 增量出湖出仓,下游ETL相应更快
Hive 表挑战3:变更
- 问题1: Schema变更(如新增一个字段)
- 问题2: 分区变更(从月级分区改为天级分区)
- 问题3:CDC数据变更
要求:
- Schema变更,表结构随业务变动而变更
- 分区变更,调整分区策略适配不同分析诉求
- 数据变更,表级/分区级/文件级/行级不同粒度变更
Iceberg的解决方案
Iceberg在大数据体系生产中的位置
挑战1: 上云
数据访问不使用任何LIST接口
可扩展的metadata存储
ACID不依赖RENAME接口
统一的Table语义
完善的计算和多云生态对接
去中心化可拓展的metadata
挑战2: 近实时数仓
丰富的metadata index加速
增量的出入湖
挑战3: 变更
快速实现Schema变更
轻量级分区变更
V2支持Merge-On-Read方式更新数据
Iceberg现状
Ecosystem对比
Features对比
Community Trending
Apache Iceberg 场景简介
Iceberg未来方向
User experience
Iceberg avoids unpleasant surprises. Schema evolution works and won’t inadvertently un-delete data. Users don’t need to know about partitioning to get fast queries.
- Schema evolution supports add, drop, update, or rename, and has no side-effects
- Hidden partitioning prevents user mistakes that cause silently incorrect results or extremely slow queries
- Partition layout ev