BigQuery용 출시 체크리스트

소개

BigQuery용 출시 체크리스트에서는 Google BigQuery를 사용하는 상업 애플리케이션을 출시하기 전에 완료해야 할 활동을 권장합니다. BigQuery 관련 활동에 초점을 맞춘 체크리스트입니다. 또한 플랫폼 체크리스트인 Google Cloud Platform용 출시 체크리스트를 사용하여 모든 서비스에 적용되는 활동을 이해해야 합니다.

BigQuery용 출시 체크리스트는 BigQuery를 능숙하게 다룰 수 있는 개발자를 대상으로 제작되었습니다. BigQuery를 처음 시작하는 사용자의 경우, 이 안내는 BigQuery 사용 방법을 알려주지 않습니다.

이 체크리스트는 다음과 같은 섹션으로 나누어져 있습니다.

  • 아키텍처 설계 및 개발
  • 비공식 출시
  • 최종 출시

이 섹션은 애플리케이션 출시를 준비할 때 권장되는 순서대로 나열되어 있습니다. 가령, 아키텍처 설계 및 개발 체크리스트에는 앱 개발 주기의 초반에 권장되는 활동이 포함되어 있으므로 먼저 시작해야 합니다. 이와 마찬가지로 비공식 출시 체크리스트에는 출시에 임박한 시점에 권장되는 활동이 포함되어 있습니다. 단, 체크리스트 활동의 정확한 타임라인과 소요 시간은 개발자의 앱 개발 기간에 따라 다릅니다.

아키텍처 설계 및 개발 체크리스트

애플리케이션의 개발 초기 단계에 이 체크리스트를 사용하는 것이 좋습니다. 이러한 체크리스트 활동을 그룹별로 병행하여 진행할 수도 있지만 소프트웨어 아키텍처 관련 작업은 비교적 오랜 시간이 걸리기 때문에 가능하면 조기에 시작하는 것이 좋습니다.

활동
커뮤니티/그룹/포럼
❑  
Stack Overflow에서 BigQuery 커뮤니티 지원을 문의합니다. 정보와 유용한 조언을 얻을 수 있는 유익한 공간입니다.
❑  
BigQuery - 공지 그룹을 구독합니다.
스키마 설계
❑  
쿼리 필요성에 따라 스키마를 설계합니다. BigQuery는 중접 및 반복(유형: RECORD) 필드를 지원하여 비정규화된 테이블에서 논리적인 일대다 관계가 허용됩니다. 이 필드의 액세스 전략을 유지하며 적절한 경우 이를 활용합니다. 반복 필드의 일반적인 중첩 해제에 대한 논리적 보기를 만드는 것이 좋습니다. 쿼리 비용을 예상합니다.
❑  
반복 필드는 첫 번째 또는 두 번째 중첩 수준 이상으로 쿼리하기 어려울 수 있습니다. 사용 사례에 적합한 중첩 수준에 대해 고민해 보세요.
❑  
BigQuery에서도 조인이 기능하지만 비정규화로 일부 쿼리의 성능을 개선할 수 있습니다. 데이터 모델에서 조인 가능성이 중요한 위치에 대해 고려해 보세요.
❑  
BigQuery에서는 DML을 통해 테이블을 추가하거나 업데이트할 수 있습니다. DML은 단일 행의 수정이 아닌 일괄 업데이트, 삭제, 삽입을 위한 용도로 사용됩니다. 업데이트 패턴이 OLAP 시스템과 일치해야 합니다.
❑  
전통적인 RDBMS와 달리 기본/보조 또는 행-ID 키에 대한 개념이 없습니다. 필요한 경우 테이블 스키마에서 이러한 용도의 열을 식별합니다.
데이터 양 추정
❑  
초기 업로드 중에 업로드될 데이터 양을 계산해 기본적인 수준을 파악합니다.
❑  
점차적으로 업로드할 데이터 양과 속도(시간/일/주 단위)를 계산합니다.
❑  
만료되는 데이터 양(존재하는 경우)과 그 빈도를 계산합니다.
쿼리 처리 추정
❑  
매일 BigQuery 데이터세트에서 실행될 쿼리 유형을 식별합니다. Stackdriver Monitoring은 리소스 사용률, 동시 실행 쿼리, 데이터세트 크기에 유용한 진단을 제공합니다.
❑  
테이블 파티션 나누기/분할 전략을 결정합니다. 예를 들어 특정 날짜 중에 발행된 쿼리가 해당 날짜에 수집된 데이터와 관련된 경우 테이블을 매일 하나씩 만듭니다. 여러 날짜의 데이터를 집계하려면 테이블 와일드 카드 또는 \_PARTITIONTIME 유사 열을 사용해 쿼리를 실행합니다.
❑  
매일 BigQuery에서 처리될 데이터 양(쿼리 수 x 쿼리당 처리 데이터)을 계산합니다. BigQuery에서는 전체 행이 아닌 개별 행의 처리에 대한 요금이 부과되므로 계산 시이를 고려해야 합니다. 또한 쿼리에서 참조되는 열에서 전체 열 검색을 호출합니다.
할당량 관리
❑  
BigQuery의 기본 할당량을 이해합니다.
❑  
해당하는 경우 다음 영역의 할당량 분석을 수행합니다.
  • 데이터를 BigQuery에 로드하는 데 필요한 일별 로드 작업 수
  • BigQuery에 대한 테이블당 일별 로드 작업 수
  • 스트리밍 API를 사용하는 경우 스트리밍 삽입 수, 삽입의 행 크기, 초당 최대 행, 요청당 최대 행, 기타 스트리밍 API 관련 매개변수
  • 애플리케이션에서 BigQuery에 발행한 쿼리 수
  • 쿼리를 동시에 실행하는 데 사용된 동시 세션 수
  • BigQuery에서 데이터를 추출하기 위해 실행된 일별 내보내기 작업 수
  • BigQuery 작업을 호출하는 API도 비율 및 일 단위로 제한됩니다. 자세한 내용은 API 비율 한도를 참조하세요.
