03. 빅데이터의 분산 처리

안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다. 감사합니다.

 

이번에는 시각화에 적합한 데이터 마트를 구축하는 것을 목적으로, 분산 시스템에 의한 데이터 처리의 기본적 흐름에 관해 설명해보겠다.

 

 

 

새로운 개념이 화수분처럼 쏟아지고, 유사한 개념이 머릿속을 헤집어 정리하는데 비교적 상당한 시간이 소요되었던 부분이다. 하지만 머릿속으로 개념을 정리하니, 평소 궁금했던 질문들이 한결 해소되었다.

그럼, 분산 시스템에 의한 데이터 처리의 기본적 흐름에 대해 포스팅을 시작하겠다.

 

(나름 열심히 포스팅을 진행했지만, 저도 공부를 하며 정리한 내용이므로 중간에 오류가 있을 수 있습니다. 혹여 게시물에 이슈가 있다면, 댓글 or eng.sohee@gmail.com으로 연락 주세요. 감사합니다.)

 

 

 

 

 

 

 

 

 

목차

대규모 분산처리 프레임워크

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

데이터 마트 구축

 

 

---

 

 

 

01. 대규모 분산처리 프레임워크

1-1. 데이터 구조화의 파이프라인

 

 

 

애플리케이션을 통해 데이터 소스를 수집한다. 그 후,

비/반구조화 데이터를 스키마가 명확히 정의된 구조화 데이터로 바꿔주어야 한다.

 

비구조화 데이터란?

자연 언어로 구성된 텍스트 데이터나, 이미지 동영상처럼 스키마가 없는 데이터

 

반구조화(스키마 리스) 데이터란?

CSv, XML, JSON처럼 데이터 서식은 정해졌어도 칼럼 수나 데이터형이 명확하게 정의되지 않은 데이터

🔥 반드시 스키마 리스 데이터를 구조화해야 할까?

No. JSON으로 요즘은 데이터를 많이 주고받는데, 이를 모두 구조화하는 것은 복잡하므로, JSON은 JSON 그대로 저장을 하고 데이터 분석에 필요한 필드만을 추출해 구조화하는 것이 일반적이다.

 

 

 

그 후, 데이터 압축률 높은 열 지향 스토리지로 저장한다.

 

MPP 데이터베이스로 전송하거나 & Hadoop에서 열 지향 스토리지 형식으로 변환한다.

이를 시간에 따라 증가하는 팩트 테이블과, 그렇지 않은 디멘젼 테이블로 분리한다. 

 

🔥 열지향 스토리지, MPP와 Hadoop의 차이는?

Hadoop에서는 직접 열 지향 스토리지의 형식을 선택하고, 쿼리 엔진에서 집계할 수 있다.

예를 들어, Apache ORC 데이터 형식은 구조화 데이터를 위해 스키마를 정한 후 데이터를 저장할 수 있고, Apache Parquet 데이터 형식은 스키마 리스에 가까운 데이터 구조로 되어 있어, JSON도 그대로 저장이 가능하다. 
※ 내가 포스팅을 하는 내용은 Hadoop 열지향 스토리지 = Apache ORC임을 참고하자.

또한, Spark 등을 이용해 ★
 

 

MPP의 설명을 보면, Hadoop과의 차이를 명확히 이해할 수 있을 것이다.

MPP 설명은 아래 링크의 이전 포스팅을 참고하자.

 

02. 빅데이터의 탐색

 

 

 

 

1-2. Hadoop 이란?

Hadoop이란, 분산 시스템을 구성하는 다수의 소프트웨어로 이뤄진 집합체를 뜻한다.

 

 

이는 대규모 분산 시스템을 구축하기 위한 공통 플랫폼의 역할을 담당하고 있다.

※ 분산 시스템: 네트워크 상 분리된 요소를 마치 하나의 서버로 구동하는 것처럼 보이는 시스템

 

Hadoop 내 소프트웨어와 타 소프트웨어를 결합해서 사용하기도 하고, 단일 Hadoop 만 사용하기도 한다는 특징이 있다.

 

 

1-2-1. Hadoop - HDFS

여러 대의 서버에 데이터를 저장하고, 각 저장된 서버에 동시에 데이터를 처리하는 방식

 

 

HDFS는 분산 시스템의 스토리지를 관리해 데이터가 항상 여러 컴퓨터에서 복사되어 저장된다.

