CN114968936B - 一种基于数据湖的时间线获取方法、装置、执行节点 - Google Patents

Abstract

本申请公开了一种基于数据湖的时间线获取方法、装置、执行节点、电子设备、计算机可读介质、计算机程序产品，该方法包括：在该执行节点确定达到时间线拉取条件时，先由该执行节点创建第一元数据客户端，并在该第一元数据客户端中创建时间线视图；再由该执行节点利用该时间线视图从管理节点的内置元数据服务中获取待使用时间线，以使该待使用时间线能够表示出该管理节点中的至少一个事务，以便后续该执行节点能够从该待使用时间线中获知需要由其执行的事务，如此能够实现借助该执行节点辅助该管理节点实现写入任务的目的，从而能够有效地提高借助该执行节点辅助管理节点所实现的写入任务的执行效果。

Description

一种基于数据湖的时间线获取方法、装置、执行节点

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于数据湖的时间线获取方法、装置、执行节点、电子设备、计算机可读介质、计算机程序产品。

背景技术

数据湖(DataLake)是指使用大型二进制对象或者文件格式存储数据的系统；而且数据湖被用于统一存储数据。

数据湖框架(Apache Hudi，简称Hudi)是一个流式数据湖平台；而且Hudi可以通过多种工具(例如，Spark、Flink等)接入大量数据(例如，关系型数据库、日志、消息队列的数据等)进行数据存储。

然而，因一些Hudi方案(例如，基于Flink的hudi等)存在缺陷，导致利用这些Hudi方案实现的写入任务的执行效果比较差。

发明内容

为了解决上述技术问题，本申请提供了一种基于数据湖的时间线获取方法、装置、执行节点、电子设备、计算机可读介质、计算机程序产品，能够有效地提高写入任务的执行效果。

为了实现上述目的，本申请实施例提供的技术方案如下：

本申请实施例提供一种基于数据湖的时间线获取方法，应用于基于数据湖的执行节点，所述方法包括：

在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

在一种可能的实施方式中，所述至少一个事务包括至少一个处于未完成状态的事务。

在一种可能的实施方式中，所述内置元数据服务用于存储所述管理节点中实时的时间线。

在一种可能的实施方式中，所述待使用时间线的更新过程，包括：

在达到时间线更新条件时，所述管理节点创建第二元数据客户端；

所述管理节点利用所述第二元数据客户端从元数据系统中拉取元数据时间线；

所述管理节点利用所述元数据时间线，更新所述内置元数据服务中存储的所述待使用时间线。

在一种可能的实施方式中，所述方法还包括：

在所述待使用时间线表示待处理事务已创建时，执行所述待处理事务。

本申请实施例还提供了一种基于数据湖的时间线获取装置，包括：

创建单元，用于在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

获取单元，用于利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

本申请实施例还提供了一种基于数据湖的执行节点，所述执行节点，用于在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

所述执行节点，还用于利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

本申请实施例还提供了一种电子设备，所述设备包括：处理器和存储器；

所述存储器，用于存储指令或计算机程序；

所述处理器，用于执行所述存储器中的所述指令或计算机程序，以使得所述电子设备执行本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式。

本申请实施例还提供了一种计算机可读介质，所述计算机可读介质中存储有指令或计算机程序，当所述指令或计算机程序在设备上运行时，使得所述设备执行本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品在终端设备上运行时，使得所述终端设备执行本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式。

与现有技术相比，本申请实施例至少具有以下优点：

本申请实施例提供的技术方案中，对于基于数据湖的执行节点(例如，Flink)来说，在该执行节点确定达到时间线拉取条件时，先由该执行节点创建第一元数据客户端，并在该第一元数据客户端中创建时间线视图；再由该执行节点利用该时间线视图从管理节点的内置元数据服务中获取待使用时间线，以使该待使用时间线能够表示出该管理节点中的至少一个事务(例如，至少一个处于未完成状态的事务等)，以便后续该执行节点能够从该待使用时间线中获知需要由其执行的事务，如此能够实现借助该执行节点辅助该管理节点实现写入任务的目的。

