BigQuery 성능/비용 팁

BigQuery는 Google에서도 강조하듯이 저장 비용이 매우 저렴합니다.

 

BigQuery 가격 책정 확인 👇

https://cloud.google.com/bigquery/pricing.html?hl=ko#storage 

가격 책정  |  BigQuery  |  Google Cloud

 

하지만 여기서 문제는 BigQuery의 검색(SELECT) 비용입니다.  저장소의 비용은 저렴하지만 SELECT의 경우 빈번하게 일어나기 때문에 이를 무분별하게 사용하면 자칫 많은 비용이 발생할 수 있습니다. 이러한 비용 폭탄을 사전에 방지 하기 위해서 몇 가지만 알고 있어도 큰 도움이 될 수 있습니다. 오늘은 이러한 몇가지 팁에 대해서 글을 작성해 보려고 합니다.

 

비용을 보고 후회하지 말자..

 

 

---

첫 번째, 비용 측정기를 적극 활용하세요.

BigQuery를 사용할 때 많은 분들이 GCP 사이트를 이용하기도 하지만 여러 가지 Tool을 이용해서 사용하기도 합니다.

제가 사용하는 Tool의 경우 예상 비용을 그때그때 보여주지는 않습니다.  또는 개발자 분들의 경우 BigQuery를 코드에 넣어서 사용 하기 때문에 예상 비용을 알지 못하고 사용하는 경우가 많습니다. 

 

아래와 같이 GCP에서 BigQuery의 Query를 입력하면 미리 예상 비용을 알 수 있습니다. 예상 비용을 보고 어느 정도 비용이 나올지 예상할 수 있고 이를 통해서 비용을 줄일 수 있습니다.

예상 비용 측정

 

 

---

두 번째, Limit은 효과가 없다.

흔히 다른 RDBMS를 익숙하게 사용하신 분들이라면 limit , top 등을 많이 활용하셨으리라 생각됩니다.

데이터를 봐야지 어떻게 생겼는지 알기 때문에 한 번씩 "SELECT FROM LIMIT 10" 구문을 실행해 보고 결과를 통해서 무언가를 하리라 생각됩니다. 하지만 Limit은 아무런 효과가 없습니다. 

 

하지만 구문 오류가 발생하지 않고 정상적으로 실행이 가능하므로 사람들은 Limit이 정상적으로 동작한다고 생각합니다. 실제로 많은 분들이 사용 합니다. (동작은 하지만 비용 측면에서 효과가 없습니다.)

 

아래는 단순히 SELECT를 했을 때입니다.

Limit 구문 없을 때

 

아래는 Limit을 추가해서 SELECT를 했을 때입니다.

Limit 구문 있을 때

 

2개의 Query는 아무런 비용에 차이가 없습니다. Limit은 BigQuery에서 비용과 성능을 줄이지 못합니다. 

이는 BigQuery가 데이터를 Table 단위 (RDBMS)로 저장하지 않고 Column 단위로 저장하기 때문입니다. 

(최근에는 RDBMS도 Colume 단위 저장 기법을 제공합니다.)

 

 

단순하게 이를 그림으로 그리면 다음과 같이 표현할 수 있습니다.

Limit으로 데이터 가져오기

 

RDBMS의 경우 데이터를 Table 단위로 넣고 BigQuery의 경우 데이터를 Column 단위로 넣습니다. 

Column 단위로 넣을 경우 위와 같이 길쭉한 막대처럼 데이터가 있고 이를 읽기 위해서는 위에만 읽어도 해당 부분을 전부 가져와야 하기 때문에 Limit 구문이 효과가 없다고 볼 수 있습니다.  

 

BigQuery 데이터 저장 관련 설명 👇

https://cloud.google.com/blog/products/bigquery/inside-capacitor-bigquerys-next-generation-columnar-storage-format

Inside Capacitor, BigQuery’s next-generation columnar storage format | Google Cloud Blog

 

 

👍 이렇게 하면 좋습니다.

 

GCP의 BigQuery에서는 미리보기를 제공합니다. 이를 통해서 데이터를 미리 보기 할 수 있습니다. 데이터 미리보기를 통해서 데이터 어떻게 생겼는지 샘플을 볼 수 있습니다.

 

데이터 미리보기

 

물론 이 미리보기의 경우 내가 원하는 방식으로 데이터를 볼 순 없습니다.

예를 들면 ORBER BY 같은 구문으로 데이터를 볼 순 없습니다. 

 

 

---

세 번째, * 사용을 자제해주세요.

위의 데이터 저장 방식 그림을 보면 더욱 이해가 가실 겁니다. *을 사용할 경우 모든 Column을 가져와야 합니다. 

