빅데이터의 분산 처리

데이터

구조화 데이터

테이블의 칼럼과 데이터형, 데이블들 간의 관계 등을 스키마라고 하는데,

스키마가 명확하게 정의된 데이터를 구조화 데이터라고 합니다.

 

비구조화 데이터

자연 언어로 작성된 텍스트 데이터, 이미지, 동영상 등의 미디어 데이터 처럼 스키마가 없는 데이터를 비구조화 데이터라고 합니다.

 

스키마리스 데이터

CSV, JSON, XML 등의 데이터처럼 서식은 정해져있지만, 칼럼 수나 데이터형은 명확하지 않은 데이터를 스키마리스 데이터라고 합니다.

 

데이터 구조화 파이프라인

SQL로 테이블을 집계하기 위해서는 비구조화 데이터와 스키마리스 데이터를 구조화 데이터로 변환시킬 필요가 있습니다.

데이터 구조화 파이프라인 예시

 

 

하둡(Hadoop)

현재는 빅데이터를 대표하는 분산 처리 프레임워크입니다.

분산 시스템을 구성하는 다수의 소프트웨어로 이루어져 있습니다.

하둡에서 사용할 수 있는 열 지향 스토리지에는 몇가지 종류가 있습니다.

그 중 Apache ORC는 구조화 데이터를 위한 스토리지로 스키마를 정한 후 데이터를 저장합니다.

Apache Parquet은 스키마리스에 가까운 데이터 구조로 되어있어서 JSON과 같은 데이터를 그대로 저장할 수 있습니다.

 

분산 시스템의 구성 요소

하둡의 기본 구성 요소는 분산 파일 시스템인 HDFS, 리소스 관리자인 YARN, 분산 데이터 처리의 기반인 MapReduce 이렇게 3가지입니다.

그 외의 프로젝트는 하둡 본체와는 독립적으로 개발되어 하둡을 이용한 분산 애플리케이션으로 동작합니다.

모든 분산 시스템이 하둡에 의존하는 것이 아니라 하둡의 일부만 사용하거나 혹은 전혀 이용하지 않는 구성도 있습니다.

예를 들어 분산 파일 시스템은 HDFS, 리소스 관리자는 Mesos, 분산 데이터 처리는 Spark를 사용하는 것입니다.

즉, 다양한 소프트웨어들 중에서 자신에게 맞는 것을 선택하고 조합하여 사용하면 됩니다.

하둡 분산 시스템 예시

 

분산 파일 시스템과 리소스 관리자

하둡에서 처리되는 데이터 대부분은 분산 파일 시스템인 HDFS에 저장됩니다.

다수의 컴퓨터에 파일을 복사하여 중복성을 높인다는 특징이 있습니다.

 

CPU나 메모리 등의 계산 리소스는 리소스 관리자인 YARN에 의해 관리됩니다.

YARN은 애플리케이션이 사용하는 CPU 코어와 메모리를 컨테이너 단위로 관리합니다.

하둡에서 분산 애플리케이션을 실행하면 YARN이 클러스터 전체의 부하를 보고 비어 있는 호스트부터 컨테이너를 할당합니다.

 

리소스 관리자는 어느 애플리케이션에 얼마만큼의 리소스를 할당 할 것인지를 관리하여 모든 애플리케이션이 차질없이 실행되도록 제어합니다.

그리고 애플리케이션마다 실행 우선순위를 결정할 수 있습니다.

즉, 덜 중요한 애플리케이션에 낮은 우선순위를 부여해서 아무도 리소스를 사용하지 않을 경우에만 실행하는 등, 높은 우선순위부터 실행함으로써 한정된 리소스를 낭비없이 활용하면서 데이터 처리를 진행할 수 있습니다.

 

분산 데이터 처리 및 쿼리 엔진

MapReduce는 YARN 상에서 동작하는 애플리케이션 중 하나이며, 분산 시스템으로 데이터 처리를 실행하는데 사용합니다.

비구조화 데이터를 가공하는데 적합하고 한번 실행으로 대량의 데이터를 읽을 수 있습니다.

