모조리 기획해주마

최근 분석을 담당하고 있는 서비스의 백엔드가 Firebase로 넘어가면서 RDB가 아닌 No SQL 형태로 넘어갔다. SQL로 분석을 하는 입장에서는 매우 당황스러운 상황인데.. 빅쿼리라는 아주 핫하고 편한(속아서는 안돼 멈춰 Stay.. st..) 도구가 분석을 도와줄거라는 꾀임에 넘어가 와 그러면 우리도 어서 구글의 신기술을 맛보고 경험해봐요 라고 했다.

그러면 안됐다. 설령 내가 반대했더라도 상황이 뭐가 달라졌을까 싶지만.. 여하튼 최근에는 이 빅쿼리에 익숙해진다고 시간을 꽤 쓴 것 같다. 간단하게 몇 가지 포인트를 정리해보자면

 - Standard SQL 기반으로 돌아간다. Legacy SQL이라는 형태도 지원을 하는 것 같은데 대부분의 레퍼런스는 Standard SQL로 작성된다. 그래서 맨 처음에 쿼리 시작 전 #standardSQL을 적절하게 넣어주고 시작하는 습관을 들이면 좋을 듯 하다.

 - from 절에 standardSQL은 역따옴표로 테이블명을 감싸준다. 새로나온 UI에서는 그런 현상이 없는 것 같은데, 구 버전에서는 디폴트 설정이 Legacy SQL로 되어있기 때문에 [] <- 이걸로 테이블명을 감싸주게된다. 레거시 설정 하에서 스탠다드 기반의 코드를 작성해서 오류가 꽤 자주 난다.

 - NoSQL 기반의 데이터 형태를 마치 RDB를 다루는 듯한 착각을 주는 도구이다. 곳곳에서 흔적을 찾아볼 수 있는데 Collections(테이블과 같은 개념) 내의 키 값에 물려있는 여러 값들의 경우에는 1 row에 여러 값이 같이 들어가는 현상이 나타난다. 이건 from절에 unnest라는 함수를 적절하게 사용해서 잘 풀어줘야 한다.

 - 시간관련해서 포매팅할 때 일일이 형 변환을 잘 해줘야 한다. 가령 MySQL에서는 substr 펑션 내에 timestamp 형의 데이터를 넣고 데이터를 잘라도 알아서 잘 되었다면, 빅쿼리에서는 seconds -> timestamp -> string 이런식으로 단계적으로 형변환을 일일이 설정해서 넘겨줘야 한다. 만약 리전을 해외리전을 사용하고 있다면 시간대도 Asia/Seoul로 적절히 바꿔주어야 한다.

 - data studio와의 연동성이 생각보다 괜찮다. 물론 어디까지나, 생각보다.

시간이 된다면 Standard SQL 구문들을 한번 정리해보고 싶은 욕심이 든다.