其中，因管理节点的内置元数据服务能够通过时间线视图直接向基于数据湖的执行节点提供时间线，使得该执行节点可以直接从管理节点的内置元数据服务中获取时间线，从而使得该执行节点无需向元数据系统请求时间线，如此能够有效地避免在由该执行节点直接向元数据系统请求时间线时所导致的不良影响(例如，元数据系统出现服务不稳定问题、任务并发量比较小等)，从而能够有效地提高借助该执行节点辅助管理节点所实现的写入任务的执行效果。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的一种基于Spark的事务提交过程的示意图；

图2为本申请实施例提供的一种基于Flink的事务提交过程的示意图；

图3为本申请实施例提供的一种时间线获取过程的示意图；

图4为本申请实施例提供的另一种时间线获取过程的示意图；

图5为本申请实施例提供的一种基于数据湖的时间线获取方法的流程图；

图6为本申请实施例提供的两种时间线获取流程的对比图；

图7为本申请实施例提供的一种基于数据湖的时间线获取装置的结构示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为了便于理解本申请实施例提供的技术方案，下面先介绍一些技术名词。

数据湖是原始数据层，可以存放各种结构化、半结构化、甚至非结构化的数据。

Hudi用于通过分布式文件系统(Hadoop Distributed File System，HDFS)或者云存储等来摄取和/或管理大型分析型数据集；而且Hudi可以被用于构建数据湖。

另外，在Hudi中，将随着时间流逝针对表的一系列增查改删(Create RetrieveUpdate Delete，CRUD)操作称为时间线(Timeline)；并将Timeline中某一次操作称为事务(instant)。

此外，Hudi的文件系统服务(File System)至少包括元数据(metadata)系统。其中，元数据用于以时间线(timeline)的形式将数据集上的各项操作元数据维护起来，以支持数据集的瞬态视图，。

时间线(Timeline)，用于维护在不同时间点对数据湖表的全部操作。

Hoodie Table是指数据表的抽象，而且Hoodie Table用于定义写hudi表依赖的组件及对表操作接口。另外，用户可以通过Hoodie Table中的文件系统视图(File SystemView)来访问内嵌时间线服务(Embedded Timeline Service)；而且构建File System View所需使用的时间线通常需要通过元数据客户端访问元数据系统获取。

Spark是一种专为大规模数据处理而设计的快速通用的计算引擎。

Flink是一种基于开源流处理框架的计算引擎；而且Flink以数据并行和流水线方式执行任意流数据程序。另外，Flink的流水线运行时系统可以执行批处理和流处理程序。此外，Flink的运行时本身也支持迭代算法的执行。

基于上述技术内容的相关内容，下面介绍本申请技术方案。

发明人在针对Hudi的研究中发现，因Hudi本身设计之初就是基于Spark微批的模型，使得基于Spark的Hudi的事务提交是基于两阶段提交(如图1所示的事务提交过程)来完成的，对于每一批数据来说，先由管理节点生成每个事务；再由管理节点将每个事务的信息分发给各个任务执行者(也就是，Spark引擎)，以便在确定各个任务执行者均完成提交后，该管理节点去完成事务提交，才会再消费下一批数据。其中，管理节点用于针对Hudi中大量写入任务进行管理(例如，创建事务、记录事务的执行状态信息等)。

发明人还发现，在一些情况下，可以利用Flink引擎辅助Hudi进行事务提交(如图2所示的事务提交过程)，以实现借助Flink引擎完成Hudi中的写入任务。其中，因Flink是一个纯流式的模型，使得利用Flink处理的数据流实际上会被检查点(check point)切分成微批，从而使得微批数据的提交是异步的；但是，对于同一个写入Hudi的Flink任务来说，该任务所涉及的大量事务是有严格的先后顺序，只有当上一次检查点全部完成之后，才会新建下一个事务。可见，对于每一个提前完成任务的任务执行者(也就是，Flink引擎)来说，该任务执行者会不断地轮询管理节点中的时间线以获取一些事务信息(例如，上一次事务的完成情况、或者开启的新事务等)。