여러 컴퓨터에 처리할 디스크를 나눠 저장한다. 이를 Name Node가 관리하고, Data Node가 저장한다.

※ MPP 데이터베이스 처리 방식을 기억하자! 

※ 여기에서는 Name Node와 Data Node의 개념이 나오는데, 이는 추후 포스팅할 것이다.

 

 

 

1-2-2. Hadoop - YARN

YARN 이란, 리소스 관리자다. CPU 등의 리소스에 부하가 없도록 관리한다.

 

🔥 YARN의 목적은 무엇일까?
리소스를 낭비 없이 활용하며 데이터 처리를 수행하도록 하는 것이다.

 

 

 

1-2-3. Hadoop - MapReduce, Hive

 

MapReduce 란?

 

단어 개수 count 하는 문제의 경우에서의 MapReduce 파이프라인

 

YARN 내에서 움직이는 분산 애플리케이션 중 하나이며, 분산 데이터 처리 방법이다.

 

이는 맵리듀스의 저장도 분산으로 하니까, 처리도 분산으로 하자!라는 아이디어에서 시작됐다.

비구조화 배치 데이터를 가공하는 데에 적합하며 자바 기반 프레임워크다.

왜 배치 데이터 처리에서 적합할까?
분산된 데이터를 한 번에 쭉 끌어 오기 때문이다. 그러면 작은 쿼리 반복 수행은, 시스템 처리에서 오버헤드가 크니까 다소 부적합하다.

 

• Map: 분산(Spliting)할 데이터를 Key, Value 쌍으로 분산 처리해서 (예를 들어 cnt 문제라면 Key가 몇 번 나왔는지 Value에 저장) 처리 & 리스트 생성
• Reduce: 각 분석된 데이터를 통합관리(Shuffling 한 뒤 Reducing. Filtering과 Sorting으로 원하는 데이터 추출하고, 중복 데이터를 제거하는 등)

 

 

Hive 란?

MapReduce의 성질이나 자바가 아닌 SQL로 데이터를 처리할 수 있는 프로그램이다.

 

SQL 쿼리로 배치 처리를 하고 싶다면, Hive를 이용하자. MapReduce의 성격을 그대로 받아왔지만, 자바 언어가 아닌 SQL로 처리가 가능하다. 그래서 쿼리 엔진으로 배치 데이터 집계할 때 쓴다.

 

 

 

 

1-2-4. Spark

MapReduce보다 더 효율적 데이터 처리 실행하기 위한 Hadoop과는 다른 독립된 프로젝트다.

 

Spark와 Hive 정리

배치 처리에서 MapReduce를 대체할 수 있는 것? Spark
배치 처리에서 MapReduce의 자바언어 사용을 대체할 수 있는 것? Hive

 

Spark의 목적?
대량 메모리로 데이터 처리 고속화를 실현한다.
👉🏻 즉, 가능한 한 많은 데이터를 메모리 상에 옮긴 상태로 두어 디스크에는 아무것도 기록하지 않는다.

Spark의 특징?
1. 실행에는 자바 런타임 필요하지만, Spark 내에서 실행되는 데이터 처리는 스크립트 언어(파이썬, R, 자바 등)를 사용할 수 있다. 그리고 SQL을 사용할 수도 있다.

2. 배치처리 말고도, 실시간 스트림 처리도 가능하다. 왜냐하면 Spark에는 Spark SQL과, Spark Streaming 기능이 있기 때문이다.

❓ MapReduce와의 차이?

MapReduce: 디스크의 읽고 쓰기

Saprk: 메모리에 활용. 가능한 한 많은 데이터를 메모리에 올려 디스크에는 아무것도 기록하지 않는다. 중간에 처리하면 중간 데이터 사라지지만, 그땐 처리를 다시 시도하면 된다는 것이 Spark의 핵심

 

1-2-5. Impala, Presto

 

Hive는 배치 처리가 가능한 SQL인데, 이는 맵리듀스 성질이 그대로 있다. 그래서 작은 쿼리문을 여러 번 시행하는 게 부적합하다. 이를 가속화하기 위해 Tez 가 개발되었다.

 

Tez란 무엇인가?
Hive 고속화를 위한 프로젝트.
1회의 맵리듀스 스테이지 종료 후 데이터를 처리해야 하는 맵리듀스의 성질을 없애고, 앞선 스테이지 종료를 기다리지 않고 처리 끝난 데이터를 차례대로 후속 처리에 전달해 쿼리 전체의 실행 시간을 단축시키는 것

