[Bigquery 최적화] 구체화된 뷰 (MATERIALIZED VIEW) 테이블에 대하여

빅쿼리( bigquery ) 최적화 방법론을 고민하고 있다. 그러던 중, 예기치 못한 상황에서 'materialized view'에 대해서 알게 되었다.
현재는 view 테이블로 streaming 테이블을 연산하고 있는데, 이를 개선할 수 있지 않을까 싶었다.
결론적으로는, 구체화된 뷰를 결국 도입하진 않았다. 그 생각의 과정과, 도입할 수 없었던 이유 등을 간단히 작성해보려고 한다.

 

 

 

01. MATERIALIZED VIEW란?

https://cloud.google.com/bigquery/docs/materialized-views-intro?hl=ko 

구체화된 뷰 소개  |  BigQuery  |  Google Cloud

 

개념을 소개하는 것은 위 문서에 잘 나와 있으므로, 자세히 다루지는 않겠다 !

 

내가 이해한 MATERIALIZED VIEW(이하 '구체화된 뷰')는, 쿼리 결과를 주기적으로 캐시 하는 뷰다.

기존 VIEW 테이블은 쿼리를 저장해두고, VIEW 테이블 실행 시 쿼리를 실행하여 결과값을 반환한다.

하지만 방대한 데이터거나, VIEW테이블을 자주 조회할 경우 연산비용이 계속 든다.

하지만 구체화된 뷰를 사용하면 기존에 연산을 할 수 있기 때문에 연산비용이 줄어든다. 비록 보관비용도 함께 들기야 하지만, 만약 큰 streaming insert 되는 테이블에서 작은 연산테이블을 지속적으로 운영한다고 한다면, 구체화된 뷰는 최적의 선택이 될 것이라고 문서에서 언급하고 있다.

 

 

 

 

02. MATERIALIZED VIEW 의 장점?

높은 계산 비용과 작은 데이터셋을 추출하는 VIEW테이블에, 미리 사전 집계함으로써 연산비용을 줄인다.

연산만이 아니라 필터링도 가능하다.

사전 기초 조인도 가능하다.

클러스터링이랑 파티셔닝도 적용시킬 수가 있어서, 경우에 따라 재클러스터링을 할때(클러스터링 컬럼을 재지정하고 싶을때)도 유용하다.

실시간으로 연산하는게 부담스럽다면, 연산 주기도 설정할 수 있다.(ex:30분마다 연산) 따라서 배치 데이터 마트를 생성할 수도 있다.

 

즉, 이게 잘만 된다면 airflow에서 배치처리하는 게 의미가 없고, 스트리밍 데이터 마트를 잘 만들 수 있다는 것이다!

(하지만 환경에 따라 그럴 수 없기도 하다. 아래의 단점을 확인해보자.)

 

 

 

 

 

03. MATERIALIZED VIEW 의 단점?

1. 자체 연산 시에도 비용이 든다. 또한 적재할 때도 비용이 든다.

2. 또한 구체화된 뷰 생성 쿼리를 변경할 수 없다.

3. 데이터 세트마다 20개, 프로젝트 단위로 100개의 생성 개수 제한이 있다.

4. 복잡한 쿼리를 지원하지 않는다. 가령 self join이나, 서브쿼리 등이 이에 해당한다. 미지원 쿼리 리스트는 하단 링크를 참고하자. 23년 9월 기준 미지원 쿼리리스트는 아래와 같다.

• Left/right/full outer 조인
• 자체 조인(동일한 테이블을 두 번 이상 사용하는 조인)
• 윈도우 함수
• ARRAY 서브 쿼리
• RAND(), CURRENT_DATE(), SESSION_USER(), CURRENT_TIME()과 같은 비확정적 함수
• 사용자 정의 함수(UDF)
• TABLESAMPLE.
• FOR SYSTEM_TIME AS OF

https://cloud.google.com/bigquery/docs/materialized-views-create?hl=ko#unsupported_sql_features 

구체화된 뷰 만들기  |  BigQuery  |  Google Cloud

 

 

하지만, 이처럼 실시간 증분을 할 경우에만 쿼리 제한이 많고, self join 등의 연산이 필요할 경우 max_staleness, refresh_interval_minutes 값 추가를 통해 구체화된 뷰 테이블 '구성' 자체는 가능하다. 즉, 복잡한 쿼리를 사용하려면 주기 설정이 필요로 한다.

 