发明人还发现，基于Flink的事务提交过程(如图2所示的事务提交过程)不同于基于Spark的事务提交过程(如图1所示的事务提交过程)，而且两者之间的区别至少包括①-②所示的内容：

①从管理节点中获取事务的方式不同。因Spark引擎是利用由管理节点向其发送的事务信息来获取事务的，但是Flink引擎则是利用从管理节点中拉取的timeline来获取事务的。

②事务提交方式不同。因Spark引擎是基于两阶段提交来完成事务提交的，但是Flink引擎则是直接向管理节点中进行事务提交的。

发明人还发现，由于Hudi是基于Spark设计的，使得在利用Flink引擎辅助Hudi进行事务提交的场景下存在以下(1)-(2)所示的问题：

(1)因构建File System View所需要的timeline只能通过元数据客户端访问元数据系统的方式获取，使得在利用Flink引擎每次创建HoodieTable时都需要请求一次元数据系统，从而使得在大量并发任务场景下需要频繁地请求元数据系统，进而造成元数据系统的服务负载过高，如此会导致元数据系统出现的服务不稳定的问题。

(2)因元数据系统能够响应的请求数量有限，如此导致基于Flink引擎调整所得的Hudi可以支撑的任务并发数比较小。

发明人还发现，Hudi本身存在一个能够实现时间线存储功能的对象，也就是，内嵌时间线服务(Embedded Timeline Service)；但是，由于Hudi是基于Spark所设计的，而且Spark不需要在任务(task)粒度上轮询timeline，如此导致Embedded Timeline Service这一对象通常只用于缓存已完成事务，不会缓存正在进行中的事务，从而导致EmbeddedTimeline Service无法向Flink引擎提供未完成事务(例如，刚开启的事务或者正在执行的事务)的相关信息。另外，如图3所示，因Embedded Timeline Service的访问入口在FileSystem View中，使得当Flink引擎每次想要从Embedded Timeline Service中获取timeline时，该Flink引擎均需要先获取File System View的所有内容，再从File SystemView中通过访问Embedded Timeline Service的方式获取timeline。可见，Flink引擎无法通过元数据客户端直接访问Embedded Timeline Service，使得在Flink引擎每次想要从Embedded Timeline Service中获取timeline时，不仅需要获取Embedded TimelineService，还需要获取File System View中除了Embedded Timeline Service以外的其他多余内容，如此导致资源浪费。

基于上述发现，为了解决背景技术部分所示的技术问题，本申请实施例提供了一种适用于Flink的基于数据湖的时间线获取方法，以使Flink引擎能够借助新增的时间线视图(Timeline View)直接从内置元数据服务(如图4所示)中获取管理节点中实时的时间线。其中，内置元数据服务是基于上述Embedded Timeline Service进行改进的，而且该改进点具体为：该内置元数据服务中所存储的时间线与管理节点中实际的时间线一直保持同步。

另外，本申请实施例提供的适用于Flink的基于数据湖的时间线获取方法，具体可以包括：在基于数据湖的执行节点(例如，Flink引擎)确定达到时间线拉取条件时，先由该执行节点创建第一元数据客户端(如图4所示的元数据客户端)，并在该第一元数据客户端中创建时间线视图(如图4所示的时间线视图)；再由该执行节点利用该时间线视图从管理节点的内置元数据服务(如图4所示的内置元数据服务)中获取待使用时间线，以使该待使用时间线能够表示出该管理节点中实际的时间线，从而使得该待使用时间线能够表示出该管理节点中的至少一个事务(例如，至少一个处于未完成状态的事务等)，以便后续该执行节点能够从该待使用时间线中获知需要由其执行的事务，如此能够实现借助该执行节点辅助该管理节点实现写入任务的目的。

