本文主要是介绍【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();@Overridepublic 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 支持隐藏分区。
- Iceberg 处理了表中行生成分区值的繁琐且容易出错的任务。
- Iceberg 自动避免读取不必要的分区。使用者无需知晓表是如何分区的,也无需在他们的查询中添加额外的过滤器。
- 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 之间的关系。
这导致了几个问题:
- Hive 不能验证分区值 —— 正确值的产生取决于写入者
- 使用错误的格式,例如使用 2018-12-01 而不是 20181201,会导致悄无声息的错误结果,而不是查询失败
- 使用错误的源列,如 processing_time,或者错误的时区,也会导致错误的结果,而不是失败
- 用户需要正确编写查询
- 使用错误的格式也会导致悄无声息的错误结果
- 不理解表的物理布局的用户会遇到不必要的慢查询 —— Hive 不能自动转换过滤器
- 正常工作的查询与表的分区方案绑定,因此分区配置不能在不破坏查询的情况下更改
Iceberg的隐藏分区
Iceberg 通过获取列值并可选择对其进行转换来产生分区值。Iceberg 负责将 event_time 转换为 event_date,并跟踪这种关系。
表的分区是使用这些关系来配置的。日志表将按照 date(event_time) 和 level 来进行分区。
因为 Iceberg 不要求用户维护分区列,所以它可以隐藏分区。分区值每次都能正确产生,并且总是在可能的情况下用于加速查询。生产者和消费者甚至可能看不到 event_date。
最重要的是,查询不再依赖于表的物理布局。有了物理和逻辑之间的分离,Iceberg 表可以随着数据量的变化,随时间演进其分区方案。配置错误的表可以在不进行昂贵迁移的情况下修复。
有关所有支持的隐藏分区转换的详细信息,请参阅分区转换部分。
有关更新表的分区规范的详细信息,请参阅分区演化部分。
这篇关于【Iceberg学习三】Reporting和Partitioning原理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!