Google Bigquery -4 (워크로드 관리)
https://nani-log.tistory.com/169
Google bigquery -3 (최적화 기법 - 파티셔닝, 클러스터링, 캐싱, 쿼리 튜닝)
https://nani-log.tistory.com/168 Google Bigquery -2 (아키텍처)https://nani-log.tistory.com/167 Google Bigquery -1 (설계적 특성 - OLAP, Columnar, MPP, Serverless)https://nani-log.tistory.com/161 Amazon Redshift -1 (설계적 특성 - OLAP, Colum
nani-log.tistory.com
Bigquery는 쿼리 실행시 병렬로 실행되는 처리를 슬롯이라는 단위로 나타낸다. 슬롯의 사이즈를 결정하고 운영하는 일은 쿼리의 비용과 성능에 연관되어 있기 때문에 아주 중요하다
여러 사용자가 동시에 쿼리를 요청하면 어떻게 처리할까?
쿼리 실행시 슬롯이 할당되는데 사용 가능한 슬롯 풀을 여러 쿼리가 공유할 수 있고, 필요에 따라서 더 많은 슬롯을 할당받을 수도 있다. Bigquery는 동적 동시성 관리를 통해 사용 가능한 컴퓨팅 리소스를 기반으로 동시에 실행할 수 있는 쿼리의 수를 결정한다. 동시성 한계를 초과하는 쿼리는 자동으로 큐에 배치되며 스케줄링을 통해 리소스가 분배된다
말이 좀 어렵게 느껴지지만 그림으로 살펴보면 다음과 같다. 즉, 사용 가능한 컴퓨팅 리소스를 참고해 동시에 실행 가능한 만큼 여러 쿼리를 실행하고 남은 쿼리는 큐에서 대기시킨다
당연한 말이겠지만 슬롯이 충분하면 쿼리는 신속하게 실행될거고, 슬롯이 충분하지 않다면 쿼리 결과는 아주 늦게 반환되거나 실패할 수도 있다
슬롯 할당 전략
필요한 슬롯의 수를 산정하려면, 먼저 쿼리를 지속적으로 모니터링하고 분석하는 방법이 우선이다. 쿼리의 평균 슬롯 소비량은 totalSlotMs / elapsedMs(=평균 슬롯 소비량) 계산을 통해 알 수 있다. 각 쿼리의 평균 슬롯 소비량을 더하면 동시 실행 슬롯 수를 확인할 수 있으니 쿼리를 튜닝하거나 슬롯을 추가하는 방안을 고려할 수 있다
슬롯을 모든 쿼리에 균등하게 분배하기보다 우선순위와 필요를 잘 파악해 분배해야 한다. 우선순위를 결정할 땐 쿼리의 중요도, 실행 빈도, 복잡성 등을 고려할 수 있다
또 프로젝트 내에서 쉬고 있는 유휴 슬롯을 사용할 수 있게 설정하면, 더 빠르게 쿼리를 처리할 수 있다
정리
다른 곳에서도 슬롯이라는 용어는 많이 사용되지만 Bigquery에서의 슬롯은 더 동적인 의미를 가진다. 그 이유는 컴퓨팅 레이어와 스토리지 레이어가 분리되어 있기 때문이다
Redshift나 하둡 YARN에서의 슬롯은 노드에 스토리지와 컴퓨팅이 결합되어 있어 원하는 데이터가 존재하는 노드에서 처리를 하는게 우선이지만, Bigquery에선 데이터 지역성을 고려하지 않고 독립적인 슬롯 풀을 사용해 쿼리를 처리한다
이러한 특성 덕분에 Bigquery에서의 슬롯은 더 추상화되고 유연하게 동작한다. 시스템의 구조에 따라 자원을 관리하고 사용하는 방식이 다름을 인지하면 각 시스템을 더 잘 사용할 수 있는 길이 될 것이다