其中，因管理节点的内置元数据服务能够通过时间线视图直接向基于数据湖的执行节点提供时间线，使得该执行节点可以直接从管理节点的内置元数据服务中获取时间线，从而使得该执行节点无需向元数据系统请求时间线，如此能够有效地克服在由该执行节点直接向元数据系统请求时间线时所导致的不良影响(例如，元数据系统出现服务不稳定问题、任务并发量比较小等)，从而能够有效地提高借助该执行节点辅助管理节点所实现的写入任务的执行效果。

需要说明的是，对于图4来说，写入客户端(write function)是指Flink引擎中的一个对象，以使该写入客户端用于执行向Hudi中写入数据的相关事务。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了更好地理解本申请实施例提供的技术方案，下面结合图4-6对本申请实施例提供的基于数据湖的时间线获取方法进行详细说明。其中，图4为本申请实施例提供的另一种时间线获取过程的示意图；图5为本申请实施例提供的一种基于数据湖的时间线获取方法的流程图；图6为本申请实施例提供的两种时间线获取流程的对比图。

如图5所示，本申请实施例提供的基于数据湖的时间线获取方法，包括S1-S2：

S1：在达到时间线拉取条件时，基于数据湖的执行节点创建第一元数据客户端，并在该第一元数据客户端中创建时间线视图。

其中，时间线拉取条件是指在基于数据湖的执行节点需要拉取管理节点中时间线的触发条件；而且本申请实施例不限定该时间线拉取条件，例如，其可以为现有的或者未来出现的任意一种能够触发由该执行节点从管理节点中拉取时间线的条件进行实施。又如，当该执行节点每间隔预设时长拉取一次管理节点中时间线时，该时间线拉取条件具体可以为：当前时间与上一次拉取管理节点中时间线的触发时间点之间的时长达到预设时长。其中，预设时长可以预先设定，例如，预设时长为10秒。

基于数据湖的执行节点用于执行Hudi中写入任务的设备；而且本申请实施例不限定该执行节点，例如，其具体可以为任意一种能够针对流式数据进行处理的设备(例如，Flink引擎等)进行实施。

第一元数据客户端是指在基于数据湖的执行节点侧创建的元数据客户端(metaclient)；而且该第一元数据客户端可以借助在其内创建的时间线视图这一对象，直接访问管理节点中的内置元数据服务。

时间线视图是指一个在第一元数据客户端内创建的用于从管理节点中获取时间线的对象；而且该时间线视图能够直接访问管理节点中的内置元数据服务。

内置元数据服务是指管理节点中改进后的Embedded Timeline Service(如图6所示的内置元数据服务)；而且该内置元数据服务中所存储的时间线能够与管理节点中实际的时间线保持同步，以使该内置元数据服务能够存储该管理节点中实时的时间线。

可见，对于内置元数据服务来说，因内置元数据服务能够存储该管理节点中实时的时间线，以使该内置元数据服务不仅能够存储已完成的事务，还能够存储未完成的事务(例如，刚创建的事务、以及处于执行状态下的事务)，从而使得该内置元数据服务能够代替元数据系统处理时间线请求(例如，该内置元数据服务能够代替元数据系统响应那些用于辅助Hudi执行事务的所有执行节点的时间线相关请求)，进而使得元数据系统只需处理该内置元数据服务的时间线请求即可，如此不仅能够有效地减少元数据系统的服务负载，还能够有效地解决因元数据系统能够响应的请求数量有限而导致的任务并发数比较小的问题，进而能够有效地提高可以支撑的任务并发数(例如，实测可以从2000写入任务以内的并发写入提升至8万写入任务以内的并发写入等)。

