Práticas recomendadas para executar algoritmos no Spanner Graph

Este documento descreve as práticas recomendadas para executar algoritmos no Spanner Graph. Ele abrange os seguintes tópicos:

Práticas recomendadas para esquemas de gráficos em algoritmos

Se você usa rótulos e propriedades personalizados no Spanner Graph, recomendamos sempre expor chaves de elementos como propriedades. Assim, é possível acessar essas propriedades principais na cláusula RETURN da consulta do algoritmo e usá-las para identificar o elemento do gráfico para o qual o algoritmo gera saída.

Processar a saída do algoritmo

Esta seção compartilha recomendações sobre o que retornar da saída do algoritmo e onde persistir os resultados retornados.

O que devolver

Quando a assinatura de saída do algoritmo contém elementos de gráfico, o Spanner Graph permite retornar qualquer propriedade desses elementos. Para reduzir o custo de processamento, recomendamos minimizar a lista de propriedades a serem retornadas. Por exemplo, retorne apenas propriedades que são chaves de um elemento, porque elas são necessárias para identificar o elemento.

Onde persistir

O Spanner Graph permite manter o resultado da consulta do algoritmo no Cloud Storage ou na mesma instância do Spanner Graph em que você iniciou a consulta.

Persistir de volta ao Spanner torna a saída do algoritmo acessível a todas as operações do Spanner de forma nativa. Por exemplo, é possível executar WeaklyConnectedComponent e manter cluster_id de volta no gráfico. Em seguida, execute PageRank para um gráfico de entrada com cluster_id específico. Recursos do Spanner, como Change Stream, propagam novas saídas de algoritmo para sistemas downstream. Se você quiser usar a saída do algoritmo no Spanner, recomendamos a persistência no Spanner. Embora o Spanner Graph use maneiras eficientes de agrupar e persistir a saída do algoritmo no Spanner, todas as gravações precisam passar pela mesma réplica líder. Se você já tiver cargas de trabalho críticas ocupando a capacidade do líder, talvez seja melhor escalonar as execuções de algoritmos para evitar a concorrência com cargas de trabalho críticas.

Considere persistir no Cloud Storage se você não planeja usar a saída do algoritmo no Spanner ou quer avaliar a saída antes de ingerir na sua fonte de dados principal. Consulte os formatos de arquivo aceitos.

Considerações sobre modelagem de dados para aumentar o gráfico

Nesta seção, discutimos algumas considerações sobre modelagem de dados ao persistir a saída do algoritmo no Spanner.

Propriedades x arestas

Os algoritmos podem gerar vários insights, incluindo:

  • Métricas no nível do nó (por exemplo, pontuação de centralidade). Elas podem ser mantidas como novas propriedades no nó.
  • Insights de pares (por exemplo, semelhança entre dois nós). Eles podem ser mantidos como novas arestas entre os dois nós, com o valor de saída como propriedade de aresta.
  • Os algoritmos de detecção de comunidade identificam comunidades lógicas no gráfico e podem atribuir uma ou mais comunidades a um determinado nó. É possível modelar a associação à comunidade como uma nova propriedade no nó marcando cada nó de membro com o ID da comunidade atribuída. Você também pode modelar a participação na comunidade como novos subgrafos e armazenar as comunidades lógicas como um novo tipo de nós no grafo com arestas que os conectam aos nós de membros. A propriedade da comunidade pode ser suficiente se você quiser saber a qual comunidade um nó pertence ao acessar um nó. O subgrafo de comunidade pode ser mais adequado quando você quer navegar por comunidade (por exemplo, encontrar nós na mesma comunidade que um nó inicial). Dependendo de como você planeja usar as informações da comunidade, é possível escolher uma ou as duas opções.

Esquema predefinido x esquema flexível

