데이터 웨어하우스 운영자를 위한 BigQuery

업데이트: 2017년 9월

이 문서에서는 BigQuery를 데이터 웨어하우스로 사용하는 방법을 설명합니다. 우선 일반적인 데이터 웨어하우스 개념에 비교해 BigQuery의 데이터 웨어하우스 개념을 설명한 다음 BigQuery에서 표준 데이터 웨어하우징 작업을 수행하는 방법을 다룹니다.

서비스 모델 비교

다음 표는 표준 데이터 웨어하우스 개념에 대비하여 BigQuery의 데이터 웨어하우스 개념을 보여줍니다.

데이터 웨어하우스 BigQuery
데이터 웨어하우스 BigQuery 서비스는 기존 데이터 웨어하우스의 일반적인 하드웨어 설정을 대체합니다. 즉 BigQuery 서비스는 조직의 모든 분석 데이터를 수집하는 장소로 사용됩니다.
데이터 마트 데이터세트는 비즈니스 종목 또는 주어진 분석 도메인으로 구분할 수 있는 테이블 모음입니다. 각 데이터세트는 Google Cloud Platform(GCP) 프로젝트와 연결됩니다.
데이터 레이크 데이터 레이크에는 Cloud Storage 또는 Google 드라이브의 파일 또는 Cloud Bigtable의 트랜잭션 데이터가 포함될 수 있습니다. BigQuery는 스키마를 정의하고 외부 데이터에 제휴 데이터 소스로 쿼리를 직접 실행할 수 있습니다.
테이블 및 뷰 테이블 및 뷰 기능은 BigQuery에서도 기존 데이터 웨어하우스와 동일한 방식으로 작동합니다.
권한 부여 Cloud Identity and Access Management(Cloud IAM)는 BigQuery에서 특정한 작업을 수행할 수 있는 권한을 부여하는 데 사용됩니다.

데이터세트

BigQuery는 데이터 테이블을 데이터세트라는 단위로 구성합니다. 이러한 데이터세트의 범위는 GCP 프로젝트에 지정됩니다. 명령줄, SQL 쿼리 또는 코드에서 테이블을 참조할 때는 다음 구문을 사용하여 참조합니다.

project.dataset.table

프로젝트, 데이터세트, 테이블 등 이러한 여러 범위를 사용하면 정보를 논리적으로 구성하는 데 도움이 됩니다. 여러 데이터세트를 사용하여 서로 다른 분석 도메인에 속한 테이블을 구분할 수 있고, 프로젝트 수준 범위 지정을 사용하여 비즈니스 요구 사항에 따라 데이터세트를 서로 분리할 수 있습니다.

BigQuery 구조의 개요는 다음과 같습니다.

BigQuery 구조 개요

프로비저닝 및 시스템 크기 조정

많은 RDBMS 시스템과 달리 BigQuery를 사용하기 전에는 리소스를 프로비저닝할 필요가 없습니다. BigQuery는 사용량 패턴에 따라 스토리지 및 쿼리 리소스를 동적으로 할당합니다.

  • 스토리지 리소스는 사용자가 이를 소비할 때 할당되며 데이터를 제거하거나 테이블을 삭제할 때 할당이 취소됩니다.
  • 쿼리 리소스는 유형과 복잡성에 따라 할당됩니다. 각 쿼리는 특정한 양의 CPU와 RAM으로 구성되는 계산 단위인 슬롯을 여러 개 사용합니다.

BigQuery를 사용하기 위해 최소 사용량 약정을 사용할 필요가 없습니다. 이 서비스는 실제 사용량에 따라 리소스를 할당하고 비용을 청구합니다. 기본적으로 BigQuery 고객은 누구나 쿼리 작업을 위해 2,000개의 슬롯에 액세스할 수 있고 또한 프로젝트에 고정된 수의 슬롯을 예약할 수도 있습니다. 사용할 방법에 대한 자세한 내용은 비용 섹션을 참조하세요.

스토리지 관리

내부적으로 BigQuery는 데이터 웨어하우스 작업 부하에 다양한 이점이 있는 Capacitor라는 독점적 열 형식으로 데이터를 저장합니다. BigQuery는 데이터 레이아웃에 대한 심층적인 지식을 활용하여 쿼리 실행을 최적화하는 쿼리 엔진과 함께 발전할 수 있는 독점적 형식을 사용합니다. BigQuery는 쿼리 액세스 패턴을 사용하여 물리적 분할의 최적 개수와 인코딩 방법을 결정합니다.

데이터는 여러 개의 디스크에 중복 청크를 저장하는 데 삭제 인코딩을 사용하여 내구성을 보장하는 Google의 분산 파일 시스템인 Colossus에 물리적으로 저장됩니다. 또한 데이터는 여러 개의 데이터 센터에 복제됩니다.

제휴 데이터 소스를 사용하여 Cloud Storage, Google 드라이브 또는 Cloud Bigtable 등에 저장된 BigQuery 스토리지 외부의 데이터에 대해 BigQuery 쿼리를 실행할 수도 있습니다. 하지만 이러한 소스는 BigQuery 작업에 최적화되어 있지 않으므로 BigQuery 스토리지에 저장된 데이터처럼 작동하지 않을 수 있습니다.

유지보수

BigQuery는 완전 관리형 서비스로, BigQuery 엔지니어링 팀이 업데이트와 유지보수를 담당합니다. 업그레이드 중에는 대개 다운타임이 발생하거나 시스템 성능이 저하되지 않습니다.

기존 시스템 대부분은 데이터 블록을 다시 셔플 및 정렬하고 공간을 복구하는 작업을 다양한 주기로 실행하기 위해 리소스 집약적인 격리 처리가 필요합니다. BigQuery에서는 스토리지 엔진이 데이터 저장 및 복제 방법을 지속적으로 관리 및 최적화하므로 격리 처리에 해당하는 과정이 없습니다. 또한 BigQuery는 테이블에 색인을 사용하지 않으므로 색인을 다시 작성할 필요가 없습니다.

