본문 바로가기
스터디/데이터 중심 애플리케이션 설계

[데이터 중심 애플리케이션 설계] 10. 일괄 처리

by 디토20 2023. 2. 1.
반응형

 

 

 

 

 

 

[데이터 중심 애플리케이션 설계] 10. 일괄 처리

1. 시스템의 세가지 종류

1.1 서비스(온라인 시스템)

  • 클라이언트의 요청이나 지시를 기다렸다가 요청이 들어오면 가능한 빨리 처리 후 응답을 되돌려보낸다.
  • 응답시간가용성은 서비스 성능의 중요한 지표다.

1.2 일괄 처리 시스템(오프라인 시스템)

  • 매우 큰 입력 데이터를 받아서 데이터를 처리하는 작업을 수행하고, 결과 데이터를 생산한다.
  • 일괄 처리 작업은 수 분에서 수 일이 걸리므로 사용자가 응답을 기다리지 않고, 반복적으로 일정한 시간에 수행한다.
  • 처리량은 중요한 성능 지표다.

1.3 스트림 처리(준실시간 시스템)

  • 온라인과 오프라인 사이 어딘가에 있기 때문에 준실시간 처리이다.
  • 일괄 처리 시스템처럼 요청에 대해 응답하지 않으며, 입력 데이터로부터 출력 데이터를 만들어낸다.
  • 일괄 처리 시스템과 다른 점은 입력 데이터의 크기가 정해지지 않은 시점, 즉 입력 이벤트 하나가 발생하자마자 바로 작동하므로 일괄 처리보다는 지연 시간이 낮다.

2. 맵리듀스와 분산 파일 시스템

  • 수천 대의 장비로 분산해서 실행이 가능하다.
  • 입력을 수정하기 않기 때문에 출력을 생산하는 것 외에 사이드 이펙트가 없다.
  • 출력은 한 번만 쓰여지고 이후 수정되지 않는다.

2.1 맵리듀스 작업 실행하기

  • 맵 리듀스 : 분산 파일 시스템 위에서 대용량 데이터셋을 처리하는 코드 작성 프로그래밍 프레임워크
  • 유닉스 도구로의 단순 분석과 유사한 데이터 처리 패턴
    • 입력파일을 레코드로 쪼갠다 (separator = \n)
    • 각 레코드마다 매퍼 함수를 호출해 키와 값 추출
    • 키 기준으로 키-값 쌍 모두 정렬
    • 정렬된 키-값 쌍 전체 대상으로 리듀스 함수 호출 (같은 키값은 서로 인접 -> 쉽게 결합)
  • 2 가지 콜백 함수 구현 필요
    • 매퍼 (Mapper) : 입력 레코드로부터 키와 값을 추출하는 작업을 한다.
      • 모든 입력 레코드마다 독립적으로 한 번씩만 호출
    • 리듀서 (Reduccer) : 정렬된 데이터 가공해 출력 레코드를 생성한다.
      • 맵리듀스 프레임워크는 같은 키를 모으고 해당 값의 집합을 반복해 리듀서 함수 호출

2.1.1 맵리듀스 워크플로 (workflow)

  • 하나의 맵리듀스 출력을 다른 맵리듀스의 입력으로 연결 (파일 경로를 통한 암묵적 방식)
  • 일괄 처리 작업의 출력은 성공했을 때만 유효 (실패시 남은 출력 제거)

2.2 리듀스 사이드 조인과 그룹화

  • 사용자 활동 이벤트 분석 예제
    • 사용자가 웹사이트에서 활동한 이벤트 로그 분석
    • 원격 데이터베이스에 직접 질의한다는 건 너무 느리고 일괄 처리가 비결정적(원격 테이터가 변할 수 있음)이라는 뜻
    • 데이터베이스의 사본을 추출해 분산 파일 시스템에 넣어 효율적으로 처리한다.

2.2.1 정렬 병합 조인 (SMB, Sort-Merge Join)

  • 매퍼 출력이 키로 정렬된 후 (sort) 리듀서가 조인의 양측에 정렬된 레코드 목록 병합 (merge)
  • 특정 id의 모든 레코드를 한번에 처리. 한번에 한 id의 레코드만 메모리에 유지. 네트워크 x
  • 리듀서가 작업 레코드 재배열하는 보조 정렬 secondary sort)을 하기도 함

2.2.2 같은 곳으로 연관된 데이터 가져오기

  • 같은 키 (주소) 를 가진 키-값 쌍은 모두 같은 리듀서 호출
  • 맵리듀스는 데이터 모으는 연산 (물리적 네트워크 통신) 과 처리하는 로직 (애플리케이션 로직) 분리
  • 맵리듀스는 모든 네트워크 통신을 직접 관리하기 때문에 네트워크 실패가 발생해도 애플리케이션 코드에서는 고민할 필요가 없다.

2.2.3 그룹화

  • SQL GROUP BY
  • 맵리듀스로 그룹화 구현 => 키-값 생성 시 그룹화할 대상을 키로 설정

