최신 DWH, ETL의 기술적 배경과 관련하여 "초대략적"

개시하다

DWH와 ETL에 필요한 대규모 처리는 어떤 배경과 아이디어로 이뤄졌을까.

데이터 처리 기술의 추세

먼저 ETL 처리에 대해 살펴보겠습니다.DWH도 마찬가지로, 분산 처리가 키워드입니다.

요청된 Bigdata에 대한 대응

이른바 3V(Variety, Velocity, Volume)에서 정의가 많은 빅다타가 등장함에 따라 이를 분석 처리하는 소프트웨어는 우선 "현실적인 시간 안에 대량의 데이터 처리를 끝내야 한다"고 요구한다.

분산 처리 프레임의 고개 들기

대량의 데이터를 효과적으로 처리하기 위해 Hadoop과 같은 처리 기술을 사용했다.
Hadoop은 다음과 같은 구조로 대량의 데이터를 효과적으로 처리했다.
데이터 분할 후 다중 서버로 처리(Map)
개별 데이터 처리 결과 요약
효율적인 MacReduce 가상 스토리지 시스템(HDFS: Hadoop Distributed File System)
이 기술적 요소는 구글이 발표한 논문을 바탕으로 아파치 하도프로 OSS화됐다.

Hadoop에 대한 좌절.

Hadoop은 현재 Hadoop의 구조가 없으면 대규모 데이터 처리를 말할 수 없지만 완벽하지는 않다.

클러스터 준비

분산 처리를 위해서는 클러스터(서버의 블록 모양)를 준비해야 하지만, Hadoop의 혜택을 누리기 위해서는 최소한 TB급 데이터 처리가 필요하기 때문에 일부 제한된 기업에서만 사용한다.

분석 용례에 대한 저효성

Hadoop은 구조적으로 매번 처리할 때마다 Disk에 쓰기 때문에 여러 개의 처리 절차를 조합한 처리와 처리 결과를 반복적으로 사용하는 처리에서 효율이 낮다고 지적했다.

개발의 난이도

하도프 개발은 자바를 다룰 수 있는 인재가 필요하기 때문에 데이터 분석이 가능하고, 자바가 다룰 수 있는 인재라는 측면에서 개발이 어려워 보급을 막았다.

Hadoop의 보급과 분산 처리의 진화

클라우드 공급업체의 Hadoop 민주화

클러스터 관리 측면에서 클라우드 공급업체를 통해 PaaS(또는 IaS)를 제공하면 더욱 간단하게 사용할 수 있다.

스파크의 등장.

그렇다면 Hadoop의 분석 용례와 개발 언어의 문호 협착은 스파크라는 OSS 분산 처리 프레임워크를 탄생시켰다.

참조: http://spark.apache.org/talks/overview.pdf
스파크는 그동안 Hadoop의 핵심 기술인 MapReduce를 대체했다.
처리 단계를 최적화할 계획입니다. Hadoop은 메모리에 매번 처리가 Disk에 기록된 중간 처리 결과를 저장하여 Disk 입출력 횟수를 줄입니다.

또 스파크에는 자바 기반 스칼라뿐 아니라 파이톤, R, SQL,,, 등이 있다.Net에서 인코딩할 수 있으며 특히 Pyspark은 최근 머신러닝 열풍으로 급격히 증가하는 Python 사용자와 호환성이 좋아 널리 사용되고 있다.

MPP형 DWH의 등장

다음은 DWH 제품의 구조에 대한 설명입니다.이곳의 분산 처리도 키워드다.

SMP:Symmetric Multi Processing

SMP형의 처리는 주로 기존의 단일 서버에서 완성된 OLTS를 대상으로 하는 DB이다. 최근 몇 년 동안 DWH 제품은 MPP형의 처리를 전제로 했다.

MPP:Massively Parallel Processing

초병행 처리라고도 부른다.
MPP형 DWH는 Hadoop과 같은 생각으로 대량의 데이터를 분할하고 각 노드에서 처리함으로써 대규모 데이터 처리에 대응한다.

Shared Everything에서 Shared Nothing으로

MPP를 구현하기 위해 Shared Nothing형이 많이 적용됐다.
최근에는 이 프레임을 넘어 메모리 층, 컴퓨터 층, 응용 층 등의 형태로 혼합으로 구성된 DWH가 많이 등장했다.

Shared Nothing의 확장 작업 보완

Shared Nothing에서는 메모리와 컴퓨터가 일체화되기 때문에 컴퓨터가 늘어날 때 메모리의 역처리가 발생하고 공간을 좁히는 데 시간이 걸리는 등의 문제가 발생한다.

샤레드 낫싱이지만 각사 DWH는 컴퓨터 증가와 관련이 없도록 층을 형성하는 등 대책을 강구했다.

열별 스토리지를 통해 총 처리 효율성 향상

특히 합계 처리에서 중요한 것은 열을 향한 저장 장치의 존재다.

참조: https://www.slideshare.net/nttdata-tech/bigdata-storage-layer-software-nttdata

행별 스토리지

csv 등을 파일에 간단하게 넣거나 OLPP를 위한 DB는 이런 형식으로 데이터를 저장합니다.

열용 스토리지

DWH 제품은 주로 이쪽에서 사용합니다.카람나 메모리 등 표시가 있으면 이걸 말할 거예요.
파일 형식은 parquet을 대표하는 구조입니다.
데이터 블록을 열별로 배열하면'합계 처리의 고속화'와'압축의 효율화'를 실현할 수 있다.

열을 위한 저장소의 장점

총 처리의 고속화

특히 통계 처리에서 아래의 조회를 자주 사용하지만 전체적인 열을 기록하는 것을 보면 열을 사용하는 수가 적고 열을 향한 저장의 장점을 발휘한다.
sql

SELECT
    顧客ID 
    ,SUM(金額) AS 集計金額
FROM
    売上テーブル
GROUP BY
    顧客ID

압축 효율화

행에 대한 데이터는 블록에 앞의 열을 입력하고 열에 대한 데이터는 같은 블록에서 같은 열을 처리하기 때문에 같은 데이터가 빈번하게 나타나고 압축 효율이 높아지는 경우도 증가한다.

끝맺다

다양한 DWH 제품과 ETL 도구가 있지만 배경 구조와 기술에 대한 이해를 깊게 함으로써 제품 평가에 도움이 되었으면 좋겠습니다.