使用 Apache Arrow 导出
Neo4j 图数据科学库中的图支持节点和关系的属性。导出这些属性的一种方法是使用 Cypher 过程,如流式传输节点和流式传输关系中所述。与这些过程类似,GDS 也支持通过 Arrow Flight 导出属性。
本章假设已设置并配置 Flight 服务器。要了解有关安装的更多信息,请参阅安装章节。
Arrow 导出功能是版本化的,以允许将来的更改。有关版本化命令的更多详细信息,请参阅配置 Apache Arrow 服务器文档中的相应部分。
Arrow Ticket 格式
Arrow 客户端通过调用 GET
函数并提供 Flight ticket 来启动从内存中图读取属性的 Flight 流。其总体思想是模仿从内存中图流式传输属性的过程的行为。为了识别我们想要模仿的图和过程,ticket 必须包含以下键
名称 | 类型 | 描述 |
---|---|---|
|
字符串 |
图目录中图的名称。 |
|
字符串 |
图关联的数据库。 |
|
字符串 |
镜像的属性流过程。 |
|
映射 |
特定于过程的配置。 |
下图显示了使用节点属性流式传输作为示例进行数据导出的客户端-服务器交互。

流式传输所有节点标签
要流式传输图中每个节点的节点标签,客户端需要提供以下 ticket
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.nodeLabels.stream", configuration: { consecutive_ids: false } } }
特定的命令配置支持以下键
名称 | 类型 | 描述 |
---|---|---|
|
布尔值 |
返回映射到连续 ID 空间的节点 ID,即 |
结果记录的模式如下
名称 | 类型 | 描述 |
---|---|---|
|
nodeId |
整数 |
|
false |
labels |
|
节点的标签。 |
false |
流式传输单个节点属性
要流式传输单个节点属性,客户端需要将该信息编码到 ticket 中,如下所示
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.nodeProperty.stream", configuration: { node_labels: ["*"], node_property: "foo", list_node_labels: true, consecutive_ids: false } } }
procedure_name
表示我们模仿现有过程的行为。特定配置需要包含以下键
名称 | 类型 | 描述 |
---|---|---|
|
字符串或字符串列表 |
仅流式传输具有给定标签的节点的属性。 |
|
字符串 |
图中要流式传输的节点属性。 |
|
布尔值 |
是否在结果中包含相应节点的节点标签。 |
|
布尔值 |
返回映射到连续 ID 空间的节点 ID,即 |
结果记录的模式与相应过程相同
名称 | 类型 | 描述 | 可选 |
---|---|---|---|
nodeId |
整数 |
节点的 ID。 |
false |
propertyValue |
|
存储的属性值。 |
false |
labels |
字符串列表 |
节点的标签。如果设置了 |
true |
流式传输多个节点属性
要流式传输多个节点属性,客户端需要将该信息编码到 ticket 中,如下所示
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.nodeProperties.stream", configuration: { node_labels: ["*"], node_properties: ["foo", "bar", "baz"], list_node_labels: true, consecutive_ids: false } } }
procedure_name
表示我们模仿现有过程的行为。特定配置需要包含以下键
名称 | 类型 | 描述 |
---|---|---|
|
字符串或字符串列表 |
仅流式传输具有给定标签的节点的属性。 |
|
字符串或字符串列表 |
图中要流式传输的节点属性。 |
|
布尔值 |
是否在结果中包含相应节点的节点标签。 |
|
布尔值 |
返回映射到连续 ID 空间的节点 ID,即 |
请注意,结果记录的模式与相应过程不完全相同。每个属性都在自己的列中返回,而不是包含属性键的单独列。因此,每个节点只有一行,其中包含其所有属性值。
例如,给定节点 (a { foo: 42, bar: 1337, baz: [1,3,3,7] })
并假设节点 a
的 ID 为 0
,则结果记录模式如下
nodeId | foo | bar | baz |
---|---|---|---|
0 |
42 |
1337 |
[1,3,3,7] |
流式传输单个关系属性
要流式传输单个关系属性,客户端需要将该信息编码到 ticket 中,如下所示
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.relationshipProperty.stream", configuration: { relationship_types: "REL", relationship_property: "foo", consecutive_ids: false } } }
procedure_name
表示我们模仿现有过程的行为。特定配置需要包含以下键
名称 | 类型 | 描述 |
---|---|---|
|
字符串或字符串列表 |
仅流式传输具有给定类型的关系的属性。 |
|
字符串 |
图中要流式传输的关系属性。 |
|
布尔值 |
返回映射到连续 ID 空间的节点 ID,即 |
结果记录的模式与相应过程相同
名称 | 类型 | 描述 |
---|---|---|
sourceNodeId |
整数 |
关系的源节点 ID。 |
targetNodeId |
整数 |
关系的目标节点 ID。 |
relationshipType |
整数 |
字典编码的关系类型。 |
propertyValue |
浮点数 |
存储的属性值。 |
请注意,关系类型列存储的是编码为整数的关系类型。相应的字符串值需要从相应的字典值向量中检索。该向量可以使用类型字段的编码 ID 从字典提供程序加载。
流式传输多个关系属性
要流式传输多个关系属性,客户端需要将该信息编码到 ticket 中,如下所示
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.relationshipProperties.stream", configuration: { relationship_types: "REL", relationship_property: ["foo", "bar"], consecutive_ids: false } } }
procedure_name
表示我们模仿现有过程的行为。特定配置需要包含以下键
名称 | 类型 | 描述 |
---|---|---|
|
字符串或字符串列表 |
仅流式传输具有给定类型的关系的属性。 |
|
字符串或字符串列表 |
图中要流式传输的关系属性。 |
|
布尔值 |
返回映射到连续 ID 空间的节点 ID,即 |
请注意,结果记录的模式与相应过程不完全相同。每个属性都在自己的列中返回,而不是包含属性键的单独列。因此,每个关系只有一行,其中包含其所有属性值。
例如,给定关系 [:REL { foo: 42.0, bar: 13.37 }]
连接 ID 为 0
的源节点和 ID 为 1
的目标节点,则结果记录模式如下
sourceNodeId | targetNodeId | relationshipType | foo | bar |
---|---|---|---|---|
0 |
1 |
0 |
42.0 |
13.37 |
请注意,关系类型列存储的是编码为整数的关系类型。相应的字符串值需要从相应的字典值向量中检索。该向量可以使用类型字段的编码 ID 从字典提供程序加载。
流式传输关系拓扑
要流式传输一个或多个关系类型的拓扑,客户端需要将该信息编码到 ticket 中,如下所示
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.relationships.stream", configuration: { relationship_types: "REL", consecutive_ids: false } } }
procedure_name
表示我们模仿现有过程的行为。特定配置需要包含以下键
名称 | 类型 | 描述 |
---|---|---|
|
字符串或字符串列表 |
仅流式传输具有给定类型的关系的属性。 |
|
布尔值 |
返回映射到连续 ID 空间的节点 ID,即 |
结果记录的模式与相应过程相同
sourceNodeId | targetNodeId | relationshipType |
---|---|---|
0 |
1 |
0 |
请注意,关系类型列存储的是编码为整数的关系类型。相应的字符串值需要从相应的字典值向量中检索。该向量可以使用类型字段的编码 ID 从字典提供程序加载。
分区数据流
某些用例要求对数据流进行分区。例如,如果数据流由分布式系统消费,则数据流需要均匀地分发到分布式系统的成员。为了支持此用例,客户端可以通过向 GDS Flight Server 的 FlightInfo
端点发送流请求来请求对数据流进行分区。服务器将返回多个端点,每个端点及其附带的 ticket 可用于流式传输数据的一个分区。ticket 的 concurrency
设置可用于控制分区数量。
例如,要流式传输一个或多个关系类型的拓扑,客户端需要将该信息编码到 ticket 中,如下所示
{ name: "GET_COMMAND", version: "v1", body: { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.relationships.stream", concurrency: 2, configuration: { relationship_types: "REL" } } }
这将最多创建 2 个数据流分区。服务器将返回 2 个 ticket
[ { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.relationships.stream", concurrency: 4, partition_offset: 0, partition_size: 100, configuration: { relationship_types: "REL" } }, { graph_name: "my_graph", database_name: "database_name", procedure_name: "gds.graph.relationships.stream", partition_offset: 100, partition_size: 100, concurrency: 4, configuration: { relationship_types: "REL" } } ]
现在,每个 ticket 都可以用于通过 GDS Flight Server 的 GET
端点请求分区数据。