본문 바로가기

Studying/Data System Design

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

  1. 데이터 처리 방식
    1. 서비스(온라인 시스템): 클라이언트가 요청이 올 때까지 기다리는 방식
    2. 일괄 처리 시스템(오프라인 시스템): 큰 입력을 받아 처리하는 방식으로 사용자가 대기 하지 않고 주기적으로 실행됨
    3. 스트림 처리 시스템(준실시간 시스템): 온라인과 오프라인 사이로 요청에 대해 응답이 아닌 입력 데이터를 소비하여 출력 데이터 생산
  2. 유닉스 도구 일괄 처리
    1. 일반적인 프로그래밍 언어에선 메모리에 데이터를 올리고 작업을 하지만, 메모리 보다 큰 데이터셋을 자동으로 디스크로 보내고 자동으로 여러 CPU코어에서 병렬로 정렬한다. (메모리 부족 없이 큰 데이터셋을 처리 가능)
    2. 각 프로그램이 하나의 일만 하게 한다.
    3. 모든 출력이 다른 프로그램의 입력이 되게 한다.
  3. 맵리듀스와 분산 파일 시스템
    1. 맵리듀스: 맵퍼 + 리듀서
    2. 조인
      1. 리듀스 사이드 조인과 그룹화
        1. 정렬 병합 조인: 리듀서에 특정 키의 데이터가 같이 들어가고 보조 정렬(작업 레코드를 재배열)한 뒤, 병합한다.
        2. 그룹화: 매퍼가 그룹화하려는 대상을 키를 지정한다.
        3. 쏠림 다루기
          1. 핫 키를 여러 리듀서에 퍼뜨리기
          2. 핫 키를 나머지 키와 별로 파일에 저장하여 처리 (하이브)
      2. 맵 사이드 조인
        1. 브로드 캐스트 해시 조인: 작은 데이터셋을 전체 매퍼가 읽을 수 있도록 저장하여 처리하는 방식
        2. 파티션 해시 조인: 파티셔닝을 진행하여 조인할 레코드가 같은 파티션에 위치시키는 방식
        3. 맵 사이드 병합 조인: 입력 데이터가 파티셔닝 + 정렬까지 되어 있을 경우 매퍼에서 병합 연산을 수행하는 방식
  4. 하둡과 분산 데이터베이스의 비교
    1. 저장소의 다양성
      1. 하둡: 어떤 형태라도 저장할 수 있게 한다
      2. MPP: 작업하기 형식의 데이터
    2. 처리 모델의 다양성
      1. 하둡: 엔지니어가 작성한 코드 기반이고 원한다면 SQL 실행 엔진을 구축하여 SQL도 사용 가능하다. 맵리듀스의 경우 어떤 형태의 경우 성능이 나쁜 등 한계가 있지만, 다른 모델들을 가져와서 해결이 가능하다.
      2. MPP: 일체식(monolithic) 구조로 여러 소프트웨어가 긴밀하게 통합되어 있어 성능이 좋고, SQL을 사용하여 편리하다. 하지만 SQL로 모든 걸 표현하기 어렵다.
    3. 빈번하게 발생하는 결함을 줄이는 설계
      1. 하둡: 실패를 견디는 데 초점을 맞췄다. 일부 장비가 죽어도 큰 문제가 없이 진행 가능하고, 디스크에 저장을 하여 중간 재시작에 용이하다. 대용량 처리에 적합하다.
      2. MPP: 한 장비만 죽어도 전체 질의가 중단된다. 일반적으로 금방 끝나는 질의를 하므로 재시도의 비용이 크지 않아 수용가능하다. 메모리에 많은 데이터를 유지하는 것을 선호한다.