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

데이터 엔지니어링 입문서로 추천되는 '빅데이터를 지탱하는 기술'에 대해 개인적인 생각으로 정리한 글입니다.

데이터 엔지니어로서 업무를 시작하기 전과 시작한 후에 느끼는 점이 달라 정리하게 됐습니다. 잘못된 부분이 있다면 댓글로 알려주시면 감사하겠습니다.

(출처 표기가 되지 않은 이미지는 모두 직접 그린 것이기 때문에 사용하실 때 반드시 출처를 남겨주시길 바랍니다.)

 

빅데이터를 지탱하는 기술 | 니시다 케이스케 - 교보문고

이 책의 두 번째 장인 '빅데이터의 탐색' 부분에서는 크로스 집계, 열 지향 스토리지, 시각화 도구, 데이터 마트의 설계에 대해 정리한다.

책의 전체 내용이 아닌 각 파트에서 개인적으로 와닿았던 부분들을 나의 용어로 정리한다.

크로스 집계의 기본

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

'크로스 집계'의 개념

크로스 테이블(Cross table)은 행과 열이 교차하는 부분에 숫자 데이터가 들어가는 테이블을 말한다.

왼쪽과 같이 사람들이 보기 편한 형태지만, 데이터 베이스에서는 다루기 어려운 데이터 형식이다.

데이터베이스에 새로운 행을 추가하는 것은 간단하지만, 열을 늘리는 것은 간단하지 않기 때문이다. 

(행을 추가하는 것은 이미 정의된 스키마에 따라 데이터를 입력하기만 하면 되지만, 열을 늘리는 것은 스키마 변경, 기존 데이터와의 호환성, 데이터 무결성 등을 고려해야 한다.)

따라서, 오른쪽의 트랜잭션 테이블(Transaction table) 형태와 같이 행 방향으로만 증가하게 하고, 열 방향으로는 데이터를 증가시키지 않도록 해야 한다.

트랜잭션 테이블에서 크로스 테이블로 변환하는 과정을 '크로스 집계(Cross tabulation)'이라고 하는데, 스프레드 시트의 '피벗 테이블(pivot table)' 기능을 사용하면 빠르고 쉽게 변환할 수 있다.

 

룩업 테이블

테이블을 결합하여 속성 늘리기

트랜잭션 테이블에 새로운 항목을 추가하는 것이 아니라, 다른 테이블과 결합하고 싶은 경우 룩업 테이블(Lookup table)을 사용할 수 있다.

룩업 테이블은 특정 정보에 대한 빠른 참조를 제공하기 위해 사전에 계산되거나 정의된 데이터를 포함하는 테이블이다.

크로스 테이블 -> 트랜잭션 테이블 -> 룩업 테이블

다음과 같이 룩업 테이블을 사용하면, 시스템에서 'M', 'F', 'U'와 같은 코드를 사용자가 이해할 수 있는 "남성", "여성", "알 수 없음"으로 쉽게 변환할 수 있다. 트랜잭션 테이블과 룩업 테이블은 서로 독립적으로 관리할 수 있다. 트랜잭션 테이블은 업무 데이터베이스 등에서 가져오는데 비해 룩업 테이블은 데이터 분석 용도에 따라 자유롭게 변경해도 상관 없다.

 

크로스 집계 방법

1. BI 도구에 의한 크로스 집계(ex. Tableau Public)

2. Pandas에 의한 크로스 집계

3. SQL에 의한 테이블 집계

수십 억 레코드의 데이터 레이크(Data Lake)에서 먼저 'SQL로 집계'해 수만~수억 레코드의 데이터 마트(Data Mart)를 생성한다.

다음으로, '시각화 도구로 크로스 집계'를 통해 5~100개 항목 정도의 크로스 테이블과 대시보드를 만든다.

각각의 단계를 '데이터 집계의 프로세스', '시각화 프로세스'라고 부르기로 한다.

 

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

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

데이터의 집계와 시각화 사이에 있는 것이 데이터 마트다.

