갈아먹는 BigQuery[4] 빅쿼리 아키텍쳐

지난 글

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

갈아먹는 BigQuery [2] 빅쿼리 스키마 및 데이터 모델

갈아먹는 BigQuery [3] 빅쿼리 SQL 분산 실행

갈아먹는 BigData [1] MapReduce 이해하기

들어가며

지난 포스팅들에서 빅 쿼리가 무엇이고 어떠한 특징이 있는지 살펴보았습니다. 그리고 로우 레벨의 관점에서 어떻게 데이터를 저장하고 SQL 쿼리를 분산처리 하는지 살펴보았습니다. 이번에는 빅 쿼리의 아키텍쳐에 대해서 좀 더 자세히 알아보겠습니다.

BigQuery Architecture

빅 쿼리는 크게 네 가지 구성 요소로 이루어져 있습니다.[1]

Dremel(Compute): 방대한 분산 노드들에서 SQL 쿼리를 실행

Colossus(Storage): 데이터를 저장하고 실시간 처리를 할 수 있는 구글의 차세대 파일 시스템

Jupiter(Network): Compute와 Storage 사이의 통신 담당

Borg(Orchestration): 이 모든 분산 노드들을 조율 및 운영, 쿠버네티스의 전신

이제 각 요소별로 구체적으로 어떠한 역할을 담당하는 지를 알아보겠습니다.

Dremel - Execution Engine

빅 쿼리에서 쿼리의 수행 연산은 Dremel을 통해서 이루어집니다. Dremel은 SQL 쿼리가 들어오면 이를 execution tree로 만듭니다. 그리고 분산된 노드들에서 쿼리를 수행할 수 있게끔 원본 쿼리를 쪼갠 다음, 앞서 만든 트리를 통해 리프 노드로 전달합니다. 리프 노드는 파일 시스템(빅 쿼리의 경우 Colossus)에서 데이터를 읽어와서 쿼리 연산을 수행한 뒤, 결과를 부모 노드에게 전달하고 이를 모두 취합하여 쿼리 결과를 가져오게 됩니다. SQL 분산 처리에 관한 더 자세한 내용은 다음 포스팅을 참고해주세요. [2]

Colossus - Distributed Storage

Colossus는 GFS(구글 파일 시스템) 이후 등장한 구글의 가장 최신 버전의 분산 파일 시스템입니다. 구글의 각 데이터 센터 별로 콜로수스 클러스터가 구성되어 있으며, 이는 빅 쿼리에 넉넉한 저장 용량을 제공합니다. 지난 포스팅에서 언급했듯이 BigQuery는 Columnar Storage 방식으로 Colossus에 데이터를 저장하게 됩니다. 

 

ps. Colossus에 대해서 더 조사를 해보고 싶었으나 공식 논문도 없고 공개된 자료도 많이 부족했습니다. 제프 딘의 피피티 자료가 있었는데 기회가 된다면 Colossus에 대한 포스팅도 작성해보겠습니다.

Borg - Compute

방대한 규모의 분산 서버 클러스터를 운영하다보면 일부 머신이 고장난다던가, 파워가 끊긴다던가, 네트워크 장애가 발생한다던가 하는 문제가 발생할 수 있습니다. 또한 CPU 코어와 같은 물리적인 리소스를 적절히 할당해주는 것도 큰 도전 과제입니다. 빅 쿼리는 이러한 운영 상의 문제를 해결하기 위해서 Borg를 사용하며, 이는 쿠버네티스의 전신 격으로 생각하면 될 것 같습니다.

Jupiter - The Network

빅 데이터 분산 처리의 가장 큰 병목 구간은 연산도 저장도 아닌 네트워크 병목인 경우가 많았습니다. Jupiter 네트워크는 초당 1 페타바이트 규모의 데이터를 전송가능하여 거대한 작업량도 순식간에 분산시켜줍니다. 또한 이는 10만대 가량의 머신들 간에 초당 10Gbs로 통신을 할 수 있도록 지원합니다. 

BigQuery Storage Hierarchy

다음으로 빅 쿼리가 데이터를 저장하는 개념적인 구조를 살펴보겠습니다. 크게 구글에 의해서 운영되어지는 Managed by Google 레이어 위에 사용자가 직접 정의하고 데이터를 저장하거나 조작할 수 있는 User-level Features가 정의되어 있습니다. 가장 아랫단에는 구글의 인프라가 있으며 그 위에 구글의 분산 파일 시스템인 Colossus가 얹어져서 동작합니다.

 

Colossus 레이어 위에 Capacitor란 Columnar Storage 방식으로 데이터를 압축하여 저장하는 일종의 포맷입니다. Automated DBA Tasks란 데이터 베이스가 더 빨리 동작하도록 주기적으로 물리 데이터 영역을 최적화 시키는 동작을 말합니다. 사용자들이 쓰는 로지컬 데이터 영역에 영향을 주지 않기 때문에 사용자는 인식하지 못합니다. 마지막으로 Dynamic Execution인데 이는 SQL 쿼리를 동적으로 계획하여 분산 노드에서 실행시켜주는 모듈을 말합니다.

 

Managed by Google 레이어 위에 이제 사용자가 직접 정의하고 사용할 수 있는 레이어가 얹어집니다. Logical Storage Layer는 사용자가 직접 테이블을 정의하고 데이터를 적재하는 레이어입니다. 그 위로 IAM을 직접 정의하여 데이터 접근 권한을 제어합니다. 그리고 그 위로 public dataset을 사용한다던가 다른 데이터 셋들을 구매해서 사용한다는 등의 모듈들이 추가되는 방식입니다.

마치며

지금까지 빅 쿼리가 어떠한 구성 요소들로 이루어져 있고, 데이터를 저장하기 위해서 어떠한 구조를 설계하였는 지를 아주 간략하게 살펴보았습니다. 사실 구성 요소 하나하나 깊이 파고들면 한도 끝도 없을 것 같아서 여기서 마무리 하지만, 추후에 더 알게되거나 자료를 찾게 되면 좀 더 자세히 공부하여 포스팅을 작성해보려 합니다.

 

개인적으로 이런 아키텍쳐를 먼저 살피고 기술을 익히면 이해가 좀 더 잘되는 경험이 있습니다. 빅 쿼리를 공부하시거나 관심이 있으신 분들께 아래  레퍼런스로 달려있는 문서 원문들을 한번쯤 읽어보시길 권해드립니다.

 

감사합니다.

Reference

[1] BigQuery under the hood, https://cloud.google.com/blog/products/gcp/bigquery-under-the-hood, google cloud

[2] 갈아먹는 BigQuery[4] 빅 쿼리 SQL 분산처리

[3] Separation of storage and computation, https://cloud.google.com/blog/products/gcp/separation-of-storage-and-compute-in-bigquery, google cloud