❑  
할당량이 부족하면 GWSC를 통해 파일 할당량을 조정합니다.
비용 분석
❑  
데이터 양과 쿼리 처리 추정값을 기반으로 BigQuery 가격 또는 가격 계산기를 사용하여 BigQuery 저장소와 처리 비용을 계산합니다.
❑  
다음 비용 최적화 권장사항을 고려해 보세요.
  • 쿼리에서 관련된 열만 선택합니다. BigQuery에서는 where 절의 필터와 상관없이 선택한 열을 대상으로 전체 열 검색을 실행하며 그에 대한 요금이 부과됩니다.
  • 파티션 나누기/분할을 통해 테이블을 더 작은 단위로 나누어 처리 비용을 최적화합니다. 최적화와 성능은 상충 관계일 때가 많습니다. 작은 테이블이 너무 많은 경우 쿼리에서 참조하는 각 테이블을 로드하는 과정에서 고정된 오버헤드가 발생해 성능에 영향을 미칠 수 있습니다.
  • 하나의 큰 테이블 대신 테이블의 작은 파티션에서 쿼리를 테스트합니다.
  • API를 사용하는 경우 dryRun 플래그를 사용해 쿼리 구문의 유효성을 확인하고 데이터 처리 통계를 얻습니다.
  • 쿼리할 필요가 없는 오래된 테이블을 삭제하거나 테이블에 expirationTime 속성을 사용합니다.
보안
❑  
BigQuery에 대한 IAM 정책을 신중하게 검토해 데이터세트 액세스 및 작업 실행 권한이 올바른지 확인합니다. 고려사항:
  • 프로젝트 구성원의 BigQuery 권한을 감사해 보안 정책을 준수하는지 확인합니다. bigquery.User 역할을 통해 사용자가 프로젝트에서 작업을 실행할 수 있는 반면 dataset.Viewer는 지정된 데이터세트의 모든 테이블 읽기 권한을 제어합니다. dataset.Editordataset.Owner는 사용자가 테이블 또는 데이터세트를 수정해야 할 경우에 한해 각각 부여됩니다.
  • 특정 데이터세트를 팀 구성원과 공유해야 한다면 공유 데이터세트 또는 명시적 IAM 역할을 사용합니다.
  • 보다 세부적인 보안을 요하는 경우에는 승인된 보기를 사용해 액세스를 제어해 보세요.