데이터 집계와 시각화 사이에는 트레이드 오프(trade off) 관계가 있기 때문에, 필요에 따라 어느 정도의 정보를 남길 것인가를 결정해야 한다.

최종적으로는 '데이터 마트의 크기'에 따라 시스템 구성이 결정된다.

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

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

데이터의 양이 증가함에 따라 집계에 걸리는 시간 역시 길어진다. 초 단위로 데이터를 집계하기 위해서는 처음부터 그것을 예상해서 시스템을 마련해야 한다. 데이터 수집 단계에서는 거기까지 생각하지 않기 때문에 다음과 같이 3계층의 시스템을 만든다.

3계층의 데이터 집계 시스템

데이터 처리의 지연

데이터 처리의 응답이 빠르다는 표현을 '대기 시간(latency)이 적다' 또는 '지연이 적다'고 한다.

데이터 마트를 만들 때, 가급적 지연이 적은 데이터베이스가 있어야 하는데 이를 위한 가장 간단한 방법은 모든 데이터를 메모리에 올리는 것이다.

 

만일 한 레코드 크기가 500바이트라고 하면 천만 레코드의 경우 5GB가 되며, 이 정도의 양이라면 일반적인 RDB(MySQL, PostgreSQL 등)가 데이터 마트로 적합하다. RDB는 원래 지연이 적고, 많은 수의 클라이언트가 동시 접속해도 성능이 나빠지지 않으므로 많은 사용자가 사용하는 실제 운영 환경의 데이터 마트로 특히 우수하다.

 

하지만, RDB는 메모리가 부족하면 급격히 성능이 저하된다. 수억 레코드를 초과하는 데이터 집계에서는 항상 디바이스 I/O가 발생한다고 가정하고, 이것을 효율화하는 것이 중요해진다.

 

'압축'과 '분산'에 의해 지연 줄이기

데이터를 가능한 한 작게 압축하고, 그것을 여러 디스크에 분산함으로써 데이터 로드에 따른 지연을 줄일 수 있다.

분산된 데이터를 읽어 들이려면 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리하는 것이 효과적이다.

이러한 아키텍처를 MPP(Massive Parallel Processing: 대규모 병렬 처리)라고 부르며, Amazon Redshift나 Google BigQuery 등이 대표적이다. MPP는 데이터 집계에 최적화돼있으며, 데이터 웨어하우스와 데이터 분석용의 데이터베이스에 특히 많이 사용된다.

 

열 지향 데이터 베이스의 접근

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

빅데이터로 취급되는 데이터 대부분은 디스크 상에 있기 때문에 쿼리에 필요한 최소한의 데이터만을 가져옴으로써 지연이 줄어들게 된다.

이 때, 가장 많이 사용되는 방법이 '칼럼 단위로의 데이터 압축' 일반적으로 사용되는 데이터베이스는 레코드 단위의 읽고 쓰기에 최적화된 '행 지향 데이터베이스(row-oriented database)'이지만, 데이터 분석에 사용되는 데이터베이스는 칼럼 단위의 집계에 최적화돼있는 '열 지향 데이터베이스(column-oriented database)' 또는 '칼럼 지향 데이터 베이스(columnar database)'라고 한다.

 

처리량과 지연 시간

데이터 처리 성능은 다음의 두 종류로 자주 표시된다.

- 처리량(throughput): 일정 시간에 처리할 수 있는 데이터의 양으로, 주로 배치 처리 등의 대규모 데이터 처리에서 중요시된다.

- 지연(latency): 데이터 처리가 끝날 때까지의 대기 시간으로, 주로 애드 혹 데이터 분석 등에서 중요시된다.

 

데이터 웨어하우스와 데이터 레이크는 대량의 데이터 처리를 위해 처리 속도를 우선시하는 설계로 돼있는 반면, 데이터 마트는 빠른 응답 시간을 요구하므로, 충분한 메모리 확보와 디스크 I/O 최소화가 필수적이다.

 

행 지향 데이터베이스

새로운 레코드를 추가할 때, 끝부분에 추가되므로 고속으로 쓰기가 가능하다

