변경 데이터 캡처를 사용한 데이터베이스 복제

Last reviewed 2020-10-20 UTC

이 문서에서는 다양한 데이터 소스를 BigQuery와 통합하기 위해 Change Data Capture(CDC)를 사용하는 몇 가지 방법을 설명합니다. 이 문서는 각 방식의 데이터 일관성, 사용 용이성, 비용에 대한 장단점 분석을 제공합니다. 이를 통해 기존 솔루션을 이해하고, CDC가 복제한 데이터를 소비하는 다양한 접근 방식에 대해 알아보고, 접근 방식의 비용 이점 분석을 생성할 수 있습니다.

이 문서는 데이터 설계자, 데이터 엔지니어, 비즈니스 분석가가 BigQuery에서 복제된 데이터에 액세스하는 최적의 방법을 개발할 수 있도록 작성되었습니다. 여기서는 사용자가 BigQuery, SQL, 명령줄 도구에 대해 잘 알고 있다고 가정합니다.

CDC 데이터 복제 개요

MySQL, Oracle, SAP와 같은 데이터베이스는 가장 많이 논의되는 CDC 데이터 소스입니다. 그러나 기본 키에서 식별된 데이터 요소에 대한 변경사항을 캡처하고 제공하는 모든 시스템은 데이터 소스로 간주될 수 있습니다. 시스템에서 트랜잭션 로그와 같은 기본 제공 CDC 프로세스를 제공하지 않는 경우 증분 일괄 리더를 배포하여 변경사항을 가져올 수 있습니다.

이 문서에서는 다음 기준을 충족하는 CDC 프로세스에 대해 설명합니다.

1. 데이터 복제는 각 테이블의 변경사항을 개별적으로 캡처합니다.
2. 모든 테이블에는 기본 키 또는 복합 기본 키가 있습니다.
3. 내보낸 모든 CDC 이벤트에는 단조 증가하는 변경 ID가 할당되며, 일반적으로 트랜잭션 ID 또는 타임스탬프와 같은 숫자 값이 할당됩니다.
4. 모든 CDC 이벤트에는 변경된 행의 전체 상태가 포함됩니다.

다음 다이어그램은 데이터 소스를 BigQuery에 복제하기 위해 CDC를 사용하는 일반 아키텍처를 보여줍니다.

이전 다이어그램에서 기본 테이블과 델타 테이블은 각 소스 데이터 테이블의 BigQuery에 생성되었습니다. 기본 테이블에는 소스 테이블의 모든 열과 최신 변경 ID 값의 열 1개가 포함됩니다. 최신 변경 ID 값을 레코드의 기본 키로 식별된 항목의 버전 ID로 간주할 수 있으며 이 값을 사용하여 최신 버전을 찾을 수 있습니다.

델타 테이블에는 소스 테이블의 모든 열, 작업 유형 열(업데이트, 삽입, 삭제 중 하나), 변경 ID 값이 포함됩니다.

다음은 CDC를 사용하여 BigQuery에 데이터를 복제하는 전체 프로세스입니다.

1. 소스 테이블의 초기 데이터 덤프가 추출됩니다.
2. 추출된 데이터는 선택적으로 변환된 다음 해당 기본 테이블에 로드됩니다. 테이블에 최종 업데이트된 타임스탬프와 같은 변경 ID로 사용할 수 있는 열이 없으면 변경 ID는 해당 열의 데이터 유형에 가능한 가장 낮은 값으로 설정됩니다. 이렇게 하면 이후 처리에서 초기 데이터 덤프 후 업데이트된 기본 테이블 레코드를 식별할 수 있습니다.
3. 초기 데이터 덤프 후 변경되는 행은 CDC 캡처 프로세스에 의해 캡처됩니다.
4. 필요한 경우 CDC 처리 레이어에서 추가 데이터 변환을 수행합니다. 예를 들어 CDC 처리 레이어는 BigQuery에서 사용할 타임스탬프 형식을 다시 지정하거나 열을 수직으로 분할하거나 열을 삭제할 수 있습니다.
5. 데이터는 마이크로 배치 로드 또는 스트리밍 삽입을 사용하여 BigQuery의 해당 델타 테이블에 삽입됩니다.

BigQuery에 데이터가 삽입되기 전에 추가 변환이 수행될 경우 열의 수와 유형이 소스 테이블과 다를 수 있습니다. 그러나 기본 및 델타 테이블에는 동일한 열 집합이 존재합니다.