Antes de persistir a saída do algoritmo no Spanner, defina a coluna ou tabela de destino no esquema de uma das seguintes maneiras:

  • Se os casos de uso do algoritmo forem estáveis e conhecidos, adicione outras colunas ou tabelas com antecedência.
  • Se você estiver iterando e testando diferentes maneiras de extrair insights (por exemplo, testando diferentes algoritmos, parâmetros, subgrafos de entrada), talvez queira uma maneira flexível de manter e diferenciar a saída de várias experimentações sem atualizar o esquema do Spanner para cada execução. Nesse caso, considere armazenar novas propriedades e arestas produzidas por algoritmos em tabelas filhas genéricas.

Para armazenar novas propriedades e arestas produzidas por algoritmos em tabelas secundárias genéricas, siga estas etapas:

Etapa 1: criar tabelas secundárias genéricas

-- Create `AccountAlgoProperty` as a child table of `Account`, to store all
-- properties produced by algorithms for `Account`.
-- `algo_run_id`: a unique ID for a given algorithm run.
-- `int_val`: column to store integer algorithm output.
-- `float_val`: column to store float algorithm output.
CREATE TABLE AccountAlgoProperty (
 id INT64 NOT NULL,
 algo_run_id STRING(200) NOT NULL,
 int_val INT64,
 float_val FLOAT64
) PRIMARY KEY(id, algo_run_id),
 INTERLEAVE IN PARENT Account;

-- Create `AccountAlgoEdge` as a child table of `Account`, to store all
-- outgoing edges produced by algorithms for `Account`.
-- `algo_run_id`: a unique ID for a given algorithm run.
-- `to_id`: destination `Account` id.
-- `int_val`: column to store integer algorithm output.
-- `float_val`: column to store float algorithm output.
CREATE TABLE AccountAlgoEdge (
 id INT64 NOT NULL,
 algo_run_id STRING(200) NOT NULL,
 to_id INT64 NOT NULL,
 int_val INT64,
 float_val FLOAT64,
 CONSTRAINT FK_AccountId FOREIGN KEY (to_id) REFERENCES Account (id) NOT ENFORCED,
) PRIMARY KEY(id, algo_run_id, to_id),
 INTERLEAVE IN PARENT Account;

Etapa 2: armazene propriedades e arestas produzidas por algoritmos como linhas da tabela filha, junto com o algo_run_id exclusivo que as gerou.

-- Store PageRank score as property in child table.
EXPORT DATA
 OPTIONS (format = "CLOUD_SPANNER",
          table = "AccountAlgoProperty",
          write_mode = 'upsert_ignore_all' ) AS
GRAPH FinGraph
CALL PageRank(node_labels => ['Account'], edge_labels => ['Transfers'])
RETURN node.id, "page_rank_123" AS algo_run_id, score As float_val;

-- Store ShortestPath output as edge in child table.
EXPORT DATA
 OPTIONS (format = "CLOUD_SPANNER",
          table = "AccountAlgoEdge",
          write_mode = 'upsert_ignore_all' ) AS
GRAPH FinGraph
CALL ShortestPath(
    source_nodes => ARRAY {
                      MATCH (n:Account {id: 7})
                      RETURN n
                    },
    target_nodes => ARRAY {
                      MATCH (n:Account {id: 16})
                      RETURN n
                    }
  ) YIELD source_node, target_node, path, cost
RETURN source_node.id AS id, "shortest_path_456" AS algo_run_id,
  target_node.id AS to_id, PATH_LENGTH(path) AS int_val, cost AS float_val;

Etapa 3: acessar a saída do algoritmo usando GRAPH_TABLE

SELECT acct.id, prop.float_val AS page_rank_score
FROM GRAPH_TABLE(
  FinGraph
  MATCH (n:Account)
  RETURN n.id
) acct JOIN AccountAlgoProperty prop ON acct.id = prop.id
  AND prop.algo_run_id = 'page_rank_123';

SELECT acct.id, edge.to_id, edge.int_val AS path_len, edge.float_val AS cost
FROM GRAPH_TABLE(
  FinGraph
  MATCH (n:Account)
  RETURN n.id
) acct JOIN AccountAlgoEdge edge ON acct.id = edge.id
  AND edge.algo_run_id = 'shortest_path_456';

Etapa 4: opcionalmente, crie um gráfico lógico aumentado com propriedades e arestas geradas por algoritmo para facilitar o acesso à saída do algoritmo.