基于上述S1的相关内容可知，对于基于数据湖的执行节点(例如，Flink等)来说，该执行节点可以通过不断轮询管理节点中时间线的方式获知一些事务信息(例如，是否创建了需要由该执行节点执行的事务，一些事务的执行状态信息等)。基于此可知，在该执行节点确定达到时间线拉取条件时，该执行节点可以确定其具有从管理节点中获取时间线的需求，故该执行节点可以创建第一元数据客户端(如图6所示的基于数据湖的执行节点侧的元数据客户端)，并在该第一元数据客户端中创建时间线视图，以便后续该执行节点能够借助该第一元数据客户端中的时间线视图从管理节点中获取时间线。

S2：基于数据湖的执行节点利用时间线视图从管理节点的内置元数据服务中获取待使用时间线。

其中，待使用时间线是指内置元数据服务中已存储的时间线；而且该待使用时间线用于记录管理节点中至少一个事务(例如，至少一个处于完成状态的事务，和/或，至少一个处于未完成状态的事务)。

另外，因内置元数据服务中所存储的时间线能够与管理节点中实际的时间线保持同步，使得该内置元数据服务用于存储该管理节点中实时的时间线，从而使得该内置元数据服务中所存储的待使用时间线就是该管理节点中实时的时间线，进而使得该待使用时间线能够更准确地表示出该管理节点中所有事务及其所有事务的相关信息(例如，事务描述信息、执行状态信息等)。

此外，为了能够保证待使用时间线与管理节点中实际的时间线保持同步，本申请实施例还提供了更新待使用时间线的一种可能的实施方式，其具体可以包括步骤11-步骤13：

步骤11：在达到时间线更新条件时，管理节点创建第二元数据客户端。

其中，时间线更新条件是指需要对内置元数据服务中所存储的时间线进行更新时所达到的条件；而且本申请实施例不限定时间线更新条件，例如，其具体可以为：管理节点中实际的时间线发生变化(例如，修改了某个已有事务的执行状态、创建了一个新的事务等)。

实际上，在一些情况下，对于管理节点来说，在该管理节点确定管理节点中实际的时间线发生变化时，该管理节点可以自动触发时间线更新请求，以使该管理节点的内置元数据服务中所存储的待使用时间线自动进行更新，以保证该待使用时间线能够与管理节点中实际的时间线保持同步。其中，时间线更新请求用于请求将管理节点中实际的时间线同步于该管理节点的内置元数据服务中所存储的待使用时间线。需要说明的是，本申请实施例不限定该时间线更新请求，例如，其可以为Embedded Timeline Service#sync这一指令。

基于上一段落所示的情况可知，在一种可能的实施方式下，时间线更新条件具体可以为：触发了时间线更新请求。

第二元数据客户端是指管理节点侧的元数据客户端；而且该第二元数据客户端能够直接从该管理节点的元数据系统中拉取timeline。

步骤12：管理节点利用第二元数据客户端从元数据系统中拉取元数据时间线。其中，元数据时间线是指管理节点中实际的时间线。

步骤13：管理节点利用元数据时间线，更新内置元数据服务中存储的待使用时间线。

需要说明的是，本申请实施例不限定步骤13的实施方式，例如，其具体可以为：直接利用元数据时间线替换内置元数据服务中已存储的待使用时间线，得到更新后的待使用时间线。又如，步骤13具体可以为：按照元数据时间线与待使用时间线之间的差异表征数据，对内置元数据服务中存储的待使用时间线进行调整，得到更新后的待使用时间线，以使更新后的待使用时间线与该元数据时间线保持一致。

基于步骤11至步骤13的相关内容可知，对于管理节点来说，在该管理节点确定达到时间线更新条件时，该管理节点可以确定出需要针对内置元数据服务中已存储的待使用时间线进行更新处理，故该管理节点可以先创建第二元数据客户端，再借助该第二元数据客户端从元数据系统中拉取到元数据时间线，以使该元数据时间线能够表示出该元数据系统在当前时刻下所存储的时间线，最后，由该管理节点利用该元数据时间线，更新该内置元数据服务中存储的待使用时间线，以使更新后的待使用时间线能够与管理节点中实际的时间线保持同步，以便后续该内置元数据服务能够更好地代替元数据系统向各个基于数据湖的执行节点反馈该管理节点中实时的时间线。

