[빅데이터를 지탱하는 기술] Ch3.빅데이터 분산 처리 프레임워크

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

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

• 구조화 데이터(structured data)
  • 스키마(schema) 명확하게 정의된 데이터
  • 테이블
• 비구조화 데이터(unstured data)
  • 스키마가 없는 데이터
  • 텍스트, 이미지
• 스키마리스 데이터(schemaless data)
  • CSV, JSON(인터넷을 통해 주고받는 데이터), XML
  • 서식은 정해져 있지만, 컬럼 수나 데이터형은 명확X
  • 일반적으로 구조화 데이터 압축률 높이기 위해 열지향 스토리지로 저장
  • 즉, MPP DB로 저장하거나 Hadoop 상에서 열 지향 스토리지 형식으로 변환
  • 구조화된 데이터중 시간에 따라 증가하는 데이터를 팩트 테이블, 그에 따른 부속 데이터를 디멘젼 테이블데이터 구조화
• 열 지향 스토리지의 작성
  • MPP DB의 경우 제품에 따라 스토리지의 형식이 고정되어 있어 사용자가 상세를 몰라도 됨
  • Hadoop에서는 사용자가 직접 열 지향 스토리지의 형식을 선택, 자신이 좋아하는 쿼리엔진에서 그것을 집계
  • Apache ORC
    • 구조화 데이터를 위한 열 지향 스토리지
    • 처음에 스키마를 정한 후 데이터 저장
  • Apache parquet
    • 스키마리스에 가까운 데이터 구조
    • JSON 같은 뒤얽힌 데이터도 그대로 저장
  • 비구조화 데이터를 읽어 들여 열 지향 스토리지로 변환 하는데 데이터의 가공 및 압축을 위해 리소스 소비 큼 → Hadoop, Spark와 같은 분산 처리 프레임 워크로 해결

<Hadoop>

• 기본구성 3가지
  • HDFS(Hadoop Distributed File System): 분산 파일 시스템(distributed file system)
  • YARN(Yet Another Resource Negotiator): 리소스 관리자(resource manager)
  • MapReduce: 분산 데이터 처리(distributed data processing
• 모든 분산 시스템이 Hadoop에 의존하는게 아니라 일부만 사용, 전혀 사용하지 않아도 됨
  • ex) 분산 파일 시스템으로 HDFS, 리소스 관리자로 Mesos, 분산 데이터 처리로 Spark
• HDFS
  • Hadoop에서 처리되는 대부분의 데이터는 HDFS에 저장
  • 다수의 컴퓨터에 파일을 복사하여 중복성을 높이는 특징이 있음
• YARN
  • CPU나 메모리 계산 리소스 관리
  • 컨테이너(container)라고 불리는 단위로 관리
  • Hadoop에서 분산 애플리케이션을 실행하면 전체 부하를 보고 비어있는 호스트부터 컨테이너 할당
• MapReduce, Hive
  • YARN 상에서 동작하는 분산 애플리케이션 중 하나로 데이터 처리를 실행하는데 사용
  • 임의의 자바 프로그램을 실행시킬 수 있기 때문에 비구조화 데이터 가공에 적합
  • Apache Hive: SQL등의 쿼리를 자동으로 MapReduce로 변환함
    • 대용량 데이터를 배치처리하는데 적합 → 애드 혹 쿼리 여러번 실행시키는데는 부적합
  • Impala, Presto
    • 대량의 비구조화 데이터를 가공하는 무거운 배치 처리,
    • Hive로 완성한 구조화 데이터를 대화식으로 집계
    • 지연이 적음

<Spark>

• Hadoop과는 다른 독립적인 프로젝트로 MapReduce보다 더 효율적인 데이터 처리
  • Hadoop의 대체가 아니라 MapReduce의 대체
  • HDFS, YARN 그대로 사용가능, 커스텀도 가능
    • 분산 스토리지: Amazon S3
    • 데이터 읽어 들이는것: 카산드라(cassandra)
  • 대량의 메모리 활용해 고속화
  • 가능한 많은 데이터를 메모리에 올려 디스크에 기록 x가 현실화
• Spark 상에서 다양한 스크립트 언어 사용 가능
  • 자바, 스칼라, 파이썬, R 등

3-2 쿼리 엔진

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

• 1)분산 스토리지에 저장된 데이터를 구조화 하고 열 지향 스토리지 형식으로 저장
  • 다수의 텍스트 파일을 읽어 가공하는 부하가 큰 처리로 Hive 이용
• )
• 2)완성한 구조화 데이터를 결합, 집계, 비정규화 테이블로 데이터 마트에 써서 내보냄
•  
  •  
  • 열 지향 스토리지를 이용한 쿼리 실행은 Presto
• Hive 메타 스토어: Hive에서 만든 각 테이블 정보를 DB로 저장

<빅데이터 집계시 최적화>

• 서브 쿼리 안에서 레코드 수 줄이기
  • Hive 쿼리는 SQL 과 유사하지만 일반적인 RDB랑 다름
  • Hive는 DB가 아닌 데이터 처리를 위한 배치 처리 구조
  • 데이터 양 의식해서 쿼리 작성해야 성능 좋음
  • 서브 쿼리 안에서 팩트 테이블을 작게 하는게 중요
  • 데이터 감소 시킨후 집계
