运行作业
Neo4j Graph Analytics 提供了一个算法目录，可以通过运行作业 (jobs) 来执行这些算法。
作业的执行通常分为三个步骤：投影 (project)、计算 (compute) 和 写入 (write)。投影-计算-写入模式是图处理中的一种通用模式：首先从数据中投影出一个图，然后在图上运行计算，最后将结果写回数据存储中。
运行作业时，用户提交一个类似于 JSON 的配置，其键对应于作业的各个步骤。
{
'project': ...,
'compute': ...,
'write': ...
}对于每个步骤，我们将描述其工作原理及上述配置的相关部分。该结构实际上是类型为 VARIANT 的 Snowflake SQL 数据。它的行为类似于 JSON，但值得注意的是，字符串使用单引号表示。
除了“project”、“compute”和“write”之外，还有一个可选的 defaultTablePrefix 参数，可以简化您提供的输入配置。更多信息请参阅下方的默认表前缀部分。
投影 (Project)
图投影是从 Snowflake 数据库中的表/视图创建图的过程。投影读取两种表——节点表和关系表——以便创建一个针对运行大规模图算法而优化的内存图。输入表必须遵循下述的特定约定。
节点表
节点表表示图中的节点。表的每一行代表图中的一个节点。表必须有一个名为 NODEID 的列，用于唯一标识表中的节点。这些节点标识符支持的数据类型为 NUMBER(*, 0)（任何精度属性设置为 0 的 NUMBER，例如 INT / BIGINT 别名）和 VARCHAR。任何其他列都将被视为分配给节点的属性，即所谓的节点属性。
请考虑以下节点表的示例
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.NODE_DATA (NODEID NUMBER PROPERTY1 NUMBER, PROPERTY2 FLOAT);
INSERT INTO EXAMPLE_DB.DATA_SCHEMA.NODE_DATA VALUES (1, 42, 13.37), (2, 43, 13.38), (3, 44, 13.39);在此示例中，我们有两个节点属性：PROPERTY1 和 PROPERTY2。节点属性支持的数据类型为 NUMBER、FLOAT 和 ARRAY。
关系表
关系表必须包含两列 SOURCENODEID 和 TARGETNODEID，用于存储投影中节点表的节点标识符引用。表的每一行代表图中的一个关系，即从源节点到目标节点的连接。因此，SOURCENODEID 和 TARGETNODEID 列告诉我们图中哪些节点是连接的。
关系表还可以包含一个额外的列，该列被视为关系的属性。这在运行加权图算法时非常有用。
请考虑以下关系表的示例
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.RELATIONSHIP_DATA (SOURCENODEID NUMBER, TARGETNODEID NUMBER, PROPERTY1 FLOAT);
INSERT INTO EXAMPLE_DB.DATA_SCHEMA.RELATIONSHIP_DATA VALUES (1, 2, 1.0), (2, 3, 2.5);被投影的图由三个节点组成，“first”连接到“second”（权重为 1.0），“second”连接到“third”（权重为 2.5）。SOURCENODEID 和 TARGETNODEID 列引用了上述节点表中的 NODEID 列。这意味着它们必须与 NODEID 列具有相同的数据类型。注意，如果 SOURCENODEID 和 TARGETNODEID 引用不同的节点表，它们可以具有不同的类型。任何额外列都被视为关系属性。在此示例中，我们有一个属性 PROPERTY1。关系属性必须是 FLOAT 类型。
使用视图进行投影
除了表之外，您还可以使用 Snowflake 视图作为图投影的源。当您需要转换现有的数据模式以匹配所需的节点和关系表格式，或者想要在创建图投影之前过滤或聚合数据时，视图特别有用。
有关视图的更多信息，请参阅 Snowflake 文档中的视图概述。
用于投影的视图必须遵循与表相同的结构要求：
-
节点视图必须包含
NODEID列。 -
关系视图必须包含
SOURCENODEID和TARGETNODEID列。 -
额外的列将成为节点或关系属性。
以下是为图投影创建视图的示例：
CREATE VIEW EXAMPLE_DB.DATA_SCHEMA.NODE_VIEW AS
SELECT
existing_id AS NODEID,
existing_value AS node_property
FROM EXAMPLE_DB.RAW_SCHEMA.EXISTING_TABLE;
CREATE VIEW EXAMPLE_DB.DATA_SCHEMA.RELATIONSHIP_VIEW AS
SELECT
first_id AS SOURCENODEID,
second_id AS TARGETNODEID,
existing_value AS relationship_property
FROM EXAMPLE_DB.RAW_SCHEMA.TABLE;表和视图的读取权限
任何作业的投影部分都要求应用程序拥有由管理员授予的读取访问权限。这适用于投影中使用的表和视图。
投影配置语法
作业配置中 project 部分的语法如下：
'project': {
'defaultTablePrefix': OPTIONAL VARCHAR,
'nodeTables': LIST OF VARCHAR,
'relationshipTables': MAP FROM VARCHAR TO MAP
}其中 nodeTables 的每个元素是节点表或视图的简单名称或全限定名称，relationshipTables 的每个键是关系表或视图的简单名称或全限定名称。relationshipTables 中每个条目的值是一个如下形式的映射：
{
'sourceTable': VARCHAR,
'targetTable': VARCHAR,
'orientation': OPTIONAL VARCHAR
}其中 sourceTable 和 targetTable 是节点表中出现的表或视图的简单名称或全限定名称。在将 sourceTable 和 targetTable 与 nodeTables 的条目匹配时，区分大小写。如果 nodeTables、relationshipTables、sourceTable 和 targetTable 中的所有或多个表/视图位于同一架构中，defaultTablePrefix 参数有助于减少代码量。关于方向 (orientation)，请参阅下方的解释。
从表到异构图的映射
project 配置可以包含多个节点表和关系表。实际上，被投影的图是一个带节点标签和关系类型的图。这种图称为异构图，某些算法可以利用节点标签和关系类型所携带的信息。在调用算法时，节点标签和关系类型也可用于过滤图。这样，我们就可以在图的一个子集上运行算法。
源自某个节点表的所有节点都被“标记”上一个节点标签，其名称就是该节点表的简单名称。例如，db.schema.Person 将生成节点标签 Person，它是区分大小写的，尽管 Snowflake 中的表名不区分大小写。
源自某个关系表的所有关系都被“标记”上一个关系类型，其名称就是该关系表的简单名称。
请注意，由于简单表名到节点标签或关系类型的映射，不能使用多个具有相同简单名称的节点表，也不能有两个具有相同简单名称的关系表。节点标签和关系类型都是区分大小写的，因此例如投影 person 和 PERSON 标签是可以的。
我们之前提到过，每个节点表必须在 NODEID 列中具有唯一值。当使用多个节点表时，节点标识符在表之间不需要唯一。
方向 (Orientation)
在投影配置语法中，我们提到每个关系表都可以使用方向进行投影。方向可以是 NATURAL、UNDIRECTED 和 REVERSE 中的一个值。当未指定方向时，将使用默认的 NATURAL。NATURAL 方向意味着包含表中描述的方向的关系（从源节点到目标节点）。REVERSE 方向则相反，在包含每个关系之前将其方向从目标反转为源。最后，UNDIRECTED 方向是前两种方向的并集，即每个关系既包含原始方向，也包含反向。
复杂视图的仓库大小调整
当使用涉及多个连接或聚合的复杂视图时，您可能需要调整仓库大小以确保投影期间的良好性能。默认情况下，应用程序使用 XS 仓库进行图投影。管理员可以通过更新仓库配置来修改仓库大小：
ALTER WAREHOUSE Neo4j_Graph_Analytics_app_warehouse -- adjust based on your application name
SET WAREHOUSE_SIZE = XLARGE;
-- Available sizes: XSMALL | SMALL | MEDIUM | LARGE | XLARGE | XXLARGE | XXXLARGE | X4LARGE | X5LARGE | X6LARGE有关 Snowflake 仓库的更多信息，请参阅 https://docs.snowflake.com/en/user-guide/warehouses-overview。
投影完成后，您可以将仓库缩减以降低成本。
ALTER WAREHOUSE Neo4j_Graph_Analytics_app_warehouse
SET WAREHOUSE_SIZE = XSMALL;计算 (Compute)
计算步骤是作业的核心，包括运行一种支持的算法。配置中对应的 compute 部分是特定于算法的。然而，某些配置选项（如 resultProperty）由多种算法共享。大多数算法产生的结果通过修改内存中的图来存储，要么生成节点属性，要么在节点之间创建关系。少数算法则生成并存储机器学习模型，这些模型可用于后续作业进行预测。
写入 (Write)
对于产生图输出数据（即节点属性或新关系）的算法，必须配置第三个也是最后一个 write 步骤。每个算法的页面都指定了输出类型，例如，关于写入配置的表格包含节点属性产生时的 nodeLabel，以及关系产生时的 sourceLabel 和 targetLabel。我们首先描述产生节点属性的算法情况。
节点属性
一些算法将其结果作为节点属性输出。要将这些节点属性写回 Snowflake，您需要指定一个配置映射列表。每个映射包含一个节点标签和一个输出表的名称。
通用语法是：
'write': LIST OF MAP，其中每个映射的形式为：
{'nodeLabel': VARCHAR, 'outputTable': VARCHAR}并且每个映射都强制将具有一个节点标签的所有节点写入输出表。outputTable 值在各个条目中必须是唯一的。对于每个条目，节点标签必须与表到图映射中的某个节点标签匹配（区分大小写）。写入的输出表包含一个 NODEID 列以及一个用于存放待写入节点属性的额外列。
以下示例说明了如何将 WCC 等算法的结果写回新表：
'write': [
{'nodeLabel': 'CUSTOMERS', 'outputTable': 'EXAMPLE_DB.DATA_SCHEMA.CUSTOMERS_COMPONENTS'}
]由于应用程序将写入表（在本例中为 EXAMPLE_DB.DATA_SCHEMA.CUSTOMERS_COMPONENTS），因此在运行作业之前，必须授予应用程序写入权限。 |
如果输出表已经存在，只要有相应的权限，应用程序就会覆盖该表。
关系和关系属性
我们现在讨论写入在计算阶段由算法创建的关系。根据算法的不同，生成的关系可能包含也可能不包含关系属性。由于目前没有任何算法会产生不同类型的关系，因此输出关系上不暴露关系类型。
可以根据每个关系的源节点和目标节点的节点标签对关系进行分组。关系有两种写入操作类型：同构和异构，下面将进行说明。
写入配置遵循以下语法：
'write': LIST OF MAP，其中每个映射的形式为：
{'sourceLabel': VARCHAR, 'targetLabel': VARCHAR, 'outputTable': VARCHAR}用于同构写入，以及：
{'outputTable': VARCHAR}用于异构写入。
算法的选择决定了允许哪种类型的写入操作。要确定允许的写入操作，请查看相关算法的文档，了解 write 参数是否包含 sourceLabel 和 targetLabel。
同构写入
sourceLabel 和 targetLabel 值根据源节点和目标节点标签的分组，确定要写入的关系子集。输出表包含 SOURCENODEID 和 TARGETNODEID 列。如果算法在关系上产生属性，它还包含一个用于存放待写入关系属性的额外列。
以下示例演示了如何写回例如节点相似度 (Node Similarity) 算法计算出的关系，包括其计算出的属性 (SCORE)：
'write': [
{'sourceLabel': 'ORDERS', 'targetLabel': 'ORDERS', 'outputTable': 'EXAMPLE_DB.DATA_SCHEMA.ORDER_SIMILARITIES'}
]由于应用程序将写入表（在本例中为 EXAMPLE_DB.DATA_SCHEMA.ORDER_SIMILARITIES），因此在运行作业之前，必须授予应用程序写入权限。 |
如果输出表已经存在，只要有相应的权限，应用程序就会覆盖该表。
异构写入
在异构关系写入中，不应用根据 sourceLabel 和 targetLabel 的过滤。因此，这些参数在写入配置中被省略。相反，
-
写入的输出表包含额外的列
SOURCELABEL和TARGETLABEL。 -
SOURCENODEID和TARGETNODEID列始终为VARCHAR类型。例如，节点 ID 42 变为 '42'。
关于 outputTable 和 relationshipType：同构和异构写入配置都接受 relationshipType 参数。这应与算法计算配置中的 resultRelationshipType 值相匹配。默认情况下，算法过程会将这些设置为匹配值，您无需更改它们——除非在运行多算法作业 (experimental.run_job_v1) 时。relationshipType 在内部使用，并且不会存储在 Snowflake 的输出表中（输出表仅包含节点标识符和标签）。相反，outputTable 名称既作为标识符，也作为所写入关系的描述性标签。 |
运行作业示例
让我们考虑一个包含多个节点和关系表的更复杂示例。
下表代表一个交易商店系统的子集。通常，现实场景中的表会包含更多的列和行。在这里，创建一个 VIEW 将源表转换为可用于图投影的格式。
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.PRODUCTS (nodeId Number, price Double);
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.ORDERS (nodeId Number, total Number);
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.CUSTOMERS (nodeId Number);
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.LINEITEM (sourceNodeId Number, targetNodeId Number, quantity Double);
CREATE TABLE EXAMPLE_DB.DATA_SCHEMA.PURCHASE (sourceNodeId Number, targetNodeId Number);为了从这些表中创建图，我们需要定义节点和关系表及其映射。节点相似度算法就是一个例子，它可用于根据 LINEITEM 和 PURCHASE 关系查找相似的产品。该算法将产生连接各种标签的相似节点的新关系。这些关系将包含一个 similarity 属性，其中包含连接节点彼此相似程度的得分。最后，我们将产品到产品以及订单到订单的相似关系写回 Snowflake 表，以便进行进一步分析。
另请注意，在以下示例中，我们使用默认的应用程序名称 Neo4j_Graph_Analytics。如果您在安装过程中选择了不同的应用名称，请将其替换为该名称。
CALL Neo4j_Graph_Analytics.graph.node_similarity('CPU_X64_XS', {
'defaultTablePrefix': 'EXAMPLE_DB.DATA_SCHEMA',
'project': {
'nodeTables': ['PRODUCTS', 'ORDERS', 'CUSTOMERS'],
'relationshipTables': {
'LINEITEM': {
'sourceTable': 'ORDERS',
'targetTable': 'PRODUCTS'
},
'PURCHASE': {
'sourceTable': 'CUSTOMERS',
'targetTable': 'PRODUCTS'
}
}
},
'compute': {'topK': 2},
'write': [
{'sourceLabel': 'CUSTOMERS', 'targetLabel': 'CUSTOMERS', 'outputTable': 'CUSTOMER_SIMILARITIES'},
{'sourceLabel': 'ORDERS', 'targetLabel': 'ORDERS', 'outputTable': 'ORDER_SIMILARITIES'}
]
});请注意，此处的 defaultTablePrefix 用于为配置中的所有表指定默认数据库和架构。有关此内容的更多信息，请参见默认表前缀部分。