1. Table Types

1.1 Copy On Write

Copy-On-Write表的file slice只有一个base file，每一次action都会进行compaction，产生新version的file slice

说明：

field1、field2、field3在10:05的数据全部在base file中
此时query能查询到version 10:05的数据
10:10的upsert操作被compaction到field1、field2、field5，产生新version的base file
此时query能查询到version 10:05和10:10的数据

1.2 Merge On Read

Merge on read表是copy on write表的超集。commit的数据首先被储存在log files中，然后会进行后台的compaction，将base file + log files合并，生成一个新version的base file。读取能达到近实时，可能有几分钟的延迟，有3种数据读取方式：

Snapshot Queries：读取某个instant time的Snapshot，包含base file + log files。读取的数据延时低，查询性能低
Incremental Queries：读取某个instant time后的增量数据，包含base file + log files
Read Optimized Queries：读取某个instant time的Snapshot，只读取base file。读取的数据延时高，查询性能高

1.3 Copy On Write对比Merge On Read

对比点	CopyOnWrite	MergeOnRead
写入延迟	Higher	Lower
query延迟	Lower	Higher
Update cost(I/O)	Higher，rewrite整个parquet文件	Lower，append数据到delta log
Parquet File Size	Smaller	Larger
Write Amplification	Higher	Lower(取决于compaction strategy)
查询方式	Snapshot Queries + Incremental Queries	Snapshot Queries + Incremental Queries + Read Optimized Queries

2. Indexing

每一个file group对应表的一个primary key。Hudi将partition + primary key作为hoodie key，映射到一个file group

Hudi支持以下几种Index类型，可以通过hoodie.index.type参数(BLOOM / HBASE / INMEMORY)进行指定：

Bloom Index(default)：
- 对record key使用bloom filters。如果构造的record key是event_time + event_id这种顺序key，布隆过滤器还可以进行范围过滤。
- Hudi支持动态布隆过滤器(使用hoodie.bloom.index.filter.type=DYNAMIC_V0启用)，它根据存储在给定文件中的记录数自动调整配置以改善误报率
- 适用于update / delete的数据影响少部分partition
Simple Index：
- 将表中的字段解析成key，和update/delete record进行join
- 适用于update / delete的数据影响大部分partition
HBase Index: 将Index mapping储存在Hbase中
Bring your own implementation: 可以继承API实现自定义的indexing

Index有全局索引和非全局索引

全局索引：
- primay key只会存在一个partition中，hoodie key就是primary key
- 会随着表的数据越多，性能越慢
- update/delete的数据等于该primary key，但不属于该partition，会造成数据错误问题。所以需要我们保证primary key只能属于一个partition
- 对于user_id为primary key，home_city为partition，会发生home_city变化的情况，这样partition path就会发生变化。需要设置hoodie.bloom.index.update.partition.path=true / hoodie.simple.index.update.partition.path=true
- Hbase索引是全局索引
非全局索引：
- primary key可能存在多个partition中
- 布隆索引和Simple Index默认是非全局索引，可以通过hoodie.index.type=GLOBAL_BLOOM / hoodie.index.type=GLOBAL_SIMPLE进行指定

3. Metadata Table

文件listings和partitions信息直接通过metadata table查询获取，减少HDFS的访问，提升读写性能

当完成一次成功的数据写入之后，coordinator会先同步抽取文件listings、partiitons等信息写入metadata table，然后再写event log到timeline

Metadata Table默认是开启的，可以通过hoodie.metadata.enable进行设置

【数据湖Hudi的概念】Table Types、Indexing和Metadata Table相关推荐

【Hudi】数据湖Hudi核心概念与架构设计总结
Hudi是现在非常热门的数据湖开源方案,非常适合于搭建一个数据湖平台. 有些人认为数据湖肯定与大数据技术体系完全不一样,是两个东西,甚至认为他俩没关系. 但是,你知道Hudi的全称叫啥么?就是&quo ...
从0到1搭建数据湖Hudi环境
一.目标前面一篇博文中已经详细讲解过数据湖Hudi相关的一些基本概念,想学习下的,可以去看下.数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi_一个数据小开发的博客-CSDN博客 ...
Flink 版本数据湖(hudi)实时数仓---flinkcdc hudi kafak hive
1.架构图 2.实现实例 2.1 通过flink cdc 的两张表合并成一张视图, 同时写入到数据湖(hudi) 中同时写入到kafka 中 2.2 实现思路 1.在flinksql 中创建fl ...
数据湖-hudi概述
前言数据湖是目前比较热的一个概念,许多企业都在构建或者计划构建自己的数据湖. 数据湖是一个集中式存储库,允许您以任意规模存储所有结构化和非结构化数据.您可以按原样存储数据(无需先对数据进行结构化处理 ...
数据湖基本概念--什么是数据湖，数据湖又能干什么？为什么是Hudi
一.什么是数据湖对于经常跟数据打交道的同学,初步听到数据湖这个概念的时候,肯定有点懵,但是相信大家对于数据仓库这个概念并不陌生. 到了20世纪80年代以后,基于关系型数据库的事务处理成为了企业IT ...
震惊！这篇文章解读数据仓库、数据湖、数据中台等概念，竟然写了4万字！
点击上方 "zhisheng"关注, 星标或置顶一起成长 Flink 从入门到精通系列文章如今,随着诸如互联网以及物联网等技术的不断发展,越来越多的数据被生产出来-据统计,每天 ...
4万字全面解读数据中台、数据仓库、数据湖等概念！建议收藏！
作者丨修鹏李建议阅读需50分钟如今,随着诸如互联网以及物联网等技术的不断发展,越来越多的数据被生产出来-据统计,每天大约有超过2.5亿亿字节的各种各样数据产生.这些数据需要被存储起来并且能够被方便 ...
数据湖架构Hudi（五）Hudi集成Flink案例详解
五.Hudi集成Flink案例详解 5.1 hudi集成flink flink的下载地址: https://archive.apache.org/dist/flink/ Hudi Supported ...
百信银行基于 Apache Hudi 实时数据湖演进方案
简介:本文介绍了百信银行实时计算平台的建设情况,实时数据湖构建在 Hudi 上的方案和实践方法,以及实时计算平台集成 Hudi 和使用 Hudi 的方式. 本文介绍了百信银行实时计算平台的建设情况,实 ...

【数据湖Hudi的概念】Table Types、Indexing和Metadata Table

目录