1. Big Query란?
- 확장성이 뛰어난 구글의 기업용 서버리스 기반의 데이터 웨어하우스, 표준 SQL을 지원하기 때문에 기존 SQL을 알고 있는 사용자도 손쉽게 사용 가능, 매월 무료로 최대 1TB 상당의 데이터를 분석하고 10GB의 데이터를 저장할 수 있음.
- 스토리지와 컴퓨팅이 분리되어 있기 때문에 데이터 웨어하우스의 용량을 원하는 대로 계획할 수 있는 탄력적인 확장성을 가짐.
- 내부적으로 관리형 열 형식 스토리지, 대량 동시 실행, 자동 성능 최적화 기능을 제공
- 데이터 크기에 관계없이 클라우드 데이터 레이크를 구축하고 동시에 빠르게 분석할 수 있음.
- 기존 ETL 도구와의 연동도 지원(GCS, 구글 시트, 구글 드라이브, 인포메티카, 탈랜드)
- BI 도구와 자체적으로 BI Engine을 지원하여 누구나 손쉽게 보고서와 대시보드를 만들 수 있음(태블로, 마이크로스트레티지, 루커, 데이터 스튜디오)
- 모든 배치와 스트리밍 데이터를 분석, 강력한 스트리밍 수집 기능은 실시간으로 데이터를 캡쳐하고 분석해 통계를 항상 최신의 상태로 유지
- ML을 이용하면 SQL 쿼리를 통해 ML 모델을 학습시키는 것이 가능, 클라우드 ML 엔진 및 텐서플로와도 통합이 가능
2. Big Query 개요
- 스토리지와 컴퓨팅의 분리
- 필요에 따라서 스토리지와 컴퓨팅을 모두 독립적으로 확장 가능
- 쿼리를 실행하면 쿼리 엔진이 여러 작업자에 작업을 동시에 분산하여 스토리지의 관련 테이블을 스캔하고 쿼리를 처리
2-1 Big Query 스토리지 주요 기능
- 관리형 : 완전 관리형 서비스, 스토리지 리소스를 프로비저닝 하거나 스토리지 단위를 예약할 필요가 없음. 시스템에 데이터를 로드할 때 자동으로 할당, 사용한 스토리지 용량에 대해서만 비용을 지불, 가격은 컴퓨팅과 스토리지 요금을 별도로 청구
- 내구성 : 내구성과 가용성을 위해 여러 위치에 데이터를 복제, 머신 수준 장애 또는 영역 장애로 인한 데이터 손실 방지, 리전간리전 간 재해 복구의 경우 데이터를 백업하도록 리전 간 복사를 설정 가능
- 암호화 : 디스크 기록하기 전에 모든 데이터를 자동으로 암호화, 자체 암호화 키 또는 Google 관리형 암호화 키를 관리 할 수 있음.
- 효율적 : 분석 워크로드에 최적화된 효율적인 인코딩 형식을 사용
2-2 데이터 테이블
- Big Query에 저장되는 데이터 대부분은 테이블 데이터임
- 캐시된 쿼리 결과는 임시 테이블로 저장되며 해당 스토리지는 요금이 청구되지 않음.
- 표준 테이블 : 구조화된 데이터가 포함됨. 모든 테이블에는 스키마가 있으며 스키마의 모든 열에는 데이터 유형이 있음. 데이터를 열 형식으로 저장
- 구체화된 뷰 : 뷰 쿼리 결과를 주기적으로 캐시 하는 미리 계산된 뷰, 캐시 된 결과는 Big Query 스토리지에 저장
- 테이블 스냅샷 : 테이블의 특정 시점의 사본, 읽기 전용이지만 테이블 스냅샷에서 테이블을 복원할 수 있음. 스냅샷과 기본 테이블 간의 델타만 저장
- 외부 테이블 : GCS와 같이 외부 데이터 저장소에 데이터가 있는 특수한 유형의 테이블 메타 데이터만 Bug Query 스토리지에 유지됨. 외부 테이블 스토리지에 대한 요금을 부과하지 않지만 외부 데이터 저장소에 있는 스토리지 요금이 부과됨.
2-3 메타데이터
- Big Query 스토리지에는 Big Query 리소스에 대한 메타 데이터도 저장됨. 메타 데이터 스토리지에는 요금이 부과되지 않음.
- Big Query에서 테이블, 뷰 또는 사용자 정의 함수와 같은 영구 항목을 만들면 Big Query가 항목에 대한 메타 데이터를 저장
- 사용자 정의 함수 및 논리 뷰와 같은 테이블 데이터가 포함되지 않는 리소스도 동일
- 메타데이터에는 테이블 스키마, 파티견 나누기 및 클러스터링 사양, 테이블 만료 시간, 기타 정보가 포함됨.
3. 스토리지 레이아웃
- Big Query는 테이블 데이터를 열 형식으로 저장, 각 열을 개별적으로 저장, 열 기반 데이터베이스는 전체 데이터 세트에서 개별 열을 스캔하는데 효율적임.
- 열 기반 DB는 수많은 레코드에 데이터를 집계하는 분석 워크로드에 최적화
- 분석 쿼리는 테이블에서 몇 개의 열만 읽으면 되는 경우가 많음.
- 열기반 DB는 열 내의 데이터가 일반적으로 행의 데이터보다 중복성이 더 높아서 실행 길이 인코딩 같은 기술을 사용하여 읽기 성능을 향상 시킬 수 있어서 더 큰 데이터 압축을 가능하게 함.
- Big Query는 외래 키를 지원하지 않음. 따라서 OLTP 워크로드 보다 OLAP 데이터 웨어 하우스 워크로드에 적합
4. 데이터 테이블 최적화
4-1 중첩되고 반복되는 필드
- Big Query의 내부 저장소 형식은 중첩 필드와 반복 필드를 모두 지원
- 중첩 필드는 강력하게 유형화된 하위 필드를 한 개 이상 포함하는 복잡한 데이터 유형, 표준 SQL에서 중첩 필드는 STRUCT 데이터 유형으로 표시
- 반복 필드는 데이터 유형이 동일한 0개 이상의 값 순서가 지정된 목록, 표준 SQL에서는 반복 필드가 ARRAY 데이터 유형으로 표시
4-2 파티션 나누기
- 파티션을 나눈 테이블은 파티션 키라는 테이블의 열 값을 기준으로 파티션이라는 더 작은 부분으로 분할된 테이블
- 테이블의 구성은 다음과 같음
- 시간 단위 열
- 정수 열
- 데이터가 수신된 시간 (Big Query는 테이블 스키마의 일부가 아닌 유사 열에 수집 시간을 자동으로 저장)
- 파티션은 버킷으로 나눔
- 시간 단위 열 또는 수집 시간을 기준으로 하는 경우 파티션의 경우 버킷 크기는 시간별, 일별, 월별 또는 연간 일 수
- 정수 열의 경우 버킷의 크기를 정수 범위로 지정
- 파티션을 나눈 테이블에 데이터를 로드할 때 각 행은 파티션 키 값에 해당하는 파티션에 배치됨.
- Big Query가 필터와 일치하는 파티션만 스캔하고 일치하지 않는 파티션을 건너뛸 수 있기 때문에 파티션 나누기는 파티션 키를 필터링하는 쿼리 속도를 높일 수 있음 (해당 프로세스는 프루닝이라고 함)
- 파티션 나누기는 파티션 키에 고유한 값이 적을 때 (수천 개 이하) 가장 잘 작동함. 시간 기준 파티션 나누기는 이전 파티션이 자동으로 삭제되도록 파티션 만료 시간을 설정할 수 있음
4-3 클러스터링
- 하나 이상의 열 콘텐츠를 기준으로 테이블을 구성하므로 유사한 값이 같은 위치에 배치, 테이블이 클러스터링 되면 Big Query는 클러스터링 열의 값을 사용해 테이블 데이터를 정렬
- 클러스터링은 쿼리 성능을 여러 가지 방법으로 개선할 수 있음.
- 쿼리에 클러스터링 열을 기준으로 하는 필터 절이 포함된 경우 Big Query는 정렬된 블록을 사용하여 불필요한 데이터 스캔을 줄임
- 쿼리가 클러스터링 열의 값을 기준으로 데이터를 집계하면 비슷한 값이 같은 위치에 배치되므로 성능이 할당되어 데이터 셔플링이 줄어들 수 있음.
- 클러스터링은 대규모 팩트 테이블이 더 작은 측정기준 테이블과 조인될 때 별표 스키마보다 조인을 개선할 수 있음.
5. Big Query 스토리지에 데이터 수집
- 일괄 로드 : 단일 일괄 작업으로 소스 데이터를 Big Query 테이블에 로드, 일회성 작업일 수 있으며 일정에 따라 발생하도록 자동화, 일괄 로드 작업에서 새 테이블을 만들거나 기존 테이블에 데이터를 추가할 수 있음.
- 스트리밍 : 소규모의 데이터 배치를 지속적으로 스트리밍, 데이터를 거의 실시간으로 쿼리
- 생성된 데이터 : SQL 문을 사용하여 기존 테이블을 행을 삽입하거나 쿼리 결과를 테이블에 작성
728x90
'IT > 하려고 하는 클라우드' 카테고리의 다른 글
[AWS 기초] AWS IAM과 관련된 기본 개념 (0) | 2022.09.01 |
---|---|
[금융권] 클라우드 이용보고 관련 자료 준비 R&R (0) | 2021.12.12 |
[GCP]GCP 기초_Cloud SQL 만들기 (0) | 2021.09.15 |
[GCP]GCP 기초_Cloud SQL (0) | 2021.09.13 |
[GCP]GCP 기초_GCS(Google Cloud Storage)_실습 (2) | 2021.09.08 |
댓글