갈아먹는 BigQuery [1] 빅쿼리 소개

들어가며

구글 BigQuery는 이름에서 알 수 있듯이 엄청나게 큰 데이터에 대한 SQL 쿼리를 빠르게 수행해주는 google cloud platform의 서비스 중 하나입니다. 무려 페타바이트에 달하는 데이터도 빠르게 분석할 수 있다고 합니다. 자체 클러스터를 구성하고 운영하는 수고로움은 덜고, 데이터 분석에만 집중할 수 있는 툴로 많은 기업들에서 데이터 웨어하우스로 도입하고 있습니다. 그러면 빅 쿼리가 어떻게 생겼는지 살펴볼까요?

 

빅 쿼리는 다들 한번씩 사용해보셨을 MySQL과 같은 RDBMS의 웹 어드민처럼 생겼습니다. 여기서 데이터 셋을 불러오고, 쿼리를 입력할 수 있습니다. 위의 예시는 100억개의 위키피디아 문서에서 각 언어 별로 Google이라는 단어가 제목에 등장한 문서의 수를 세어주는 쿼리를 입력한 것입니다.[2] 쿼리 실행 세부 정보를 살펴보면 아래와 같습니다.

 

빅 쿼리는 해당 SQL문을 수행하는데 415.8GB에 달하는 데이터를 처리하여 16.2초 만에 주어진 SQL문을 수행하였습니다. 슬롯이라는 것은 빅 쿼리가 분산 처리를 하는 단위인데 이에 관련해서는 다음 포스팅에서 자세히 소개하도록 하겠습니다. 여기서는 분산 처리를 하지 않고 단일 머신으로 해당 쿼리를 수행했을 경우 소요되는 시간이다 정도로 이해하고 넘어가겠습니다.

 

정리하자면 빅 쿼리는 우리에게 친숙한 SQL문 만으로 분산 저장되어 있는 방대한 데이터를 순식간에 분석해주는 마법같은 도구입니다. 그렇다면 도대체 빅 쿼리는 무엇이고, 어떻게 탄생하였으며, 이토록 빠른 성능을 낼 수 있는지 하나씩 뜯어보겠습니다.

 

BigQuery 탄생 배경

BigQuery는 구글 내부에서 방대한 양의 데이터를 SQL문을 통해서 분석하기 위해 개발한 Dremel이라는 프로젝트의 public implementation입니다.[1] Dremel 이전에는 그 당시에 최신 유행이었던 하둡 기반의 클러스터를 구축하고, Map Reduce 방식을 통해서 데이터 웨어하우스를 구축하였다고 합니다. 문제는 간단한 분석 작업 하나도 맵 리듀스 방식으로는 하루가 넘게 걸리는 등 속도가 너무 느리다는데 있었습니다. 

 

이를 극복하고자 시작한 것이 Dremel 프로젝트입니다. Dremel은 structured 데이터를 분산 저장하고 SQL문을 통해 빠르게 데이터를 분석하는데 특화되어 있습니다. 이를 통해서 데이터 분석가들이 다양한 쿼리문을 통해서 데이터에서 인사이트를 뽑아낼 수 있도록 도와주는 도구입니다.

 

빅 쿼리는 이 Dremel 프로젝트를 기반으로 구글 외부의 사용자들도 쓸 수 있도록 서버리스 클라우드 서비스로 만들어 공개한 것이 빅 쿼리입니다. 빅 쿼리가 빠르다 못해 미친 성능을 보여주는 것은 다음 두 가지 특징 덕분입니다. 하나는 Columnar Storage, 다른 하나는 Tree 기반의 distribution입니다. 

Columnar Storage

일반적인 RDBMS는 레코드 단위로 데이터를 저장합니다. 하지만 Dremal은 컬럼 단위로 데이터를 뜯어내어 저장합니다. Dremal은 애당초 방대한 양의 데이터를 분석하기 위해 설계되었습니다. 이런 스케일의 데이터를 컬럼 기반으로 저장할 경우 다음과 같은 장점이 있습니다.

 

1. 트래픽 최소화

예를 들어서 "SELECT top(title) from foo"와 같은 쿼리가 들어왔다고 하면 컬럼 기반 저장 방식에서는 해당하는 컬럼만 조회하면 됩니다. 이는 데이터의 양이 방대해 질 수록 효과가 극대화됩니다. 그러므로 빅 쿼리에 앞으로 쿼리를 입력할 때에는 "SELECT * "와 같은 문법은 지양하는 것이 바람직해 보입니다.

 

2. Higher Compression Ratio