※ 스테이지란? 위 그림에서 매핑, 스플릿팅, 셔플링 등을 스테이지라고 한다.

 

 

하지만, 맵리듀스를 최적화하기 위한 개선책이 아닌, 아예 작은 데이터 반복 처리를 위한 쿼리 엔진을 개발했다.

그것의 대표적 엔진이 Impala, Presto다.

 

이들은 오버헤드를 제거해, 사용할 수 있는 리소스를 최대한 활용한다.

 

❓ 그렇다면 MapReduce와 Hive, Tez는 리소스가 효율적이지 않다는 뜻인가?

그렇지 않다. 그러나 MapReduce와 Hive, Tez는 장시간의 배치 처리를 가정해, 한정된 리소스를 유효하게 활용하도록 애초에 설계가 되어 있다. 그래서 작은 쿼리문 반복 처리에 적합하지 않다.

 

이 Impala와 Presto도, MPP처럼 멀티 코어를 활용한다. 그리고 데이터 처리를 병렬화한다. 이때, 리소스 관리자를 사용하지 않고(YARN 사용 X) SQL의 실행만 특화한 독자적 분산 처리를 구현하고 있다.

 

 

Presto의 결합 - 분산 결합과 브로드캐스트 결합

이것의 차이는 현재 잘 모르겠다. 구글링 해서 알아낸 뒤 찾아놓자!

 

 

---

 

02. 데이터 마트 구축 파이프라인

2-1. Hive와 Presto 결합한 파이프라인

 

 

 

2-1-1. Hive 통한 테이블 구조화

Hive의 역할

비구조화 데이터를 구조화 데이터로 만들고 열 지향 스토리지 형식(일반적으로 ORC 형식)으로 Hive 메타 스토어에 저장.

 

Hive 메타 스토어란, Hive를 통해 만들어진 팩트 테이블과 디멘젼 테이블 등의 정보가 저장되는 곳이다.

.

Hive도, MPP처럼 데이터를 내부로 가져오지 않아도 텍스트 파일을 그대로 집계할 수 있다. 따라서, 시간을 들여 데이터를 전송하지 않아도 돼서 좋다. 하지만, 그렇다고 해서 데이터를 그대로 집계하면 비효율적(쿼리 실행시킬 때마다 매번 텍스트 읽어야 하므로) 이므로 열 지향 스토리지 형식으로 저장해준다.

 

 

2-1-2. Hive, Presto 통한 테이블 비정규화

 

구조화된 데이터로 데이터 마트를 만든다. 데이터 마트는, 만들어진 테이블을 결합해서 만들어야 해서 비정규화 테이블 형태다. Presto 같은 대화형 쿼리 엔진 vs Hive 같은 배치형 쿼리 엔진을 선택해 테이블을 비정규화한다.

 

비정규화 테이블은 일반적으로 시간이 걸리는 배치 처리이므로 Hive를 사용한다.

하지만, 작은 쿼리를 여러 번 사용해야 할 경우는 Presto를 쓴다.

🔥 Impala도 있는데, 왜 작은 쿼리 여러 번 사용할 때 Presto를 염두에 두는 것인가?

답은, ORC 로드에 최적화된 프로그램이기 때문이다. 그리고 하나의 쿼리 내에서 여러 데이터 소스에 연결이 가능한 분산 시스템이다. 그리고, Hive와 달리 디스크 쓰기를 하지 않는다. 따라서, 디스크 쓰기 필요한 것만 Hive를, 그렇지 않은 것은 Presto를 쓰기도 한다. 


🔥 Presto로 테이블 구조화를 하면 안 되나?

바람직하지 않다. 텍스트 처리가 중심인 ETL 프로세스 및 데이터 구조화에는 대화형 쿼리 엔진은 적합하지 않기 때문이다.

 

 

빠른 비정규화 테이블 생성 방법

1. 서브 쿼리 내에서 레코드 수 줄이기 - 애초에 검색 대상에서 where 절로 줄여준다.
2. 애초에 팩트 테이블을 작게 생성해주기

 

 

데이터 처리 정리

인메모리 기반 데이터 처리	Spark, Presto - 메모리 관리 이슈가 중요하다. 여러 번 이용하는 데이터는 캐시에 올리거나 디스크에 스왑해 메모리 해제하는 등의 제어가 필요하다.
디스크 기반 데이터 처리	MapReduce, Hive(내부에서 MapReduce 동작하므로)

 