백업 및 복구

BigQuery는 서비스 수준에서 백업 및 재해 복구를 수행합니다. 또한 BigQuery는 테이블의 전체 변경 내역을 7일 치만큼 유지하므로 데이터의 특정 시점 스냅샷을 쿼리할 수 있습니다. 백업에서 복구를 요청할 필요 없이 변경 사항을 간편하게 되돌릴 수 있습니다. (테이블이 명시적으로 삭제되면 2일 뒤 해당 테이블의 내역이 완전히 지워집니다. 이 문서 작성 시점을 기준으로 스냅샷 기능은 이전 SQL에서만 지원됩니다.)

워크플로 관리

이 섹션에서는 BigQuery의 데이터세트 구성, 권한 부여, 온보딩 작업 등의 관리 작업에 대해 다루며 또한 동시 실행 작업 부하를 관리하고, 데이터 웨어하우스의 상태를 모니터링하고, 사용자 액세스를 감사하는 방법에 대해서도 설명합니다.

데이터세트 구성

데이터의 클래스 또는 비즈니스 단위를 기반으로 데이터세트를 개별 프로젝트로 분류하거나 단순화를 위해 공통 프로젝트로 통합할 수 있습니다.

정의한 임의의 제한된 역할로 데이터 분석가를 초대하여 기존 데이터세트에서 공동작업할 수 있습니다. 데이터 분석가가 BigQuery 웹 UI에 로그인하면 프로젝트에서 공유된 데이터세트만 표시됩니다. 각 데이터세트에서 수행할 수 있는 작업은 각 데이터세트에서의 역할에 따라 다릅니다.

권한 부여

기존의 RDBMS 시스템에서는 SQL 권한을 만들고 데이터베이스 시스템 내의 지정된 사용자에게 적용하여 테이블을 보거나 수정하는 권한을 부여합니다. 또한 일부 RDBMS 시스템에서는 LDAP와 같은 외부 디렉터리의 사용자에게 권한을 부여할 수 있습니다. BigQuery에서 사용자 및 권한을 관리하는 모델은 이 경우와 비슷합니다.

BigQuery는 리소스에 대한 액세스를 제어하기 위해 사전 정의된 역할을 제공합니다. 또한 정의된 권한 세트로 구성된 커스텀 Cloud IAM 역할을 생성한 다음 이 역할을 사용자 또는 그룹에 할당할 수도 있습니다. 역할을 Google 이메일 주소 또는 G Suite 그룹에 할당할 수 있습니다.

데이터 웨어하우스 운영에서 중요한 측면은 서로 다른 사용자 그룹에 동일한 그룹에 공유되지만 제한된 액세스를 허용하는 것입니다. 예를 들어 재무, 인사, 마케팅 부서는 모두 동일한 테이블에 액세스할 수 있지만 액세스 수준은 서로 다릅니다. 기존의 데이터 웨어하우징 도구는 행 수준 보안을 시행하여 이를 실현합니다. BigQuery에서는 승인된 뷰행 수준 권한을 정의하여 동일한 결과를 얻을 수 있습니다.

온보딩

기존에 새로운 데이터 분석가를 온보딩하는 데는 상당한 리드 타임이 필요했습니다. 분석가가 단순한 쿼리를 실행할 수 있게 하려면 데이터 소스가 어디에 있는지 알려주고, ODBC 연결 및 도구와 액세스 권한을 설정해야 했습니다. GCP를 사용하면 분석가가 생산성을 향상시키는 데 필요한 시간을 크게 단축할 수 있습니다.

GCP에서 분석가를 온보딩하려면 관련 프로젝트에 대한 액세스 권한을 부여하고, 분석가를 Google Cloud Platform Console 및 BigQuery 웹 UI에 초대하고, 데이터에 익숙해질 수 있도록 일부 쿼리를 공유합니다.

  • GCP Console은 GCP 환경의 모든 애셋에 대한 중앙 집중식 뷰를 제공합니다. 데이터 분석가와 가장 관련이 큰 애셋은 Cloud Storage 버킷으로, 여기서 분석가는 파일로 공동작업할 수 있습니다.
  • BigQuery 웹 UI는 분석가가 액세스할 수 있는 데이터세트 목록을 표시합니다. 분석가는 메타데이터 보기, 데이터 미리보기, 쿼리 실행, 저장, 공유와 같이 GCP Console에서 부여한 역할에 따라 작업을 수행할 수 있습니다.

작업 부하 및 동시 실행 관리

BigQuery는 프로젝트당 적절한 할당량을 적용하고 최대 요청 수신 비율을 제한합니다. 구체적인 정책은 리소스 가용성, 사용자 프로필, 서비스 사용 기록 등 기타 요인에 따라 다릅니다. 자세한 내용은 BigQuery 할당량 정책을 참조하세요.

BigQuery는 2가지 유형의 쿼리 우선순위인 대화형 쿼리와 일괄 쿼리를 제공합니다. 기본적으로 BigQuery는 대화형 쿼리를 실행하기 때문에 쿼리가 가능한 즉시 실행됩니다. 대화형 쿼리는 쿼리 할당량에 반영됩니다. 일괄 쿼리는 유휴 리소스를 사용할 수 있게 되는 대로 보통 몇 분 내에 큐에 포함되어 실행됩니다.

BigQuery는 양방향 또는 일괄 쿼리의 우선순위 세분화를 지원하지 않습니다. BigQuery 작업의 속도와 규모 덕분에 기존 작업 부하 문제의 대부분은 발생하지 않습니다. 명시적인 쿼리 우선순위가 필요할 경우 민감한 작업 부하를 명시된 수의 예약된 슬롯이 있는 프로젝트로 분리할 수 있습니다. 정액제 고객이 되려면 Google 담당자에게 문의하세요.