그렇기 때문에 필요한 Column만 가져올 경우 성능 및 비용에 대해서 큰 이득을 볼 수 있습니다.

 

*을 통한 SELECT

 

*을 통해서 SELECT를 할 경우 위에서 본 것과 같이 모든 Column을 가져와야 하기 때문에 성능, 비용에 모두 좋지 않습니다. 물론 정말 모든 Column을 사용해야 하는 경우도 있지만 대부분이 그렇지 않습니다. 

 

 

👍 이렇게 하면 좋습니다.

다음과 같이 필요한 Column만 지정해서 데이터를 SELECT 해야 합니다.

 

Column을 지정한 SELECT

 

Column을 지정 함으로써 비용이 크게 내려간 것을 볼 수 있습니다.

약간 귀찮게(?) 느껴질 수 있지만 필요한 Column만 사용한다면 많은 부분에서 이점을 얻을 수 있습니다.

 

 

---

네 번째, 파티션을 이용하세요.

많은 분들이 BigQuery에 파티션 없이 테이블을 많이 활용합니다. 파티션이 없어도 빠르게 결과가 나오지 때문에 파티션을 이용해야 한다고 크게 공감을 못 하는 듯합니다. 하지만 파티션이 있을 경우 성능 및 비용에 아주 큰 이득을 볼 수 있습니다.

 

BigQuery 파티션 테이블 👇

https://cloud.google.com/bigquery/docs/partitioned-tables?hl=ko 

파티션을 나눈 테이블 소개  |  BigQuery  |  Google Cloud

 

제가 알기로 2021년 6월 기준으로 아직 파티션은 날짜 형태의 Column만 제공하는 것으로 알고 있습니다.

(INT Column에 제공한다고 하지만 제약이 아주 많아서 쓰기 어렵다.)

 

하지만 우리가 사용하는 대부분의 BigQuery 테이블의 경우 Log 형태이기 때문에 날짜 형태의 Column이 존재할 것이기 때문에 파티션을 만들고 사용하는데 큰 무리가 없다고 생각됩니다. 

 

파티션은 RDBMS에서 INDEX로 알고 계시면 좋습니다.

파티션 테이블을 통해서 빠르고 저렴하게 SELECT를 할 수 있습니다.

 

 

👍 이 부분을 알고 계시면 좋습니다.

 

파티션을 할 때 대부분의 사용자 분들이 이 부분 때문에 파티션이 잘 걸려 있는 테이블에서 파티션을 잘 활용하지 못합니다. 예전에 제가 다른 글에도 작성하였지만 여기서 다시 한번 언급하는 이유는 매우 중요하기 때문입니다. ( 참고 )

 

대부분의 사용자 분들이 파티션만 걸려 있으면 무조건 파티션이 잘 사용된다고 생각합니다. 

하지만 아래와 같이 Query를 할 경우 파티션은 아무런 영향을 받지 않습니다.

 

좌변 가공

 

위와 같이 좌변을 가공하고 SELECT를 할 경우 값 자체가 변경된 것이기 때문에 파티션을 활용할 수 없습니다.

좌변이 아닌 우변을 가공해서 데이터를 SELECT 해야 합니다.

 

우변 가공

 

데이터의 SELECT 결과는 다르지 않습니다. 

다만 좌, 우를 어디를 가공하냐에 차이입니다. 더욱 정확히 말하면 파티션 Column을 가공하면 안 됩니다.

가공하지 않고 그대로 SELECT를 해야지 파티션의 영향을 받습니다.

 

 

---

마치며...

BigQuery에서 몇 가지 부분만 알아도 비용을 크게 줄일 수 있습니다.  위에서 언급한 내용의 경우 제가 2년 정도 운영을 하면서 거의 대부분의 분들이 겪는 문제였습니다. 아무래도 분석가 또는 개발자의 경우 Query의 성능에 대해서 완전하게 알지 못하기 때문에 많이들 겪는 문제라고 보입니다.

 

위의 언급한 4가지를 기억해서 나중에 데이터를 분석하거나 개발을 하실 때 많은 부분에 있어서 좋은 영향이 있기를 바랍니다.

 

 

감사합니다.

 

 

---

참고 자료

 

https://towardsdatascience.com/5-bigquery-sql-performance-tips-for-modern-data-scientists-f880b79cfa71

5 Bigquery SQL performance tips for modern data scientists

https://towardsdatascience.com/10-sql-standards-to-make-your-code-more-readable-in-2021-4410dc50b909

10 SQL standards to make your code more readable in 2021

https://bcho.tistory.com/1117

구글 빅데이타 플랫폼 빅쿼리 아키텍쳐 소개