[빅데이터를 지탱하는 기술] CH 03. 빅데이터의 분산처리

CH 03. 빅데이터의 분산처리

3-1. 대규모 분산 처리의 프레임 워크

구조화 데이터와 비구조화 데이터

스키마(테이블의 칼럼명, 데이터형, 테이블간의 관계등을 의미)가 명확하게 정의된 데이터를 구조화된 데이터라고 하며 기존의 데이터웨어하우스에서는 항상 구조화된 데이터로 축적하는 것이 일반적이었다.

빅데이터 시대의 핵심은 기존처럼 정형화된 데이터만이 아니라, 이미지 동영상 같이 비정형화된 데이터가 증가하고 이 또한 분석이 필요해졌다는 사실이다. 이러한 비정형화된 데이터는 SQL로 제대로 집계할 수 없다. 

** CSV,JSON같은 데이터는 서식은 있지만 칼럼수나 데이터형이 명확하지 않은 스키마리스 데이터라고 한다. 

NoSQL 데이터 베이스가 이러한 스키마리스 데이터에 대응하고 있다. 

이러한 다양한 형태의 데이터를 우선 데이터 레이크에 저장한 후, 분석하기 용이하게 분산스토리지에 옮기는 파이프라인이 필요하다.

데이터 레이크에서 데이터를 가공하는 과정에서 비정형 데이터의 스키마를 정의하고 구조화된 데이터로 변환함으로써 다른 데이터와 마찬가지로 분석할 수 있게 되는 것이다. 

이때 MPP데이터 베이스 즉, 데이터 웨어하우스 같이 이미 하드웨어가 구축된 스토리지 서비스를 쓸 수도 있고, Hadoop 내에서 열지향스토리지 형식을 지정하여 그 곳에 데이터를 저장할 수도 있다. 여러 형태의 데이터들을 구조화된 데이터로 변경하여 SQL로 집계할 수 있는 것에 집중하고, 특별히 테이블간의 조인은 하지 않는다.(이러한 조인은 데이터 마트를 만들 때 고려한다.)

하둡에서 사용할 수 있는 열지향 스토리지에는 대표적으로 두개가 있다.

Apache ORC는 구조화 데이터를 위한 열지향 스토리지로 처음에 스키마를 정한 후 데이터를 저장한다.

Apache Parquet는 스키마리스에 가까운 데이터 구조로 되어잇어 json같은 데이터도 그대로 저장할 수 있다. 

이 때 비 구조화 데이터도 열지향 스토리지로 변환하는 과정을 거쳐야 하는데, 사용되는 것이 Hadoop과 Spark 다.

 

Hadoop

- 분산 데이터 처리의 공통 플랫폼

 

Hadoop은 현재 빅데이터를 대표하는 시스템으로 알려져있다. 단일 소프트웨어가 아니라 분산 시스템을 구성하는 다수의 소프트웨어로 이루어진 집합체다. 기본 구성요소는 분산파일 시스템인 HDFS, 리소스 관리자인 YARN, 분산 데이터 처리인 MapReduce가 있다. 여기에 쿼리엔진으로 Hive, Impala가 있고, 더 발전하여 (하둡과는 독립적인 ) 쿼리엔진과 분산데이터 처리가 동시에 가능한 Apache Spark, Flink가 존재한다. 

모든 분산시스템이 Hadoop(이하 하둡)의 모든 시스템을 사용하는 것이 아니라, 상황에 따라 선별적으로 사용한다. 

하둡에서 처리되는 데이터 대부분은 분산파일시스템에 저장된다. 이는 파일서버와 같은 존재이다. 이 때 CPU, 메모리 등의 계산 리소스는 리소스 매니저에서 관리한다. 리소스 관리자인 YARN을 통해 어플리케이션 실행의 우선순위를 결정할 수 있다. 