基于上述S2的相关内容可知，对于基于数据湖的执行节点来说，当该执行节点在第一元数据客户端中创建好时间线视图之后，该执行节点可以借助该时间线视图直接访问管理节点的内置元数据服务，以使该时间线视图能够直接从该内置元数据服务中获取待使用时间线(如图6所示的“获取时间线”)，以使该待使用时间线能够表示出该管理节点中一些事务(例如，一些未完成事务、一些已完成事务等)以及这些事务的相关信息，以便后续该执行节点能够从该待使用时间线中获知这些事务的相关信息。

基于上述S1至S2的相关内容可知，对于本申请实施例提供的基于数据湖的时间线获取方法来说，在基于数据湖的执行节点(例如，Flink引擎)确定达到时间线拉取条件时，先由该执行节点创建第一元数据客户端(如图4所示的元数据客户端)，并在该第一元数据客户端中创建时间线视图(如图4所示的时间线视图)；再由该执行节点利用该时间线视图从管理节点的内置元数据服务(如图4所示的内置元数据服务)中获取待使用时间线，以使该待使用时间线能够表示出该管理节点中实际的时间线，从而使得该待使用时间线能够表示出该管理节点中的至少一个事务(例如，至少一个处于未完成状态的事务等)，以便后续该执行节点能够从该待使用时间线中获知需要由其执行的事务，如此能够实现借助该执行节点辅助该管理节点实现写入任务的目的。

其中，因管理节点的内置元数据服务能够通过时间线视图直接向基于数据湖的执行节点提供时间线，使得该执行节点可以直接从管理节点的内置元数据服务中获取时间线，从而使得该执行节点无需向元数据系统请求时间线，如此能够有效地克服在由该执行节点直接向元数据系统请求时间线时所导致的不良影响(例如，元数据系统出现服务不稳定问题、任务并发量比较小等)，从而能够有效地提高借助该执行节点辅助管理节点所实现的写入任务的执行效果。

实际上，在基于数据湖的执行节点从管理节点中获取到时间线之后，该执行节点还会从该时间线中分析出需要由该执行节点完成的事务。基于此，本申请实施例还提供了基于数据湖的时间线获取方法的一种可能的实施方式，在该实施方式中，该时间线获取方法不仅可以包括上文S1-S2，可以还包括S3：

S3：在待使用时间线表示待处理事务已创建时，基于数据湖的执行节点执行待处理事务。

其中，待处理事务是指由管理节点创建的需要由基于数据湖的执行节点辅助执行的事务。例如，如果基于数据湖的执行节点为Flink，则待处理事务可以是指由管理节点创建的需要由Flink辅助执行的事务。

基于上述S3的相关内容可知，对于基于数据湖的执行节点来说，在该执行节点从管理节点中获取到时间线之后，如果该待使用时间线表示待处理事务已创建，则该执行节点可以确定出需要由其执行该待处理事务，故该执行节点可以执行该待处理事务，如此能够实现由该执行节点辅助管理节点实现针对某个数据表的写入任务。

基于上述基于数据湖的时间线获取方法，本申请实施例还提供了一种基于数据湖的时间线获取装置，下面结合图7进行解释和说明。其中，图7为本申请实施例提供的一种基于数据湖的时间线获取装置的结构示意图。另外，该时间线获取装置的技术详情，请参照上述基于数据湖的时间线获取方法的相关内容。

如图7所示，本申请实施例提供的基于数据湖的时间线获取装置700，包括：

创建单元701，用于在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

获取单元702，用于利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

在一种可能的实施方式下，所述至少一个事务包括至少一个处于未完成状态的事务。

在一种可能的实施方式下，所述内置元数据服务用于存储所述管理节点中实时的时间线。

