챕터3. 빅데이터의 분산처리

챕터3 :빅데이터의 분산처리

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

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

• 스키마가 명확하게 정의된 데이터를 ‘구조화된 데이터’
• 스키마가 없는 데이터는 ‘비구조화 데이터’
• 비구조화 데이터를 분산 스토리지 등에 저장하고 그것을 분산 시스템에서 처리하는 것이 데이터 레이크의 개념

스키마리스 데이터

CSV,JSON,XML 등의 데이터는 서식은 정해져 있지만, 칼럼 수나 데이터형은 명확하지 않아 ‘스키마리스 데이터’라고 부른다.

 

데이터 구조화의 파이프라인

• 일반적으로 구조화 데이터는 데이터의 압축률을 높이기 위해 열 지향 스토리지로 저장한다.
• 구조화 데이터 중 시간에 따라 증가하는 데이터를 팩트 테이블, 그에 따른 부속 데이터를 디멘전 테이블로 취급한다.

비구조화 데이터를 읽어 열 지향 스토리지로 변환하는 과정에서 데이터의 가공 및 압축을 위해 많은 컴퓨터 리소스가 소비된다.

→ 그래서 사용되는 것이 Hadoop과 Spark 등의 분산 처리 프레임워크이다.

Hadoop

하둡은 단일 소프트웨어가 아닌 분산 시스템을 구성하는 다수의 소프트웨어로 이루어진 집합체다.

• 하둡의 기본 구성 요소(대표, 일부)
• ‘분산 파일 시스템’ → HDFS
• ‘리소스 관리자’ → YARN
• ‘분산 데이터 처리’ → MapReduce

다양한 소프트웨어 중 자신에게 맞는 것을 선택하고 그것들을 조합함으로써 시스템을 구성하는 것이

Hadoop을 중심으로 하는 데이터 처리의 특징이다.

 

분산 파일 시스템과 리소스 관리자 (HDFS, YARN)

• 다수의 컴퓨터에 파일을 복사하여 중복성을 높인다는 특징이 있다.
• CPU나 메모리 등의 계산 리소스는 YARN에 의해 관리된다.
• YARN은 애플리케이션이 사용하는 CPU 코어와 메모리를 ‘컨테이너’라 불리는 단위로 관린한다.
• 하둡에서 분산 애플리케이션을 실행하면 YARN이 클러스터 전체의 부하를 보고 비어있는 호스트부터 컨테이너를 할당한다.

*YARN 컨테이너

→ 도커를 떠올리는 사람도 있을 것이다. YARN의 컨테이너는 OS수준의 가상화 기술이 아니라 어떤 호스트에서

어떤 프로세스를 실행시킬 것인지 결정하는 애플리케이션 수준의 기술이다.

 

분산 데이터 처리 및 쿼리 엔진 (MapReduce, Hive)

MapReduce는 임의의 자바 프로그램을 실행시킬 수 있기 때문에 비구조화 데이터를 가공하는 데 적합하다.

• MapReduce는 대량의 데이터를 배치 처리하기 위한 시스템이다
• 작은 프로그램 실행을 위해서라면 오버헤드가 너무 크기 때문에 몇 초 안에 끝나버리는 쿼리 실행에는 적합하지 않다.
• Hive도 마찬가지이다. 시간이 걸리는 배치 처리에는 적합하나, 애드 훅 쿼리를 여러 번 실행하는 데는 부적합하다.

Hive On Tez

Hive를 가속화하기 위한 노력으로 개발된 것이 Apache Tez이다.

*Hive on Spark → Apache Spark를 사용해 Hive를 고속화 하는 개발도 진행되고 있다.

 

대화형 쿼리 엔진 (Impala, Presto)

• Presto와 Impala는 YARN과 같은 범용적인 리소스 관리자를 사용하지 않고 SQL의 실행만 특화한
  독자적인 분산 처리를 구현하고 있다.

-대량의 비구조화 데이터를 가공하는 무거운 배치 처리에는 높은 처리량으로 리소스를 활용할 수 있는 Hive

-그렇게 해서 완성한 구조화 데이터를 대화식으로 집계하고자 할 때는 지연이 적은 Impala와 Presto 등이 적합하다.

Spark

Hadoop의 연장선 상에 있는 Tez와 달리 Spark는 Hadoop과는 다른 독립된 프로젝트다.