테이블의 각 행을 디스크 상에 하나의 덩어리로 저장한다. 매일 발생하는 대량의 트랜잭션을 지연없이 처리하기 위해 데이터 추가를 효율적으로 할 수 있도록 하는 것이 특징이다. 행 지향 데이터베이스에서는 데이터 검색을 고속화하기 위해 인덱스(Index)를 만든다.

만약 인덱스가 없다면, 모든 행을 스캔(Full Scan)해 많은 디스크 I/O가 발생해 성능이 저하된다. 따라서 적절한 인덱스를 설정해야 쿼리 성능을 최적화 할 수 있다. (ex. Index Scan)

한편, 데이터 분석에서는 어떤 컬럼이 사용되는지 미리 알 수 없기 때문에 인덱스를 생성했다고 해도 거의 도움이 되지 않는다.

필연적으로 데이터 분석은 항상 디스크 I/O를 동반하기 때문에 인덱스에 의지하지 않는 고속화 기술이 필요하다.

 

열 지향 데이터 베이스

컬럼별로 데이터를 보관해, 집계 시에 관련된 컬럼만 읽는다. 데이터 구조상 집계는 고속이지만, 저장(쓰기)는 시간이 걸린다.

데이터 분석에서는 주로 일부 컬럼만이 집계 대상이 되지만, 행 지향 데이터베이스에서는 레코드 단위로 데이터가 저장돼있으므로 필요없는 열까지 디스크로부터 로드된다. 반면, 열 지향 데이터베이스에서는 데이터를 미리 컬럼 단위로 저장함으로써 필요한 컬럼만을 로드해 디스크 I/O를 줄일 수 있다.

열 지향 데이터베이스는 각 열이 동일한 타입의 데이터만 포함하기 때문에 압축 효율이 높다. 특히, 같은 문자열이 반복될 때 매우 효과적으로 데이터를 압축할 수 있다. 

 

가장 널리 사용되는 압축 방법 중 하나인 Run-Length Encoding에 대한 예시를 살펴보자

예를 들어, 고객 데이터베이스의 '회원 등급' 컬럼에 'Silver', 'Gold', 'Platinum'과 같은 등급이 저장돼있고, 대부분의 고객이 'Silver' 등급이라고 가정해보자. 만약 1000명의 고객 중 950명이 'Silver' 등급이라면 다음과 같이 압축할 수 있다.

- 원본 데이터: Silver, Silver, Silver, …, Silver (950회 반복), Gold, Platinum, Silver, …

- RLE 압축 후: (Silver, 950), Gold, Platinum, Silver, …

반복되는 값과 그 반복 횟수만을 저장함으로써 데이터를 매우 효율적으로 압축할 수 있다.

 

대표적인 열 지향 데이터베이스 시스템은 다음과 같은 것들이 있다.

- Apache Cassandra: 분산 NoSQL 데이터베이스 시스템으로, 대규모 데이터를 다루는 분산환경에 적합하며 고가용성과 확장성을 제공한다.

- Apache HBase: Hadoop 기반의 분산 데이터베이스로, 대량의 데이터를 빠르게 읽고 쓸 수 있다.

- Apache Parquet: 데이터베이스 시스템이 아닌 열 지향적인 데이터 저장 포맷으로, 높은 압축률 및 인코딩 효율을 제공한다.

- Google BigQuery: Google Cloud에서 제공하는 완전 관리형 데이터 웨어하우스로, 대규모 데이터셋의 스토리지 및 쿼리를 위해 열 지향 저장 방식을 사용한다.

- Amazon Redshift: AWS에서 제공하는 완전 관리형 데이터 웨어하우스 서비스로, 열 지향 저장 방식을 통해 빠른 데이터 로딩, 저장, 쿼리 성능을 제공한다.

 

열 지향 데이터베이스는 종류에 따라 다르지만 압축되지 않은 행 지향 데이터베이스와 비교하면 1/10 이하로 압축할 수 있다.

 

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

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

행 지향 데이터베이스에서 보통 하나의 쿼리는 하나의 스레드(단일 CPU 코어)를 사용해 해당 쿼리를 실행한다.