모니터링 및 감사

다양한 차트와 알림이 BigQuery 측정항목 기반으로 정의되는 Stackdriver를 사용하여 BigQuery를 모니터링할 수 있습니다. 예를 들어 쿼리 시간 측정항목을 사용하여 시스템 처리량을 모니터링하거나 할당된 슬롯 측정항목을 기반으로 쿼리 요구 사항 경향을 시각화할 수 있습니다. 까다로운 쿼리를 사전에 계획해야 하는 경우 사용 가능한 슬롯 측정항목을 사용할 수 있습니다. 시스템 상태를 적극적으로 관리하기 위해 정의한 기준을 기반으로 알림을 생성할 수 있습니다. Stackdriver는 셀프 서비스 웹 기반 포털을 제공하며 Stackdriver 계정을 통해 포털에 대한 액세스를 제어할 수 있습니다.

BigQuery는 사용자 작업의 감사 로그를 자동으로 생성합니다. 감사 로그를 배치의 다른 BigQuery 데이터세트로 또는 데이터 스트림으로 내보내고 원하는 분석 도구를 사용하여 로그를 시각화할 수 있습니다. 자세한 내용은 BigQuery를 이용한 감사 로그 분석을 참조하세요.

데이터 관리

이 섹션에서는 스키마 설계 고려 사항, 비정규화, 파티션 나누기의 작동 원리와 BigQuery에 데이터를 로드하는 방법에 대해 설명합니다. 이 섹션의 뒷부분에서는 분석 다운타임을 제로로 유지하면서 웨어하우스 내의 변경 사항을 처리하는 방법에 대해 알아봅니다.

스키마 설계

다음 일반 가이드라인에 따라 BigQuery에 최적인 스키마를 설계하세요.

  • 최적 쿼리의 이점에 비해 데이터 조작, 즉 UPDATEDELETE 작업의 비용이 많이 든다는 명백한 근거가 없을 경우 크기가 10GB 이상인 측정기준 테이블을 비정규화합니다.
  • 테이블이 UPDATEDELETE 작업을 빈번히 수행할 경우 크기가 10GB 미만인 측정기준 테이블을 정규화 상태로 유지합니다.
  • 비정규화된 테이블 내의 중첩 및 반복 필드를 최대한 활용합니다.

비정규화

데이터를 비정규화하는 일반적인 방법은 팩트를 측정기준과 함께 플랫 테이블 구조로 작성하는 것입니다. 예를 들어 영업 거래의 경우 레코드에 각 팩트를 주문 및 고객 정보 등 연관된 측정기준과 함께 작성합니다.

그 반면 선호되는 데이터 비정규화 방법은 JSON 또는 Avro 입력 데이터 내의 중첩 및 반복 구조에 대한 BigQuery의 기본 지원을 활용합니다. 중첩 및 반복 구조를 사용하여 레코드를 나타내면 기반 데이터를 더욱 자연스럽게 표현할 수 있습니다. 영업 주문의 경우 JSON 구조의 바깥 부분에는 주문 및 고객 정보가 포함되어 있고, 구조의 안쪽 부분에는 중첩 및 반복 요소로 나타나는 주문의 개별 항목이 포함되어 있습니다.

{
  "orderID": "ORDER",
  "custID": "EMAIL",
  "custName": "NAME",
  "timestamp": "TIME",
  "location": "LOCATION",
  "purchasedItems": [
    {
      "sku": "SKU",
      "description": "DESCRIPTION",
      "quantity": "QTY",
      "price": "PRICE"
    },
    {
      "sku": "SKU",
      "description": "DESCRIPTION",
      "quantity": "QTY",
      "price": "PRICE"
    }
  ]
}

중첩 및 반복 필드를 사용하여 레코드를 나타내면 JSON 또는 Avro 파일을 사용하여 데이터 로드를 단순화할 수 있습니다. 이러한 스키마를 생성한 다음에는 개별 필드에서 SELECT, INSERT, UPDATE, DELETE 작업을 Order.Item.SKU와 같은 점 표기법으로 수행할 수 있습니다. 예시는 BigQuery 문서를 참조하세요.

비정규화의 장점

BigQuery는 본질적으로 분석 엔진으로 DML 작업을 지원하지만 온라인 트랜잭션 처리(OLTP) 저장소로 사용하기 위해 고안된 것은 아닙니다. 데이터 변경에 대한 논의는 제로 분석 다운타임을 유지하면서 변경 사항을 처리하고 최적의 온라인 분석 처리(OLAP) 성능을 제공하는 방법에 대한 지침을 제공합니다. 별표나 눈송이 스키마와 같이 정규화된 데이터 또는 부분 정규화된 데이터 구조는 업데이트/삭제 작업에 적합하지만 OLAP 작업 부하에는 적합하지 않습니다. 정규화된 테이블에 OLAP 작업을 수행할 경우 필요한 집계를 수행하기 위해 여러 개의 테이블을 조인해야 합니다. 조인은 BigQuery를 통해 수행할 수 있고 소규모 테이블에서는 권장되기도 하지만 일반적으로 비정규화된 구조만큼 성능이 좋지는 않습니다.

다음 그래프는 테이블 크기와 관련하여 조인을 사용하는 쿼리 성능을 단순 필터와 비교합니다. 조인을 사용할 경우 쿼리 성능은 훨씬 급격하게 감소합니다.

조인과 필터를 사용한 쿼리 시간 비교

비정규화의 단점

비정규화된 스키마는 스토리지에 최적화되지는 않았지만 BigQuery는 저장용량 비용이 낮으므로 스토리지의 비효율성에 대해 우려하지 않아도 됩니다. 쿼리 속도의 이점과 비용을 비교하여 스토리지가 중요한 요소가 아닌 이유를 알아볼 수 있습니다.