하지만 작은 프로그램을 실행하면 오버헤드가 너무 크기 때문에 몇 초 안에 끝나는 쿼리 실행에는 적합하지 않습니다.

 

SQL 등의 쿼리 언어에 의한 데이터 집계가 목적인 쿼리 엔진 중 Apache Hive가 있습니다.

Apache Hive는 MapReduce의 성질을 계승하였기 때문에 시간이 걸리는 배치 처리에는 적합하나 애드 혹 쿼리를 여러번 실행하는데는 적합하지 않습니다.

 

Hive on Tez

Hive를 가속화하기 위해 개발된 것이 Apache Tez입니다.

Tez는 기존의 MapReduce를 대체할 목적으로 개발된 프로젝트이며, MapReduce에 있던 몇가지 단점을 해소함으로써 고속화를 실현했습니다.

 

현재의 Hive는 MapReduce뿐만 아니라 Tez에도 동작하도록 되어있습니다.

이것을 Hive on Tez라고 불리고 예전 Hive는 Hive on MR이라 불립니다.

 

대화형 쿼리 엔진

Hive를 고속화하는 것이 아닌, 처음부터 대화형의 쿼리 실행만을 전문으로 하는 쿼리 엔진 중 Apache Impala와 Presto가 있습니다.

대화형 쿼리 엔진은 순간 최대 속도를 높이기 위해 모든 오버헤드가 제거되어 사용할 수 있는 리소스를 최대한 활용하여 쿼리를 실행합니다.

그 결과 MPP 데이터베이스와 비교해도 꿀리지 않는 응답속도를 가졌습니다.

 

대량의 비구조화 데이터를 가공하는 무거운 배치 처리에는 높은 처리량을 가진 Hive를 이용하고, 그렇게 해서 만들어진 구조화 데이터를 대화식으로 집계하고자 할 때 지연이 적은 Impala와 Presto를 이용합니다.

 

하둡에서는 다수의 쿼리 엔진이 개발되어 있으며, 그것들을 총칭해 SQL-on-Hadoop이라 불립니다.

 

 

Spark

Apache Spark는 하둡과는 다른 독립된 프로젝트입니다.

컴퓨터에서 취급하는 메모리의 양이 증가함에 따라 대량의 메모리를 활용하여 고속화를 실현한 것이 Spark의 특징입니다.

이 경우 컴퓨터가 비정상 종료되면 중간 데이터들이 사라져 버리지만, 처리를 다시 시작해서 중간 데이터를 다시 만들면 됩니다.

 

Spark는 하둡을 대체하는 것이 아니라 MapReduce를 대체하는 존재입니다.

즉, 분산 파일 시스템 HDFS, 리소스 관리자 YARN, 분산 데이터 처리 Spark로 쓸 수 있습니다.

 

Spark 상에서 실행되는 데이터 처리는 스크립트 언어를 사용할 수 있습니다.

표준으로 자바, 스칼라, 파이썬 그리고 R언어가 있습니다.

 

Spark에서는 SQL로 쿼리를 실행하기 위한 Spark SQL과 스트림 처리를 수행하기 위한 Spark Streaming 기능이 있습니다.

그래서 대규모 배치 처리뿐만 아니라 대화형 쿼리 실행과 실시간 스트림 처리에도 이용되고 있습니다.

 

 

비정규화 테이블 만들기

데이터의 구조화가 끝나면 다음은 데이터 마트의 구축을 합니다.

즉, 테이블을 결합 및 집약해서 비정규화 테이블을 만듭니다.

이때 Hive와 같은 배치형 쿼리 엔진을 사용할 것인지 Presto와 같은 대화형 쿼리 엔진을 사용할 것인지 선택할 수 있습니다.

 

Hive

시간이 걸리는 배치 처리는 원칙적으로 Hive를 사용합니다.

비정규화 테이블을 만드는데 오랜 시간이 걸리는 것은 흔한 일이며, 그렇기에 효율적인 쿼리를 작성해야 합니다.

Hive의 쿼리를 개선하는 예로 서브 쿼리 안에서 레코드 수 줄이기와 데이터 편향 피하기가 있습니다

 

서브 쿼리 안에서 레코드 수 줄이기