즉, 하나의 쿼리가 여러 CPU 코어에 의해 나누어 처리(분산처리)되지는 않는다. 하지만, 멀티코어 환경에서는 여러 쿼리를 동시에 처리할 수 있으므로, 서로 다른 쿼리들이 각각 다른 CPU 코어에서 동시에 실행될 수 있다. (이는 여러 사용자가 동시에 데이터베이스에 접근 가능하게 한다.) 각 사용자의 쿼리는 별도의 스레드에서 처리되므로, 여러 코어가 활용돼 전체 시스템의 효율을 높일 수 있다. 

 

한편, 열 지향 데이터베이스에서는 쿼리를 처리할 때 관련된 열에 저장된 모든 데이터를 읽어야 하므로, 하나의 쿼리 실행에 상대적으로 많은 시간이 소요될 수 있다. 또한, 압축된 데이터를 해제해야 하므로 CPU 리소스이 추가적으로 필요로된다. 이러한 이유들로 인해, 멀티 코어 프로세서의 병렬 처리를 활용해 쿼리 속도를 향상시킬 수 있다. MPP에서는 하나의 쿼리를 여러 개의 작은 태스크로 나누고(분산처리), 이를 여러 프로세서나 컴퓨터에서 동시에 병렬로 처리할 수 있도록 한다.

 

MPP 데이터베이스에서는 여러 디스크에 분산된 데이터가 서로 다른 CPU 코어(또는 노드)에 있는 스레드에 의해 독립적으로 읽혀 부분적인 쿼리 실행이 이루어진다. 그 결과들은 한 곳에 모이고 최종적인 결과가 출력된다. 이 일련의 처리는 가능한 한 동시에 병렬로 실행된다.

 

MPP 데이터베이스와 대화형 쿼리 엔진

MPP(Massively Parallel Processin) 데이터베이스는 쿼리 처리를 병렬화하여 CPU 코어 수에 비례해 데이터 처리 속도를 높일 수 있는 시스템이다. 

1. 데이터 분산: 데이터는 여러 디스크에 균일하게 분산돼, 디스크 읽기 작업이 병목 현상을 일으키지 않도록 해야 한다.

2. 하드웨어 균형: MPP 시스템은 CPU와 디스크 사용이 균형을 이루도록 설계돼야 하며, 때로는 하드웨어와 소프트웨어가 통합된 형태로 제공된다. 이처럼 하드웨어 수준에서 데이터 집계에 최적화된 데이터베이스를 'MPP 데이터베이스'라고 한다.
(ex. Amazon Redshift, Google BigQuery, Teradata)

3. Hadoop과의 연동: MPP 아키텍처를 기반으로 하는 시스템은 대용량 데이터 처리와 빠른 쿼리 응답 능력을 갖춤으로써 '대화형 쿼리 엔진'으로서의 역할을 할 수 있으며, Hadoop과 함께 사용될 경우 Hadoop 데이터에 대한 효율적인 쿼리 처리를 지원한다. 이 경우 데이터를 저장하는 것은 분산 스토리지 역할이다.

애드 혹 분석과 시각화 도구

대시보드 도구

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

정기적으로 쿼리를 실행해 보고서를 작성하거나 주요 그래프를 모아서 대시보드를 작성하면, 최신의 집계 결과를 즉시 확인할 수 있다.

하루에 한 번 자동 갱신하거나, 때에 따라서는 실시간으로 데이터를 업데이트할 수 있도록 해야 한다. 정해진 지표의 일상적인 변화를 모니터링하고 싶은 경우에 이러한 대시보드가 적합하다.

 

Redash

파이썬으로 만든 대시보드 도구로, 데이터 소스에서 직접 쿼리를 실행하고 결과를 시각화해 대시보드를 만들 수 있다. 사용자 친화적인 인터페이스를 제공하며, SQL과 같은 쿼리 언어를 통해 데이터베이스에서 직접 데이터를 조회할 수 있다. 하나의 쿼리가 하나 또는 여러 그래프에 대응하며 등록한 쿼리는 정기적으로 실행돼 그 결과가 Redash 자신의 데이터베이스에 저장된다. Hive에서 1시간 걸리는 쿼리가 있더라도, Redash는 마지막으로 실행된 집계 결과를 표시할 뿐이기에 대시보드의 표시가 즉시 이루어져 별도의 데이터 마트를 만들 필요가 없다.