분산데이터를 처리하는 대표적인 것으로 맵리듀스가 있다. 그리고 쿼리언어에 의한 데이터 집계가 목적이라면 그것을 위한 쿼리엔진인 Hive을 사용한다. 기본적으로 하둡 시스템 내의 맵리듀스나 하이브는 대량 배치처리에 적합하지, 빠르지만 가벼운 데이터 집계에는 적절하지 않다. 이를 위한 보안으로 Tez가 등장했다. Tez는 hive를 가속화하기 위해 등장, 맵리듀스의 단점을 보완하여 고속화 실현했다.

가령 맵리듀스에서는 스테이지가 끝날 때까지 다음 처리를 진행할 수 없었지만, tez에서는 스테이지의 종료를 기다리지 않고 처리가 끝난 데이터를 차례대로 후속처리에 전달함으로써 쿼리 전체의 실행시간을 단축한다. Hive는 Tez에서도 동작하므로 Hive on Tez라고도 불린다. 대화형 쿼리엔진인 Impala, Presto도 등장했다. 맵리듀스와 Tez는 장시간의 배치처리를 가정해 한정된 리소스를 유요하게 활용한다.

그러나 대화형 쿼리엔진으로는 순간 최대 속도를 높여 쿼리를 실행할 수 있는 것이다. 

 

Spark

- 인메모리 형의 고속 데이터 처리

 

스파크는 맵리듀스를 대체하여 맵리듀스보다 더 효율적인 데이터 처리를 실현하는 것으로 등장했다. 스파크의 특징은 대량의 메모리를 활용하여 고속화를 실현하는 것이다.  실행 중에 많은 메모리가 필요하지만 실행시간이 단축된다. 

스파크는 하둡을 대체한 것이 아니라 데이터 처리인 맵리듀스를 대체한 것이다. 

스파크의 특징은 실행에 자바 런타임이 필요하지만, 실행되는 데이터 처리는 스크립트 언어를 사용할 수 있다. 

이번 챕터에는 데이터 처리 방식에 대한 이야기가 많이 나온다. 
데이터 처리에는 아래와 같이 크게 세가지 방식이 있다,(참고 블로그)
1. 배치처리
2. 실시간 처리
3. 대화형 처리(스칼라나 파이썬 같은 언어들)

 

3-2. 쿼리 엔진

hadoop에 의하여 비구조화 데이터나 스키마리스 데이터들을 구조화 데이터로 변형하여 비정규화 테이블에 저장하는 파이프라인에는 대표적으로 hive와 presto가 사용된다. (정리된 참고 블로그) 

맵리듀스는 말그대로 HDFS에 저장된 데이터를 집계하거나 처리하기 위함이고, 저장된 데이터를 구조화하기 위해서는 쿼리엔진을 활용한다고 이해했다. 

 

데이터마트 구축의 파이프라인

 

처음 분산스토리지에 저장된 데이터르 ㄹ구조화하고 열 지향 스토리지 형식으로 저장하는 것은 다수의 텍스트 파일을 읽어 가공하므로 hive를 사용한다. 그리고 완성된 구조화 데이터를 결합하고 집계하여 비정규화 테이블로 만드는 과정은 presto를 활용하여 시간을 단축한다. 

 

Hive에 의한 구조화 데이터 작성

 

hive로 구조화 데이터를 작성할 때는 외부 테이블을 지정하여 참고한 특정 파일에 테이블이 존재하는 것 처럼 읽어들인다. 이런 식으로 데이터 베이스처럼 데이터를 내부로 가지고 오지 않아도 텍스트 파일을 그대로 집계할 수 있다. 즉 데이터를 그 자리에서 바로 집계할 수 있는 것이다. 그러나 이는 비효율적이다. 쿼리를 실행할 때 마다 텍스트를 읽어들여야 하기 때문에 매우 느리다.

따라서 hive로 열지향 스토리지형식을 만들고, 외부 테이블에서 읽은 데이터를 모두 저장한다. 이를 통해 변환에서의 시간은 소요될지 몰라도 이후 집계 과정에서의 시간을 절약할 수 있다.

이후 비정규화 테이블을 만들 때 presto같은 대화형 쿼리 엔진을 사용할 것인지, hive같은 배치형 쿼리엔진을 사용할 것인지에 따라 활용방법이 달라진다. 

