빅데이터를 지탱하는 기술

1. 기초 용어

1) 데이터웨어하우스 : 데이터의 장기 보관을 목적으로 하는 저장소

2) 데이터마트: 데이터웨어하우스에서 필요한 데이터만 추출한 것

3) 데이터레이크: raw data가 흘러들어오는 것에 비유하여, 데이터의 축적 장소

4) 애드혹 분석: 일회성 분석

 

2. 분산처리

열지향 테이블의 이점

1) 지역성: 같은 칼럼에서는 동일한 값이 반복되기도 함 -> 압축률을 높일 수 있다

2) 데이터 분석시 모든 열을 분석하는 것이 아니라, 일부 열만 이용. 이 경우 행지향 테이블의 경우 모든 레코드를 탐색해야한다. 데이터의 양이 클 경우 메모리가 부족할 수 있음. 열지향은 일부 열만 메모리에 올리기 때문에 효율적.

 

◆ 비정규화 테이블을 사용하는 이유:

 

정형 데이터: 스키마가 명확히 정해지는 데이터 : RDB가 강함

비정형 데이터: 스키마가 명확하지 않은 데이터 -> 이미지, 동영상 등 : NoSQL이 강함

스키마리스 데이터: 형식은 정해져있지만 칼럼수나 데이터형이 명확하지 않은 데이터

 

◆ Hadoop

1) HDFS(Hadoop Distributed File System): 분산 파일 관리 시스템 : 네임 노드(메타데이터 + 데이터 노드 관리) + 데이터 노드

2) YARN(Yet Another Resource Negotiator): 리소스 관리자 - 클러스터 자원 관리, 할당

3) MapReduce: 분산 데이터 처리 모듈

SQL-on-Hadoop : Hadoop에서 사용되는 쿼리 엔진. Hive, Tez/ Impala, Presto(대화형)

4) Hadoop Common : 하둡의 다른 모듈을 지원하기 위한 공통 컴포넌트 모듈

 

◆ Spark

MapReduce와 달리 대량의 메모리를 사용해서 고속화. 스트리밍 데이터에 적합

MapReduce는 적은 메모리로 디스크 I/O 많이 이용. Spark는 메모리에 다 올려버린다.

또한 데이터 구축의 파이프라인을 원샷으로 해결할 수 있다. 텍스트 데이터를 열 지향 스토리지로 변환하고 SQL로 집계하여 결과를 내보낼 수 있다.

 

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

비구조화 데이터 ->(데이터 구조화: Hive) -> 구조화 데이터(팩트 테이블, 디멘젼 테이블. 열 지향 스토리지) ->(데이터 집약: Presto) -> 비정규화 테이블

 

3) 데이터 마트의 구축

- 팩트 테이블: 추가(append), 치환(테이블 전체를 replace)

테이블 파티셔닝: 하나의 테이블을 여러 개의 파티션으로 나누어 파티션 단위로 데이터 업데이트 가능.

- 집계 테이블: 팩트 테이블을 집계한 것.

카디널리티: 각 칼럼이 가질 수 있는 값의 범위. 카디널리티가 작아야 집계 테이블이 작다.

- 스냅샷 테이블: 테이블 전체를 저장 / 이력 테이블: 변경된 데이터만 스냅샷

 

3. 빅데이터의 축적

1) 벌크형 vs. 스트리밍형

벌크형 : 크기가 너무 크지 않도록 분할해서 전송. 재실행이 가능하다는 장점

2) 스트리밍형: 계속 전송되어오는 작은 데이터를 위한 방법. 메시지 배송을 통함.

-클라이언트 : 메시지가 처음 생성되는 기기

-프런트엔드: 메시지를 먼저 받는 서버. 클라이언트와의 통신 프로토콜을 제대로 구현하는 역할.

클라이언트 -> 프런트엔드 -> 메시지 브로커

-메시지 브로커: 디스크에 빈번하게 쓰는 것은 비효율적. 중간 데이터 축적층.

푸시: 송신 측에서 메시지 브로커에 넣는 것

풀: 수신측이 데이터를 가져오는 것

- 메시지 라우팅: 메시지 브로커의 데이터는 여러 다른 소비자가 읽을 수 있다. 이를 통해 메시지가 복사되어 여러 경로로 분기될 수 있다.

 

2) 메시지 배송 : at least once 배송을 하고 중복을 확인한다.(offset/고유 id 이용)

 

3) 시계열 데이터의 최적화

- 시계열 인덱스

- 조건절 푸시다운: 테이블 파티셔닝에서 만들어진 통계를 이용함(최솟값, 최댓값)

- 시계열 테이블: 시계열 데이터를 이용한 테이블 파티셔닝

- 데이터마트를 이벤트 시간으로 정렬

 

4) 비구조화 데이터의 분산 스토리지: NoSQL 이용

수정하는 것은 새로 파일을 써야하므로 갱신이 많은 곳에는 부적합

log와 같이 축적에 주로 사용

- KVS: dynamoDB

- wide column store: 2개 이상의 키. cassandra

-도큐먼트 스토어: 스키마리스 데이터 관리 가능. mongoDB

 

CAP

Consistency: 

Availiability: 장애 X

Partition-tolerance

 

- 데이터 수집의 파이프 라인:

클라이언트 -> 프런트엔드 -> 메시지 브로커 -> 소비자 -> 분산 스토리지 -> 중복 제거/데이터 구조화(열 지향 스토리지로 변환)-> 다시 분산 스토리지로

 

4. 워크플로우 관리

멱등:  동일한 태스크를 여러 번 실행해도 동일한 결과가 되는 것

 

◆ MapReduce:

1) 파일을 일정 크기로 나누어 작은 데이터인 스플릿을 만든다.

2) 나눈 데이터를 읽어 비슷한것 끼리 묶는다

3) Map: 처리한다

4) Reduce:다시 합한다.

 

◆ DAG:

태스크의 실행 순서를 DA로 나타내서 처리한다. 의존성 문제 해결

 

◆ 람다 아키텍처

실시간 분석을 지원하는 빅데이터 아키텍쳐

대량의 데이터를 실시간으로 분석하기 어려우므로, batch로 미리 만든 데이터와 실시간 데이터를 혼합해서 사용하는 방식.

배치 레이어: 모든 데이터가 거치는 레이어

서빙 레이어: 배치 처리 결과는 서빙 레이어를 통해 접근. -> 배치 뷰. 하지만 실시간 정보를 얻을 수 없다.

스피드 레이어: 스트림 처리를 위함. 실시간뷰

스피드 레이어의 실시간 뷰 결과는 나중에 배치 뷰로 치환된다.

데이터 =>1) 배치 레이어 -> 서빙 레이어 & 2) 스피드 레이어 => 쿼리.

 

카파 아키텍처: 배치 레이어/서빙레이어 제거. 대신, 메시지 브로커의 데이터 보관 기간을 늘려 재실행 가능게 함.