데이터 중심 애플리케이션 설계 10장

[epicblues]

데이터 저장 시스템 유형

레코드 시스템

• 믿을 수 있는 데이터 버전 저장
  • source of truth
• 정규화
• 가장 먼저 저장되는 데이터

파생 데이터 시스템

• 다른 시스템에서 받은 데이터를 새로운 형식으로 가공
• 복제
  • 비정규화로 생성
• 읽기 성능 향상
• 동일한 데이터에 대한 여러 관점을 제공

유닉스 철학

동일 인터페이스 ⇒ 파일

• 정렬된 바이트의 연속
• 각 소프트웨어는 입출력 형식을 신경쓰지 않음
  • 소켓
  • 파일
  • 키보드
  • 다른 프로그램의 출력
• 대부분 ASCII 문자열로 읽음
  • \n 구분자

파이프라인

• 한 프로그램의 출력을 임시 버퍼에 담아서 다음 프로그램의 입력으로 활용
  • 인메모리 버퍼
• 프로그램에 새로운 로직이 필요할 경우 기존 프로그램을 고치지 않고 새로 프로그램을 짜서 파이프라인으로 연결

빠른 실험 용이

• 입력 파일의 불변성 → 부담 없이 테스트
• 파이프라인 중간에 결과를 테스트할 수 있음
  • 어떤 ‘작은’ 프로그램에서 잘못되었는지 확인 가능
• 테스트용으로 출력을 별도의 파일로 저장해서 결과 확인 가능

MapReduce

• 유닉스 철학 반영
• 분산 파일 시스템
  • 유닉스 명령어 파이프라인과의 근본적인 차이
  • HDFS
    • 비공유 디스크 방식
      • 별도의 하드웨어 필요 없음, 네트워크 연결만 있으면 된다
    • 중앙서버에서 각 장비의 파일 저장 상태 추적
• 과정
  • 파싱
    • 파일 → 레코드 변환
  • Map
    • 레코드 당 1회 호출
    • 입력되는 레코드를 key value 로 추출
  • 정렬
    • 사용자가 작성 X
    • 리듀스로 들어가기 전의 매퍼의 출력을 정렬
  • Reduce
    • 동일한 key를 가진 value 값의 집합을 입력으로 받음
      • iterator를 통해 값 순회
      • 예시
        • 동일한 key를 가진 record 개수 집계
    • 부분 정렬
      • Reducer 연산을 시작하기 전에 레코드를 특정 기준으로 미리 정렬 가능
        • 시간 기반 등
• 분산 실행
  • 파티셔닝 기반
    • 각 파일을 독립된 파티션으로 간주
    • 최대한 입력 파일이 있는 장비에서 작업 수행
      • 파일 복사 / 네트워크 비용 최소화
  • 태스크 수
    • 맵 태스크 수 = 입력 파일 블록 수
    • 리듀스 태스크 수 = 사용자 정의
      • 같은 key-value ⇒ 같은 리듀서에서 처리 보장(해시값)
  • 과정
    • 매퍼의 출력을 리듀서 별 파티셔닝
    • 리듀서는 자신에게 할당된 매퍼의 출력 파티션들의 파일들을 다운로드
    • 다운로드된 파일들을 merge-sort
• 워크플로
  • 맵 리듀스의 작업들을 연결
    • = 유닉스 파이프라인
  • 디렉터리를 통한 연결
    • 워크플로 1의 출력 디렉터리 = 워크플로 2의 입력 디렉터리
  • 중간의 실패한 작업의 부분 출력은 제거된다
• Join
  • OLTP ⇒ 테이블의 일부 데이터만 join해서 검색
    • 색인을 사용하는 이유
  • OLAP ⇒ 기본적으로 모든 데이터를 다룸 → full scan
    • 색인이 필요 없음
    • 분산 시스템은 OLAP에 더 가까움
  • 종류
    • 리듀스 사이드 조인
      • 정렬 병합 조인
        • 매퍼의 출력 레코드들을 key 값을 기반으로 리듀서에서 정렬 / 병합
        • ID 별 리듀서 1회 호출
        • 그릅화에 유용
        • 핫스팟 문제
          • 해당 키를 가진 레코드가 너무 많아서 하나의 리듀서로 처리 못함
          • skewed join
            • 핫 키 탐색
            • 핫 키를 가진 레코드들은 정렬 없이 무작위 파티션으로 저장
            • 조인할 레코드를 핫 키를 가진 모든 리듀서에 전송
            • 핫 키에 대한 처리를 여러 리듀서에서 담당
    • 맵 사이드 조인
      • 브로드캐스트 해시 조인
        • 작은 데이터셋 전체를 메모리에 해시 테이블로 적재
        • 큰 데이터셋 레코드를 읽으면서 작은 데이터셋과 조인 작업 수행
      • 파티션 해시 조인
        • 조인할 레코드들은 파티셔닝
        • 각 파티션에서 조인 작업 수행
      • 맵 사이드 병합 조인
        • 입력 데이터의 파티셔닝/정렬 완료 가정
        • 양쪽 입력을 병합
  • 출력으로 무엇을 하는가?
    • 검색 인덱스 구축
    • 또 하나의 데이터베이스로 사용
      • key-value DB

맵리듀스 VS MPP(대규모 병렬 처리) DB

• 로직을 수행하는 수단에 제약을 받지 않음
  • 프로그래밍 언어
  • 프로그램
  • 입력 형식
    • 텍스트, 이미지, 벡터…
• 빠른 데이터 수집 >>>>> 정교한 데이터 모델링
  • 데이터 모델링 / 해석 책임을 데이터 사용자에게 위임
    • = schema-on-read
• 제약 없는 데이터 처리 방식
  • SQL 만으로 처리하지 못하는 다양한 데이터들
    • 애플리케이션 코드로 처리할 수 있음
• 결함 방지
  • 작업 성공/실패 유무가 다른 작업에 영향을 미치지 않음
  • 선점형 아키텍처에서 유용
    • 우선순위 낮은 작업은 언제든지 취소될 수 있음

데이터플로

💡 여러 작업들을 하나로 통합

• 별도의 맵과 리듀스 존재 X
  • 각 중간 결과값이 파일로 저장되지 않고, 유닉스 처럼 중간 처리 과정을 거침
  • 작업이 끝나지 않고 다음 작업을 호출할 수 있음
  • 파일 정렬이 필요 하지 않음
  • 중간 결과를 메모리-로컬 디스크에 저장
    • 분산 파일 시스템에 저장하는 부담 X
• 맵리듀스보다 내결함성 떨어짐
  • 각 연산들의 결합이 높음(동시에 실행되고 있음)
  • 중간 파일을 저장하기가 애매함

그래프와 반복 처리

맵리듀스는 항상 입력 전체를 처리하기 때문에 반복 수행이 비효율적

프리글 처리 모델

• 정점
  • 간선으로 받은 “메시지” 처리
  • 연산
  • 다른 간선으로 메시지 호출
• 각 정점은 처리한 메시지를 기억 → 새로운 메시지만 처리
• 추상화된 정점 전송
  • 프레임워크에서 결정
    • 네트워크
      • 빈번한 네트워크 호출로 인한 성능 저하
    • 동일 노드