IceBerg的自我学习（3）

存储过程

这个IceBerg中非常强大的特性，使用语法为

CALL catalog.system.produce_name( arg_name_2 => arg_2 , arg_name_3 => arg_3)

这是通过名称进行传递参数（推荐），所有的过程都在系统的命名空间中存储

这里我们主要介绍高频使用的存储过程

清理未被元数据引用的孤立文件（remove_orphan_files）

在版本更新的时候，经常会有更新后就不被元数据使用到的文件，这些我们就叫作孤立文件，如果没有被及时清理，这些文件无疑会占用资源，因此该存储过程的适用场景为

• 定期清理写入失败存储的文件
• 解决版本更新未被元数据引用的问题
• 存储优化
• 解决Spark作业崩溃导致的中间文件残留

先是他的参数说明

CALL catalog.system.remove_orphan_files(
	table => yours_table -- 访问的表（必选）
	,orphan => timestamp -- 时间戳设定（可选），只清除早于该时间戳的孤立文件，要求毫秒级Unix
	,location => custom_path -- 限定查找路径（可选），默认全搜索
	,dry_run => true/false	-- 是否模拟查询结果（可选），true的话返回删除的孤立文件但不实际执行
)

举例使用

-- 安全模式：删除七天前的孤立文件
CALL hive_prod.system.remove_orphan_files(
	table => sales_table
	,orphan => (current_timestamp.cast('long')*1000 - interval 7 days) * 1000
	,dry_run => true
)

-- 实际使用：
CALL hive_prod.system.remove_orphan_files(
	table => sales_table
	,orphan => (current_timestamp - interval 7 days) * 1000
)

使用建议：

• 窗口时间设置为最近有效的快照时间，避免误删新文件
• 第一次开启安全模式验证结果
• 大表的话，可以通过location来限定路径，进行拆分

合并小文件/优化文件分布！！(rewrite_data_files)

这个存储过程主要用来合并小文件，来提升查询效率，因此在存储过程中非常重要

那我们先来看看他的参数

高级参数调优

Sort策略特有参数

• 若发现 rewrite_data_files 生成的文件大小与预期不符（如压缩后数据膨胀），优先调整 compression-factor。
• 若使用 Z-Order 且排序键包含变长列，根据字段实际长度调整 var-length-contribution。

首先是排序规则，涉及到了一个排序策略：Z-order策略

这个主要是将多维的数据拆分为一维数据来映射，在保留原始数据的基础上，能够比传统线性排序更好的优化多维查询

例如：x=3(11), y=5(101) → Z-Address=110111

‌列选择‌：优先选择高基数、高频查询的维度（如用户 ID、事件时间）‌。

‌数据治理‌：定期合并小文件（rewrite_data_files）并清理孤立文件，维持存储效率‌。

‌混合策略‌：结合时间分区（如 dt）与 Z-Order，平衡写入性能与查询效率‌。

适用场景：

• 适合2~4列高频过滤列的复合查询场景
• 适合在OLAP场景下对多维度等值查询的优化
• 当数据均匀的时候，Z-order排序的效率显著优于简单排序

要注意Z-Order重写需要额外的资源，因此最好是低频更新的表

使用例子：

-- 基础配置

CALL catalog.system.rewrite_data_files(
  table => 'db.orders',
  options => map(
    'target-file-size-bytes' , '1073741824'  -- 合并为1GB的文件
    ,'min-file-size-bytes','268435456' --256MB以下的文件强制合并
  )
)

-- 排序合并（优化性能）

CALL catalog.system.rewrite_data_files(
  table => 'db.logs',
  stragery => 'sort',
  sort_order => 'zorder(user_id,event_time)', --以z-order的排序来提高性能
  options => map(
    'target-file-size-bytes','2147483648' -- 合并成2GB的文件
    ,'max-concurrent-file-group-rewrites',
    '10' --提高并行度
  )
)

-- 局部合并（分区优化）

CALL catalog.system.rewrite_data_files(
  table => 'db.sales',
  where => 'dt >= "2023-01-01" AND dt <= "2023-01-07"',  -- 合并指定分区
  options => map('rewrite-all', 'true')                   -- 忽略阈值强制合并
);

• sort策略需要消耗额外资源，因此最好在低负载的时候去使用
• 如果大分区，就需要调整max-file-group-size-bytes，避免OOM

在合并之后，旧的文件就成为了孤立文件，咱们就可以用刚才讲的remove_orphan_files去进行清楚操作

清楚不需要的过期快照以及文件（expire_snapshots）

IceBerg每次在进行插入/更新/删除/修改的操作，都会产生新的快照，同时保留旧数据以供时间旅行的实现

expire_snapshots就是用来清理这些旧快照以及被这些旧快照单独引用的数据文件，但是仅删除未被其他快照/标签引用的

介绍一下参数

光看不行，还得有点操作步骤

-- 删除7天前的快照但是保留十个快照
CALL catalog.system.expire_snapshots(
	table => 'db.sample',
  	older_than => current_timestamp() - INTERVAL '7' DAY,
  	retain_last => 10
);

-- 安全清理示例（含孤立文件清理）
CALL catalog.system.expire_snapshots(
  table => 'db.audit_log',
  older_than => TIMESTAMP '2025-05-09 00:00:00',
  retain_last => 5,
  max_concurrent_deletes => 4,
  stream_results => true,
  delete_orphan_files => true
);