Spark의 특징은 대량의 메모리를 활용하여 고속화를 실현하는 것이다.

 

MapReduce 대체하기

• Spark에서는 스트림 처리르 수행하기 위한 Spark Streaming이라는 기능이 처음부터 포함되어 있다.
• 따라서 대규모 배치 처리 뿐만 아니라 SQL에 의한 대화형 쿼리 실행과 실시간 스트림 처리에 이르기까지 널리 이용되고 있다.

---

3-2 쿼리엔진

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

• 처음에 분산 스토리지에 저장된 데이터를 구조화하고 열 지향 스토리지 형식으로 저장한다(Hive를 이용)
• 완성한 구조화 데이터를 결합, 집계하고 비정규화 테이블로 데이터 마트에 써서 내보낸다.
  → 열 지향 스토리지를 이용한 쿼리의 실행에는 Presto를 사용해 실행시간을 단축할 수 있다.
• Hive에서 만든 각 테이블의 정보는 ‘Hive 메타 스토어’라고 불리는 특별한 DB에 저장된다.

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

// 비효율적인 쿼리의 예
//테이블을 결합한 후에 WHERE 로 검색
SELECT ...
FROM access_log a
JOIN users b ON b.id = a.user_id
WHERE b.created_at = '2017-01-01'

//보다 효율적인 쿼리의 예시
SELECT ...
FROM(
	SELECT * access_log
	WHERE time >= TIMESTAMP '2017-01-01 00:00:00'
) a
JOIN users b ON b.id = a.user_id
WHERE b.created_at = '2017-01-01'

• 서브쿼리 안에서 팩트테이블을 작게 하는 것이 확실하다.
• 가능한 ‘초기에 팩트 테이블을 작게하는 것’이 중요하다.

대화형 쿼리 엔진 Presto의 구조

플러그인 가능한 스토리지

Presto의 하나의 특징이 프러그인 가능한 스토리지 설계다.

• Presto는 전용 스토리지를 갖고 있지 않으므로 Hive와 마찬가지로 다양한 데이터 소스에서 직접 데이터를 읽어 들인다.

CPU 처리의 최적화

Presto는 SQL의 실행에 특화된 시스템으로 쿼리를 분석해 최적의 실행 계획을 생성 → 자바의 바이트 코드로 변환
→ 바이트 코드는 Presto의 워커 노드에 배포 → 그것은 런타임 시스템에 의해 기계 코드로 컴파일된다.

Presto 쿼리는 일단 실행이 시작되면 중간에 끼어들 수 없기 때문에, 너무 큰 쿼리를 실행해서는 안 된다.

 

인 메모리 처리에 의한 고속화

Presto는 쿼리의 실행 과정에서 디스크에 쓰기를 하지 않는다.

모든 데이터 처리를 메모리상에서 실시하고 메로리가 부족하면 여유가 생길때 까지 기다리거나 오류로 실패한다.

 

분산 결합과 브로드캐스트 결합

• Presto는 기본적으로 분산 결합을 실시하며 같은 키를 갖는 데이터는 동일한 노드에 모인다.
• 한쪽 테이블이 충분히 작은 경우 브로드캐스트 결합을 사용해 속도를 고속화할 수 있다.

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

MPP데이터베이스

• 스토리지 및 계산 노드가 일체화되어 있어 처음에 ETL 프로세스 등으로 데이터를 가져오는 절차가 필요하다
• 그 다음은 SQL만으로 데이터를 집계할 수 있다.

Hive

• 하둡 상의 분산 애플리케이션은 원래부터 높은 확장성과 내결함성을 목표로 설계되어 있다.
• 하이브는 앞으로도 데이터양에 좌우되지 않는 쿼리 엔진으로 계속 이용될 것으로 예상된다.

Presto

• 하이브와 정반대인 쿼리엔진으로 속도로 인해 다양한 것을 희생한다.
• 대화식 쿼리의 실행에 특화되어 있기 때문에 텍스트 처리가 중심이 되는 ETL프로세스 및 데이터 구조화에는 적합하지 않다.
• 데이터 구조화에는 Hive와 Spark를 사용하는 편이 좋다.

Spark

• 인 메모리의 데이터 처리가 중심이며 대화형 쿼리 실행에 적합하다.
• ETL프로세스에서 SQL에 이르기 까지의 일련의 흐름을 하나의 데이터 파이프라인으로 기술할 수 있다는 점이 장점이다.
• 스파크에서는 메모리르 어떻게 관리하냐가 중요하다.

