[빅데이터를 지탱하는 기술] CH 02. 빅데이터의 탐색

CH 02. 빅데이터의 탐색

빅데이터 탐색이란 즉 시각화하는 것이다.

2-1. 크로스 집계의 기본

트랜잭션 테이블, 크로스 테이블, 피벗 테이블

- 크로스 집계의 개념

 

일반적으로 데이터를 정리한 표에서 행과 열이 교차하는 부분에 파악하고자 하는 숫자데이터가 들어가게 되고 이를 크로스 테이블이라 부른다. 액셀에서는 간단한 작업같지만, 데이터베이스에서는 열을 늘리는 것이 간단한 작업이 아니다. 따라서 엑셀과는 다르게 데이터의 추가가 테이블의 행 추가로만 이어지는 것을 일반 데이터 베이스의 트랜잭션 테이블이다. 

트랜잭션 테이블에서 크로스 테이블로 변환하는 과정을 크로스 집계라고 한다.  일반적으로 피벗 테이블을 많이 활용한다. 

판다스를 통해서도 이러한 작업이 가능하다. 데이터가 너무 많으면 우선 SQL로 집계하고 크로스 집계를 하는 것이 좋다. 

 

데이터 집계 -> 데이터 마트 -> 시각화

- 시스템 구성은 데이터 마트의 크기에 따라 결정된다.

 

데이터 집계를 최소화 한다면 시각화 작업이 복잡해 지거나 그 반대이다. 즉 데이터 마트의 크기에 따라 집계와 시각화는 트레이드 오프 관계이다. 

 

2-2. 열지향 스토리지에 의한 고속화

데이터베이스의 지연 줄이기

 

탐색, 즉 시각화하여 데이터 분석에 활용하기 위해서는 데이터 저장소에서 데이터를 가지고 오는 과정이 필요하다. 이를 탐색이라 하는데, 이를 위해 데이터를 처리하는 대기 시간이나 지연이 적도록 해야 한다. 

가장 간단한 방법은 모든 데이터를 메모리에 올리는 것이다.  하지만 이 또한 메모리용량을 초과하는 데이터의 경우에는 불가능하다. 

데이터베이스 자체의 메모리를 늘리면 되지만 보통은 데이터를 분산/압축하는 방식을 진행한다. 

압축하고 분산된 데이터를 읽어들이려면 멀티코어를 활용하여 디스크 I/O를 병렬처리해야 한다. 이를 위해서는 MPP(massive parallel processing : 대규모 병렬처리) 아키텍쳐를 기반으로 한 데이터 베이스를 사용한다.

이러한 데이터 베이스는 또한 기본적으로 열지향 데이터 베이스로서 분석을 위한 대용량 읽기처리를 지원한다. 

 

열 지향 데이터 베이스 접근

- 칼럼을 압축하여 디스크 I/O 줄이기

 

일반적으로 업무 시스템에서 사용되는 데이터베이스는 레코드 단위의 읽고 쓰기에 최적화 되어 있으며 이를 행지향 데이터베이스라고 부른다. 하지만 빅데이터를 다루는 경우에는 쿼리에 필요한 최소한의 데이터를 가져옴으로써 지연을 줄여야 하고 이 때 칼럼단위로의 데이터 압축 방법을 사용한다. 따라서 분석용 데이터 베이스는 열지향 데이터 베이스이다.

데이터 처리의 성능은 두 종류의 숫자로 표시된다. 
- 일정 시간에 처리할 수 있는 데이터의 양(처리양) : 대규모 데이터 처리에서 중요시 
- 데이터 처리가 끝날 때까지의 대기시간(지연) : 데이터 분석에서 중시

이 두가지는 무조건 양립하진 않는다. 
일반적으로 데이터 웨어하우스와 데이터 레이크는 대량의 데이터를 처리하기 위해 처리량에 집중했다. 
반면에 데이터 마트는 지연시간의 단축에 집중했다. 

행지향 데이터베이스는 테이블의 각 행을 하나의 덩어리로 디스크에 저장한다. 일반적은 업무용 데이터 베이스의 경우 쓰기/ 수정작업 등의 트랜잭션 처리가 많으므로, 이에 특화되어있다. 읽기 작업을 위해 인덱스 작업은 필수이다.