-- Create a view that aggregates non-null algorithm properties per node into
-- name-value pairs in JSON.
CREATE OR REPLACE VIEW AccountWithAlgoProperties SQL SECURITY INVOKER AS
SELECT
  n.id, ANY_VALUE(n.create_time) AS create_time,
  ANY_VALUE(n.is_blocked) AS is_blocked, ANY_VALUE(n.nick_name) AS nick_name,
  JSON_OBJECT(
    IF(COUNT(c.algo_run_id) = 0, [], ARRAY_AGG(c.algo_run_id)),
    IF(COUNT(c.algo_run_id) = 0, [], ARRAY_AGG(
      COALESCE(
        IF (c.int_val IS NULL, NULL, TO_JSON(c.int_val)),
        IF (c.float_val IS NULL, NULL, TO_JSON(c.float_val))
      )))) AS algo_props
FROM Account AS n LEFT JOIN AccountAlgoProperty AS c ON n.id = c.id
GROUP BY n.id;

-- Create FinGraphAugmented with algorithm generated properties and edges.
CREATE OR REPLACE PROPERTY GRAPH FinGraphAugmented
  NODE TABLES (
    AccountWithAlgoProperties AS Account
      KEY(id)
      LABEL Account PROPERTIES(
        create_time,
        id,
        is_blocked,
        nick_name,
        algo_props),
    Person
  )
  EDGE TABLES (
    PersonOwnAccount
      SOURCE KEY (id) REFERENCES Person (id)
      DESTINATION KEY (account_id) REFERENCES Account (id)
      LABEL Owns,
    AccountTransferAccount
      SOURCE KEY (id) REFERENCES Account (id)
      DESTINATION KEY (to_id) REFERENCES Account (id)
      LABEL Transfers,
    AccountAlgoEdge
      SOURCE KEY (id) REFERENCES Account (id)
      DESTINATION KEY (to_id) REFERENCES Account (id)
  );

Em seguida, acesse diretamente as propriedades do algoritmo e navegue pelas arestas geradas por ele na consulta de gráfico:

-- Retrieve PageRank score property in graph query.
GRAPH FinGraphAugmented
MATCH (a:Account)
RETURN a.id, a.algo_props.page_rank_123 AS page_rank
ORDER BY page_rank DESC
LIMIT 5;

-- Navigate through ShortestPath edge in graph query.
GRAPH FinGraphAugmented
MATCH (s:Account {id: 7})-[e:AccountAlgoEdge {algo_run_id : 'shortest_path_456'}]->(d:Account)
RETURN s.id AS src, d.id AS dst, e.int_val AS path_len, e.float_val AS cost

Especificar machine_category para cargas de trabalho grandes

Para a maioria das cargas de trabalho, a default machine_category é adequada. Se o gráfico de entrada tiver mais de 1 bilhão de nós e mais de 10 bilhões de arestas, recomendamos que você escolha explicitamente large para machine_category.

Reutilizar a computação para iteração rápida

Se você estiver testando algoritmos ou parâmetros de entrada diferentes em conjuntos de dados pequenos para iteração rápida, recomendamos usar max_idle_time. Um max_idle_time Spanner Graph maior permite reutilizar recursos de computação já provisionados para mais cargas de trabalho de algoritmos. Isso reduz o overhead de inicialização a frio da computação sob demanda e diminui o risco de não ser possível provisionar computação devido à falta temporária de capacidade. Observação: o cálculo do algoritmo é faturável quando está inativo.

Diferenciar tipos de elementos na saída

Se a saída do algoritmo contiver vários tipos de elementos, inclua ELEMENT_DEFINITION_NAME na saída para diferenciá-los. Exemplo:

EXPORT DATA OPTIONS (
  uri = "gs://bucket-name/page_rank.csv",
  format = "csv",
  overwrite = TRUE) AS
GRAPH FinGraph
CALL PageRank()
YIELD node, score
RETURN ELEMENT_DEFINITION_NAME(node) AS node_type, node.id, score;

A seguir