델타 테이블에는 초기 로드 이후 특정 테이블의 모든 변경 이벤트가 포함됩니다. 모든 변경 이벤트를 사용할 수 있으면 트렌드를 파악하거나, 테이블이 특정 시점에 나타나는 항목의 상태 또는 변경 빈도를 파악하는 데 유용합니다.

특정 기본 키로 표시되는 항목의 현재 상태를 가져오려면 가장 최근의 변경 ID가 있는 레코드의 기본 테이블과 델타 테이블을 쿼리하면 됩니다. 이 쿼리는 기본 테이블과 델타 테이블 사이의 조인을 수행하고 한 테이블 또는 모든 테이블의 전체 테이블 스캔을 완료하여 특정 기본 키의 가장 최근 항목을 찾아야 할 수 있으므로 비용이 많이 들 수 있습니다. 기본 키를 기준으로 테이블을 클러스터링 또는 파티션 나누기하여 전체 테이블 스캔을 수행할 수 있지만 항상 가능한 것은 아닙니다.

이 문서에서는 테이블의 파티션을 나누거나 클러스터링할 수 없을 때 항목의 현재 상태를 가져오는 데 도움이 되는 다음과 같은 일반 접근 방식을 비교 설명합니다.

• 즉각적 일관성 방식: 쿼리는 복제된 데이터의 현재 상태를 반영합니다. 즉각적 일관성에는 기본 테이블과 델타 테이블을 조인하는 쿼리가 필요하며 각 기본 키에 대한 최신 행을 선택합니다.
• 비용 최적화 방식: 데이터 가용성이 약간 지연되는 대신 더 빠르고 저렴한 쿼리가 실행됩니다. 주기적으로 데이터를 기본 테이블에 병합할 수 있습니다.
• 하이브리드 방식: 요구사항 및 예산에 따라 즉각적 일관성 방식 또는 비용 최적화 방식을 사용합니다.

이 문서에서는 이러한 방식 외에 성능 개선 방법을 추가적으로 설명합니다.

시작하기 전에

이 문서에서는 bq 명령줄 도구와 SQL 문을 사용하여 BigQuery 데이터를 보고 쿼리하는 방법을 설명합니다. 이 문서의 뒷부분에 테이블 레이아웃 및 쿼리 예시가 나와 있습니다. 샘플 데이터로 실험하려면 다음 설정을 완료하세요.

1. 프로젝트를 선택하거나 프로젝트를 만들고 프로젝트에 결제를 사용 설정합니다.
   • 프로젝트를 만들면 BigQuery가 자동으로 사용 설정됩니다.
   • 기존 프로젝트를 선택하는 경우 BigQuery API를 사용 설정합니다.
2. Google Cloud Console에서 Cloud Shell을 엽니다.

3. BigQuery 구성 파일을 업데이트하려면 텍스트 편집기에서 ~/.bigqueryrc 파일을 열고 파일의 임의 위치에 다음 줄을 추가하거나 업데이트합니다.

   [query]
   --use_legacy_sql=false
   
   [mk]
   --use_legacy_sql=false
   

4. BigQuery 환경을 설정할 스크립트가 포함된 GitHub 저장소를 클론합니다.

   git clone https://github.com/GoogleCloudPlatform/bq-mirroring-cdc.git
   

5. 데이터 세트, 기본, 델타 테이블을 만듭니다.

   cd bq-mirroring-cdc/tutorial
   chmod +x *.sh
   ./create-tables.sh
   

실험을 완료한 후 요금이 청구되지 않도록 하려면 프로젝트를 종료하거나 데이터 세트를 삭제합니다.

BigQuery 데이터 설정

BigQuery에 CDC 데이터 복제를 위한 다양한 솔루션을 시연하려면 다음과 같은 간단한 예시 테이블같이 샘플 데이터로 채워진 기본 및 델타 테이블 쌍을 사용합니다.

이 문서에 설명된 수준보다 더 정교한 설정을 사용하려면 CDC BigQuery 통합 데모를 사용하세요. 데모는 테이블을 채우는 프로세스를 자동화하고 복제 프로세스를 모니터링하는 스크립트를 포함합니다. 데모를 실행하려면 이 문서의 시작하기 전에 섹션에서 클론한 GitHub 저장소의 루트에 있는 README 파일의 안내를 따릅니다.