열지향 데이터베이스는 일부 칼럼만이 집계 대상이 된다. 데이터를 미리 칼럼 단위로 정리해 둠으로써 필요한 칼럼만을 로드하여 디스크 I/O를 줄인다.

 

MPP데이터 베이스의 접근 방식

- 병렬화에 의해 멀티코어 활용

 

열지향데이터 베이스에서는 한번의 쿼리로 대량의 데이터를 읽어들이고 압축된 데이터를 전개하므로 CPU리소스가 많이 필요하여 멀티코어를 활용하여 고속화 하는 것이 좋다. 

MPP에서는 하나의 쿼리를 작은 태스크로 분해하고 이를 가능한 병렬로 실행한다. 이후 CPU코어수에 비례하여 고속화한다. 단 디스크로부터 병목이 발생하지 않도록 데이터가 고르게 분산되어 있어야 한다. 

즉 여러 하드웨어적인 작업의 효율성을 위해서 하드웨어와 소프트웨어가 결합한 MPP데이터베이스를 사용하기도 한다. 

이에 따라 실제로 모든 데이터 저장소로 MPP아키텍처를 따른 데이터베이스를 쓸 것 같지만, 때에 따라서는 Hadoop과 함께 대화형 쿼리엔진을 사용하기도 한다. 이 때 데이터를 저장하는 것은 분산스토리지의 역할이다.

그러나 결국 열지향으로 압축해야 하는 작업을 해야하므로  데이터를 저장할 때 열지향 스토리지로 만들기 위해 별도 라이브러리를 사용해야 한다. Hadoop과의 궁합을 위해서 이를 감안하고 택하기도 한다. 반대로 시스템 안정성과 서포트 체제 등을 고려해서는 MPP데이터베이스를 쓰기도 한다. 

 

2-3. 애드혹 분석과 시각화 도구

Jupyter Notebook에 의한 애드혹 분석

 

대시보드 도구

-정기적으로 집계결과를 시각화 하기

 

데이터 탐색을 위한 분석툴에 대해서 이 책에서는 크게 redash / superset(내부적으로 druid와 연동, 외부 데이터 스토어와 연동) / kinbana(실시간 데이터 시각화 , elasticsearch만 지원) 세가지가 있다. 물론 이 것만 있는 게 아니라 다양한 툴들이 존재한다. 그리고 이러한 BI툴들이 데이터를 효율적으로 탐색하기 위한 저장소로 데이터 마트가 존재한다. 데이터 마트는 데이터 웨어하우스에서 분석에 필요한 데이터만을 가공해서 빠른 속도로 최적화된 환경에서 분석하게 하기 위한 별도의 데이터 저장소이다.(물론 데이터 웨어하우스의 성능향상으로 필요하지 않게 되는 경우도 있다.)

데이터의 집계속도가 점점 빨라지면서 데이터 마트를 만들지 않아도 되는 경우가 늘어나고 있다. 
그렇지만 현실적으로 시스템의 부하를 낮출필요가 있으므로 데이터 마트를 만드는 것이 장기적으로 좋다. 
데이터 마트는 안정적인 성능이 요구된다. 데이터 웨어하우스에서 커다란 배치처리가 동작할 때마다 BI도구의 움직임이 멈추는 현상은 피하고 싶을 것이다. 

 

2-4. 데이터 마트의 기본구조

시각화에 필요한 정보만을 모은 데이터 마트는 필수적이다. 

 

시각화에 적합한 데이터 마트 만들기

- OLAP

이에 대해서는 블로그에 정리해두었으니 참고(OLTP VS OLAP)

 

RDB는 표형식으로 모델링된 데이터를 SQL로 집계한다. OLAP에서는 다차원 모델의 데이터 구조를 MDX(multidimensional expressions) 쿼리언어로 집계한다. 데이터 분석을 위해 만들어진 다차원 데이터를 OLAP큐브라고 부른다. 이를 크로스 집계하는 구조가 OLAP이다. 