---

3-3 데이터 마트의 구축

팩트 테이블

빅데이터 분석은 데이터를 구조화하는 것부터 시작하는데, 그중에서도 압도적으로 많은 부분을 차지하는 것이 팩트 테이블이다.

 

팩트 테이블의 작성

 

테이블 파티셔닝

팩트 테이블 효율만 생각하면 추가가 유리하다 그러나 아래같은 문제점이있다.

• 추가에 실패한 것을 알아채지 못하면 팩트 테이블의 일부에 결손이 발생한다.
• 추가를 잘못해 여러번 실행하면 일부가 중복된다.
• 나중에 팩트 테이블을 다시 만들고 싶은 경우의 관리가 복잡해진다.

이런 문제가 일어날 가능성을 줄이기 위해 테이블 파티셔닝을 기술한다.

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

 

데이터 마트의 치환

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

팩트 테이블 전체를 치환하는 것은 많은 장점이 있다.

• 중간 데이터가 중복되거나 빠뜨릴 가능성이 거의 없다.
• 스키마 변경등에 유연하게 대응할 수 있다.
• 유일하게 우려되는 것은 처리 시간이다.

집계 테이블

팩트 테이블을 어느 정도 모아 집계하면 데이터의 양이 크게 줄어든다.

→ 이것을 집계 테이블 이라고 한다.

스냅샷 테이블

마스터 데이터처럼 업데이트될 가능성이 있는 테이블에 대해서 두 가지 방안이 있다.

1. 정기적으로 테이블을 통째로 저장하는 방법으로 이를 ‘스냅샷 테이블’ 이라고 한다
2. 다른 하나는 변경 내용만 저장하는 방법으로 ‘이력 테이블’이라고 한다

• 스냅샷 테이블은 시간이 지남에 따라 점점 커지므로 일종의 팩트 테이블로 간주한다.
• 다른 팩트 테이블과 결합함으로써 디멘전 테이블로도 사용할 수 있다.
• 스냅샷은 특정 시점의 테이블의 상태를 기록한 것으로 나중에 다시 만들 수 없다. 데이터 레이크나 데이터 웨어하우스와 같은 영구적인 저장소에 보관하여 삭제되지 않도록 주의한다.

*이력 테이블 보다는 마스터 관계의 테이블은 기본적으로 매일 스냅샷 하는 것이 좋다. 또 데이터의 양을 줄이는 데 도움이 되지만, 어느 순간부터는 마스터 테이블을 복원하는 것이 어려워 진다.

---

3-4 요약

• 그냥 그대로 DW에서 가져올 때 ‘비구조화 데이터’ 또는 ‘스키마리스 데이터’등을 취급하는 경우가 많아 이러한 데이터를 여러 컴퓨터에서 ‘분산처리’하는 방법이 요구된다.
• 하둡과 스파크가 분산 처리 프레임워크로 널리 이용되고 있다.
• 하둡은 분산파일 시스템에서 리소스 관리자 그리고 MapReduce에 의한 분산 데이터 처리에 이르는 종합적인 컴포넌트를 제공하여 많은 분산 애플리케이션의 공통 플랫폼이다.
• 스파크는 ‘대량의 메모리를 활용한 고속의 데이터 처리 기반’ 이므로 MapReduce를 대체하는 ‘분산 프로그래밍 환경’으로 사용된다.
• Hive는 디스크 상 에서 대량의 데이터 처리를 하기 때문에 대규모 배치 처리에 유용하다.
• Presto는 메모리 상 에서 고속 집계에 특화되어 있어 대화형 쿼리 실행에 적합하다.
• ‘데이터 구조화’만 잘되어 있으면 그 후 DW와 같은 개념으로 데이터 마트를 구축할 수 있다.
• 팩트 테이블과 디멘전 테이블을 준비하고 그것들을 결합,집계 하면서 시각화에 적합한 비정규화 테이블을 만든다.
• 디멘전으로 사용하는 데이터는 평소 정기적인 스냅샷으로 이력을 축적해둔다.
• 디멘전의 ‘카디널리티’만 작아지면 비정규화 테이블은 작게 집약할 수 있다.

 

*출처 - 빅데이터를 지탱하는 기술 / 저자: 니시다 케이스케 / 출판: 제이펍