예시 데이터는 시스템 생성 필수 세션 ID와 선택적 사용자 이름을 포함하는 웹 세션인 간단한 데이터 모델을 사용합니다. 세션이 시작될 때 사용자 이름은 null입니다. 사용자가 로그인하면 사용자 이름이 채워집니다.

BigQuery 환경 스크립트에서 기본 테이블에 데이터를 로드하려면 다음과 같은 명령어를 실행할 수 있습니다.

bq load cdc_tutorial.session_main init.csv

기본 테이블 콘텐츠를 가져오려면 다음과 같은 쿼리를 실행할 수 있습니다.

bq query "select * from cdc_tutorial.session_main limit 1000"

출력은 다음과 같이 표시됩니다.

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | NULL     |         1 |
| 101 | Sam      |         2 |
| 102 | Jamie    |         3 |
+-----+----------+-----------+

다음으로, CDC 변경사항의 첫 번째 배치를 델타 테이블에 로드합니다. BigQuery 환경 스크립트에서 델타 테이블에 CDC 변경사항의 첫 번째 배치를 로드하려면 다음과 같은 명령어를 실행하면 됩니다.

bq load cdc_tutorial.session_delta first-batch.csv

델타 테이블 콘텐츠를 가져오려면 다음과 같은 쿼리를 실행할 수 있습니다.

bq query "select * from cdc_tutorial.session_delta limit 1000"

출력은 다음과 같이 표시됩니다.

+-----+----------+-----------+-------------+
| id  | username | change_id | change_type |
+-----+----------+-----------+-------------+
| 100 | Cory     |         4 | U           |
| 101 | Sam      |         5 | D           |
| 103 | NULL     |         6 | I           |
| 104 | Jamie    |         7 | I           |
+-----+----------+-----------+-------------+

앞의 출력에서 change_id 값은 테이블 행 변경의 고유 ID입니다. change_type 열의 값은 다음을 나타냅니다.

• U: 업데이트 작업
• D: 삭제 작업
• I: 삽입 작업

기본 테이블에는 세션 100, 101, 102에 대한 정보가 포함되어 있습니다. 델타 테이블에는 다음과 같은 변경사항이 있습니다.

• 세션 100이 사용자 이름 'Cory'로 업데이트됩니다.
• 세션 101이 삭제됩니다.
• 새 세션 103 및 104가 생성됩니다.

소스 시스템의 현재 세션 상태는 다음과 같습니다.

+-----+----------+
| id  | username |
+-----+----------+
| 100 | Cory     |
| 102 | Jamie    |
| 103 | NULL     |
| 104 | Jamie    |
+-----+----------+

현재 상태가 테이블로 표시되지만 이 테이블은 구체화된 형식으로 존재하지 않습니다. 이 테이블은 기본 테이블과 델타 테이블의 조합입니다.

데이터 쿼리

세션의 전체 상태를 확인하는 데 사용할 수 있는 여러 가지 방법이 있습니다. 다음 섹션에서는 각 방법의 장점과 단점을 설명합니다.

즉각적 일관성 방식

즉각적인 데이터 일관성이 기본 목표이고 소스 데이터가 자주 변경되는 경우, 기본 테이블과 델타 테이블을 조인하고 가장 최신 행.(가장 최신의 타임스탬프 또는 가장 높은 값을 갖는 행)을 선택하는 단일 쿼리를 사용할 수 있습니다.

기본 및 델타 테이블을 조인하고 최신 행을 찾는 BigQuery 뷰를 만들려면 다음과 같은 bq 도구 명령어를 실행합니다.

