Apache Iceberg Research

Apache iceberg 的感性认知,架构,业务,特性,优点
摘要由CSDN通过智能技术生成

官网及其他参考文档

官网
Apache Iceberg

GitHub - apache Iceberg

阿里云 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?

ache iceberg:Netflix 数据仓库的基石 - 知乎
(zhihu.com)

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 数据库,扩展性

要求:

  1. 支持多种对象存储
    特点:弹性、低廉、稳定
  2. 统一的Table语义
    抽象度高,ACID,多种文件格式
  3. 计算引擎互连互通
    支持Hive,Spark,Flink,Presto读写

Hive 表挑战2:近实时数仓

Hive Table:小时级别时效性体验
Generic Table :分钟级别时效性体验

  • 入仓:HMS( hive metastore) 受限于扩展性,难以做按分钟做分区
  • 查询:先查MySQL找分区,再list分区目录找文件,元数据index效率低
  • 查询:缺乏文件级全局统计信息

要求:

  1. 分钟级入湖入仓,数仓内数据更实时
  2. 更高效索引加速数据分析,查询相应更快
  3. 增量出湖出仓,下游ETL相应更快

Hive 表挑战3:变更

  • 问题1: Schema变更(如新增一个字段)
  • 问题2: 分区变更(从月级分区改为天级分区)
  • 问题3:CDC数据变更

要求:

  1. Schema变更,表结构随业务变动而变更
  2. 分区变更,调整分区策略适配不同分析诉求
  3. 数据变更,表级/分区级/文件级/行级不同粒度变更

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
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值