---

03. 데이터 마트 구축

 

앞서 설명한 데이터를 구조화하는 작업까지는 어느 정도 설명을 했고, 비 정규화하는 작업 그리고 그 비정규화한 테이블로 데이터 마트를 구축하는 과정을 더 자세히 설명해보겠다.

 

3-1. 팩트 테이블 작성하기 - 증분과 치환

 

추가란, 새로 생성된 데이터를 더하는 작업

치환이란, 과거의 데이터 포함 테이블 전체를 치환하는 작업

 

🔥 무엇이 더 좋은가?

데이터 처리 시간이 일반적으로 1시간에 처리가 된다면, 치환이 무조건 좋다. 결손&중복 등의 이슈가 발생하지 않고, 스키마 변경 시에도 유연히 대응할 수 있다. 이런 이슈가 없다 보니 관리도 수월해지기 때문이다.

데이터의 양이 많다면, 어쩔 수 없이 추가를 해야 한다. 결손&중복 등의 이슈 발생 위험을 줄이기 위해 테이블 파티셔닝을 수행한다. 테이블 파티셔닝이란, 여러 물리적 파티션으로 팩트 테이블을 나눠(ex: 1일 1회 등) 저장한 것이다. 각 파티션 별로 치환하는 등을 통해 관리한다. 즉, 추가를 그냥 추가하는 게 아니라 지속적으로 치환된 테이블을 추가한다라고 보는 것 같다.(나도 배워가는 거라 확실치 않다. 정확히 찾아보자!) 이 파티션들을 추후 배치 처리 해 한 개의 팩트 테이블로 만든다. 파티션 테이블은 위치별로 잘 관리해줘야 한다.


🔥 테이블 비정규화 시 처리 방법 순서(좋은 순부터)
치환 > 파티셔닝 > 추가

 

 

 

3-2. 팩트 테이블 관리하기 - 집계 테이블 활용

 

팩트 테이블을 어느 정도 모아서 집계해 저장하면 나중에 데이터 마트를 만들 때도 수월해진다.

이때 카디널리티(각 칼럼이 취하는 값의 범위)를 줄이고(범주화 등의 방법이 있겠다), 필요 없는 데이터는 날려 집계 테이블을 형성하는 것이 좋다.

그래야 집계 테이블의 파워가 세지기 때문이다.

 

 

 

3-3. 마스터 데이터 관리하기 - 스냅샷 테이블

 

마스터 테이블이 바뀔 염려가 있다면, 데이터 분석을 용이하게 하기 위해 스냅샷을 찍어 관리한다.

 

 

스냅샷 테이블이란, 정기적으로 수정된 테이블을 통째로 저장하는 방법이다.

 

 

이런 특성 때문에, 스냅샷 테이블은 시간이 지날수록 많아지기 때문에, 이를 팩트 테이블처럼 간주하기도 한다.

혹은 디멘젼과 결합해 디멘젼 데이터로도, 팩트 테이블에 날짜를 포함해 팩트 테이블로도 적용할 수 있다. 

 

🔥 스냅샷 테이블에서 주의해야 할 점이 있다면?

1. 스냅샷을 끌어와 저장하는 날짜와, 스냅샷을 찍는 날짜가 같아야 한다. 그러니 웬만하면 끌어오는 날짜는 자정 등으로 지정하자. 그래야 나중에 데이터 분석할 때 스냅샷 날짜가 혼동되어 마스터 데이터를 혼동해 사용할 일이 없게 된다.


2.  특정 시점 상태를 기록한 것이므로 날아가면 복구가 어렵다. 따라서 데이터 레이크나 웨어하우스에 잘 저장해두자.

 

 

 

 

3-2. 결론 - 비정규화 테이블은 어떻게 만드는가?

 

1. 팩트 테이블에서 필요한 데이터를 꺼낸다. 이때 필요한 칼럼만 선택하고, 수집 기간을 정해주어 로드 효율을 높인다.
2. 디멘젼 테이블과 결합해 데이터마트에 저장할 칼럼을 선택해준다. 이때 카디널리티를 작게 해주자.
3. 이를 그룹화해서 측정값을 집계한다. 그러면 비정규화 테이블 완성이다!
4. 이것을 마트로 내보내거나 & CSV 파일로 저장하면 끝이다!