비정규화된 스키마로 작업할 때의 어려움 중 하나는 데이터 무결성을 유지하는 것입니다. 변경 빈도와 범위에 따라 데이터 무결성을 유지하기 위해 테스트와 검증에 소요되는 머신 시간이 증가할 수 있으며 때로는 작업자 시간도 증가할 수 있습니다.

테이블 파티션 나누기

BigQuery는 날짜별 테이블 파티션 나누기를 지원합니다. 테이블 작성 프로세스 중 파티션을 나누기를 사용 설정할 수 있습니다. BigQuery는 추가 유지보수가 필요 없는 새로운 날짜 기반 파티션을 자동으로 생성합니다. 또한 파티션의 데이터 만료 시간을 지정할 수 있습니다.

파티션을 나눈 테이블에 삽입되는 새 데이터는 삽입 시 원시 파티션에 기록됩니다. 데이터가 로드되는 파티션을 명시적으로 제어하기 위해 로드 작업에서 특정 날짜 파티션을 지정할 수 있습니다.

데이터 로드

분석 작업 부하를 위해 BigQuery에 데이터를 로드하기 전에 데이터는 일반적으로 원본의 기본 형식으로 Cloud Storage 제품에 저장됩니다. GCP 마이그레이션의 초기 단계에서 일반적인 패턴은 기존의 추출, 변환, 로드(ETL) 도구를 사용하여 데이터를 BigQuery에 적합한 스키마로 변환하는 것입니다. 데이터를 변환하면 데이터는 CSV, JSON, 또는 Avro 파일로 Cloud Storage에 전송되며 여기에서 로드 작업 또는 스트리밍을 사용하여 BigQuery에 로드됩니다. 또는 기존 온프레미스 데이터 스토리지의 기본 스키마를 사용해 Cloud Storage에 파일을 전송하고 BigQuery의 스테이징 테이블세트에 로드한 다음 BigQuery SQL 명령을 사용하여 BigQuery에 적합한 스키마로 변환할 수 있습니다. 이 2가지 접근법을 시각화하면 다음과 같습니다.

데이터 로드에 대한 첫 번째 접근법

데이터 로드에 대한 두 번째 접근법

GCP 사용 공간을 확장함에 따라 Cloud Bigtable, Cloud Datastore 또는 Cloud Spanner에서 소스 데이터를 직접 캡처하고 Cloud Dataflow를 사용하여 배치 또는 스트림 방식으로 BigQuery에 데이터를 ETL 처리할 수 있습니다.

직접 소스 코드 캡처

로드 작업 사용

이 섹션에서는 데이터가 지원되는 파일 형식의 파일 모음으로 Cloud Storage에 있다고 가정합니다. 각 데이터 형식에 대한 자세한 내용과 형식을 선택할 때 고려해야 하는 특정 요구 사항 및 기능은 BigQuery 데이터 형식을 참조하세요.

--field_delimiter 플래그를 사용하여 CSV 외에 쉼표가 아닌 구분 기호를 사용하는 데이터 파일을 사용할 수도 있습니다. 자세한 내용은 bq load 플래그를 참조하세요.

BigQuery는 gzip 압축 파일 로드를 지원하지만 압축 파일 로드는 압축되지 않은 파일 로드만큼 빠르지 않습니다. 시간에 민감한 시나리오 또는 압축되지 않은 파일을 Cloud Storage로 전송하는 대역폭 또는 시간에 제약이 있는 시나리오의 경우 빠른 로딩 테스트를 수행하여 가장 효과적인 대안을 확인하세요.

로드 작업은 비동기적이므로 작업이 실행되는 동안 클라이언트 연결을 유지할 필요가 없습니다. 무엇보다도 로드 작업은 다른 BigQuery 리소스에 영향을 미치지 않습니다.

로드 작업은 대상 테이블이 없는 경우 대상 테이블을 만듭니다.

BigQuery는 다음과 같이 데이터 스키마를 결정합니다.

  • 데이터가 자기 기술형인 Avro 형식일 경우 BigQuery는 스키마를 직접 결정할 수 있습니다.
  • 데이터가 JSON 또는 CSV 형식일 경우 BigQuery는 스키마를 자동 감지할 수 있지만 수동 확인이 권장됩니다.

스키마를 인수로 로드 작업에 전달하여 스키마를 명시적으로 지정할 수 있습니다. 진행 중인 로드 작업은 초기 로드와 동일한 절차를 사용하여 동일한 테이블에 추가할 수 있지만 각 작업에 스키마를 전달할 필요가 없습니다.

CSV 파일에 초기 로드 및 테이블 생성 이후 무시해야 하는 헤더 행이 항상 포함되어 있을 경우 --skip_leading_rows 플래그를 사용하여 행을 무시할 수 있습니다. 자세한 내용은 bq load 플래그를 참조하세요.

BigQuery는 프로젝트 및 테이블당 수행할 수 있는 로드 작업의 수와 크기에 대한 일일 제한을 설정합니다. 또한 BigQuery는 개별 로드 파일 및 레코드 크기에 대한 제한도 설정합니다. 자세한 내용은 할당량 정책을 참조하세요.

BigQuery 웹 UI를 통해 로드 작업을 실행할 수 있습니다. 프로세스를 자동화하기 위해 지정된 버킷에서 새로 도착한 파일과 관련된 Cloud Storage 이벤트를 수신 대기하고 BigQuery 로드 작업을 실행하도록 Cloud Functions를 설정할 수 있습니다.

스트리밍 삽입 사용

대체 및 보완적인 접근법으로 데이터를 BigQuery로 직접 스트리밍할 수도 있습니다. 스트리밍된 데이터는 즉시 사용할 수 있고 기존 테이블 데이터와 함께 실시간으로 쿼리할 수 있습니다.

