Google BigQuery
Google BigQuery는 대량의 데이터를 SQL로 분석하는 서버리스 데이터 웨어하우스입니다. 운영 데이터베이스로는 감당하기 어려운 집계와 리포트, 로그 분석을 별도 클러스터 관리 없이 처리하게 해 줍니다. 조직 관점에서는 공통 분석 플랫폼의 중심축으로 쓰이는 경우가 많습니다.
▶아키텍처 다이어그램
📊 데이터 흐름 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
데이터가 커지면 운영 DB에서 집계 쿼리를 돌리는 순간 응답이 느려지고, 분석용 별도 클러스터를 꾸미면 이번에는 관리가 무거워집니다. 조회가 많고 범위가 넓을수록 일반 OLTP DB는 분석에 맞지 않습니다. 결국 분석 지연이 의사결정 지연으로 이어지는 문제가 생깁니다.
과거의 대규모 분석은 별도 하둡 클러스터를 붙이고 배치 작업을 돌리는 식이었습니다. 데이터가 늘수록 클러스터 관리가 데이터 분석보다 더 큰 일이 되었고, 그 부담을 줄이기 위해 서버리스 분석 엔진이 나왔습니다. BigQuery는 이런 흐름에서 분석 인프라의 진입 장벽을 크게 낮췄습니다.
데이터를 컬럼 단위로 저장하고, 쿼리가 들어오면 내부적으로 분산 실행합니다. 사용자는 SQL만 쓰고, BigQuery가 워커를 배정해 필요한 컬럼만 읽어 결과를 만듭니다. 저장과 실행이 분리되어 클러스터 운영을 직접 만질 일이 적습니다. 파티셔닝·클러스터링을 적용하면 비용과 응답 시간을 함께 제어하기도 쉽습니다.
BigQuery와 Cloud SQL은 둘 다 SQL을 쓰지만, Cloud SQL은 운영 데이터의 트랜잭션 처리에 맞고 BigQuery는 대량 집계와 분석에 맞습니다. 행 단위 쓰기와 수정이 빈번하면 Cloud SQL, 수억 행을 집계하고 리포트를 만들면 BigQuery가 맞습니다. 즉, 시스템을 '기록하는 DB'와 '질문하는 DB'로 역할 분리할 때 BigQuery가 분석 축을 맡습니다.
대시보드, 로그 분석, 제품 사용 패턴, 실험 결과 집계처럼 넓은 범위의 데이터를 자주 다시 묶어 봐야 할 때 적합합니다. 초당 쓰기와 행 단위 수정이 중심인 저장소로는 맞지 않습니다. 데이터팀뿐 아니라 제품·마케팅 팀이 SQL 기반으로 빠르게 인사이트를 얻는 환경에 특히 유리합니다.