집계 분석의 한계를 넘은 연결 분석의 시작

BigQuery Graph, 연결 관계를 분석하다

며칠 전 Google Cloud가 BigQuery Graph를 정식 출시했는데요.

참고로 BigQuery는 Google Cloud에서 제공하는 클라우드 데이터 분석 서비스입니다.

기업의 고객 · 주문 · 상품 · 접속 로그처럼 많은 데이터를 테이블 형태로 저장하고, SQL을 이용해 빠르게 집계하고 분석할 수 있습니다. 예를 들어 쇼핑몰에서는 BigQuery를 이용해 월별 매출, 상품별 판매량, 고객별 구매금액, 유입 채널별 전환율 등을 계산합니다. BigQuery Graph는 여기에 고객·상품·주문·판매자 등이 어떻게 연결돼 있는지 탐색하는 기능을 추가한 것입니다.

"Graph"라고 하니, 이름만 보면 막대그래프나 선그래프를 만드는 기능처럼 들리겠지만,

여기서 말하는 "Graph"는 차트가 아닙니다.

고객과 상품, 주문처럼 데이터에 등장하는 대상을 노드(Node)로 만들고,

고객이 상품을 조회하거나 주문했다는 관계를 엣지(Edge)로 연결한 데이터 구조입니다.

간단히 표현하면 노드는 명사에 가깝고, 엣지는 노드와 노드 사이에서 발생한 동사에 가깝습니다.

고객, 상품, 주문, 판매자, 기기: 노드

조회했다, 구매했다, 판매했다, 사용했다: 엣지

다만, 실제 데이터를 설계할 때는 노드와 엣지를 이보다 조금 더 세밀하게 구분해야 합니다.

BigQuery Graph는 이렇게 연결된 데이터를 따라가며, 여러 단계에 걸친 관계와 경로를 찾는 기능입니다.

기존 데이터 분석이 “얼마나 발생했는가?”를 주로 물었다면, 연결관계 분석은 “어떤 대상을 거쳐 이런 결과가 만들어졌는가?”를 묻습니다.

BigQuery Graph는, 분석에서 흔히 활용되는 "집계분석"과 결이 같다고 보는 편이 좀 더 이해하기 쉬울 듯한데요, 일반적인 집계분석은 이미 테이블에 있는 항목을 기준으로 데이터를 묶지만, BigQuery Graph는 여러 테이블의 연결관계를 따라가며, 기존에는 없었던 새로운 분석 집단을 찾아준 다음 그 집단을 다시 집계하는 기능을 갖고 있습니다.

즉 BigQuery Graph는 집계를 대신한다기보다, 무엇을 하나의 집단으로 묶어 봐야 하는지 찾아주는 역할에 가까운거죠.

집계 분석만으로는 보이지 않던 공통 경로의 발견

한 쇼핑몰에서 전자제품에 대한 반품이 늘었다고 해보겠습니다.

이 경우 분석가는 먼저 월별 반품 건수와 반품률을 계산할 수 있습니다.

상품과 카테고리, 판매자, 배송지역별로 나눠

어느 집단에서 반품이 많이 증가했는지 확인할 수도 있겠죠.

이런 저런 분석 결과 무선청소기와 휴대용 선풍기, 무선 스피커에서

반품률이 조금씩 높아졌다고 해보겠습니다.

각 상품의 증가 폭은 크지 않습니다.

상품 종류도 서로 달라서 처음에는 별개의 문제처럼 보이기도 하고

어느 상품 하나를 판매 중단해야 할 정도로 반품률이 높지도 않고요.

여기까지가 우리가 익숙하게 해온 집계분석입니다.

상품별 반품률을 비교하고, 반품이 많이 증가한 상품을 찾아내는 방식이요.

무엇이 얼마나 달라졌는지 확인하는 데는 이 방식이 잘 맞습니다.

그런데 세 상품에 같은 배터리 부품이 사용됐다면 이야기가 달라집니다.

그 배터리는 같은 부품업체에서 생산됐고,

동일한 물류센터를 거쳐 각 판매자에게 공급됐으며

반품 사유에도 충전 불량과 전원 문제가 반복해서 나타났습니다.

즉, 상품별로 나눠봤을 때는 작은 반품 증가였지만,

상품과 부품, 공급업체를 연결해서 보니 하나의 문제로 모이는 것이죠.

부품업체 → 배터리 → 여러 상품 → 주문 → 반품

물론 이 경로가 확인됐다고 배터리를 곧바로 반품 원인으로 확정할 수는 없습니다.

아직까지는 서로 다른 상품에서 동시에 나타난

반품 증가를 함께 설명할 만한 원인 후보는 찾은 셈입니다.

이렇게 집계분석이 반품이 증가한 상품을 찾았다면,

연결관계 분석은 그 상품들이 공통으로 거친 부품과 공급경로를 찾습니다.

차트가 아닌 연결구조로서의 Graph

앞의 사례에서 상품과 배터리, 공급업체, 주문은 각각 노드가 됩니다.

상품에 배터리가 사용됐다는 사실, 공급업체가 배터리를 납품했다는 사실,

그리고 고객이 상품을 주문했다는 기록은 엣지가 되고요.

노드와 엣지에는 추가 정보도 붙일 수 있습니다.

상품에는 카테고리와 가격, 출시일을 넣을 수 있고

구매 관계에는 주문일과 구매금액, 수량이 들어갑니다.

공급 관계에는 납품일과 납품량, 계약 기간을 기록할 수 있고요.

이 정보가 새로 생기는 것은 아닙니다.

기업의 데이터베이스에는 이미 상품 테이블과 주문 테이블, 부품 테이블, 공급업체 테이블이 있습니다.

연결관계 분석은 이 테이블에 흩어진 대상을 노드와 엣지로 정의하고,

여러 대상을 거쳐 이어지는 경로를 조회하는 것입니다.

그래서 BigQuery Graph를 이해할 때는

Graph를 시각화의 한 종류로 보기보다,

데이터를 연결관계 중심으로 표현하는 구조라고 보는 편이 정확합니다.

결과를 점과 선으로 시각화할 수는 있지만, 시각화 자체가 목적은 아닙니다.

어떤 상품과 부품, 공급업체가 몇 단계를 거쳐 연결돼 있는지 찾는 것이 먼저입니다.

기존 BigQuery 테이블에서 시작하는 연결관계 분석

고객과 상품, 거래 사이의 관계를 분석하는 기술은 이전부터 있었습니다.

다만 기존 데이터 웨어하우스와 별도로 그래프 데이터베이스를 구축해야 하는 경우가 많았습니다.

BigQuery에 저장된 데이터를 추출하고, 노드와 엣지 형태로 바꾼 뒤 별도 시스템에 적재해야 했습니다.

원본 데이터가 갱신되면 그래프 데이터도 다시 맞춰야 했고요.

데이터가 두 곳에 나뉘면 관리할 부분도 늘어납니다. 어느 쪽 데이터가 최신인지 확인해야 하고, 접근권한도 다시 설정해야 합니다. 연결망에서 발견한 결과를 기존 매출이나 고객 지표와 비교하려면 데이터를 다시 가져와야 할 수도 있습니다.

BigQuery Graph는 이 과정을 BigQuery 안으로 가져왔습니다.