사기 행위 감지 또는 시스템 측정항목 모니터링과 같이 실시간 정보의 이점을 활용할 수 있는 상황에서 스트리밍은 중요한 차별화 요소가 될 수 있습니다. 하지만 BigQuery에서 무료로 수행할 수 있는 로드 작업과는 달리 스트리밍 데이터에는 비용이 청구되므로 이점이 비용보다 중요한 상황에서는 스트리밍을 사용하는 것이 좋습니다.

BigQuery 테이블에 데이터를 스트리밍할 때 BigQuery API를 사용하여 레코드를 BigQuery에 직접 전송합니다. 또한 GCP의 로깅 서비스인 Logging을 사용할 경우 App Engine의 요청 로그와 Logging으로 전송된 커스텀 로그 정보를 포함한 GCP 프로젝트의 로그를 BigQuery에 직접 스트리밍{/}할 수 있습니다.

변경 관리

많은 데이터 웨어하우스는 엄격한 서비스수준계약(SLA) 하에서 작동하므로 다운타임이 거의 없습니다. Google은 BigQuery의 업타임을 관리하지만 고객은 데이터의 변경을 반영하는 접근법을 통해 데이터세트의 가용성과 대응력을 제어합니다.

BigQuery의 모든 테이블 수정 사항은 ACID를 준수합니다. 이는 DML 작업, 대상 테이블이 있는 쿼리, 로드 작업에 적용됩니다. 사용자 쿼리를 처리하는 동안 삽입, 업데이트, 삭제를 거치는 테이블은 동시 실행을 원활하게 처리하고 원자적 방식으로 하나의 상태에서 다음 상태로 전환합니다. 따라서 테이블을 수정해도 다운타임이 필요하지 않습니다. 하지만 내부 프로세스에서 새로 갱신된 데이터를 분석에 사용하기 전에 테스트 및 검증 단계가 필요할 수 있습니다. 또한 DML 작업은 슬롯을 두고 분석 작업 부하와 경쟁하기 때문에 격리하는 것이 좋습니다. 이러한 이유로 다운타임이 필요할 수 있습니다. 이 문서에서는 BigQuery 서비스 다운타임과의 혼동을 방지하기 위해 '분석 다운타임'이라는 용어를 사용합니다.

기존의 입증된 기술 대부분을 적용하여 분석 다운타임을 처리할 수 있습니다. 이 섹션에서는 알려진 문제점 및 해결 방법 중 일부를 살펴봅니다.

슬라이딩 시간 윈도우

기존의 데이터 웨어하우스는 데이터 레이크와는 달리 고정된 기간(예: 지난 5년)의 데이터만 보관합니다. 각 업데이트 주기마다 새로운 데이터가 웨어하우스에 추가되고 가장 오래된 데이터는 롤오프되어 고정된 기간을 유지합니다. 대부분의 경우 이 개념은 이전 기술의 한계를 극복하기 위해 채택되었습니다.

BigQuery는 규모에 맞게 설계되었으며 웨어하우스 크기가 증가함에 따라 확장할 수 있으므로 이전 데이터를 삭제할 필요가 없습니다. 전체 내역을 유지함으로써 비즈니스에 대한 유용한 정보를 더 많이 제공할 수 있습니다. 스토리지 비용이 우려될 경우 BigQuery의 장기 스토리지 가격 책정을 활용하여 이전 데이터를 보관하고 필요할 때 특수 분석에 사용할 수 있습니다. 이전 데이터를 삭제해야 할 합당한 이유가 있는 경우 날짜로 파티션을 나눈 테이블파티션 만료에 대한 BigQuery의 기본 지원을 사용할 수 있습니다. 즉, BigQuery는 이전 데이터를 자동으로 삭제할 수 있습니다.

스키마 변경

데이터 웨어하우스를 설계하고 개발하는 동안 열을 추가, 업데이트 또는 삭제하거나, 전체 테이블을 추가 또는 삭제하여 테이블 스키마를 수정하는 것이 일반적입니다. 변경 내용이 추가된 열 또는 테이블 형식이 아닐 경우 삭제된 테이블, 이름이 변경된 열 등을 참조하는 저장된 쿼리와 보고서 등이 손상될 수 있습니다.

데이터 웨어하우스가 프로덕션 단계일 경우 이러한 변경 사항에는 엄격한 변경 제한이 적용됩니다. 분석 다운타임 동안 사소한 스키마 변경을 처리하기로 결정할 수 있지만 대부분의 경우 스키마 변경 사항은 버전 업그레이드 시 반영되도록 예약됩니다. 이전 버전의 데이터 웨어하우스가 분석 작업 부하를 처리하는 동안 동시에 업그레이드를 설계, 개발, 테스트하도록 하세요. BigQuery 데이터 웨어하우스에 스키마 변경 사항을 적용할 때도 동일한 접근법을 따릅니다.

지연 변경 측정기준

정규화된 데이터 스키마는 측정기준 테이블의 변경 사항을 격리하여 지연 변경 측정기준(SCD)의 영향을 최소화합니다. 이는 일반적으로 SCD가 플랫 팩트 테이블에 대한 광범위한 업데이트를 야기할 수 있는 비정규화된 스키마보다 선호됩니다. 하지만 스키마 설계 섹션에서 살펴본 것처럼 BigQuery에서는 정규화를 신중하게 사용해야 합니다.

SCD에 관해서는 모든 상황을 충족하는 단일 해결책이 존재하지 않습니다. 변경 사항의 특성을 이해하고 문제점에 가장 적합한 해결책 또는 그 조합을 적용하는 것이 중요합니다. 이 섹션의 나머지 부분에서는 몇 가지 해결책을 살펴보고 이를 SCD 유형에 적용하는 방법에 대해 살펴보겠습니다.

기술 1: 뷰 전환

