2장 빅데이터의 탐색
데이터를 시각화하는 환경을 정비함으로써 데이터를 더 효율적으로 탐색할 수 있도록 준비하자.
2-1 크로스 집계의 기본
크로스 테이블 : 행과 열이 교차하는 부분에 데이터가 들어가는 테이블 (사람이 보기 쉬움)
트랜잭션 테이블 : 행 방향으로만 증가하게 하고, 열 방향으로는 증가하지 않는 테이블 (DB에서 다루기 쉬움)
트랜잭션 테이블에서 크로스 테이블로 변환하는 과정을 크로스 집계(cross tabulation)라고 한다.
소량의 데이터를 크로스 집계하는데 편리한 것이 스프레드시트의 피벗 테이블(pivot table)이다.
행과 열의 원하는 속성을 선택하고 결과값을 설정 할 수 있다. (합계, 평균, 최댓값 등)
크로스 집계로 결과를 즉시 얻을 뿐 아니라 그것을 그래프로 시각화하는 피벗 그래프(pivot graph) 또한 존재한다.
트랜잭션 테이블에 새로운 항목 추가가 아닌, 다른 테이블과 결합하고 싶을 때 사용하는 것이 룩업 테이블(lookup table)이다.
트랜잭션 테이블과 룩업 테이블은 서로 독립적으로 관리할 수 있다.
스프레드시트 외에도 BI 도구(tableau), Pandas, SQL로 크로스 집계가 가능하다.
본 책에서도 데이터를 먼저 'SQL로 집계'하고 '시각화 도구로 크로스 집계'하는 두 단계의 절차를 밟는다.
BI도구에 의존하지 않고 SQL과 Pandas 각각 한 가지만 사용해서 크로스 집계하는 것 또한 가능하다. (p.52)
데이터 마트는 데이터의 집계와 시각화 사이에 존재한다.
데이터 마트가 작을수록 시각화하는게 간단하지만, 원래 데이터에 포함된 정보가 누락되는 등 시각화 프로세스에서 할 수 있는 것이 적어진다. => 정보 부족
데이터 마트가 큰 것 또한 성능이 나빠져 좋은 시각화를 할 수 없게 된다.
둘은 서로 트레이드 오프(trade off) 관계이고 필요에 따라 어느정도 정보를 남길 것인지 결정해야 한다.
2-2 열 지향 스토리지에 의한 고속화
데이터가 증가할수록 집계에 걸리는 시간이 길어지기 때문에 이에 대비하는 작업이 필요하다.
데이터 레이크나 DWH에 방대한 데이터를 저장하고, 원하는 데이터를 추출하여 데이터 마트를 구축, 이후에는 항상 초 단위의 응답을 얻어 즉각적으로 시각화를 얻을 수 있도록 한다.
데이터가 적다면 RDB를 사용해도 지연이 적고 오히려 우수한 데이터 마트 구축이 가능하다.
하지만 RDB는 메모리가 부족하면 급격히 성능이 저하된다.
고속화를 위해 사용되는 기술이 압축과 분산이다. 데이터를 가능한 작게 압축하고 그것을 여러 디스크에 분산하는 것이다.
분산된 데이털르 읽을려면 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리하는 것이 효과적이다. 이러한 아키텍처를 MPP(massive parallel processing, 대규모 병렬 처리)라 한다. (ex. Amazon Redshift, Google BigQuery).
지금은 클라우드 서비스의 보급 등으로 도입 문턱이 낮아져 널리 이용된다.
이제 MPP의 기술을 데이터 마트에도 활용하는 것을 생각해보자
일반적으로 업무 시스템 등에서 사용되는 DB는 레코드 단위의 읽고 쓰기에 최적화되어 있으며, 이를 행 지향 DB라고 한다. (일반적인 RDB)
행 지향 DB는 테이블의 각 행을 하나의 덩어리로 디스크에 저장한다.
이러면 새 레코드를 추가할 때 파일의 끝에 데이터를 쓰기만 하면 되서 빠르게 추가가 가능하다.
매일 대량의 트랜잭션을 지연 없이 처리하기 위해 데이터 추가를 효율적으로 할 수 있도록 하는 것이 특징이다.
데이터 검색을 고속화하기 위해 인덱스(index)를 만든다. 인덱스가 없다면 저장되는 모든 데이터를 로드해야 하기 때문에 많은 디스크 I/O가 발생해 성능 저하로 이어진다. 따라서 적절한 인덱스가 사용되도록 튜닝하는 것이 좋다.
이에 반해 데이터 분석에 사용되는 DB는 칼럼 단위의 집계에 최적화되어 있으며 열 지향 DB라고 한다. (ex. Teradata, Amazon Redshift)
데이터 분석에는 어떤 칼럼이 사용되는지 미리 알 수 없기 때문에 인덱스 외의 방법이 필요하다.
데이터 분석에는 종종 일부 칼럼만이 집계 대상이 된다. (ex. 점포의 총매출) 행 지향 DB라면 칼럼을 불러올 때 필요없는 열의 데이터까지 디스크에서 불러오게 된다.
열 지향 DB는 데이터를 미리 칼럼 단위로 정리해 둠으로써 필요한 칼럼만을 로드하여 디스크 I/O를 줄인다.
열 지향 DB는 데이터의 압축 효율도 우수하다. 칼럼에는 대게 유사한 데이터 나열되기 때문이다.
쿼리 지연을 줄이는 다른 방법으로는 MPP 아키텍처에 의한 데이터 처리의 병렬화다.
행 지향 DB는 쿼리를 분산 처리하는 상황을 가정하지 않는다. (각 쿼리들이 금방 끝나기 때문)
열 지향 DB는 한번에 대량의 데이터를 읽기 때문에 단개의 쿼리 실행 시간이 길어진다. 또, 압축된 데이터를 풀어야 함으로 CPU 리소스를 필요로 한다. 이 때는 멀티 코어를 활용해 병렬 처리하는 것이 좋다.
MPP에서는 하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 가능한 병렬로 실행한다. => 코어 갯수와 성능이 정비례한다. (쿼리가 리소스를 전부 사용해 시스템이 마비되는 것을 막기 위해 리소스 제한 기법도 있다.)
MPP 데이터베이스 : MPP의 구조상 HW와 SW가 통합된 제품으로 제공된다. 이렇게 HW 수준에서 집계에 최적화된 DB를 MPP 데이터베이스라고 한다.
대화형 쿼리 엔진 : MPP의 아키텍처와 Hadoop과 함께 사용해서 대화형 쿼리 엔진으로도 많이 채택한다. 이 경우 데이터를 저장하는 것은 분산 스토리지의 역할이다.
결론은 빅데이터 집계를 위해서는 열 지향 DB로 데이터를 압축해서 사용하는 것을 책에서는 설명한다.
2-3 애드 혹 분석과 시각화 도구
Jupyter Notebook에 의한 애드 혹 분석 (노트북에 분석 과정 기록하기)
어떤 데이터 분석이라도 처음에는 애드 혹 분석부터 시작한다.
중구난방으로 있고, 집계에 얼마나 걸릴지 모르는 데이터를 여러 번의 시행착오를 반복해서 데이터를 살펴보는 것이다.
위 과정에서 대화형 실행환경이 자주 사용된다. 이런 환경으로 Jupyter notebook이 인기다.
주피터 노트북안에서 바로 애드 혹 분석이 가능하고 시각화 또한 파이썬 코드만으로 즉각적으로 가능해서 편리하다.
또한 여러 셀로 나누어 작업을 해놔도 한 번에 순차적으로 실행할 수 있는 기능이 있어 간단한 워크플로는 노트북으로도 가능하다.
대시보드 도구 (정기적으로 집계 결과를 시각화하기)
애드 혹 분석과는 대조적으로, 정기적으로 쿼리를 실행해야 하는 경우 (보고서, 그래프로 대시보드 만들기 등) BI 도구를 사용할 수 있겠다.
하지만 단순히 대시보드를 만드는 것이라면 특화된 전용 도구가 있다.
BI 도구와 다르게 대시보드 도구에선느 최신의 집계 결과를 즉시 확인할 수 있길 기대한다. 정해진 지표의 일상적인 변화를 모니터링하고 싶은 경우에 적절하다.
대시보드 도구로는 오픈 소스인 Redash, Superset 실시간 시각화 도구인 Kibana가 있다.
BI 도구 (대화적인 대시보드)
몇 개월 단위의 장기적인 데이터를 시각화하거나, 집계의 조건을 세부적으로 바꿀 수 있는 대시보드를 만들려면, BI 도구를 사용하는 것이 적합하다. (tableau가 대표적이다)
BI 도구에서는 이미 있는 데이터를 그대로 가져올 뿐만 아니라, 시간을 들여 데이터를 분석하기 쉽도록 가공하는 일이 자주 있다. 따라서, 즉각 시각화에 적합한 상태를 만들기 위해 데이터 마트를 만들어 읽고 쓰는 것을 전제로 한다.
대화형 대시보드를 만들기 위해서는 그 바탕이 되는 데이터를 모두 포함하는 하나의 테이블을 작성한다. 테이블에서는 다수의 대시보드를 만든다.
전체 숫자를 파악할 수 있는 테이블이 적어도 하나, 그것을 분해하여 주요 지표를 정리한 것이 몇 가지 있으면 좋다.
2-4 데이터 마트의 기본 구조
BI 도구를 사용함에는 시각화에 필요한 데이터만 모아놓은 데이터 마트가 필수이다.
이 데이터 마트에 핵심적인 개념인 OLAP(online analystic processing)라는 구조가 있다.
OLAP에서는 '다차원 모델'의 데이터 구조를 MDX(multidimensional expressions) 등의 쿼리 언어로 집계한다. 데이터 분석을 위해 만들어진 다차원 데이터를 OLAP 큐브라고 하고, 이를 크로스 집계하는 구조가 OLAP이다.
컴퓨터 성능이 좋지 못 할 때는 크로스 집계에 모든 조합을 미리 계산하여 DB 안에 캐시해두고 쿼리가 실행되면 이미 집계된 결과를 반환하는 구조로 했다.
그러나 최근에는 MPP DB와 인 메모리 DB 등의 보급으로 사전에 계산해 둘 필요가 없어졌다. OLAP 큐브를 위해 특별한 구조를 준비하는 것이 아니라 BI 도구와 MPP 데이터베이스를 조합하여 크로스 집계하는 경우가 증가하고 있다.
하지만 MPP DB에 다차원 모델 개념이 없기 때문에 비정규화 테이블을 BI 도구에서 열어서 기존의 OLAP와 동등한 시각화를 실현 가능하다.
시각화에 적합한 데이터 마트를 만드는 것은 BI 도구를 위한 비정규화 테이블을 만드는 프로세스다.
팩트 테이블 : DWH의 기록된 실직적인 (사실적인) 데이터 (집계의 기반이 되는 숫자 데이터)
디멘전 테이블 : 마찬가지로 팩트 테이블 데이터에 참고되는 마스터 데이터 (데이터를 분류하기 위한 속성값)
스타 스키마 : 팩트 테이블을 중심으로 여러 디멘전 테이블을 결합하여 만든 스키마 (데이터 마트)
디멘전 테이블을 작성하려면 정규화에 의해 분해된 테이블을 최대한 결합하여 하나의 테이블로 정리한다. (비정규화 작업이기 때문에 중복은 괜찮다.)
스타 스키마를 사용하는 이유가 2가지인데, 첫째는 단순해서 이해가 쉽고 둘째는 성능상의 이유다.
하지만 MPP DB 같은 열 지향 DB가 보급됨에 따라 칼럼의 수가 아무리 늘어나도 성능에 영향을 주지 않게 됐다.
이에 지연이 거의 없어져 하나의 거대한 팩트 테이블만 있으면 충분해졌다.
스타 스키마는 과거의 얘기가 됐고 적어도 성능상의 문제는 열 지향 스토리지로 해결된다.
스타 스키마에서 좀더 비정규화를 진행해 모든 테이블을 결합한 팩트 테이블을 비정규화 테이블(denomarlized table)이라고 한다.
본 책에서는 데이터 마트는 비정규화 테이블로 만드는 것으로 가정한다.
다차원 모델 (multidimensional model) : BI 도구의 기본이 되는 데이터 모델로 테이블 및 칼럼의 집합을 알기 쉽게 정리해 이름한 것이다.
시각화 프로세스는 시각화하고 싶은 측정값 및 디멘전을 결정(이 다차원 모델의 정의는 언제든 확장할 수 있다)하고 데이터 마트에 비정규화 테이블을 만들고 그것을 BI 도구로 시각화한다.
위에 만들어진 비정규화 테이블이 바로 데이터 마트인 것이다. 그래프를 만들고 나면 비정규화 테이블을 업데이트하는 것만으로 이를 참고하는 모든 그래프가 업데이트 된다.
워크플로 관리 도구 등을 이용해서 데이터 마트를 정기적으로 자동 업데이트 시킬 수도 있다.
요약
빅데이터를 탐색을 위해 기본이 되는 DB 구조들과 여러 아키텍처들을 배웠고 이들을 어떤 상황에서 어떻게 분석하는 것이 효율적인지 또한 배웠다.