예시로 모든 데이터를 읽어 들인 후 결합된 테이블을  WHERE 문으로 검색한다고 해봅시다.

테이블을 결합 한 후 WHERE문으로 검색하기 보다는 먼저 WHERE문을 적용하고 테이블을 결합하는 것이 서브 쿼리 안에서 팩트 테이블을 작게 하기 때문에 좀 더 효율적입니다.

즉, 초기에 팩트 테이블을 작게 하여 데이터 양을 줄이는 것입니다.

 

데이터 편향 피하기

예시로 30일의 기간동안 하루마다의 고유 방문자 수를 알아낸다고 합시다.

그렇다면 보통 날짜별로 GROUP BY를 하고 distinct count로 방문자를 중복제거하여 고유 방문자 수를 구할 것입니다.

이때 날짜별로 GROUP BY를 했기 때문에 하나의 노드에서 하루의 방문자들을 distinct로 중복제거를 할 것입니다.

30일 동안 고유 방문자가 모두 균등하게 방문하였다면 노드에 distinct로 처리해야할 데이터 양이 균등하게 분산이 되어 데이터 편향은 없겠지만, 어느 특정 기간에만 고유 방문자가 많이 방문하였다면 일부 노드에 distinct로 처리해야할 데이터 양이 많아져 데이터편향이 생길 것입니다.

그러면 처음에 distinct로 (날짜, 방문자)를 중복제거하고 날짜별로 GROUP BY하고 방문자 수를 세주는 것이 데이터 편향을 줄임으로써 좀 더 효율적입니다.

즉, 최초에 중복을 제거하여 균등하게 분산 처리를 하는 것입니다.

 

 

Presto

작은 쿼리를 여러번 실행하는 대화형 데이터 처리, 쿼리 실행의 지연을 감소시키는 것에 적합한 것이 대화형 쿼리 엔진입니다.

Presto는 그 중 하나입니다.

 

Presto는 다양한 데이터 소스를 테이블로 참고할 수 있는 플러그인 가능한 스토리지입니다.

예를 들어, 하나의 쿼리 안에서 분산 스토리지 상의 팩트 테이블과 MySQL의 마스터 테이블을 조인할 수 있습니다.

 

메모리 상에서 할 수 있는 단시간 쿼리 실행에 효율적입니다.

열지향 스토리지에서 집계를 매우 빠르게 실행합니다.

 

 

데이터 마트  구축

팩트 테이블의 작성에는 추가와 치환 두가지 방법이 있습니다.

추가는 새로 도착한 데이터만을 증분으로 추가하는 것이고, 치환은 과거의 데이터를 포함하여 테이블 전체를 치환하는 것입니다.

 

추가

효율만을 생각하면 추가가 압도적으로 좋으나 잠재적인 문제가 있습니다.

첫째, 추가에 실패한 것을 알아채지 못하면 팩트 테이블의 일부에 결손이 발생합니다.

둘째, 추가를 잘못해서 여러번 실행하면 팩트 테이블의 일부가 중복됩니다.

셋째, 나중에 팩트 테이블을 다시 만들고 싶은 경우의 관리가 복잡해집니다.

이러한 문제가 일어날 가능성을 줄이기 위해 테이블 파티셔닝이라는 기술을 사용합니다.

 

테이블 파티셔닝

테이블 파티셔닝은 하나의 테이블을 여러 물리적인 파티션으로 나눔으로써 파티션 단위로 정리하여 테이터를 쓰거나 삭제할 수 있도록 한 것입니다.

일반적으로 1일 1회, 또는 1시간에 1회라는 식으로 자주 새 파티션을 만들고 그것을 팩트 테이블에 붙입니다.

각 파티션은 매번 교체하도록 하고 만약 이미 존재한다면 덮어씁니다.

이렇게 하면 데이터가 중복될 가능성을 배제하면서 필요에 따라 여러번 데이터의 기록을 바로 잡을 수 있습니다.

테이블 파티셔닝 예시

 

치환

데이터 파티셔닝은 데이터 웨어하우스를 구축하는데 유용합니다.

데이터 마트를 만드는 경우에는 단순히 팩트 테이블을 치환하는 경우가 많을 수도 있습니다.