이 기술은 데이터의 두 가지 뷰인 '메인'과 '섀도'를 기반으로 합니다. 실제 테이블을 숨기고 사용자에게는 '메인' 뷰를 노출하는 기능입니다. 업데이트 주기 중 '섀도' 뷰가 생성/업데이트되고 데이터 정확성 테스트가 수행되는 동안 사용자는 '메인' 뷰로 작업합니다. 전환 시점에 '메인' 뷰가 '섀도' 뷰로 전환됩니다. 이전의 '메인'인 현재의 '섀도' 뷰는 조직에서 정의한 규칙과 프로세스에 따라 다음 업데이트 주기 이전에 해제하거나 일부 워크플로에서 유지할 수 있습니다.

두 뷰는 공통 테이블을 기반으로 하고 'view_type' 등의 열로 구분하거나 서로 다른 테이블을 기반으로 할 수 있습니다. 전자의 경우 테이블의 '섀도' 뷰에 대한 DML 작업으로 인해 실질적인 이점은 얻지 못한 채 '메인' 뷰에 대한 사용자 쿼리의 속도가 느려질 수 있으므로 권장되지 않습니다.

뷰 전환은 제로 분석 다운타임을 제공하지 않지만 업데이트 주기 중 두 개의 데이터 사본이 존재하기 때문에 비용이 많이 듭니다. 무엇보다도 업데이트 주기가 90일보다 잦을 경우 이 방법으로 인해 조직이 장기 스토리지 가격 책정의 이점을 얻지 못할 수 있습니다. 90일은 이 문서 작성 시점의 가격 책정 정책을 기반으로 합니다. 최신 정책을 확인하세요.

데이터의 서로 다른 세그먼트가 별도의 주기로 변경되는 경우가 있습니다. 예를 들어 북미 지역의 영업 데이터는 매일 업데이트되고, 아시아 태평양 지역의 영업 데이터는 격주로 업데이트될 수 있습니다. 이 경우 변경 사항의 주요 요소(이 경우 국가)를 기반으로 테이블의 파티션을 나누는 것이 좋습니다. 그러면 전체 데이터 웨어하우스가 아니라 영향을 받은 파티션에 뷰 전환이 적용됩니다. 이 문서의 작성 시점에는 국가와 같은 커스텀 데이터 속성만을 기반으로 데이터를 명시적으로 여러 테이블로 분리하여 파티션을 나눌 수 있습니다.

기술 2: 인플레이스(In-Place) 파티션 로드

데이터의 변경 사항을 파티션으로 격리하고 짧은 분석 다운타임을 허용할 경우 뷰 전환이 불필요할 수 있습니다. 그 대신 영향을 받은 파티션의 데이터를 다른 BigQuery 테이블에 스테이징하거나 Cloud Storage 내의 파일로 내보내 분석 다운타임 중에 교체할 수 있습니다.

타겟 파티션의 데이터를 다른 테이블의 쿼리 데이터로 교체하려면 다음을 실행하세요.

bq query --use_legacy_sql=false --replace \
         --destination_table 'flight_data.fact_flights_part$20140910' \
         'select * from `ods.load_flights_20140910`

Cloud Storage에서 로드하여 타겟 파티션의 데이터를 교체하려면 다음을 실행하세요.

bq load  --replace \
         --source_format=NEWLINE_DELIMITED_JSON
         'flight_data.fact_flights_part$20140910' \
         gs://{bucket}/load_flights_20140910.json
기술 3: 업데이트 데이터 마스킹

자주 변경되는 소규모 측정기준은 정규화의 우선 대상입니다. 이 기술에서 이러한 측정기준으로 업데이트하면 나머지 데이터와 조건부로 결합되는 격리된 테이블 또는 뷰로 스테이징됩니다.

SELECT f.order_id as order_id, f.customer_id as customer_id,
    IFNULL(u.customer_first_name, f.customer_first_name) as customer_first_name,
    IFNULL(u.customer_last_name, f.customer_last_name) as customer_last_name
FROM fact_table f
LEFT OUTER JOIN pending_customer_updates u
ON f.customer_id = u.customer_id
SCD 유형 1: 속성 값 덮어쓰기

유형 1 SCD는 변경 내역을 유지하지 않고 속성 값을 새로운 데이터로 덮어씁니다. 예를 들어 '완벽한 모이스처라이저 크림' 제품이 '건강/미용' 카테고리에 해당하고 현재 '화장품' 카테고리로 분류될 경우 변경 사항은 다음과 같습니다.

이전:

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC 완벽한 모이스처라이저 크림 - 100oz 건강/미용

이후:

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC 완벽한 모이스처라이저 크림 - 100oz 건강/미용
화장품

속성이 정규화된 측정기준 테이블에 있을 경우 변경 내용이 완전히 격리됩니다. 측정기준 테이블에서 영향을 받은 행을 업데이트하면 됩니다. 자주 발생하는 유형 1 업데이트가 포함된 소규모 측정기준 테이블에 대해서는 기술 3: 업데이트 데이터 마스킹을 참조하세요.

속성이 팩트 테이블 내에 비정규화된 방식으로 포함되어 있을 경우 변경 사항이 광범위하게 적용됩니다. 속성이 반복되는 모든 팩트 행을 업데이트해야 합니다. 이러한 경우 기술 2: 인플레이스(In-Place) 파티션 로드 또는 기술 1: 뷰 전환을 사용하세요.

SCD 유형 2: 속성 값 변경 및 변경 내역 유지

이 방법은 개별 서로게이트 키를 통해 특정 자연 키에 대한 여러 레코드를 만들어 이전 데이터를 무한하게 추적합니다. 예를 들어 SCD 유형 1에서 살펴본 동일한 변경 사항을 다음과 같이 처리합니다.

이전:

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY START_DATE END_DATE
123 ABC 완벽한 모이스처라이저 크림 - 100oz 건강/미용 2009년 1월 31일 NULL

이후:

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY START_DATE END_DATE
123 ABC 완벽한 모이스처라이저 크림 - 100oz 건강/미용 2009년 1월 31일 2017년 7월 18일
124 ABC 완벽한 모이스처라이저 크림 - 100oz 화장품 2017년 7월 19일 NULL

