[구글 빅쿼리 완벽 가이드 - 1장] 빅쿼리의 등장 배경과 특징

빅쿼리의 등장 배경과 특징

빅쿼리란?

페타바이트급 데이터를 저장 및 분석할 수 있는 클라우드 기반 데이터 웨어하우스

빅쿼리의 장점

1. 스파크나 하둡 등 기존 빅데이터 플랫폼과 달리 빅쿼리는 SQL과 호환되는 쿼리 언어를 지원 → RDBMS 사용 경험이 있으면 금세 활용 가능
2. 클라우드 기반 서비스이므로 사용자가 직접 인프라를 운영할 필요 X

RDBMS

데이터를 MySQL, PostgreSQL 같은 온라인 트랜잭션 처리(OLTP) 데이터베이스에 저장.

• SQL을 사용할 수 있음
• 단순히 raw 데이터를 가져오는 것뿐만 아니라 그 이상의 작업도 가능
• 아래 SQL 쿼리는 대여와 반납의 위치가 다른 거래에 대한 데이터를 가져옴 ex) 위와 같은 쿼리는 타임스탬프 값을 파싱하여 연도와 월을 추출하며 집계, 필터링, 그룹화 및 정렬을 수행함
  
• 쿼리만 짜면 DB 소프트웨어가 알아서 쿼리를 실행하는 최적의 방법을 스스로 찾아냄
• BUT 이런 쿼리를 OLTP DB에서 수행하는 것은 비효율적
• 왜냐면 OLTP DB는 Locking 등의 방법을 통해 데이터 일관성을 확보하는 데 최적화되어있음 → 인덱스를 걸면 읽기속도는 올라가지만 쓰기를 할때마다 인덱스를 재구성 해야되므로 느려짐 → OLTP DB는 이처럼 전체 데이터셋을 훑어야 하는 애드혹(ad hoc) 쿼리 실행에는 부적합 → 분석 쿼리에 부적합 → 순회가 필요한 특수 목적의 분석은 자바나 파이썬 같은 언어로 수행
  

• 여기서 나오는 애드혹 쿼리는 인덱스 같은 기능을 사용해 최상의 성능을 발휘하도록 미리 만들어 둔 DB에 쿼리하는 것이 아니라 즉석에서 작성해 실행하는 쿼리를 뜻함

맵 리듀스 프레임워크

위에서 보았듯 OLTP DB는 전체 데이터셋의 순회가 필요한 애드혹 쿼리에 부적합 → 이러한 특수 목적의 연산을 아래의 두 단계로 추상화

• 키/값 상을 처리해 중간 키/값 쌍을 생성하는 map 함수
• 동일한 중간 키와 연관된 모든 중간 값을 병합하는 reduce 함수

→ 하둡 생태계의 발전으로 이어짐

하둡 생태계의 데이터 파이프라인

1. HDFS에서 CSV 텍스트 파일로 데이터를 정기적으로 내보냄
2. ad hoc 분석을 위해 다음을 수행하는 스파크 프로그램 작성
   1. 텍스트 파일의 데이터를 데이터프레임으로 불러옴
   2. SQL 쿼리 실행(ex: 앞에서 본 분석쿼리 같은 것)
   3. 결과를 다시 텍스트 파일로 내보냄
3. 하둡 클러스터에서 스파크 프로그램 실행

BUT

• HDFS에 데이터를 저장하려면 클러스터가 충분히 커야함
• 맵리듀스에서는 데이터가 HDFS에 저장되어 있어야만 컴퓨팅 노드가 해당 데이터에 접근가능
• 데이터의 크기가 증가하면 분석에 필요한 처리 노드의 수도 증가(반대도 마찬가지) → 클러스터가 부족하거나 과도하게 프로비저닝 되는 경우 발생
  

→ 이렇게 하둡 클러스터에서 스파크 프로그램을 실행하기 위해선 하둡 클러스터 관리, 모니터링 및 프로비저닝 전문가가 필요

→ 빅쿼리 등장

빅쿼리의 특징

• 서버리스이므로 인프라 운영 필요 X
• RDBMS처럼 SQL 쿼리 실행 가능
• 맵 리듀스처럼 전체 데이터셋 탐색을 효율적 분산 가능 → 서비스가 즉각적으로 수천의 워커에게 쿼리 처리를 분산하기 때문에 페타바이트에 이르는 데이터를 집계할 때도 서비스 확장 용이
  • 빅쿼리는 맵 리듀스를 직접적으로 노출하지 않고, 내부적으로 최적화된 방식으로 데이터 처리를 수행 → 사용자는 맵 리듀스를 명시적으로 사용하지 않아도 빅쿼리를 통해 대규모 데이터를 처리 가능
• 다른 소스의 데이터셋 조인 or 외부 데이터 쿼리가 쉬움 → 큰 조직 내에서 부서간 데이터 공유가 쉬움 → 유연한 협업
  
• Looker와 같은 비즈니스 인텔리전스(BI) 도구를 통한 다양한 분석 가능
• 컴퓨팅 및 스토리지 분리
  • 데이터 양이 증가하거나 처리할 작업 증가하더라도 필요한 만큼 쉽게 스케일링 가능 → 필요한 리소스만큼만 할당할 수 있으므로 비용도 절감
• 컬럼 스토어 형식으로 데이터 저장(아래에서 자세히 다룰 예정)
• 스토리지 및 네트워킹 인프라, 관리형 스토리지, GCP와의 통합, 보안 및 규정 준수 등…

컬럼 스토어 형식

빅쿼리에서는 컬럼 스토어(Columnar Store) 형식으로 데이터를 저장

컬럼 스토어 형식 VS 로우 스토어(Row Store) 형식

• 로우 스토어 형식은 테이블 전체를 하나의 레코드 단위로 저장하는 방식
• ex) 학생의 성적 정보를 저장하는 테이블이 존재
  • 로우 스토어 형식은 각 학생의 이름, 학번, 국어 점수, 영어 점수, 수학 점수 등을 하나의 레코드로 묶어서 저장하는 방식
  • 컬럼 스토어 형식은 이름 컬럼을 따로, 학번 컬럼을 따로, 국어 점수 컬럼을 따로, 영어 점수 컬럼을 따로, 수학 점수 컬럼을 따로 저장하는 방식

컬럼 스토어 형식의 장점

1. 압축률이 높음: 컬럼 스토어 형식은 같은 값이 반복되는 경우에 대해서 압축을 하기 때문에, 로우 스토어 형식보다 압축률이 높음
2. 쿼리 속도가 빠름: 컬럼 스토어 형식은 컬럼 단위로 값을 읽어오기 때문에, 특정 컬럼에 대한 쿼리 속도가 빠름
3. 집계 연산에 용이: 컬럼 스토어 형식은 컬럼 단위로 값을 저장하기 때문에, 집계 연산에 용이
4. 인덱싱: 인덱싱을 사용하여 특정 컬럼에 대한 검색 속도를 높힐 수 있음

컬럼 스토어 형식의 단점

1. 삽입 속도가 느림: 컬럼 스토어 형식은 컬럼 단위로 값을 삽입하기 때문에, 로우 스토어 형식보다 삽입 속도가 느립니다.

   → 스트리밍 삽입(데이터를 작은 단위로 나누어서 실시간으로 삽입) 기능으로 속도 보완

2. 업데이트 속도가 느림: 컬럼 스토어 형식은 컬럼 단위로 값을 저장하기 때문에, 업데이트 속도가 느립니다.

   → 삭제 후 다시 삽입하는 방식 사용