GCP BigQuery

 BigQuery

 

​

​

첫번째 BigQuery 소개

​

몇 초만에 대규모 데이터를 쿼리할 수 있는 관계형 클라우드 데이터베이스

SQL을 사용하므로 대용량 데이터셋을 탐색하기가 쉽고 빠름

쿼리를 실행하고 원했던 결과가 아니라면 약간 수정한 후 다시 실행할 수 있습니다.

많은 행(row)을 스캐닝하고 필터링하여 의미 있는 요약 데이터를 집계하는 분석 도구로 사용할 때 가장 강력

기존의 관계형 데이터베이스

​

​

빅데이터 처리에 있어서 기존 시스템의 한계

​

아래와 같은 과정을 통해 기존의 도구로 빅데이터를 처리할 수 있습니다.

​

① MySQL에서 특정 쿼리 실행속도를 높이기 위해 성능 관련 매개변수를 조정

② 읽기 복제본을 설정

③ Netezza와 같은 데이터웨어하우스를 이용해서 빅데이터를 처리

​

그러나 이러한 방식은 상당히 높은 비용이 발생합니다.

​

​

BigQuery

​

클라우드 인프라에 대한 약속.

- 사용한만큼만 과금

- 전통적인 데이터웨어하우스 시스템의 강력한 일부 기능을 제공

​

​

​

두번째 BigQuery 동작 방식

​

대용량 데이터처리에 있어 발생할 수 있는 주요 문제점

​

ⓐ 수십억 개의 데이터 행을 필터링해야 하는 경우 많은 컴퓨팅 성능이 필요한 수십억 개의 비교 작업을 수행해야 함

ⓑ 어딘가에 저장된 데이터에 대한 비교를 수행해야 하며, 해당 데이터가 저장된 드라이브는 비교를 수행할 컴퓨터로 데이터를 재빨리 이동시키는 데 한계를 지니고 있습니다.

​

​

위 문제에 대한 BigQurey의 해결 방법

​

ⓐ 컴퓨팅 용량 확장

​

맵리듀스 이용

* 맵리듀스(Map Reduce) 데이터를 관리 가능한 조각으로 잘라내고(맵 단계), 조각의 요약으로 축소(리듀스 단계) 이렇게 하면 작업을 많은 컴퓨터에서 병렬 처리하여 전체 프로세스의 속도를 높일 수 있음 ​ * 청크(chunk) 규칙 기반 시스템에서 단일 단위로서 저장·검색되는 사실의 집합체

수십억 개의 행을 청크로 나누어 계산

​

쿼리 요청을 처리하기 위한 수천 개의 전용 CPU 풀을 생성

쿼리를 실행하면 순간적으로 해당 컴퓨팅 용량에 액세스할 수 있게 되고 각 컴퓨팅 단위가 작은 데이터를 처리

작은 작업이 모두 완료되면 BigQuery가 모두 다시 취합하여 쿼리 결과를 제공

​

​

ⓑ 스토리지 처리량 스케일링

​

극단적인 성능을 요구할 때는 물리적인 디스크가 매우 중요한데, 이런 경우 디스크의 유형을 변경하여 문제를 해결할 수 있음

​

SSD는 무작위 데이터 액세스에 더 적합

기계식 디스크는 순차적인 데이터 액세스에 더 적합

​

단일 디스크 드라이브만으로는 필요한 성능을 얻을 수 없음

디스크가 점점 더 커짐에 따라 단일 디스크에서 모든 데이터를 가져오는 데 더 오래 걸리게 됨

디스크의 저장용량은 늘어나고 있지만, 대역폭은 반드시 용량에 맞춰 늘어나지 않음

​

많은 물리적 드라이브(sharding)를 통해 데이터베이스를 분할하고, 모든 CPU가 데이터 청크를 요청할 때 많은 드라이브가 데이터를 전송할 수 있도록 처리

