【Iceberg学习三】Reporting和Partitioning原理

Metrics Reporting

Type of Reports

从 1.1.0 版本开始，Iceberg 支持 MetricsReporter 和 MetricsReport API。这两个 API 允许表达不同的度量报告，并支持一种可插拔的方式来报告这些报告。

ScanReport（扫描报告）

扫描报告（ScanReport）记录了在对一个给定表进行扫描规划时收集的度量指标。除了包含一些关于该表的一般信息，如快照 ID 或表名，它还包括以下度量指标：

• 总扫描规划持续时间
• 结果中包含的数据/删除文件数量
• 扫描/跳过的数据/删除清单文件数量
• 扫描/跳过的数据/删除文件数量
• 扫描的等值/位置删除文件数量

CommitReport（提交报告）

提交报告记录了在提交对表的更改（也就是生成快照）之后收集的度量指标。除了包含一些关于该表的一般信息，如快照 ID 或表名，它还包括以下度量指标：

• 总持续时间
• 提交成功所需的尝试次数
• 增加/移除的数据/删除文件数量
• 增加/移除的等值/位置删除文件数量
• 增加/移除的等值/位置删除操作数量

Available Metrics Reporters

LoggingMetricsReporter

这是在没有配置其他指标报告器时的默认指标报告器，其目的是将结果记录到日志文件中。示例输出如下所示：

INFO org.apache.iceberg.metrics.LoggingMetricsReporter - Received metrics report: 
ScanReport{
    tableName=scan-planning-with-eq-and-pos-delete-files, 
    snapshotId=2, 
    filter=ref(name="data") == "(hash-27fa7cc0)", 
    schemaId=0, 
    projectedFieldIds=[1, 2], 
    projectedFieldNames=[id, data], 
    scanMetrics=ScanMetricsResult{
        totalPlanningDuration=TimerResult{timeUnit=NANOSECONDS, totalDuration=PT0.026569404S, count=1}, 
        resultDataFiles=CounterResult{unit=COUNT, value=1}, 
        resultDeleteFiles=CounterResult{unit=COUNT, value=2}, 
        totalDataManifests=CounterResult{unit=COUNT, value=1}, 
        totalDeleteManifests=CounterResult{unit=COUNT, value=1}, 
        scannedDataManifests=CounterResult{unit=COUNT, value=1}, 
        skippedDataManifests=CounterResult{unit=COUNT, value=0}, 
        totalFileSizeInBytes=CounterResult{unit=BYTES, value=10}, 
        totalDeleteFileSizeInBytes=CounterResult{unit=BYTES, value=20}, 
        skippedDataFiles=CounterResult{unit=COUNT, value=0}, 
        skippedDeleteFiles=CounterResult{unit=COUNT, value=0}, 
        scannedDeleteManifests=CounterResult{unit=COUNT, value=1}, 
        skippedDeleteManifests=CounterResult{unit=COUNT, value=0}, 
        indexedDeleteFiles=CounterResult{unit=COUNT, value=2}, 
        equalityDeleteFiles=CounterResult{unit=COUNT, value=1}, 
        positionalDeleteFiles=CounterResult{unit=COUNT, value=1}}, 
    metadata={
        iceberg-version=Apache Iceberg 1.4.0-SNAPSHOT (commit 4868d2823004c8c256a50ea7c25cff94314cc135)}}

INFO org.apache.iceberg.metrics.LoggingMetricsReporter - Received metrics report: 
CommitReport{
    tableName=scan-planning-with-eq-and-pos-delete-files, 
    snapshotId=1, 
    sequenceNumber=1, 
    operation=append, 
    commitMetrics=CommitMetricsResult{
        totalDuration=TimerResult{timeUnit=NANOSECONDS, totalDuration=PT0.098429626S, count=1}, 
        attempts=CounterResult{unit=COUNT, value=1}, 
        addedDataFiles=CounterResult{unit=COUNT, value=1}, 
        removedDataFiles=null, 
        totalDataFiles=CounterResult{unit=COUNT, value=1}, 
        addedDeleteFiles=null, 
        addedEqualityDeleteFiles=null, 
        addedPositionalDeleteFiles=null, 
        removedDeleteFiles=null, 
        removedEqualityDeleteFiles=null, 
        removedPositionalDeleteFiles=null, 
        totalDeleteFiles=CounterResult{unit=COUNT, value=0}, 
        addedRecords=CounterResult{unit=COUNT, value=1}, 
        removedRecords=null, 
        totalRecords=CounterResult{unit=COUNT, value=1}, 
        addedFilesSizeInBytes=CounterResult{unit=BYTES, value=10}, 
        removedFilesSizeInBytes=null, 
        totalFilesSizeInBytes=CounterResult{unit=BYTES, value=10}, 
        addedPositionalDeletes=null, 
        removedPositionalDeletes=null, 
        totalPositionalDeletes=CounterResult{unit=COUNT, value=0}, 
        addedEqualityDeletes=null, 
        removedEqualityDeletes=null, 
        totalEqualityDeletes=CounterResult{unit=COUNT, value=0}}, 
    metadata={
        iceberg-version=Apache Iceberg 1.4.0-SNAPSHOT (commit 4868d2823004c8c256a50ea7c25cff94314cc135)}}

RESTMetricsReporter