속성이 정규화된 측정기준 테이블에 있을 경우 변경 내용이 격리됩니다. 이전 행을 업데이트하고 측정기준 테이블에 새 행을 추가하면 됩니다. 자주 발생하는 유형 1 업데이트가 포함된 소규모 측정기준 테이블에 대해서는 기술 3: 업데이트 데이터 마스킹을 참조하세요.

속성이 팩트 테이블 내에 비정규화된 방식으로 포함되어 있을 경우, 해당 값에 명시적인 시작 및 종료 날짜를 유지하지 않고 트랜잭션 날짜를 사용한다면 더욱 편리할 수 있습니다. 이전 트랜잭션이 발생한 날짜 및 시간에만 이전 값이 적용되므로 이전 팩트 테이블 행을 변경할 필요가 없습니다. 팩트 테이블의 모습은 다음과 같습니다.

TRANSACTION_DATE PRD_SK PRD_ID PRD_DESC PRD_CATEGORY UNITS AMOUNT
2017년 7월 18일 123 ABC 완벽한 모이스처라이저 크림 - 100oz 건강/미용 2 25.16
2017년 7월 19일 124 ABC 완벽한 모이스처라이저 크림 - 100oz 화장품 1 13.50

데이터 쿼리

BigQuery는 표준 SQL 쿼리를 지원하고 ANSI SQL 2011과 호환됩니다. BigQuery의 SQL 참조는 지원되는 모든 함수, 연산자, 정규식 기능에 대한 포괄적인 설명을 제공합니다.

BigQuery는 중첩 및 중복 필드를 데이터 모델의 일부로 지원하므로 이러한 필드 유형을 지원하도록 SQL 지원이 확장되었습니다. 예를 들어 GitHub 공개 데이터세트를 사용하여 UNNEST 명령어를 실행해 중복 필드를 반복할 수 있습니다.

SELECT
  name, count(1) as num_repos
FROM
  `bigquery-public-data.github_repos.languages`, UNNEST(language)
GROUP BY name
ORDER BY num_repos
DESC limit 10

대화형 쿼리

BigQuery 웹 UI를 사용하면 데이터세트에 대화형 쿼리를 수행하고 액세스 가능한 프로젝트 전체에 걸쳐 통합된 데이터세트 뷰를 제공할 수 있습니다. 또한 콘솔은 임시 쿼리 저장 및 공유, 이전 쿼리 미세 조정 및 편집, 테이블 및 스키마 검색, 테이블 메타데이터 수집 등 여러 가지 유용한 기능을 제공합니다. 자세한 내용은 BigQuery 웹 UI를 참조하세요.

BigQuery 웹 UI 화면 캡처

자동화된 쿼리

일정/이벤트를 기반으로 쿼리 실행을 자동화하고 나중에 소비할 수 있도록 결과를 캐시하는 것이 일반적입니다.

Airflow를 사용하여 다른 자동화된 작업을 조정하고 이미 도구에 익숙할 경우 이 작업에 BigQuery용 Apache Airflow API를 사용하세요. 이 블로그 글에서는 Airflow를 설치하고 BigQuery 워크플로를 생성하는 과정을 안내합니다.

더욱 간단한 조정을 위해 크론 작업을 사용할 수도 있습니다. 이 블로그 글에서는 쿼리를 App Engine 앱으로 캡슐화하고 예약된 크론 작업으로 실행하는 방법을 안내합니다.

쿼리 최적화

BigQuery가 쿼리를 실행할 때마다 전체 열 스캔을 실행합니다. BigQuery는 색인을 사용하거나 지원하지 않습니다. BigQuery 성능 및 쿼리 비용은 쿼리 중 스캔한 데이터 양을 기반으로 하기 때문에 쿼리와 연관된 열만을 참조하도록 쿼리를 설계해야 합니다. 날짜로 파티션을 나눈 테이블을 사용할 경우 연관된 파티션만 스캔되도록 해야 합니다. PARTITIONTIME 또는 PARTITIONDATE 기반 파티션 필터를 사용하여 이를 수행할 수 있습니다.

쿼리를 실행한 후 성능의 특성을 이해하려면 세부적인 쿼리 계획 설명을 살펴봐야 합니다. 이 설명에서는 쿼리가 진행되는 단계, 각 단계에서 처리되는 입출력 행의 수, 각 단계 내의 타이밍 프로필을 세부적으로 분석합니다. 이 설명의 결과를 참조하면 쿼리를 이해하고 최적화하는 데 도움이 됩니다.

BigQuery 결과 화면 캡처

외부 소스

제휴 데이터 소스를 사용하여 BigQuery 외부에 존재하는 데이터에 대한 쿼리를 실행할 수 있지만 이 접근법에는 몇 가지 성능 전제 조건이 있습니다. 데이터를 반드시 외부에서 유지보수해야 하는 경우에만 제휴 데이터 소스를 사용해야 합니다. 또한 쿼리 제휴를 사용하여 외부 소스에서 BigQuery에 ETL을 수행할 수도 있습니다. 이 접근법을 사용하면 익숙한 SQL 구문을 사용하여 ETL을 정의할 수 있습니다.

사용자 정의 함수

BigQuery는 또한 SQL의 복잡성을 초과하는 쿼리에 사용자 정의 함수(UDF)를 지원합니다. UDF를 사용하면 내장된 SQL 함수를 확장할 수 있습니다. SQL 함수는 값 목록을 취하며 단일 값을 반환합니다. 값 목록은 어레이 또는 구조일 수 있으며 반환된 값 역시 어레이 또는 구조일 수 있습니다. UDF는 자바스크립트로 작성되며 암호화 또는 기타 라이브러리와 같은 외부 리소스를 포함할 수 있습니다.

쿼리 공유