왜냐하면 상당히 거대한 테이블을 만들지 않는 한 매번 치환하기는 어렵지않기 때문입니다.

예를 들어, 일일 보고서를 위해 지난 30일 동안의 데이터를 매일 꺼내서 치환하는 식입니다.

테이블 파티셔닝과 치환 예시

치환은 처리 시간이 우려되는 방법이지만 많은 장점이 있습니다.

첫째, 중간에 데이터가 중복되거나 빠드릴 가능성이 없습니다.

둘째, 테이블을 처음부터 다시 만들고 싶다면 쿼리를 한번 실행하기만 하면 됩니다.

셋째, 스키마 변경 등에도 유연하게 대응할 수 있습니다.

넷째, 오래된 데이터는 자동으로 지워지기 때문에 데이터 마트가 계속 확대되는 일은 없습니다.

 

만약 데이터 양이 너무 많아 처리 시간이 너무 오래 걸린다면 데이터 마트 측에도 테이블 파티셔닝을 하거나 기존의 테이블에 추가한 다음 주의 깊게 모니터링을 해야할 것입니다.

 

집계 테이블

팩트 테이블을 어느 정도 모아서 집계하면 데이터의 양이 크게 줄어드는데 이것을 집계 테이블이라고 합니다.

특히 1일 단위로 집계한 일일 집계는 일일 보고서를 만드는데 자주 사용됩니다.

 

집계 테이블을 만들기 위해서는 필요한 칼럼을 골라 숫자 데이터를 집계하면 됩니다.

이때, 각 칼럼이 취하는 값의 범위를 카디널리티라고 합니다.

카디널리티를 너무 적으면 원래 있던 정보가 크게 손실되고 너무 많으면 시각화의 효율을 낮춥니다.

그렇기에 균형에 맞춰서 카디널리티를 정해야합니다.

 

스냅샷 테이블

마스터 데이터처럼 업데이트될 가능성이 있는 테이블에 대한 방안 중 하나로 정기적으로 테이블을 통째로 저장하는 것을 스냅샷 테이블이라고 합니다.

스냅샷의 날짜를 지정하여 과거의 마스터 테이블을 언제든지 볼 수 있고, 팩트 테이블과 스냅샷 테이블을 날짜를 포함해서 결합할 수 있습니다.

이것은 매일 변화하는 마스터 정보를 이용하여 데이터를 분석하고 싶을 때 유용합니다.

 

스냅샷은 특정 시점의 테이블의 상태를 기록한 것이므로 나중에 다시 만들 수 없습니다.

그렇기에 데이터 레이크나 데이터 웨어하우스와 같은 영구적인 저장소에 보관하여 삭제되지 않도록 합니다.

 

이력 테이블

마스터 데이터처럼 업데이트될 가능성이 있는 테이블에 대한 방안 중 하나로 변경된 데이터만 저장하는 것을 이력 테이블이라고 합니다.

이력 테이블은 데이터의 양을 줄이는데 도움이 되지만, 어느 순간의 완전한 마스터 테이블을 나중에 복원하는 것이 어려워지므로, 디멘전 테이블로는 사용하기 힘듭니다.

 

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

마지막에 팩트 테이블과 디멘전 테이블을 결합하여 비정규화 테이블을 만듭니다.

디멘전 테이블로는 스냅샷 뿐만 아니라 목적에 따라 각종 중간 테이블이 만들어집니다.

 

데이터를 집계하는 전형적인 쿼리는 다음과 같습니다.

먼저 팩트 테이블에서 필요한 데이터를 꺼냅니다.

이때, 시간에 의한 검색이나 참고하는 칼럼 수를 줄이면 데이터 로드 속도는 빨라집니다.

다음으로 디멘전 테이블과 결합하여 데이터 마트에 저장할 칼럼을 선택합니다.

이때, 카디널리티를 가급적 작게하는 것이 좋습니다.

마지막으로 그룹화하여 측정값을 집계합니다.

 

그 결과, 충분히 작은 비정규화 테이블이 만들어지고 이후에는 데이터 마트로 보내면됩니다.