当使用 RESTCatalog 时，这是默认配置，其目的是将指标发送到 REST 服务器，在 /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics 端点，如 REST OpenAPI 规范中所定义。

通过 REST 发送指标可以通过 rest-metrics-reporting-enabled（默认为 true）属性进行控制。

Implementing a custom Metrics Reporter

实现 MetricsReporter API 在处理传入的 MetricsReport 实例时提供了完全的灵活性。例如，可以将结果发送到 Prometheus 端点或任何其他可观测性框架/系统。

下面是一个简短的示例，说明了一个 InMemoryMetricsReporter，它将报告存储在一个列表中并使其可用：

public class InMemoryMetricsReporter implements MetricsReporter {

  private List<MetricsReport> metricsReports = Lists.newArrayList();

  @Override
  public void report(MetricsReport report) {
    metricsReports.add(report);
  }

  public List<MetricsReport> reports() {
    return metricsReports;
  }
}

Registering a custom Metrics Reporter

Via Catalog Configuration

目录属性 metrics-reporter-impl 通过指定其完全限定类名来允许注册一个指定的 MetricsReporter，例如 metrics-reporter-impl=org.apache.iceberg.metrics.InMemoryMetricsReporter。

Via the Java API during Scan planning

即使已经通过 metrics-reporter-impl 属性在目录级别注册了 MetricsReporter，也可以在扫描规划期间提供额外的报告器，如下所示：

TableScan tableScan = 
    table
        .newScan()
        .metricsReporter(customReporterOne)
        .metricsReporter(customReporterTwo);

try (CloseableIterable<FileScanTask> fileScanTasks = tableScan.planFiles()) {
  // ...
}

Partitioning（分区）

什么是分区

分区是一种通过在写入时将相似的行分组在一起来加速查询的方法。

例如，从日志表查询日志条目通常会包含一个时间范围，就像这个查询在上午10点到12点之间的日志：

SELECT level, message FROM logs
WHERE event_time BETWEEN '2018-12-01 10:00:00' AND '2018-12-01 12:00:00';

将日志表配置为按 event_time 的日期进行分区，将把具有相同事件日期的日志事件分组到同一个文件中。Iceberg 跟踪那个日期，并将使用它来跳过其他没有有用数据的日期的文件。

Iceberg 可以按年、月、日和小时的粒度来分区时间戳。它还可以使用分类列，比如在这个日志示例中的 level，将行存储在一起以加速查询。

iceberg做了什么不一样的地方

其他表格格式如 Hive 支持分区，但 Iceberg 支持隐藏分区。

1. Iceberg 处理了表中行生成分区值的繁琐且容易出错的任务。
2. Iceberg 自动避免读取不必要的分区。使用者无需知晓表是如何分区的，也无需在他们的查询中添加额外的过滤器。
3. Iceberg 的分区布局可以根据需要进行演变。

HIVE中的分区

为了演示差异，考虑一下 Hive 将如何处理日志表。

在 Hive 中，分区是显式的并且表现为一个列，所以日志表会有一个名为 event_date 的列。在写入时，插入操作需要为 event_date 列提供数据：

INSERT INTO logs PARTITION (event_date)
  SELECT level, message, event_time, format_time(event_time, 'YYYY-MM-dd')
  FROM unstructured_log_source;

同样，搜索日志表的查询除了需要一个 event_time 过滤器外，还必须有一个 event_date 过滤器。

SELECT level, count(1) as count FROM logs
WHERE event_time BETWEEN '2018-12-01 10:00:00' AND '2018-12-01 12:00:00'
  AND event_date = '2018-12-01';

如果缺少 event_date 过滤器，Hive 会扫描表中的每一个文件，因为它不知道 event_time 列与 event_date 列之间的关系。

Hive分区方式的问题

Hive 必须被给定分区值。在日志示例中，它不知道 event_time 和 event_date 之间的关系。

这导致了几个问题：

1. Hive 不能验证分区值 —— 正确值的产生取决于写入者
2. 使用错误的格式，例如使用 2018-12-01 而不是 20181201，会导致悄无声息的错误结果，而不是查询失败
3. 使用错误的源列，如 processing_time，或者错误的时区，也会导致错误的结果，而不是失败
4. 用户需要正确编写查询
5. 使用错误的格式也会导致悄无声息的错误结果
6. 不理解表的物理布局的用户会遇到不必要的慢查询 —— Hive 不能自动转换过滤器
7. 正常工作的查询与表的分区方案绑定，因此分区配置不能在不破坏查询的情况下更改

Iceberg的隐藏分区

Iceberg 通过获取列值并可选择对其进行转换来产生分区值。Iceberg 负责将 event_time 转换为 event_date，并跟踪这种关系。

表的分区是使用这些关系来配置的。日志表将按照 date(event_time) 和 level 来进行分区。

因为 Iceberg 不要求用户维护分区列，所以它可以隐藏分区。分区值每次都能正确产生，并且总是在可能的情况下用于加速查询。生产者和消费者甚至可能看不到 event_date。

最重要的是，查询不再依赖于表的物理布局。有了物理和逻辑之间的分离，Iceberg 表可以随着数据量的变化，随时间演进其分区方案。配置错误的表可以在不进行昂贵迁移的情况下修复。

有关所有支持的隐藏分区转换的详细信息，请参阅分区转换部分。

有关更新表的分区规范的详细信息，请参阅分区演化部分。