-- 清理旧元数据文件（需单独执行）
CALL catalog.system.remove_old_metadata(
  table => 'db.audit_log',
  older_than => TIMESTAMP '2025-01-01'
);

执行顺序：最好是在rewrite_data_files合并小文件后再执行，清理旧快照

• 并发删除数 (max_concurrent_deletes) 建议设为集群可用核数的 1/4

合并清单文件以提高元数据查询效率（merge_manifests）

这个主要是用来合并清单文件，使用的程度并不会像合并数据文件一样那么高

可选的参数有

适用场景：

• 表经过大量的小文件写入操作后，可以合并一下清单文件提高元数据查询效率
• 读取元数据成为性能瓶颈的时候，可以合并一下
• 每日ETL后，可以作为维护表的一部分执行

-- 合并特定表的清单文件
CALL system.merge_manifests(
  table => 'hive_prod.analytics.events'
);

-- 强制重写所有清单文件
CALL system.merge_manifests(
  table => 'hive_prod.analytics.events',
  rewrite_all => true
);

-- 带完整参数的合并示例
CALL system.merge_manifests(
  table => 'hive_prod.analytics.events',
  rewrite_all => false,
  max_manifest_size_bytes => 16777216,  -- 16MB
  min_manifest_count => 5
);

但是要注意，合并会导致新的快照出现，历史快照并不会删除，如果要删除还需要配合expire_snapshots

优化合并删除文件（rewrite_position_delete_files）

针对删除文件，可以使用这个存储过程，去合并小位置删除文件，同时移除指向已失效数据文件的删除文件

核心参数有：

这是执行的流程

1.根据表元数据的内容定位到所有位置删除文件（以.delete结尾的文件）
2.根据文件大小策略去进行拆分或合并，会跳过指向已失效数据文件的删除文件
3.并行处理，根据并发控制去生成合并文件
4。元数据更新，更新Manifestes和快照文件，旧的快照要配合expire_snapshots删除

-- 带合并示例
CALL system.rewrite_position_delete_files(
  table => 'hive_prod.analytics.events',
  options => map(
    'max-concurrent-file-group-rewrites', '10',
    'target-file-size-bytes', '67108864',  -- 64MB
    'partial-progress.enabled', 'true',
    'rewrite-job-order', 'bytes-desc'
  )
);

迁移数据格式(migrate_table)

将Hive数据格式迁移为IceBerg的表格式，适合在企业技术架构转型的时候去使用

在这个之上，还有一个迁移方式，是migrate，二者的区别是，migrate适合大规模表格式的迁移，migrate_table则是专注于一个表

适合先用migrate进行大规模迁移，再用migrate_table单独优化个别表

捕获数据更新，IceBerg的CDC功能（craete_changelog_view）

这个是IceBerg的CDC功能，也就是用于实时捕获数据更新，通过创建一个视图view来跟踪表的数据变更情况

start-snapshot-id / end-snapshot-id：按快照 ID 范围过滤变更。

start-timestamp / end-timestamp：按时间戳范围过滤变更（如 ‘2024-01-01 00:00:00’）。

排除故障时,可以指定特定快照IDend-snapshot-id：包含结束快照 ID，默认为 table 的当前快照。start-snapshot-id：独占的启动快照 ID。如果未提供，它将从表的第一个快照中读取。

例子：

--追踪数据变更情况
CALL create_changelog_view(  
  table => 'db.users',  
  changelog_view => 'user_changes',  
  options => map('start-timestamp', '2024-03-01', 'end-timestamp', '2024-03-31')  
);  

--增量数据同步
-- 获取净变更（仅最终状态）  
CALL create_changelog_view(  
  table => 'db.orders',  
  net_changes => true,  
  identifier_columns => array('order_id')  
);  

--故障恢复和回溯
-- 分析订单表在快照 12345 到 67890 之间的所有更新  
CALL create_changelog_view(  
  table => 'db.orders',  
  options => map('start-snapshot-id', '12345', 'end-snapshot-id', '67890'),  
  compute_updates => true  
);

具体实例场景

-- 假设有一个 Iceberg 表 iceberg_db.orders，记录订单数据（含字段 order_id、amount、status），现需捕获 ‌2024-03-01 至 2024-03-31‌ 期间的所有变更（插入、更新、删除）

-- 创建变更日志视图，包含更新前后的完整行数据  
CALL catalog.system.create_changelog_view(  
  table => 'iceberg_db.orders',  
  changelog_view => 'orders_changelog',  
  options => map(  
    'start-timestamp', '2024-03-01 00:00:00',  
    'end-timestamp', '2024-03-31 23:59:59'  
  ),  
  compute_updates => true,  
  identifier_columns => array('order_id')  
);

执行SELECT * FROM orders_changelog LIMIT 3

统计表中非重复值的统计数据（compute_table_stats）

例子：

CALL catalog_name.system.compute_table_stats('my_table');

CALL catalog_name.system.compute_table_stats(table => 'my_table', snapshot_id => 'snap1' );

CALL catalog_name.system.compute_table_stats(table => 'my_table', snapshot_id => 'snap1', columns => array('col1', 'col2'));