데이터마트 즉 분석을 위한 데이터 베이스의 핵심은 OLAP이다. OLAP는 데이터 집계를 효율화하는 접근 방법 중의 하나다. 이전에는 성능이 좋지 않았기 때문에 분석을 위한 집계를 미리 계산하여 데이터베이스 안에 캐시해두었지만, 이제는 그럴 필요가 없어졌다.

본래 BI도구는 OLAP구조를 사용하여 데이터를 집계하기 위한 소프트웨어이며 데이터 마트도 OLAP큐브로 작성되었다.

그러나 MPP데이터베이스와 인메모리 데이터베이스등의 보급으로, BI도구와 MPP데이터 베이스를 조합하여 크로스 집계하여, 분석에 용이하게 분석용 데이터 베이스를 비정규화 테이블로 구성하여 사용한다. 

 

테이블을 비정규화 하기

 

테이블은 트랜잭션과 마스터로 구분되는데, 트랜잭션은 시간의 흐름에 따른 데이터의 기록이고, 마스터테이블은 개별적인 정보이다. 예를 들어, 유저들의 정보가 마스터테이블이라면, 그 유저들의 서비스 이용 내역 정보는 트랜잭션 테이블이 되는 것이다. 

데이터웨어하우스에서는 트랜잭션과 비슷한 개념이 팩트 테이블이며 사실을 기록하고, 디멘션 테이블이 마스터 테이블의 개념이다. 

이에 더 심화되어서 정교하게 작업한다면, 팩트 테이블에는 각 디멘션 테이블들에 대한 집계값도 들어가야 한다.

(ETL이 좀 더 복잡해져야 하는 것이다.)

**이에 대해서는 여러 블로그를 참고하고 실제로 회사의 데이터웨어하우스의 스키마를 짜고 팩트/디멘션 테이블을 구성했는데, 팩트 테이블을 중심으로 디멘션 테이블이 연결된 스타스키마 형태로 짰다. 더 쉽게 말하자면 팩트 테이블이 관계형 테이블의 외래키들이 쌓여있고 데이터의 특성을 정의하고, 그 주변을 각 정보들을 설명하는 디멘션 테이블로 이루어져 있다. 실제로 이후 책에서도 스타스키마에서는 팩트 테이블을 중심으로 디멘션 테이블이 이루어져 있다고 한다.

일반적으로 데이터 웨어하우스와 데이터마트 모두 스타스키마 형태로 구축하고, 데이터 마트를 비정규화 하자.
그 이유는 데이터의 구조를 이해하기 쉽고, 데이터 분석을 쉽게 할 수 있기 때문이다. 
또한 성능상의 이유로도 스키마 형태를 잘 짜야 한다. 데이터 양이 증가함에 따라 팩트 테이블은 커지고 어느순간 메모리 용량을 초과하며 디스크 I/O가 발생하여 쿼리 지연을 불러일으킬 수 있다. 따라서 팩트 테이블을 될 수 있는 한 작게 하는 것이 고속화에 중요하다.  
디멘션 테이블 작성시에는 정보가 중복되어도 좋으니, 최대한 분해된 테이블들을 합치는 작업이 필요하다. 실제로 팩트 테이블이 데이터 분석 성능을 좌우하기 때문에, 결국 ID 키값만 남게 된다. 

 

그러나 최근 MPP데이터베이스로 열지향 스토리지를 갖는 시스템이 보급됨으로써 칼럼의 수가 아무리 늘어도 성능에 영향을 주지 않는다. 따라서 애초에 팩트 테이블에 모든 칼럼을 포함하여 비정규화를 최대한으로 진행하여 쿼리 실행시 조인을 최소화 하는 것이 간단하다. 

 

즉 데이터 마트에 스타스키마가 사용되는 것은 과거의 이야기이다. 적어도 성능상의 문제가 열지향 스토리지로 해결되어서 거대한 하나의 팩트 테이블만 있어도 충분하게 되었다. 

 

그러나 데이터웨어하우스는 스타스키마가 우수하다. 데이터를 축적하는 단계에서는 팩트테이블와 디멘션 테이블로 분리하고 분석단계에서 최종적으로 결합하여 비정규화 테이블을 만드는 것을 추천한다.