2.2.4 쏠림(skew) 다루기

  • 불균형한 활성 데이터베이스 레코드 = 린치핀 객체 (linchpin object) = 핫 키 (hot key)
  • 한 리듀서에 많은 레코드가 쏠리는 현상 = 핫스팟
  • 맵 리듀서는 모든 매퍼, 리듀서가 끝나야하므로 지연시간 ↑
  • 이를 완화하기 위한 여러 핫스팟 완화 알고리즘이 있음
    • Pig의 쏠린 조인(skewed join)
    • Crunch의 공유 조인(shared join)
    • Hive의 맵 사이드 조인 (map-side-join)

2.3 맵 사이드 조인

맵 사이드 조인 (Map-Side Join)

  • 입력 데이터에 대한 특정 가정이 가능할 경우
  • 축소된 맵리듀스 작업 (리듀서 x 정렬 x)

2.3.1 브로드캐스트 해시 조인 (Broadcast Hash Join)

  • 전체 데이터 셋을 전부 메모리에 올릴 수 있을 정도로 작은 데이터 셋과 큰 데이터 셋을 조인
  • 큰 입력 파티션 하나를 처리하는 각 매퍼는 작은 입력 전체를 읽고 (broadcast), 작은 데이터셋은 각 파티션의 해시 테이블에 적재 (hash)

2.3.2 파티션 해시 조인 (Partitioned Hash Join)

  • 두 입력 모두를 같은 키, 같은 해시 함수, 같은 수로 파티셔닝하여 조인
  • 각 매퍼는 각 입력 데이터셋 중 파티션 하나만 읽어도 충분
  • 각 맵퍼 해시 테이블에 적재해야 할 데이터의 양 ↓
  •  

3. 일괄 처리 워크플로의 출력

3.1 일괄 처리의 목적

  • 일괄 처리는 트랜잭션 처리도 분석도 아니다.
  • 분석에 가깝지만 SQL 질의도 아니고 출력은 보고서가 아닌 다른 형태 구조

3.2 일괄 처리의 사용

  • 검색 색인 구축
  • 일괄 처리의 출력으로 키-값을 저장
    • 일괄 처리 워크플로 출력 예 : 검색 색인, 머신러닝 시스템 (분류기), 추천 시스템 ..
    • 일괄 처리의 출력 => 일종의 데이터 베이스가 됨

3.3 일괄 처리 출력에 관한 철학

  • 인적 내결함성 (human fault tolerance) : 버그 코드로 부터 복원 가능 여부
  • 비가역성 최소화 (minimizing irreversibility)
  • 입력 불변, 실패 출력 폐기 => 실패 시 재실행 반복 가능
  • 동일 입력 파일 집합 사용
  • 연결작업과 로직의 분리

4. 맵리듀스를 넘어

  • 맵리듀스는 분산 시스템에서 가능한 여러 프로그래밍 모델 중 단지 하나
    • 데이터 양, 자료 구조, 데이터 처리 방식에 따라 다른 도구가 더 적합할 수도
    • 맵리듀스를 편하게 쓰기위해 추상화된 다양한 고수준 프로그래밍 모델 (단, 모델 자체 문제 주의)

4.1 중간 상태 구체화

  • 맵리듀스는 다른작업과 모두 독립적 (로직과 연결의 분리)
  • 중간 상태 (Intermediate state) 를 파일로 기록하는 과정 => 구체화 (materialization)
    • 장점
      • 내구성 (내결함성 확보)
    • 단점
      • 모든 선행 작업 태스크가 종료될때까지 대기 (수행시간 slow)
      • 매퍼 중복
      • 분산 파일 시스템에서 중간 상태인 임시 데이터도 여러 장비에 복제되는 과잉 조치

4.2 데이터플로 엔진 (dataflow engine)

  • 맵리듀스의 단점을 보완한 분산 일괄 처리 엔진
  • 분산 일괄 처리 연산 엔진. 전체 워크플로를 독립된 하위작업이 아닌, 작업 하나로서 다루는 엔진
  • Spark, Tez, Flink
  • vs 맵리듀스
    •  연산자 (operator) 를 통해 더 유연한 방법으로 함수 조합 가능
    • 연산자의 출력과 다른 연산자의 입력을 연결하는 여러가지 선택지 (키로 재파티셔닝 및 정렬, 정렬 스킵, 브로드캐스트 ..)
    • 수행속도 훨씬 빠름
  • 장점
    • 정렬과 같은 값비싼 작업은 실제 필요할때만 수행 -> 맵리듀스는 모든 맵과 리듀스 사이에 무조건 정렬
    • 필요없는 맵 태스크는 없다
    • 모든 조인과 데이터 의존 관계를 명시적 선언 => 지역성 최적화
    • 연산자 간 중간 상태는 로컬 디스크나 메모리에 기록해 불필요한 장비간 복제가 없음
    • 입력 준비되는 즉시 실행 가능 (선행 단계 전체 완료 대기 x)
    • 새로운 연산자 실행 시 이미 존재하는 JVM 재활용할 수 있어 각 태스크마다 새 JVM을 사용하는 맵리듀스에 비해 시작 부담이 적음
  • 데이터플로 엔진의 내결함성 (Fault tolerance)
    • 중간 상태를 사용하지않는 데이터플로 엔진의 내결함성 확보 접근법 => 재계산
    • 데이터 재연산의 포인트는 “해당 연산이 결정적인지 파악” 하는 것
      • 연산자가 비결정적일 경우 신규 데이터를 기준으로 다시 수행하는 것이 일반적
  •  

 

 

 

 

 

 

728x90
반응형

댓글