하지만, 대량의 데이터를 처리할 수는 없다. 그래프의 수만큼 쿼리를 실행하게 되고, 대시보드가 증가함에 따라 백엔드 데이터베이스의 부하가 높아진다.

 

Superset

대화형 대시보드를 작성하기 위한 파이썬으로 만든 대시보드 생성도구이다. 쿼리가 아닌 마우스 조작으로 그래프를 만들 수 있다. 내장 스토리지 시스템을 갖지 않아 데이터 집계는 외부 데이터저장소에 의존한다. 시계열 데이터에 대응한 열 지향 스토리지 'Druid'를 표준으로 지원하며 스트리밍 형의 데이터 전송과 조합시킴으로써 실시간 정보를 취급할 수 있다. 특히, Druid는 집계 시에 테이블을 결합할 수 없기 때문에 시각화에 필요한 데이터는 미리 모두 결합해야 한다.

 

Kibana

Elastic Stack의 일부로, Elasticsearch에서 저장된 데이터를 시각화하고 탐색하는데 사용된다. 자바스크립트로 만들어진 대화식 시각화 도구로, 특히 실시간 (데이터 모니터링)대시보드를 만들 목적으로 자주 이용된다. Elasticsearch 이외의 데이터 소스에는 대응하고 있지 않아 시각화하려는 데이터는 모두 Elasticsearch에 저장해야 한다.

 

데이터 마트의 기본 구조

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

BI 도구에 핵심적인 개념 중 하나로 OLAP(Online Analytical processing)라는 구조가 있다.

데이터를 다차원적으로 분석하고 쿼리하는데 사용되며, 복잡한 데이터 분석, 트랜드 파악, 데이터 집계 및 요약 작업을 지원하기 위해 설계된 시스템이다.

 

다차원 모델과 OLAP 큐브

표 형식으로 모델링된 데이터를 SQL로 집계하는 RDB와 달리, OLAP에서는 '다차원 모델'의 데이터 구조를 MDX(Multidimensional experssions)' 등의 쿼리 언어로 집계한다. 데이터 분석을 위해 만들어진 다차원 데이터를 OLAP 큐브라고 부르며, 그것을 크로스 집계하는 구조가 OLAP다.

예를 들어, 시간, 지역, 제품 등 다양한 차원으로 데이터를 구분하고 사용자는 이러한 차원을 기반으로 데이터를 분석하고 요약할 수 있다.

 

MPP 데이터베이스와 비정규화 테이블

BI 도구와 MPP 데이터베이스를 조합해 크로스 집계하는 경우가 증가하고 있다. 만들고 싶은 그래프에 맞춰 '다차원 모델'을 설계한다. 하지만, MPP 데이터베이스에 다차원 모델의 개념은 없기 때문에 이를 대신해 '비정규화 테이블'을 준비한 후 BI 도구에서 열어서 기존의 OLAP와 동등한 시각화를 실현할 수 있다.

즉, '시각화에 적합한 데이터 마트를 만드는 것'은 'BI 도구를 위한 비정규화 테이블을 만드는' 프로세스다.

 

테이블을 비정규화하기

데이터베이스 설계에서 종종 테이블을 '마스터'와 '트랜잭션'으로 구분한다.

- 트랜잭션(Transaction) 테이블: 시간과 함께 생성되는 데이터를 기록한 것(한 번 기록하면 변화 x)

- 마스터(Master) 테이블: 트랜잭션에 참고되는 각종 정보(상황에 따라 다시 쓰임)

 

팩트 테이블과 디맨전 테이블

데이터 웨어하우스에서 사용되는 두 가지 유형의 테이블

- 팩트 테이블(Fact Table):  트랜잭션처럼 사실이 기록된 것(ex. 시간, 위치, 제품, 고객 등의 정보)