기본적으로 위에서도 언급했지만, 데이터의 양이 많아서 시간이 걸리는 작업은 하이브로 한다. 

만약 hive를 사용한다면 효율적인 쿼리를 작성해야 하며 이를 위한 방법으로는 두가지가 있다.

 

1. 서브쿼리안에서 레코드 수 줄이기(팩트테이블 작게하기)

hive는 기본적으로 SQL과 유사하나, 일반적인 특성에서 차이가 난다. 데이터 처리를 위한 배치처리 구조이므로, 읽어들이는 데이터 양을 의식하면서 쿼리를 작성해야 한다.( 가령 join을 할 때, 테이블들에 where조건을 걸지 않고 join하면 중간 데이터가 불필요하게 생성된다.)

즉 두 테이블을 결합할 때 결합되는 중간 테이블 자체에도 필터링을 걸어주어야 중간 데이터가 최대한 줄어든다. 

 

2. 데이터 편향 피하기(분산 시스템의 성능 발휘를 위해)

 

대화형 쿼리엔진 Presto의 구조

- Presto로 구조화 데이터 집계하기

 

hive가 대량출력을 수반하는 대규모 데이터 처리에 적합하다면, 작은 쿼리를 여러번 실행하는 대화형 데이터 처리에는 presto가 적합하다.

presto는 플러그인 가능한 스토리지 설계가 가능하다. 즉 하나의 쿼리안에서 여러 데이터 소스에 연결가능하다.

presto는 보통 hive 메타스토어에 등록된 테이블을 가져올 수 있으므로 hive에서 만든 구조화 데이터를 좀 더 집계하는 목적에 적합하다. 물론 다른 데이터 소스도 참고할 수 있지만, hive보다 성능이 훨씬 떨어지므로 presto를 효율적으로 활용하려면 참고하는 데이터 스토리지가 열지향 데이터구조로 되어있어야한다. 

presto는 읽기와 코드 실행을 병렬 처리한다. 디스크에 쓰기작업을 하지 않고 메모리만을 사용한다. 

또한 presto는 기본적으로 분산결합을 실시하여 같은 키를 같는 데이터는 동일한 노드에 모인다. 

 

데이터 분석의 프레임워크 선택하기

- MPP데이터 베이스, Hive, Presto, Spark

 

실제로 현재 처리해야하는 데이터 양이나 상황에 따라서 클라우드 서비스로 시작할 수도 있고 서버를 설치해서 엔진을 가동할 수도 있다. 즉 상황에 따라서 적절한 프레임워크를 선택해야 한다.

1. MPP데이터베이스 : 완성한 비정규화 테이블의 고속 집계에 적합. 즉 SQL로 집계화/ 조회 하는 업무가 대부분일 때 적절하다, 

그러나 확장성 및 유연성에는 분산 시스템이 유리하다. 대량의 텍스트 처리나 데이터 처리를 프로그래밍하거나, NoSQL 데이터베이스에 저장된 데이터를 집계하고 싶은 경우가 이런 경우이다. 

따라서 이미 구조화가 완료된 데이터를 처리하여 비정규화 테이블로 만들어 데이터마트로 활용하려 할때 MPP데이터 베이스는 최적이다.

2. Hive : 데이터 양에 좌우되지 않는 쿼리 엔진이다. 안전성이 장점이다. 즉 대규모 배치 처리를 안정적으로 할 때 최적이다. 

최근 인메모리 방식을 많이 활용하지만, 많은 양의 데이터를 안정적으로 다룰 때는 디스크 사용은 어느정도 필요하므로 이 때 Hive를 고려할 만하다.  

3. Presto : 속도 중시 & 대화형 쿼리엔진, 모든 데이터를 SQL로 집계하기 위한 중심적인 존재. 그러나 대화식 쿼리의 실행에 특화되어 있으므로 텍스트 처리 중심의 프로세스와 데이터 구조화에는 적합하지 않다. 즉 ETL 데이터 처리 프로세스는 Hive나 Spark가 적절하다.