컬럼 단위로 데이터를 저장한 다는 것은 곧 같은 데이터 타입의 데이터들이 몰려서 저장되는 것을 의미합니다. 그 결과 압축하기에 더 용이하다고 합니다. 일반적인 RDBMS는 데이터를 1:3 비율로 압축하지만 컬럼 기반 저장은 1:10 비율로 압축이 가능하다고 합니다. 많이 압축한 만큼 쿼리 수행 성능도 향상된다고 합니다.

 

이러한 컬럼 기반 저장은 사실 기존 RDBMS에서도 구현이 되어있으며, Cassandra와 같이 column based nosql 솔루션들도 이미 존재했습니다. 하지만 Dremel은 이러한 컬럼 기반 저장에 대규모 분산 처리를 성공적으로 결합하여 성능을 극대화 시켰습니다. 

Tree Architecture Distribution

구글은 수천대의 머신에 쿼리 연산을 분산시키기 위해서 트리 구조를 활용합니다. 루트 서버는 클라이언트의 SQL 쿼리문을 분석하여 분산 머신에서 동작하는 수많은 작은 단위의 쿼리문들을 만들고 이를 intermediate servers에 전달합니다. 이 서버들은 다시 실제 연산을 수행하는 리프 노드들에게 쿼리를 전달하고, 쿼리의 결과 값으로 반환되는 값들을 합쳐서 부모 노드에게 전달해줍니다. 좀 더 자세한 내용은 Dremel 논문 리뷰 포스팅에서 다뤄보도록 하겠습니다.

 

이렇게 구글은 컬럼 베이스 저장 구조와 트리 기반의 분산 처리를 통해서 방대한 양의 데이터를 분석하는 SQL 쿼리문을 순식 간에 수행하는 Dremel을 만들어 냈습니다. 그리고 이를 GCP 상에서 편리하게 사용할 수 있도록 빅 쿼리를 만들어 서버리스 솔루션으로 제공합니다. GCP에는 이 빅쿼리와 함께 빅 쿼리에 데이터를 적재할 수 있는 Cloud Dataflow, Cloud Dataproc, Cloud Storage 등의 많은 빅 데이터 에코 시스템이 구축되어 있습니다. 이러한 솔루션들을 엮어서 멋진 데이터 파이프라인을 구축하는 방법도 차례로 다뤄보도록 하겠습니다. :)

BigQuery의 한계점

지금까지 빅 쿼리의 마법같은 기능들을 살펴보았습니다. 하지만 장점이 있으면 단점도 있겠죠? 바로 빅 쿼리는 분석, OLAP에 특화되어 있기 기 때문에 OLTP에는 부적합합니다. 적은 양의 데이터를 계속해서 입력하고, 업데이트 해야하는 작업에서는 오히려 성능이 떨어지는 모습을 보입니다. 다음은 빈 테이블에 문자열을 하나 입력하고 업데이트하는 간단한 쿼리를 빅 쿼리에서 수행한 결과입니다.

 

...띠용? 수십억개의 문서도 16초만에 분석하던 녀석이 작은 레코드 하나 인서트하는데 0.9초나 걸렸습니다. 이처럼 소규모 데이터를 빈번하게 입력하거나 업데이트 하는 작업에는 빅 쿼리는 적합하지 못합니다. 그러므로 빅 쿼리가 힙 해보인다고 기존에 잘 쓰고 있던 RDBMS를 빅 쿼리로 옮겨버린다면 낭패를 보겠죠? 어디까지나 대용량 데이터를 분석하는 용도로 사용할 때 진가를 발휘할 것 같습니다.

 

(덧붙이자면 Dremel은 update문을 지원 안한다고 논문에 나와있었습니다. 그래서 당연히 빅 쿼리도 지원을 안할 줄 알았는데 insert나 update문이 동작하긴 하네요 ㅎㅎ)

마치며

지금까지 소개해드린 SQL 엔진 기능 이외에도 빅 쿼리는 놀라운 기능들을 담고 있습니다. (구글신 당신의 끝은 어디인가...!) 그 중에서도 가장 신박했던 것은 SQL문 만으로 간단한 Classification, Regression 모델을 학습시키고 성능 평가를 진행할 수 있는 BigQueryML 기능이었습니다. 아무래도 구글은 머신러닝에 미쳐있나 봅니다 ㅎㅎ

 

이어지는 포스팅 들에서는 빅 쿼리의 아키텍쳐, 데이터 저장 방식, 분산 처리 원리 등을 다뤄볼 예정입니다.

감사합니다.

Reference

[1] An Inside Look at Google BigQuery, google cloud

[2] https://github.com/GoogleCloudPlatform/training-data-analyst/blob/master/courses/data-engineering/demos/bigquery_scale.md