在一种可能的实施方式下，所述待使用时间线的更新过程，包括：

在达到时间线更新条件时，所述管理节点创建第二元数据客户端；

所述管理节点利用所述第二元数据客户端从元数据系统中拉取元数据时间线；

所述管理节点利用所述元数据时间线，更新所述内置元数据服务中存储的所述待使用时间线。

在一种可能的实施方式下，所述基于数据湖的时间线获取装置700还包括：

执行单元，用于在所述待使用时间线表示待处理事务已创建时，执行所述待处理事务。

基于上述基于数据湖的时间线获取装置700的相关内容可知，对于本申请实施例提供的基于数据湖的时间线获取装置700来说，在确定达到时间线拉取条件时，先创建第一元数据客户端，并在该第一元数据客户端中创建时间线视图；再利用该时间线视图从管理节点的内置元数据服务中获取待使用时间线，以使该待使用时间线能够表示出该管理节点中的至少一个事务(例如，至少一个处于未完成状态的事务等)，以便后续该时间线获取装置700能够从该待使用时间线中获知需要由其执行的事务，如此能够实现借助该时间线获取装置700辅助该管理节点实现写入任务的目的。

其中，因管理节点的内置元数据服务能够通过时间线视图直接向基于数据湖的时间线获取装置700提供时间线，使得该时间线获取装置700可以直接从管理节点的内置元数据服务中获取时间线，从而使得该时间线获取装置700无需向元数据系统请求时间线，如此能够有效地避免在由该时间线获取装置700直接向元数据系统请求时间线时所导致的不良影响(例如，元数据系统出现服务不稳定问题、任务并发量比较小等)，从而能够有效地提高借助该时间线获取装置700辅助管理节点所实现的写入任务的执行效果。

基于上述基于数据湖的时间线获取方法，本申请实施例还提供了一种基于数据湖的执行节点，该执行节点能够辅助管理节点实现写入任务。

另外，基于数据湖的执行节点需要通过不断轮询管理节点中时间线的方式来获知该管理节点中的一些事务信息。

此外，基于数据湖的执行节点可以利用本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式，实现从管理节点中获取时间线的目的。为了便于理解，下面结合执行节点的一些可能的实施方式进行说明。

在一种可能的实施方式中，基于数据湖的执行节点，用于在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

所述执行节点，还用于利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

在一种可能的实施方式中，所述至少一个事务包括至少一个处于未完成状态的事务。

在一种可能的实施方式中，所述内置元数据服务用于存储所述管理节点中实时的时间线。

在一种可能的实施方式中，所述待使用时间线的更新过程，包括：

在达到时间线更新条件时，所述管理节点创建第二元数据客户端；

所述管理节点利用所述第二元数据客户端从元数据系统中拉取元数据时间线；

所述管理节点利用所述元数据时间线，更新所述内置元数据服务中存储的所述待使用时间线。

在一种可能的实施方式中，所述执行节点，还用于在所述待使用时间线表示待处理事务已创建时，执行所述待处理事务。

在一种可能的实施方式中，所述执行节点为Flink引擎。

基于上述执行节点的相关内容可知，对于本申请实施例提供的基于数据湖的执行节点来说，在该执行节点确定达到时间线拉取条件时，先由该执行节点创建第一元数据客户端，并在该第一元数据客户端中创建时间线视图；再由该执行节点利用该时间线视图从管理节点的内置元数据服务中获取待使用时间线，以使该待使用时间线能够表示出该管理节点中的至少一个事务(例如，至少一个处于未完成状态的事务等)，以便后续该执行节点能够从该待使用时间线中获知需要由其执行的事务，如此能够实现借助该执行节点辅助该管理节点实现写入任务的目的。