- 디멘전 테이블(Dimension Table): 팩트 테이블에서 참고되는 마스터 데이터(ex. 제품 이름, 지역 이름)

 

스타 스키마와 비정규화

데이터 마트의 스키마

1. 정규화된 모델

- 왼쪽에 있는 “정규화된 모델”은 일반적인 트랜잭션 데이터베이스에서 볼 수 있는 구조이다. 여러 테이블로 구성되며, 각 테이블은 고유한 데이터를 저장하고 테이블 간의 관계는 외래키(Foreign Key)로 정의된다.

• 예를 들어, 주문, 제품, 고객 등 각각의 엔터티가 별도의 테이블로 구분되어 있고, 이들 사이의 관계는 키를 통해 연결된다.

 

2. 스타 스키마

- “스타 스키마”는 데이터 웨어하우스에서 사용되는 일반적인 데이터 모델링 기법이다. 중앙의 큰 테이블이 팩트 테이블(f1)이며, 주변의 작은 테이블들이 디멘전 테이블(d1, d2, d3)이다.

- 팩트 테이블은 측정 가능한 값과 이벤트(예: 판매량, 수익 등)를 포함하고, 각 디멘전 테이블은 팩트 데이터를 설명하는 차원(예: 시간, 지역, 제품 등)의 데이터를 포함한다.

- 스타 스키마는 질의 성능을 최적화하기 위해 비정규화된 형태로 설계되며, 쿼리가 단순하고 빠르게 처리되는 장점이 있다.

 

3. 비정규화된 모델

- “비정규화된 모델”은 스타 스키마의 팩트 테이블이 더 단순화된 형태이다. 모든 데이터가 하나의 큰 테이블에 통합되어 있어서, 디멘전 테이블 없이 팩트 데이터만으로 구성될 수도 있다.

- 비정규화는 데이터 중복을 증가시키지만, 단순하기 때문에 이해하기 쉽고, 데이터 분석을 쉽게할 수 있다는 장점이 있다.

 

비정규화 테이블

열 지향 스토리지는 데이터를 열 단위로 저장하고, 각 열의 유사 데이터를 묶어 압축한다. 데이터가 효과적으로 압축됨에 따라 데이터를 읽을 때 디스크 I/O 작업이 줄어들게 된다. 따라서, 열 지향 스토리지는 아무리 컬럼의 수가 늘어나도 성능에 영향을 주지 않는다.

열 지향 스토리지의 이러한 압축 및 I/O 효율성 덕분에 데이터 웨어하우스 설계에서 디멘전 테이블을 별도로 유지할 필요성이 줄어든다. 전통적인 스타 스키마에서는 팩트 테이블과 여러 디멘전 테이블이 분리되어 있어, 쿼리 시 여러 테이블 간의 조인이 필요했지만 열 지향 스토리지를 사용할 경우, 팩트 테이블 하나만으로도 충분한 정보를 효과적으로 저장하고 조회할 수 있어, 복잡한 조인 작업을 피해 데이터 관리가 단순해진다.

 

즉, 다음과 같이 정리할 수 있다.

데이터 웨어하우스 설계 - 스타 스키마(팩트 테이블과 디멘전 테이블을 사용해 데이터 축적)

데이터 마트 생성 - 비정규화 테이블 생성(분석하는 단계에 데이터 웨어하우스의 테이블을 결합해 생성)

 

 

챕터 1(빅데이터의 기초 지식)에 이어, 챕터 2는 빅데이터를 탐색하기 위한 기초 지식으로서의 시각화 및 이를 위한 초 단위로의 집계 방법(열 지향 스토리지, MPP 데이터베이스) 등을 살펴볼 수 있었다. 특히 열 지향 스토리지 방식은 매우 중요한 개념으로 실제로, 데이터 엔지니어 과제에서도 등장한 적이 있었다.

이외에는 '팩트 테이블', '디멘전 테이블', '비정규화 테이블', '트랜잭션 테이블', '마스터 테이블' 등 개념적인 용어가 많이 등장하니 반복해서 살펴볼 필요가 있는 챕터라고 생각한다.