Apache Hudi Timeline Server介绍

1. 概述

Hudi 有一个中央时间线服务器，在驱动程序节点中运行并作为 Rest 服务。它有多种好处，第一个用例是提供 FileSystemView api。
Hudi 的核心是维护一个 TableFileSystemView，它暴露 API 来获取给定数据集的文件状态，驱动程序和执行程序将在写入和表服务生命周期的不同时间点查询该状态。中央时间线服务器维护一个缓存的 FSView，每个 Spark 任务都可以轮询该 FSView，从而避免每个 Spark 任务自己加载 FSView，这些 API 响应延迟非常低。如果没有这些API，每个执行器或 Spark 任务可能必须自己构建 FSview，这将导致过多的重复工作，从而影响延迟
第二个用例是标记(Marker) 实现。Hudi 维护标记来区分 Spark 任务写入的最终数据文件集与由于 Spark 重试而创建的文件。第一个实现是直接标记，实现简单，但在非常大的范围内，我们发现删除标记花费了太多时间。因此我们引入了基于时间线服务器的标记来解决延迟问题。使用基于时间线服务器的标记，删除延迟仅为几秒钟，而在某些情况下使用直接标记需要 30 多分钟。

2 提供的服务

提供文件系统视图
Hudi 的核心是维护一个 TableFileSystemView，它暴露 API 来获取给定数据集的文件状态，驱动程序和执行程序将在写入和表服务生命周期的不同时间点查询该状态。众所周知的 API 包括：获取所有文件组的最新基本文件、获取给定分区的最新文件切片、获取最新的合并文件切片（在压缩正在进行时有用）、获取最新的挂起压缩操作、获取替换的文件组（Clustering和其他替换提交操作）等。
TableFileSystemview 有不同的实现，例如内存中的 FSView、基于元数据的 FSview、RockDBBased FSView、基于可溢出映射的 FSView 等。最常见的是内存和元数据 TableFileSystemView。内存表文件系统视图使用文件系统列表查询 Hudi 时间线和数据文件，并填充服务这些 api 所需的所有内部数据结构。基于元数据的文件系统视图使用元数据表而不是直接文件系统列表。所有这些 FSview 都有内置缓存，这意味着一旦为给定分区加载文件组，后续调用就可以从内存数据结构本身提供服务，而不会产生额外的 I/O。但是所有填充的数据结构（缓存）都必须在时间线发生新更改时（新提交完成时）重新加载，这不可避免。因此来自中央时间线服务器的缓存 FSView 通过减少延迟为我们提供了相当高的价值。
使用 Timeline Server 控制 FileSystemView 调用的流程
位于中心时间轴服务器在消除实例化 FileSystemView 过程中不必要的延迟方面发挥着至关重要的作用。时间线服务器是一个Rest服务，它在同一节点中运行，并在单独的线程中与驱动程序一起处理。所有 FileSystemView 调用都将由该时间线服务器通过 Rest 调用提供服务。执行器会将 FSview 调用路由到位于中心的时间线服务器并返回结果。由于我们还内置了一个缓存层，因此它们往往非常高效，并且避免了 FSview 的重复实例化以及不必要的 I/O。
基于元数据的 FS 视图
Hudi为每个数据表都有一个元数据表，用于缓存表中的文件列表。如果启用的话，FSview 也可以从元数据表构建。在这种情况下 FS 视图的实例化基于元数据表的 FILES 分区中的数据。这里我们讨论的是时间轴服务器中使用的 FSview 实现。
我们已经确定了一些调用（例如清理器），其中每个分区都将跨所有 Spark 任务加载，因此我们添加了优化以尽可能使用对元数据表的单个调用来预加载所有分区。当表有 1000 个或更多分区时，这会极大地加快 FS 视图调用延迟。
基于时间线服务器的标记
时间线服务器也用作另一个标记实现，在此之前我们有执行器直接操作的直接标记，我们将在其他博客中讨论这个主题。如果感兴趣可以点击此链接讨论基于时间线服务器的标记