드라이브만으로는 모든 바이트를 많은 CPU로 보낼 수 없지만, 많은 드라이브 풀은 모든 데이터를 신속하게 전달할 수 있음

* 데이터베이스 샤딩(database sharding) 대량의 데이터를 처리하기 위해 데이터베이스 테이블을 수평 분할(horizontal partitioning)하여 물리적으로 서로 다른 곳에 분산 저장 및 조회하는 것 ​ * 샤드(shard) 수평 분할된 1개의 테이블

여러 디스크에서 데이터 샤딩

 

 

 

세번째 BigQuery 기본 개념

​

(1) 데이터 집합과 테이블

​

데이터집합(dataset) : 기존 관계형 데이터베이스의 데이터베이스와 유사.주로 컨테이너 역할을 함

테이블(table) : 기존 관계형 데이터베이스의 테이블과 유사. 행의 모음

MySQL과 BigQuery 비교

​

관계형 데이터베이스와는 달리 기본저장소 시스템의 세부 사항을 제어할 필요가 없고 MySQL 또는 PostgreSQL과 같은 시스템보다 테이블의 기술적 측면을 제어할 필요는 없습니다.

​

​

(2) 스키마

​

다른 SQL 데이터베이스와 마찬가지로 BigQuery 테이블에는 구조화된 스키마가 있습니다.

표준 데이터 유형 : INTEGER, TIMESTAMP, STRING(VARCHAR)

필드는 필수(REQUIRED: NOT NULL에 해당)이거나 NULL 허용(NULLABLE)

​

쿼리를 실행하는 대신 API 호출의 일부로 스키마를 정의

MySQL의 경우 CREATE TABLE 쿼리를 이용해 테이블의 스키마 정의

BigQuery의 경우 쿼리를 BigQuery에 대한 API 호출에 해당 메시지의 일부로 스키마를 사용합니다.

스키마 자체를 각 필드의 정보가 있는 JSON 객체의 목록으로 나타내는 것이 가능합니다.

[ {"name": "name", "type": "STRING", "mode": "REQUIRED"}, {"name": "age", "type": "INTEGER", "mode": "NULLABLE"}, {"name": "birthdate", "type": "TIMESTAMP", "mode": "NULLABLE"} ]

실제로 BigQuery에서 사용하는 필드의 유형과 모드에 따라 상황은 더 복잡해집니다.

​

​

(3) 작업

​

BigQuery에 대한 API 요청은 많은 양의 데이터를 필요로 하기 때문에 단일 요청이 빨리 완료되더라도 즉시 완료되지 않을 가능성이 있습니다.

결과적으로 BigQuery를 완료하는 데 일정 시간이 걸리는 경우를 위해 작업(Job)을 사용합니다.

일부 데이터를 로드하는 요청 대신 요청된 작업을 실행하고 진행 상황을 보고하며, 작업이 완료되거나 중단될 때의 성공 또는 실패 결과를 리턴할 책임이 있는 작업이라는 반영속적인 리소스를 만듭니다.

​

​

작업을 통해 수행 가능한 네 가지 기본 작업

​

ⓐ 데이터 쿼리

ⓑ BigQuery에 새 데이터 로드

ⓒ 한 테이블에서 다른 테이블로 데이터 복사

ⓓ BigQuery에서 다른 곳(GCS 등)으로 데이터 추출(또는 내보내기)

​

기본적으로는 데이터를 한 곳에서 가져와 다른 위치에 배치하는 작업을 수행합니다.

이 과정에서 데이터에 어떤 변환이 수행될 수도 있습니다.

​

​

작업은 고유 리소스로 취급되기 때문에 테이블이나 데이터 집합에 할 수 있는 일반적인 조작을 작업으로 수행할 수 있습니다.

#실행한 모든 작업 나열, 현재 실행 중인 작업 취소, 과거 작성한 작업의 세부 사항 검색과 같은 작업 수행 가능