• 데이터 편향 피하기
  • SELECT (DISTINCT)COUNT 분산시스템에서 오래걸림
  • 데이터를 한곳에 모아야 해서 분산 처리하기 어렵기 때문에

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

• MPP DB
  • 구조화 데이터를 SQL로 집계하는 것이라면 → 기존의 DW 제품 + 클라우드 서비스
  • 스토리지 및 계산 노드가 일페화 되어있음
    • 처음 ETL 프로세스 등으로 데이터 가져오는 부분만 완성하면
    • SQL만으로 데이터 집계 가능해 Hadoop 기술 필요 X
  • 시각화를 위한 데이터 마트면 MPP 유력 → 완성한 비정규화 테이블을 고속으로 집계하는데 최적
  • 확장성 및 유연성 측면에서는 분산 시스템 프레임워크 결합
• Hive
  • 대규모 배치 처리를 꾸준히 실행
  • 장점은 대화성이라기 보다는 안정성
  • 데이터양에 좌우되지 않는 쿼리 엔진으로 계속 이용될 것으로 예상됨
• Presto
  • 속도 중시, 대화식으로 특화된 쿼리 엔진
  • 대화식 쿼리 실행에 특화
  • 텍스트 처리가 중심이 되는 ETL 프로세스 및 데이터 구조화에 적합 X
  • 데이터 구조화에는 Hive, Spark 사용이 좋음
• Spark
  • 인 메모리 데이터 처리가 중심이며, Presto 뿐만 아니라 대화형 쿼리 실행에 적합
  • 장점은 SQL보다는 ETL 프로세스에서 SQL에 이르기 까지의 흐름을 하나의 데이터 파이프라인으로 기술 가능
  • 즉, 텍스트 데이터를 읽어 들여 열 지향 스토리지로 변환, SQL로 집계해서 결과를 내보내는 등 프로세스를 한 번의 데이터 처리로 기술
  • 메모리 관리 중요
    • 자주 사용하는 데이터 → 캐쉬 메모리, 디스크에 스왑
  • 데이터 처리를 일종의 프로그래밍으로 생각하고 그것을 위한 실행 환경을 원한다면 굳!

3-3 데이터 마트의 구축

<팩트 테이블>

• 팩트테이블 작성
  • 추가(append)
    • 새로운 데이터만 증분으로 추가
    • Insert
  • 치환(replace)
    • 과거의 데이터를 포함하여 전체 치환
    • 전체를 다시 만듦, create
• 테이블 파티셔닝(table partitioning)
  • 효율만 생각하면 추가가 압도적으로 유리, 그러나 단점은
    • 추가 실패 못 알아패면 팩트 테이블 결손 발생
    • 추가 잘못해서 여러번 실행시 중복 데이터 발생
    • 나중에 다시 팩트 테이블을 만들고 싶은 경우에는 관리 복잡
  • 이런 문제 방지하고자 테이블 파티셔닝
    • 하나의 테이블을 여러 물리적인 파티션으로 나눔
    • 일반적으로 1일 1회, 1시간 1회 식으로
    • 데이터 웨어하우스 구축시 유용
• 데이터 마트의 치환
  • 팩트 테이블 전체 치환의 장점
    • 중복, 데이터 빠뜨릴 가능성 거의 없음
    • 스키마 변경 등에도 유연하게 대처가능
    • 데이터 마트 확대되는 일도 없음
  • 단점
    • 처리시간
  • 1시간 이내에 패트 테이블을 만들 수 있다면, 매번 치환하는 것으로 충분
  • 어려운 경우에는 추가를 이용한 워크 플로우 고려

<집계 테이블>

• 팩트 테이블을 어느 정도 모아서 집계시 데이터 양 크게 줄어듦 → summary table
  • 데이터를 1일 단위로 집계한 일일 집계 테이블 → 일일 보고서 만드는데 사용
• 필요한 칼럼을 골라 숫자 데이터를 집계하면 됨
• 각 칼럼이 취하는 값의 범위: 카디널리티(cardinality)
  • 성별: 카디널리티 작음
  • IP: 카디널리티 큼
• 집계 테이블을 작게하려면 칼럼의 카디널리티를 줄여야 함
  • 무리하게 줄이면 정보 손실

<스냅샷 테이블>

• 스냅샷 테이블은 시간이 지남에 점차 커지므로 팩트 테이블로 간주
• 업데이트 가능성 테이블 관리
  • 정기적으로 테이블 통째 저장: 스냅샷 테이블
  • 변경 내용만 저장: 이력 테이블
• 특정 시점의 테이블 상태를 기록한 것으로 나중에 만들 수 없음
• 따라서, DL, DW 같은 영구적인 저장소에 보관

<이력 테이블>

• 데이터 양을 줄이는 데 도움이 되지만, 완전한 마스터 테이블 나중에 복원시 어려움
• 디멘젼 테이블로 사용하기 힘듦