BigQuery 사전 데이터 처리
❑  
BigQuery에 데이터를 로드하기 전에 사전 처리하여 비용과 성능을 최적화해 보세요. 예를 들어 사용자는 다음을 할 수 있습니다.
  • 불필요한 타입캐스트 및 계산을 사전 처리합니다.
  • 빈도가 잦은 조인을 사전 연결합니다.
  • 측정항목과 자주 실행되는 분석을 사전 집계합니다.
❑  
BigQuery 자체, Cloud Dataflow, Cloud Dataproc, ETL 도구를 사용해 데이터를 사전 처리(변환, 비정규화 등)합니다.
❑  
동일 데이터세트를 다양한 쿼리 유형에 따라 다르게 구성한 여러 버전을 마련해 보세요.
❑  
테이블마다 DML 문에 일일 한도가 적용되므로 단계별 수정 배치를 통해 업데이트/삭제 계획을 세웁니다.
쿼리 미세 조정 및 테스트
❑  
예상되는 데이터 양으로 쿼리를 테스트하고 다음 원칙에 따라 미세 조정합니다.
  • select 절에서 불필요한 열을 생략해 비용을 절감하고 성능을 개선합니다.
  • 중첩 쿼리의 경우 where 절을 효과적으로 사용해 바깥쪽 쿼리에서 처리할 데이터가 줄어들도록 안쪽 쿼리의 데이터를 필터링합니다.
  • 최대한 내부까지 평면화를 적용하고 가능한 경우 WHERE 절도 함께 사용합니다.
  • regexp 등 복잡한 필터를 끝쪽으로 옮깁니다.
  • 해당하는 원본 데이터를 사용할 수 있는 경우 문자열을 그룹화하지 않고 타임스탬프와 문자열을 사용합니다.
  • 가장 바깥쪽 쿼리에 ORDER BYLIMIT를 사용해 보세요. 가능한 한 안쪽 쿼리에 ORDER BY를 사용하지 않습니다.
  • 왜곡된 (큰) 그룹을 다룰 때 GROUP BY를 사용하면 지연 시간이 늘어날 수 있습니다. 이를 필터링해 쿼리 성능을 개선합니다.
  • 자체 조인 대신 자체 조인보다 처리 오버헤드가 낮은 IF/CASE 또는 분석 SQL 함수를 사용해 보세요.
데이터 시각화
❑  
BigQuery는 큰 데이터세트의 데이터를 쿼리하는 도구입니다. 데이터 시각화를 위해 타사 도구와의 강력한 연결을 지원하고 있습니다.
  • Google 데이터 스튜디오
  • Google 스프레드시트 및 Microsoft Excel 등의 업무 생산성 도구
  • Tableau, BIME, Informatica 등의 상용 도구
  • redash 등의 오픈소스 대안

비공식 출시 체크리스트

애플리케이션의 상용 출시에 앞서 출시할 준비가 되었는지 테스트하기 위해 비공식 출시 체크리스트 활동을 사용하는 것이 좋습니다.

활동
❑  
스트리밍 API를 사용해 데이터를 로드하는 경우 할당량 위반 없이 데이터가 로드되도록 로드 테스트를 시뮬레이션합니다.
❑  
일괄 작업을 사용해 데이터를 로드하는 경우 할당량 위반 없이 합리적인 시간 내에 데이터가 BigQuery에 로드되도록 로드 테스트를 시뮬레이션합니다.
❑  
비용 모델을 실제 비용과 비교해 검토합니다. 운영 비용이 예산을 초과하지 않는지 확인합니다. 비용 모델을 수정합니다. Google Cloud Platform 가격 계산기에서 제공하는 추정치는 정확도가 우수한 편이지만 데이터 일일 처리량을 정확히 로드 테스트하기 전에는 확실한 값으로 볼 수 없습니다.

최종 출시 체크리스트

출시 직전과 출시 중에는 최종 출시 체크리스트를 사용합니다.

활동
❑  
지금까지 이 체크리스트를 따라 작업을 수행했다면 애플리케이션을 Google BigQuery에 성공적으로 출시할 준비가 된 것입니다. 수고하셨습니다. 또한 Google Cloud Platform용 출시 체크리스트최종 출시 체크리스트를 검토하는 것이 좋습니다.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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

도움이 필요하시나요? 지원 페이지를 방문하세요.