Spanner Graph에서 알고리즘 실행 권장사항

이 문서에서는 Spanner Graph에서 알고리즘을 실행하기 위한 권장사항을 설명합니다. 다음 주제를 다룹니다.

알고리즘을 위한 그래프 스키마 권장사항

Spanner Graph에서 맞춤 라벨과 속성을 사용하는 경우 항상 요소 키를 속성으로 노출하는 것이 좋습니다. 이렇게 하면 알고리즘 쿼리의 RETURN 절에서 이러한 키 속성에 액세스하고 이를 사용하여 알고리즘이 출력을 생성하는 그래프 요소를 식별할 수 있습니다.

알고리즘 출력 처리

이 섹션에서는 알고리즘 출력에서 반환할 항목과 반환된 결과를 유지할 위치에 관한 권장사항을 공유합니다.

반환할 항목

알고리즘의 출력 서명에 그래프 요소가 포함된 경우 Spanner Graph를 사용하면 이러한 요소의 속성을 반환할 수 있습니다. 처리 비용을 줄이려면 반환할 속성 목록을 최소화하는 것이 좋습니다. 예를 들어 요소의 키인 속성만 반환합니다. 키는 요소를 식별하는 데 필요하기 때문입니다.

유지할 위치

Spanner Graph는 알고리즘 쿼리 결과를 Cloud Storage에 유지하거나 쿼리를 시작하는 동일한 Spanner Graph 인스턴스에 다시 유지하는 것을 지원합니다.

Spanner에 다시 유지 하면 모든 Spanner 작업에서 알고리즘 출력에 기본적으로 액세스할 수 있습니다. 예를 들어 WeaklyConnectedComponent를 실행하고 cluster_id를 그래프에 다시 유지할 수 있습니다. 그런 다음 특정 cluster_id가 있는 입력 그래프에 PageRank를 실행합니다. 변경 스트림과 같은 Spanner 기능은 새로운 알고리즘 출력을 다운스트림 시스템에 전파합니다. Spanner에서 알고리즘 출력을 사용하려면 Spanner에 유지하는 것이 좋습니다. Spanner Graph는 알고리즘 출력을 Spanner에 일괄 처리 하고 유지하는 효율적인 방법을 사용하지만 모든 쓰기는 동일한 리더 복제본을 거쳐야 합니다. 이미 리더 용량을 차지하는 중요한 워크로드가 있는 경우 중요한 워크로드와 충돌하지 않도록 알고리즘 실행을 분산하는 것이 좋습니다.

Spanner에서 알고리즘 출력을 사용할 계획이 없거나 기본 데이터 소스에 수집하기 전에 알고리즘 출력을 평가하려는 경우 Cloud Storage에 유지 하는 것이 좋습니다. 지원되는 파일 형식을 참조하세요.

그래프 보강을 위한 데이터 모델링 고려사항

이 섹션에서는 알고리즘 출력을 Spanner에 유지할 때 고려해야 할 몇 가지 데이터 모델링 고려사항을 설명합니다.

속성과 가장자리

알고리즘은 다음과 같은 다양한 통계를 생성할 수 있습니다.

  • 노드 수준 측정항목 (예: 중심성 점수). 이러한 측정항목은 노드의 새 속성으로 유지될 수 있습니다.
  • 쌍별 통계 (예: 두 노드 간의 유사성). 이러한 통계는 출력 값을 가장자리 속성으로 사용하여 두 노드 간의 새 가장자리로 유지될 수 있습니다.
  • 커뮤니티 감지 알고리즘은 그래프에서 논리적 커뮤니티를 식별하고 지정된 노드에 하나 이상의 커뮤니티를 할당할 수 있습니다. 각 멤버 노드에 할당된 커뮤니티의 ID를 태그하여 노드의 새 속성으로 커뮤니티 멤버십을 모델링할 수 있습니다. 커뮤니티 멤버십을 새 하위 그래프로 모델링하고 논리적 커뮤니티를 구성원 노드에 연결하는 가장자리가 있는 그래프의 새로운 유형의 노드로 저장할 수도 있습니다. 노드에 액세스할 때 노드가 속한 커뮤니티를 알고 싶다면 커뮤니티 속성으로 충분할 수 있습니다. 커뮤니티별로 이동하려는 경우 (예: 시작 노드와 동일한 커뮤니티에서 노드 찾기) 커뮤니티 하위 그래프가 더 적합할 수 있습니다. 커뮤니티 정보를 사용하는 방법에 따라 둘 중 하나 또는 둘 다 선택할 수 있습니다.

사전 정의된 스키마와 유연한 스키마

알고리즘 출력을 Spanner에 다시 유지하기 전에 다음 방법 중 하나로 스키마에서 대상 열 또는 테이블을 정의합니다.

  • 알고리즘 사용 사례가 안정적이고 알려진 경우 미리 추가 열 또는 테이블을 추가할 수 있습니다.
  • 통계를 추출하는 다양한 방법을 반복하고 실험하는 경우 (예: 다양한 알고리즘, 매개변수, 입력 하위 그래프 사용해 보기) 각 실행에 대해 Spanner 스키마를 업데이트하지 않고 여러 실험의 출력을 유지하고 구분하는 유연한 방법이 필요할 수 있습니다. 이 경우 알고리즘에서 생성된 새 속성과 에지를 일반 하위 테이블에 저장하는 것이 좋습니다.

알고리즘에서 생성된 새 속성과 에지를 일반 하위 테이블에 저장하려면 다음 단계를 따르세요.

1단계: 일반 하위 테이블 만들기

-- 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;

2단계: 알고리즘에서 생성된 속성과 가장자리를 이를 생성한 고유한 algo_run_id와 함께 하위 테이블 행으로 저장합니다.

-- 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;

3단계: 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';

4단계: 필요에 따라 알고리즘 생성 속성과 가장자리로 보강된 논리적 그래프를 만들어 알고리즘 출력에 더 쉽게 액세스할 수 있습니다.

-- 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)
  );

그런 다음 그래프 쿼리에서 알고리즘 속성에 직접 액세스하고 알고리즘 생성 가장자리를 탐색할 수 있습니다.

-- 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

대규모 워크로드에 machine_category 지정

대부분의 워크로드에서 default machine_category가 적합합니다. 입력 그래프에 10억 개가 넘는 노드와 100억 개가 넘는 가장자리가 있는 경우 machine_category에 large를 명시적으로 선택하는 것이 좋습니다.

빠른 반복을 위한 컴퓨팅 재사용

빠른 반복을 위해 작은 데이터 세트에서 다양한 알고리즘 또는 다양한 입력 매개변수를 실험하는 경우 사용하는 것이 좋습니다. max_idle_time max_idle_time이 클수록 Spanner Graph는 더 많은 알고리즘 워크로드에 대해 이미 프로비저닝한 컴퓨팅 리소스를 재사용할 수 있습니다. 이렇게 하면 주문형 컴퓨팅의 콜드 스타트 오버헤드가 줄어들고 일시적인 용량 부족으로 인해 컴퓨팅을 프로비저닝할 수 없는 위험이 완화됩니다. 알고리즘 컴퓨팅은 유휴 상태일 때 청구됩니다.

출력에서 요소 유형 구분

알고리즘 출력에 여러 요소 유형이 포함된 경우 이를 구분하기 위해 출력에 ELEMENT_DEFINITION_NAME을 포함하는 것이 좋습니다. 예를 들면 다음과 같습니다.

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;

다음 단계