max_staleness 와 refresh_interval_minutes란, 구체화된 뷰를 최적화해서 사용하기 쉽게 쓰는 파라미터다. 자세한 설명은 문서에 나와 있으므로 생략하겠다.

사용 시 많은 장점이 있지만, 너무 많은 연산이 계속 이뤄져야 할 때 비활성 주기가 설정됨으로서 경제성있는 구현이 가능하다는 게 큰 장점이다. 가령 30분 주기로 연산되는 배치 테이블처럼 구성이 가능하다.

 

 

 

 

 

04. 구체화된 뷰 비도입 이유

그래서 결국, 구체화된 뷰를 도입하였을까?

결론적으로 말하면 아니다. 우리회사는 모종의 이유(회사 정보 유출이 될 수도 있으니 비밀로 하겠다.)로 self join 을 반드시 사용해야 하는 환경이다. 따라서 구체화된 뷰를 쓰려면 업데이트 주기 설정이 반드시 필요했다. 그렇다면 결국은 batch 테이블이 된다.

 

하지만 나는...  스트리밍 업데이트 테이블을 구성하고 싶었다. 그러면서도, 일반 view테이블보다는 스캔량을 적게 소요하는 아키텍처를 쓰고 싶었다. 그리고 조회할 때도, 가급적 파티셔닝과 클러스터링을 설정하여 테이블 최적화를 시도하고 싶었다. 정리하자면 아래와 같은 요건을 모두 충족하였으면 했다.

 

• 일반 view테이블보다 스캔량을 적게 소요할 것
• 결과 테이블에 파티셔닝과 클러스터링 등이 적용될 수 있는 환경이어야 할 것
• 스트리밍 환경으로 결과 테이블 조회가 가능할 것

 

 

나는 문득 구체화된 뷰 생성 로직을 보다, 예전에 스트리밍 데이터로 AI모델 만들고 싶어서(?) 시도했던 람다 아키텍처가 떠올랐다. 

람다( lambda ) 아키텍처란, 아래 포스팅을 여러 번 했으니 링크를 달도록 하겠다.

https://eng-sohee.tistory.com/156

스트리밍 데이터 기반 AI 모델 처리에 대한 고민 (1) 람다 아키텍처 활용

 

 

 

결국은 이 람다 아키텍처는 구체화된 뷰와 큰 흐름이 동일하다고 이해했다.

따라서 람다 아키텍처와 같이, batch로 이전 데이터의 최신값만을 남겨두고, 최신값에 대해서만 streaming을 가져와 이를 합하여 조회하는 로직을 적용하기로 했다.  그러면 위의 조건을 모두 충족할 수 있기 때문이다.

이렇게 되면, 기존 풀스캔 시 200GB대 조회성능을 풀스캔 시 15GB대로 간소화할 수 있게 되고 & 파티셔닝 적용을 통해 날짜 별 조회시 훨씬 더 적은 스캔량을 도모할 수 있게 되는 부분을 확인했다.

 

하지만 람다 아키텍처는, 테이블의 물리적 저장공간도 추가로 필요로 한다. 나는 추가되는 물리적 저장공간 조차도 없애고 싶었다.

따라서 빅레이크 테이블 환경을 이용해 이를 해결하기로 하였다. (빅레이크 테이블에 대한 설명은 나중에 다루도록 하겠다!)

 

 

 

 

결론적으로 내가 말하고자 하는 것은,

• 구체화된 뷰는 좋다. 잘하면 스트리밍 환경에서의 데이터 마트를 구현할 수 있다.
• 하지만 고도화된 SQL쿼리 연산 사용의 경우, batch 데이터 마트와 다름이 없다고 생각한다. SQL쿼리가 고도화될 경우, 구체화된 뷰의 장점 중 하나인 streaming 환경 제공은 어렵다.
• 비록 뷰 연산비용과 물리적인 저장비용이 들지만, 현재 환경이 조회 비용이 어마어마하게 드는 환경이라면 도입해보면 좋을 듯 싶다.
• 더 나아가, 람다 아키텍처로 로직을 구현하면 (현재까지는) 구체화된 뷰 테이블의 단점 몇가지를 해소할 수 있을 것으로 사료된다.