bq mk --view \
"SELECT * EXCEPT(change_type, row_num)
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num
  FROM (
    SELECT * EXCEPT(change_type), change_type
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_delta\` UNION ALL
    SELECT *, 'I'
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_main\`))
WHERE
  row_num = 1
  AND change_type <> 'D'" \
 cdc_tutorial.session_latest_v

앞의 BigQuery 뷰의 SQL 문은 다음을 수행합니다.

• 가장 안쪽의 UNION ALL은 기본 및 델타 테이블 모두에서 행을 생성합니다.
  • SELECT * EXCEPT(change_type), change_type FROM session_delta는 강제적으로 change_type 열을 목록의 마지막 열이 되도록 만듭니다.
  • SELECT *, 'I' FROM session_main은 기본 테이블에서 행을 삽입 행인 것처럼 선택합니다.
  • * 연산자를 사용하면 예시가 간단해집니다. 추가 열 또는 다른 열 순서가 있는 경우 단축키를 명시적 열로 바꿉니다.
• SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num은 BigQuery의 윈도우 함수를 사용하여 PARTITION BY으로 정의된 동일한 id 값을 가진 각 행 그룹에 1로 시작하는 순차적 행 번호를 할당합니다. 행은 해당 그룹 내에서 change_id에 따라 내림차순으로 정렬됩니다. change_id는 반드시 증가하기 때문에 최신 변경사항에는 값이 1인 row_num 열이 있습니다.
• WHERE row_num = 1 AND change_type <> 'D'은 각 그룹의 최신 행만 선택합니다. 이는 BigQuery의 일반적인 중복 삭제 기법입니다. 또한 이 절은 변경 유형이 삭제된 경우 결과에서 행을 삭제합니다.
• 맨 위에 있는 SELECT * EXCEPT(change_type, row_num)는 처리를 위해 도입되었으나 관련성이 없는 추가 열을 삭제합니다.

위의 예시에서는 가장 높은 change_id 값을 참조하여 원본 삽입 또는 최신 업데이트를 선택하므로 뷰의 삽입 및 업데이트 변경 유형을 사용하지 않습니다. 이 경우 각 행에는 모든 열의 전체 데이터가 포함됩니다.

뷰를 만든 후 뷰에 대한 쿼리를 실행할 수 있습니다. 최신 변경사항을 가져오려면 다음과 같은 쿼리를 실행할 수 있습니다.

bq query 'select * from cdc_tutorial.session_latest_v order by id limit 10'

출력은 다음과 같이 표시됩니다.

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

뷰를 쿼리할 때 DML 문을 사용하여 델타 테이블의 데이터를 업데이트한 경우 델타 테이블의 데이터가 즉시 표시되고 데이터를 스트리밍한 경우 거의 즉시 표시됩니다.

비용 최적화 방식

즉각적 일관성 방식은 간단하지만 BigQuery가 모든 기록 레코드를 읽고 기본 키를 기준으로 정렬하고 뷰를 구현하기 위해 쿼리의 다른 작업을 처리해야 하므로 비효율적일 수 있습니다. 세션 상태를 자주 쿼리하는 경우 즉각적 일관성 방식은 성능을 저하시키고 BigQuery에서 데이터를 저장하고 처리하는 비용을 증가시킬 수 있습니다.

비용을 최소화하기 위해 델타 테이블 변경사항을 기본 테이블에 병합하고 델타 테이블에서 병합된 행을 주기적으로 삭제할 수 있습니다. 병합 및 삭제에는 추가 비용이 발생하지만 기본 테이블을 자주 쿼리할 경우 델타 테이블에서 키의 최신 레코드를 계속 찾는 비용과 비교하면 비용은 매우 낮은 수준입니다.

델타 테이블의 데이터를 기본 테이블에 병합하려면 다음과 같이 MERGE 문을 실행합니다.

bq query \
'MERGE `cdc_tutorial.session_main` m
USING
  (
  SELECT * EXCEPT(row_num)
  FROM (
    SELECT *, ROW_NUMBER() OVER(PARTITION BY delta.id ORDER BY delta.change_id DESC) AS row_num
    FROM `cdc_tutorial.session_delta` delta )
  WHERE row_num = 1) d
ON  m.id = d.id
  WHEN NOT MATCHED
AND change_type IN ("I", "U") THEN
INSERT (id, username, change_id)
VALUES (d.id, d.username, d.change_id)
  WHEN MATCHED
  AND d.change_type = "D" THEN
DELETE
  WHEN MATCHED
  AND d.change_type = "U"
  AND (m.change_id < d.change_id) THEN
UPDATE
SET username = d.username, change_id = d.change_id'

앞의 MERGE 문은 4개의 행에 영향을 미치며 기본 테이블에는 현재 세션 상태가 있습니다. 이 뷰의 기본 테이블을 쿼리하려면 다음과 같은 쿼리를 실행합니다.

  bq query 'select * from cdc_tutorial.session_main order by id limit 10'

출력은 다음과 같이 표시됩니다.

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

기본 테이블의 데이터에는 최신 세션 상태가 반영됩니다.

데이터를 자주, 지속적으로 병합하는 가장 좋은 방법은 여러 INSERT ,UPDATE, DELETE 문을 단일 원자적 작업으로 조합하는 MERGE 문을 사용하는 것입니다. 다음은 위의 MERGE 문에 대한 몇 가지 미묘한 차이점입니다.

• 이 경우 session_main 테이블은 서브 쿼리인 USING 절에 지정된 데이터 소스와 병합됩니다.
• 서브 쿼리는 즉각적 일관성 방식의 뷰와 동일한 기법을 사용합니다. 즉, ROW_NUMBER() OVER(PARTITION BY id ORDER BY change_id DESC) row_num와 WHERE row_num = 1의 조합인 동일한 id 값을 갖는 레코드 그룹의 최신 행을 선택합니다.
• 병합은 두 테이블의 id 열(기본 키)에서 수행됩니다.
• WHEN NOT MATCHED 절은 일치를 확인합니다. 일치하는 항목이 없으면 쿼리는 최신 레코드가 삽입 또는 업데이트인지 확인한 다음 레코드를 삽입합니다.
  • 레코드가 일치하고 변경 유형이 삭제이면 기본 테이블에서 레코드가 삭제됩니다.
  • 레코드가 일치하면 변경 유형이 업데이트이고 델타 테이블의 change_id 값이 기본 레코드의 change_id 값보다 크면 데이터가 최신 데이터 change_id 값을 포함하여 업데이트됩니다.

앞의 MERGE 문은 다음 변경사항의 모든 조합에 대해 올바르게 작동합니다.

• 동일한 기본 키의 여러 업데이트 행: 최신 업데이트만 적용됩니다.

• 기본 테이블의 불일치 업데이트: 기본 테이블의 기본 키에 레코드가 없으면 새 레코드가 삽입됩니다.

  이 방식은 기본 테이블 추출을 건너뛰고 델타 테이블부터 시작합니다. 기본 테이블이 자동으로 채워집니다.

• 처리되지 않은 델타 배치에 행을 삽입하고 업데이트합니다. 가장 최근의 업데이트 행이 사용되며 새 레코드가 기본 테이블에 삽입됩니다.

• 처리되지 않은 배치에 행을 삽입하고 삭제합니다. 레코드가 삽입되지 않았습니다.

앞의 MERGE 문은 멱등성을 가집니다. 여러 번 실행해도 기본 테이블의 상태가 동일하고 부작용이 발생하지 않습니다. 델타 테이블에 새 행을 추가하지 않고 MERGE 문을 재실행하면 출력은 다음과 같습니다.

Number of affected rows: 0

MERGE 문을 정기적으로 실행하여 각 병합 후 기본 테이블을 최신 상태로 만들 수 있습니다. 기본 테이블의 데이터 최신 상태는 병합 빈도에 따라 다릅니다. MERGE 문을 자동으로 실행하는 방법에 대한 자세한 내용은 이전에 다운로드한 데모 README 파일의 '병합 예약' 섹션을 참조하세요.

하이브리드 방식

즉각적 일관성 방식과 비용 최적화 방식은 상호 배타적이지 않습니다. session_latest_v 뷰와 session_main 테이블에 대해 쿼리를 실행하면 동일한 결과가 반환됩니다. 요구사항과 예산에 따라 사용할 방식을 선택할 수 있습니다. 높은 비용과 가장 즉각적인 일관성 또는 낮은 비용과 잠재적 비활성 데이터 다음 섹션에서는 접근법과 가능한 대안을 비교하는 방법을 설명합니다.

접근 방식 비교

각 솔루션의 비용과 성능, 허용 가능한 데이터 지연 시간과 병합을 수행하는 비용간의 균형을 고려하여 접근 방식을 비교합니다.

쿼리 비용

다음 예시에서는 각 솔루션의 비용과 성능을 평가하기 위해 CDC BigQuery 통합 데모에서 생성된 약 500,000개의 세션에 대한 분석을 제공합니다. 데모의 세션 모델은 이 문서의 앞부분에 소개되었던 모델보다 약간 더 복잡하며 다른 데이터 세트에 배포되지만 개념은 동일합니다.

간단한 집계 쿼리를 사용하여 쿼리 비용을 비교할 수 있습니다. 다음 예시 쿼리에서는 델타 데이터와 기본 테이블이 결합된 뷰에 대해 즉각적 일관성 방식을 테스트합니다.

SELECT status, count(*) FROM `cdc_demo.session_latest_v`
GROUP BY status ORDER BY status

이 쿼리로 인해 다음과 같은 비용이 발생합니다.

Slot time consumed: 15.115 sec, Bytes shuffled 80.66 MB

다음 예시 쿼리는 기본 테이블에 대해 비용 최적화 방법을 테스트합니다.

SELECT status, count(*) FROM `cdc_demo.session_main`
GROUP BY status ORDER BY status

이 경우 다음과 같이 비용이 절감됩니다.

Slot time consumed: 1.118 sec, Bytes shuffled 609 B

같은 쿼리를 여러 번 실행하면 슬롯 시간 소비가 달라질 수 있지만 평균은 상당히 일관성을 유지합니다. Bytes shuffled 값은 여러 실행에서 일관적입니다.

성능 테스트 결과는 쿼리 유형과 테이블 레이아웃에 따라 달라집니다. 앞의 데모에서는 데이터 클러스터링이나 파티션 나누기를 사용하지 않습니다.

데이터 지연 시간

비용 최적화 방식을 사용하는 경우 데이터 지연 시간은 다음 항목의 합계입니다.

• 데이터 복제 트리거 지연 시간 이는 소스 이벤트 동안 데이터가 유지되는 시점과 복제 시스템이 복제 프로세스를 트리거하는 시점 사이의 시간입니다.
• BigQuery에 데이터를 삽입할 시간입니다(복제 솔루션에 따라 다름).
• 델타 테이블에 BigQuery 스트리밍 버퍼 데이터가 표시되는 시간 스트리밍 삽입을 사용하는 경우 일반적으로 몇 초입니다.
• 병합 실행 간의 지연
• 병합을 실행하는 시간입니다.

즉각적 일관성 방식을 사용할 경우 데이터 지연 시간은 다음 항목의 합계입니다.

• 데이터 복제 트리거 지연 시간
• BigQuery에 데이터를 삽입하는 시간
• 델타 테이블에 BigQuery 스트리밍 버퍼 데이터가 표시되는 시간

병합 실행에 드는 비용과 보다 일관된 데이터의 필요성 간의 균형점에 따라 병합 실행 사이에 발생하는 지연 시간을 구성할 수 있습니다. 필요한 경우 영업시간 동안 수행되는 잦은 병합과 사용 중지 기간에 수행되는 시간별 병합과 같은 보다 복잡한 스킴을 사용할 수 있습니다.

고려할 대안

즉각적 일관성 방식과 비용 최적화 방식은 다양한 데이터 소스를 BigQuery와 통합하기 위한 가장 일반적인 CDC 옵션입니다. 이 섹션에서는 더욱 간단하고 비용이 저렴한 데이터 통합 옵션을 설명합니다.

단일 정보 소스로의 델타 테이블

델타 테이블에 변경사항의 전체 기록이 포함된 경우 델타 테이블에 대해서 뷰 전용을 만들고 기본 테이블을 사용하지 않을 수 있습니다. 델타 테이블을 단일 정보 소스로 사용하는 것은 이벤트 데이터베이스의 예시입니다. 이 방식은 성능 저하 없이 낮은 비용으로 즉각적인 일관성을 제공합니다. 레코드 수가 적고 지연 변경 측정기준 테이블이 있는 경우 이 방법을 사용하는 것이 좋습니다.

CDC를 사용하지 않는 전체 데이터 덤프

관리 가능한 크기의 테이블(예: 1GB 미만)이 있는 경우 다음 순서로 전체 데이터 덤프를 수행할 수 있습니다.

1. 초기 데이터 덤프를 고유한 이름의 테이블로 가져옵니다.
2. 새 테이블만 참조하는 뷰를 만듭니다.
3. 기본 테이블이 아닌 뷰에 대한 쿼리를 실행합니다.
4. 다음 데이터 덤프를 다른 테이블로 가져옵니다.
5. 새로 업로드된 데이터를 가리키도록 뷰를 다시 만듭니다.
6. 선택적으로 원본 테이블을 삭제합니다.
7. 가져오기, 다시 만들기, 삭제하기의 위 단계를 정기적으로 반복합니다.

기본 테이블에 변경 내역 유지

비용 최적화 방식에서는 변경 내역이 보존되지 않으며 최신 변경사항이 이전 데이터를 덮어씁니다. 변경 내역을 유지해야 하는 경우 변경사항 배열을 사용하여 저장할 수 있으며 최대 행 크기 제한을 초과하지 않도록 주의해야 합니다. 기본 테이블에서 변경 내역을 보존하면 단일 MERGE 작업이 델타 테이블의 여러 행을 기본 테이블의 단일 행으로 병합할 수 있으므로 병합 DML이 더 복잡해집니다.

제휴 데이터 소스 사용

경우에 따라 BigQuery가 아닌 데이터 소스에 복제한 다음 통합 쿼리를 사용하여 해당 데이터 소스를 노출할 수 있습니다. BigQuery는 여러 외부 데이터 소스를 지원합니다. 예를 들어 MySQL 데이터베이스에서 별표와 유사한 스키마를 복제하면 지연 변경 측정기준을 기본 MySQL 복제를 사용하여 MySQL의 읽기 전용 버전으로 복제할 수 있습니다. 이 방법을 사용할 때는 자주 변경되는 팩트 테이블만 BigQuery로 복제합니다. 제휴 데이터 소스를 사용하려면 제휴 소스 쿼리에 대한 몇 가지 제한사항을 고려하세요.

추가 성능 향상

이 섹션에서는 테이블 클러스터링 및 파티션 나누기와 병합된 데이터 프루닝을 통해 성능을 더욱 향상시킬 수 있는 방법을 설명합니다.

BigQuery 테이블 클러스터링 및 파티션 나누기

자주 쿼리되는 데이터 세트가 있는 경우 클러스터링 및 파티션 나누기를 사용하여 모든 테이블의 사용량을 분석하고 테이블 디자인을 조정합니다. 기본 키로 하나 또는 둘 모두의 기본 테이블 및 델타 테이블을 클러스터링하면 다른 방식에 비해 성능이 향상될 수 있습니다. 성능을 확인하려면 10GB 이상인 데이터 세트에서 쿼리를 테스트합니다.

병합된 데이터 프루닝

델타 테이블은 시간이 지남에 따라 증가하고 각 병합 요청은 최종 결과에 필요하지 않은 여러 행을 읽어서 리소스를 낭비합니다. 델타 테이블 데이터만 사용하여 최신 상태를 계산하는 경우 병합 레코드를 프루닝하면 병합 비용을 줄이고 BigQuery에 저장된 데이터의 양을 줄여 전반적인 비용을 낮출 수 있습니다.

병합된 데이터를 다음과 같은 방법으로 프루닝할 수 있습니다.

• 기본 테이블에 최대 change_id 값을 정기적으로 쿼리하고 그 최댓값보다 낮은 change_id 값을 갖는 모든 델타 레코드를 삭제합니다. 델타 테이블에 삽입을 스트리밍하는 경우 일정 기간 동안 삽입이 삭제되지 않을 수 있습니다.
• 델타 테이블의 수집 기반 파티션 나누기를 사용하고 일일 스크립트를 실행하여 이미 처리된 파티션을 삭제합니다. BigQuery 파티션 나누기를 더 세분화하면 삭제 빈도를 늘릴 수 있습니다. 구현에 관한 자세한 내용은 이전에 다운로드한 데모 README 파일의 '처리된 데이터 삭제' 섹션을 참조하세요.

맺음말

적합한 접근 방식(또는 여러 접근 방식)을 선택하려면 해결할 사용 사례를 고려합니다. 기존 데이터베이스 마이그레이션 기술을 사용하여 데이터 복제 요구를 해결할 수 있습니다. 복잡한 요구사항이 많은 경우(예: 실시간에 가까운 데이터 사용 사례를 해결하고 나머지 데이터 액세스 패턴 비용을 최적화해야 하는 경우) 다른 제품 또는 오픈소스 솔루션을 기반으로 커스텀 데이터베이스 마이그레이션 빈도를 설정해야 할 수 있습니다. 이 문서에서 설명하는 접근 방식과 기법을 통해 이러한 솔루션을 성공적으로 구현할 수 있습니다.

다음 단계

• 데이터 파이프라인 마이그레이션 검토
• Google Cloud에서 클라우드 기반 데이터 웨어하우스를 위한 ETL 아키텍처 설계 및 Dataflow를 사용하여 관계형 데이터베이스에서 BigQuery로 ETL 수행에 대해 읽어보기
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기