4. Spark : 분산시스템을 사용한 프로그래밍 환경. ETL프로세스부터  SQL에 이르기까지의 일련의 흐름을 하나의 데이터 파이프라인으로 기술할 수 있다는 장점. spark에서는 메모리를 어떻게 관리하느냐가 핵심이다. 

 

3-3. 데이터 마트의 구축

팩트 테이블

- 시계열 데이터 축적하기

 

이후 분석을 위한 데이터 마트 구축이 진행된다. 데이터 마트 구축에는 데이터를 구조화 하는 것이 핵심이다. 이에 대해 팩트 테이블이 가장 중요하다. 팩트테이블 구성에는 추가와 증분 두가지 방식이 있다. 

추가가 효율적이긴 하나, 오류가 발생할 경우, 일부 데이터 중복이 발생할 수있다. 이를 위해 테이블 파티셔닝을 진행한다. 

보통 시점을 기준으로 파티션을 나누어서 데이터 웨어하우스에 축적해두고 배치 처리를 통해서 중복된 데이터는 치환하고 필요한 데이터만 추출하여 데이터 마트로 보낸다. 

데이터 치환 시에는 일부만 치환할 것인지, 전체를 치환할 것인지를 정해야 한다. 보통 전체 치환이 스키마변경에도 대응하기 좋고, 데이터 마트에 중복 데이터가 발생할 가능성도 없지만, 처리 시간이 느려진다. 

보통은 팩트테이블을 만드는데 1시간이내가 걸리면 전체 치환의 방식을 택한다. 

 

집계테이블

- 레코드 수 줄이기

 

팩트 테이블을 어느정도 모아서 미리 집계한 것이 집계 테이블이다. 이를 위해서는 필요한 칼럼을 골라서 그에 따라 숫자 데이터를 집계하기만 하면 된다. 이때 칼럼이 취하는 범위인 카디널리티를 작게해야한다. 그래야 레코드 수를 최소화 할 수 있기 때문이다. 

하지만 너무 줄이면 데이터 손실이 발생할 수 있다.

저장된 데이터를 효율적으로 추출하기 위해서는 쿼리 작성 당시에, 최대한 중간 데이터를 줄여야 한다. 즉 무작정 전부 join하지 말고, 필요한 칼럼만 불러와서 최소한의 데이터들끼리만 join해야한다. 

집계 테이블 작성 시에, 처음에 불필요한 디멘전을 제거함으로써 데이터 마트가 작아지고 시각화 기능이 향상된다. 
단 평균이나, count는 기준에 따라 다른 수가 나오므로 집계 시에 주의해야 한다. 
-> 평균의 평균과 전체 평균은 값이 다르다. 

 

스냅샷 테이블

- 마스터의 상태를 기록하기

 

마스터 데이터가 있는 테이블을 통째로 저장하는 방법이 스냅샷 테이블이다. 변경내용만을 저장하는 방법으로는 이력테이블이 있다. 

이러한 이력은 보통 디멘젼 테이블의 이력을 기록하는 것이다. 

스냅샷 테이블은 특정 시점의 테이블의 상태를 기록한 것이므로 영구적인 저장소에 잘 보관해야 한다. 

또한 스냅샷 테이블은 다른 테이블과도 결합하여 데이터를 분석할 수 있다. 이 때에 스냅샷 테이블을 하나의 비정규화 테이블로 만들어서 스냅샷 해두는 것이 좋다.

 

이력 테이블

- 마스터 변화 기록하기

 

작업 시의 데이터 양을 줄이기엔 좋지만 완전한 마스터 테이블을 나중에 복원하는 것이 어려워지므로 디멘젼 테이블로는 사용하기 힘들다. 

 

디멘젼을 추가하여 비정규화 테이블 완성하기

 

팩트 테이블과 디멘전테이블을 결합하여 비정규화 테이블을 만들고 이러한 테이블이 데이터 마트로서 최종적으로 시각화에 활용된다. 

이때 카디널리티를 최대한 작게 하고 시각회에 필요없는 칼럼은 삭제한다.