您当前的位置: 首页 > 

Bulut0907

暂无认证

  • 4浏览

    0关注

    346博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

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

Bulut0907 发布时间:2022-05-26 09:54:40 ,浏览量:4

目录
  • 1. Table Types
    • 1.1 Copy On Write
    • 1.2 Merge On Read
    • 1.3 Copy On Write对比Merge On Read
  • 2. Indexing
  • 3. Metadata Table

1. Table Types 1.1 Copy On Write

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

Copy On Write说明:

  • 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种数据读取方式:

  1. Snapshot Queries:读取某个instant time的Snapshot,包含base file + log files。读取的数据延时低,查询性能低
  2. Incremental Queries:读取某个instant time后的增量数据,包含base file + log files
  3. Read Optimized Queries:读取某个instant time的Snapshot,只读取base file。读取的数据延时高,查询性能高
1.3 Copy On Write对比Merge On Read 对比点CopyOnWriteMergeOnRead写入延迟HigherLowerquery延迟LowerHigherUpdate cost(I/O)Higher,rewrite整个parquet文件Lower,append数据到delta logParquet File SizeSmallerLargerWrite AmplificationHigherLower(取决于compaction strategy)查询方式Snapshot Queries + Incremental QueriesSnapshot 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进行设置

关注
打赏
1664501120
查看更多评论
立即登录/注册

微信扫码登录

0.0483s