BigQuery를 사용하면 공동작업자가 쿼리를 저장하고 팀원 간에 공유할 수 있습니다. 이 기능은 데이터 탐색 실습 또는 새로운 데이터세트 또는 쿼리 패턴을 빠르게 얻기 위한 수단으로 특히 유용합니다. 자세한 내용은 쿼리 저장 및 공유를 참조하세요.

데이터 분석

이 섹션에서는 BigQuery에 연결하고 데이터를 분석할 수 있는 다양한 방법을 소개합니다. BigQuery를 분석 엔진으로 최대한 활용하려면 BigQuery 스토리지에 데이터를 저장해야 합니다. 하지만 특정 사용 사례에서는 자체적으로 외부 소스를 분석하거나 BigQuery 스토리지의 데이터와 조인하여 이점을 얻을 수 있습니다.

상용 도구

이 문서의 작성 시점에서 베타 버전으로 제공되는 Google 데이터 스튜디오와 BigQuery에 이미 통합된 기타 파트너 도구를 사용하여 BigQuery에서 분석을 도출하고 정교한 대화식 데이터 시각화를 구축할 수 있습니다.

도구를 선택해야 하는 경우 Gartner의 Magic Quadrant 보고서G2 Crowd G2 점수 보고서의 포괄적인 공급업체 비교를 참고할 수 있습니다. Gartner 보고서는 Tableau 등의 여러 파트너 사이트에서 확인할 수 있습니다.

파트너 로고

커스텀 개발

BigQuery를 기반으로 커스텀 애플리케이션 및 플랫폼을 빌드하려면 대부분의 일반적인 프로그래밍 언어로 사용할 수 있는 클라이언트 라이브러리를 사용하거나 BigQuery의 REST API를 직접 사용할 수 있습니다.

구체적인 예시는 Python 라이브러리를 사용하여 BigQuery에 연결하고 커스텀 대화식 대시보드를 생성하는 이 가이드를 참조하세요.

타사 커넥터

API 수준에서 기본적으로 BigQuery와 통합되지 않은 애플리케이션에서 BigQuery에 연결하려면 BigQuery JDBC 및 ODBC 드라이버를 사용할 수 있습니다. 이러한 드라이버를 사용하면 이전 애플리케이션 또는 Microsoft Excel과 같이 쉽게 수정할 수 없는 애플리케이션에서 BigQuery와 상호작용할 수 있습니다. ODBC와 JDBC는 SQL을 사용하는 BigQuery와의 상호작용을 지원하지만 드라이버는 API를 직접 사용하는 것만큼 표현력이 좋지는 않습니다.

비용

대부분의 데이터 웨어하우스는 조직 내 여러 비즈니스 개체에 서비스를 제공합니다. 일반적인 당면 과제는 비즈니스 개체당 운영 비용을 분석하는 것입니다. 청구 비용을 분할하고 비용을 소비량에 따라 할당하는 방법에 대해서는 BigQuery와 데이터 스튜디오를 사용하여 GCP 비용 청구 시각화를 참조하세요.

BigQuery에는 로드, 스토리지, 쿼리 비용 등 3가지 기본 비용 측정기준이 있습니다. 이 섹션에서는 각 측정기준에 대해 자세히 설명합니다.

데이터 저장

스토리지 가격 책정은 초당 MB 단위로 계산됩니다.

연속으로 90일 동안 테이블을 수정하지 않으면 테이블이 장기 스토리지로 분류되어 해당 테이블 스토리지 가격이 한 달에 GB당 $0.01로 자동으로 50% 인하됩니다. 테이블이 장기 스토리지로 간주되더라도 성능, 내구성, 가용성 또는 기타 기능은 저하되지 않습니다. 테이블 내의 데이터가 수정되면 BigQuery는 테이블의 타이머를 재설정하고 테이블 내의 모든 데이터가 일반 스토리지 가격으로 돌아갑니다. 쿼리하고 뷰를 만드는 등 데이터를 직접 조작하지 않는 활동은 타이머를 재설정하지 않습니다.

자세한 내용은 BigQuery 스토리지 가격 책정을 참조하세요.

데이터 로드

기존의 로드 작업을 통해 BigQuery에 데이터를 무료로 로드할 수 있습니다. 데이터를 로드하면 앞서 설명한 대로 스토리지 비용을 지불해야 합니다.

스트리밍 삽입은 스트리밍되는 데이터의 양에 따라 비용이 청구됩니다. 자세한 내용은 BigQuery 스토리지 가격 책정의 스트리밍 삽입 가격을 참조하세요.

데이터 쿼리

BigQuery에서 쿼리에 적용하는 가격 책정 모델은 주문형과 정액제 2가지입니다.

주문형 가격 책정

주문형 모델의 경우 BigQuery는 쿼리 실행 중 액세스한 데이터의 양에 따라 비용을 청구합니다. BigQuery는 열 스토리지 형식을 사용하므로 쿼리와 관련된 열에만 액세스합니다. 매주 또는 매월 기준으로만 보고서를 실행하고 데이터 1TB 미만의 쿼리를 수행한 경우 매우 낮은 쿼리 비용이 청구될 수 있습니다. 쿼리 비용이 청구되는 방식에 대한 자세한 내용은 BigQuery 쿼리 가격 책정을 참조하세요.

웹 UI에서 쿼리 검사기를 사용하여 사전에 특정 쿼리가 스캔할 데이터의 양을 파악할 수 있습니다. 커스텀 개발의 경우 API 요청에서 dryRun 플래그를 설정하고 BigQuery가 작업을 실행하지 않는 대신 처리할 바이트 수와 같은 작업 통계를 반환하게 할 수 있습니다. 자세한 내용은 쿼리 API를 참조하세요.

쿼리 API

정액제 가격 책정

고정적인 월별 비용을 선호하는 고객은 정액제 가격을 선택할 수 있습니다. 자세한 내용은 BigQuery 정액제 가격 책정을 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...