其中，因管理节点的内置元数据服务能够通过时间线视图直接向基于数据湖的执行节点提供时间线，使得该执行节点可以直接从管理节点的内置元数据服务中获取时间线，从而使得该执行节点无需向元数据系统请求时间线，如此能够有效地避免在由该执行节点直接向元数据系统请求时间线时所导致的不良影响(例如，元数据系统出现服务不稳定问题、任务并发量比较小等)，从而能够有效地提高借助该执行节点辅助管理节点所实现的写入任务的执行效果。

另外，本申请实施例还提供了一种电子设备，所述设备包括处理器以及存储器：所述存储器，用于存储指令或计算机程序；所述处理器，用于执行所述存储器中的所述指令或计算机程序，以使得所述电子设备执行本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式。

参见图8，其示出了适于用来实现本公开实施例的电子设备800的结构示意图。本公开实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图8示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图8所示，电子设备800可以包括处理装置(例如中央处理器、图形处理器等)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储装置808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM803中，还存储有电子设备800操作所需的各种程序和数据。处理装置801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

通常，以下装置可以连接至I/O接口805：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置806；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置807；包括例如磁带、硬盘等的存储装置808；以及通信装置809。通信装置809可以允许电子设备800与其他设备进行无线或有线通信以交换数据。虽然图8示出了具有各种装置的电子设备800，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置809从网络上被下载和安装，或者从存储装置808被安装，或者从ROM802被安装。在该计算机程序被处理装置801执行时，执行本公开实施例的方法中限定的上述功能。

本公开实施例提供的电子设备与上述实施例提供的方法属于同一发明构思，未在本实施例中详尽描述的技术细节可参见上述实施例，并且本实施例与上述实施例具有相同的有益效果。

本申请实施例还提供了一种计算机可读介质，所述计算机可读介质中存储有指令或计算机程序，当所述指令或计算机程序在设备上运行时，使得所述设备执行本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

在一些实施方式中，客户端、服务器可以利用诸如HTTP(Hyper Text TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备可以执行上述方法。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元/模块的名称在某种情况下并不构成对该单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品在终端设备上运行时，使得所述终端设备执行本申请实施例提供的基于数据湖的时间线获取方法的任一实施方式。

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种基于数据湖的时间线获取方法，其特征在于，应用于基于数据湖的执行节点，所述方法包括：

在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

2.根据权利要求1所述的方法，其特征在于，所述至少一个事务包括至少一个处于未完成状态的事务。

3.根据权利要求1所述的方法，其特征在于，所述内置元数据服务用于存储所述管理节点中实时的时间线。

4.根据权利要求1所述的方法，其特征在于，所述待使用时间线的更新过程，包括：

在达到时间线更新条件时，所述管理节点创建第二元数据客户端；

所述管理节点利用所述第二元数据客户端从元数据系统中拉取元数据时间线；

所述管理节点利用所述元数据时间线，更新所述内置元数据服务中存储的所述待使用时间线。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述待使用时间线表示待处理事务已创建时，执行所述待处理事务。

6.一种基于数据湖的时间线获取装置，其特征在于，包括：

创建单元，用于在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

获取单元，用于利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

7.一种基于数据湖的执行节点，其特征在于，所述执行节点，用于在达到时间线拉取条件时，创建第一元数据客户端，并在所述第一元数据客户端中创建时间线视图；

所述执行节点，还用于利用所述时间线视图从管理节点的内置元数据服务中获取待使用时间线；其中，所述内置元数据服务中存储有所述待使用时间线；所述待使用时间线用于记录所述管理节点中的至少一个事务。

8.一种电子设备，其特征在于，所述设备包括：处理器和存储器；

所述存储器，用于存储指令或计算机程序；

所述处理器，用于执行所述存储器中的所述指令或计算机程序，以使得所述电子设备执行权利要求1-5任一项所述的方法。

9.一种计算机可读介质，其特征在于，所述计算机可读介质中存储有指令或计算机程序，当所述指令或计算机程序在设备上运行时，使得所述设备执行权利要求1-5任一项所述的方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品在终端设备上运行时，使得所述终端设备执行权利要求1-5任一项所述的方法。