개발일기장

Part3. 10장 일괄처리 본문

책 정리/데이터 중심 애플리케이션 설계

Part3. 10장 일괄처리

게슬 2021. 10. 11. 16:03
728x90

큰 애플리케이션에서는 데이터를 접근하고 처리하는 데 다양한 방법이 필요하다 하지만 동시에 다른 모든 요구사항을 만족하는 하나의 데이터베이스는 없다. 대게 여러 다른 데이터스토어, 색인, 캐시, 분석 시스템 등 몇 가지를 조합해서 사용하고 한 저장소에서 다른 저장소로 데이터를 이동하는 메커니즘을 구현한다. 복잡한 시스템에서 수행해야 하는 가장 중요한 일이 서로 다른 시스템을 통합하는 작업이다.

레코드 시스템

믿을 수 없는 데이터 버전을 저장한다. 레코드 시스템은 진실의 근원이라고도 하는데 예를 들어 사용자의 입력과 같은 새로운 데이터가 들어오면 먼저 레코드 시스템에 저장된다. 각 사실은 일반적으로 정규화를 거쳐 정확하게 한번 표현된다. 레코드 시스템과 다른 시스템 간에 차이가 난다면 정의에 따라 레코드 시스템이 옳다.

파생 데이터 시스템

파생 데이터 시스템에서는 데이터는 다른 시스템에 존재하는 데이터를 가져와 특정 방식으로 변환하고 처리한 결과다. 파생 데이터를 잃게 되더라도 원천 데이터로부터 다시 생성할 수 있다. 대표적인 예가 캐시인데 필요한 데이터가 캐시에 있다면 제공하고, 그렇지 않다면 기반 데이터베이스를 거쳐 제공할 수 있다. 비정규화 값, 색인, 구체화 뷰 등이 있다.

파생 데이터는 기존 데이터를 복제한다는 의미에서 중복(redundant)이다. 하지만 읽기 질의 성능을 높이는 데 종종 필수적이다. 비정규화 과정을 통해 생성한다. 단일 원천 데이터로 여러 데이터셋을 추출해 각 데이터셋마다 서로 다른 관점에서 데이터를 본다.

 

온라인 시스템은 웹 브라우저가 특정 페이지를 요청하든 서비스가 원격 API를 호출하든 일반적으로 사람이 사용자로서 요청을 보내고 응답을 기다린다고 가정한다. 사용자는 오래 기다릴 수 없기 때문에 이런 시스템에서는 응답 시간 단축에 노력을 많이 기울인다.

1. 서비스(온라인 시스템) : 서비스는 클라이언트로부터 요청이나 지시가 올 때까지 기다린다. 요청이 들어오면 서비스는 가능한 빨리 요청을 처리해서 응답을 되돌려 보내려 한다. 응답 시간은 서비스 성능을 측정할 때 중요한 지표다.

2. 일괄 처리 시스템(오프라인 시스템) : 일괄 처리 시스템은 매우 큰 입력 데이터를 받아 데이터를 처리하는 작업을 수행하고 결과 데이터를 생산한다. 일괄 처리 작업의 주요 성능 지표로는 처리량이 대표적이다. 입력 데이터 중 특정 크기만큼 처리할 때 걸리는 시간으로 나타낸다.

3. 스트림 처리 시스템(준 실시간 시스템) : 준 실시간 처리라 불린다. 일괄 처리 작업은 정해진 크기의 입력 데이터를 대상으로 작동하지만 스트림 처리는 입력 이벤트가 발생한 직후 바로 작동한다.

맵리듀스는 이전에 데이터 웨어하우스용으로 개발했던 병렬 처리 시스템보다 상당히 저수준 프로그래밍 모델이다 그러나 범용 하드웨어만들 사용해 처리한 데이터 규모 면에서 상당히 진보했다.

일괄 처리는 컴퓨터 연산에 있어 매우 오래된 형태다.

 

정렬 대 인메모리 집계

중소 규모의 웹사이트 대부분은 고유 URL과 해당 URL 카운트를 대략 1GB 메모리에 담을 수 있다. 백만 개의 로그 항목이 모두 같은 URL 하나만을 가리킨다면 해시 테이블에 필요한 공간은 한 개의 URL과 그 카운트 값을 저장할 만큼만 필요하다.

반면 허용 메모리보다 작업 세트가 크다면 정렬 접근법을 사용하는 것이 좋다. 디스크를 효율적으로 사용하는데 먼저 데이터 청크를 메모리에서 정렬하고 청크를 세그먼트 파일로 디스크에 저장한다. 그 다음 각각 정렬된 세그먼트 파일 여러 개를 한 개의 큰 정렬 파일로 병합한다.

 

유닉스 철학

유닉스 파이프는 다른 방법으로 데이터 처리가 필요할 때 정원 호스와 같이 여러 다른 프로그램을 연결하는 방법이 필요하다.”

1. 각 프로그램이 한 가지 일만 하도록 작성하라. 새 작업을 하려면 기존 프로그램을 고쳐 새로운 기능을 추가해 프로그램을 복잡하게 만들기보다는 새로운 프로그램을 작성하라.

2. 모든 프로그램의 출력은 아직 알려지지 않은 다른 프로그램의 입력으로 쓰일 수 있다고 생각하라. 출력이 너저분해서는 안 된다.

3. 소프트웨어를 빠르게 써볼 수 있게 설계하고 구축하라. 거슬리는 부분은 과감히 버리고 새로 구축하다.

4. 프로그래밍 작업을 줄이려면 미숙한 도움보단 도구를 사용하라.

자동화, 빠른 프로토 타이핑, 증분 반복, 실험 친화, 큰 프로젝트를 청크로 나누어 처리하기와 같은 방법은 오늘날의 애자일 및 DevOps 운동과 매우 흡사하다.

동일 인터페이스

어떤 프로그램의 출력을 다른 프로그램의 입력으로 쓰고자 한다면 이들 프로그램은 같은 데이터 형식을 사용해야 한다. 특정 프로그램이 다른 어떤 프로그램과도 연결 가능 하려면 프로그램 모두가 같은 입출력 인터페이스를 사용해야 한다는 의미.

유닉스에서 인터페이스는 파일이다. 파일은 단지 순서대로 정렬된 바이트의 연속이다. 이처럼 단순해서 같은 인터페이스로 파일시스템의 실제 파일, 프로세스 간의 통신 채널, 장치 드라이버, TCP 연결을 나타내는 소켓 등 다른 여러 가지 것을 표현할 수 있다.

각 레코드를 파싱하는 건 애매하다. 유닉스 도구는 대개 한 줄을 공백이나 탭 문자로 분리해 필드로 만든다. 하지만 CSV나 파이프 문자 등의 다른 부호화 방법도 사용한다. 동일한 데이터 모델인 데이터베이스 간에도 한쪽에서 다른 쪽으로 데이터를 옮기는 게 쉽지 않다. 데이터가 발칸화되는 이유는 유닉스 도구와 같은 통합이 부족했기 때문이다.

 

로직과 연결의 분리

유닉스 도구의 다른 특징으로 표준 입력과 표준 출력을 사용한다는 점이다. 파이프는 한 프로세스의 표준출력을 다른 프로세스의 표준입력과 연결한다. 이때 중간 데이터를 디스크에 쓰지 않고 작은 인메모리 버퍼를 사용해 프로세스 간 데이터를 전송한다. 프로그램은 입력이 어디서부터 들어오는지 출력이 어디로 나가는지 신경 쓰거나 알 필요조차 없다.(느슨한 결합, 지연 바인딩, 제어 반전) 프로그램에서 입출력을 연결하는 부분을 분리하면 작은 도구로부터 큰 시스템을 구성하기가 훨씬 수월하다.

그러나 표준출력, 입력을 사용할 때 몇 가지 제약사항이 있다. 여러 개의 입력을 받거나 여러 개의 출력이 필요할 때는 불가능하지는 않지만 까다롭다. 출력을 네트워크와 연결하지는 못한다.

 

투명성과 실험

유닉스는 진행 사항을 파악하기가 상당히 쉽다.

1. 명령에 들어가는 입력 파일은 일반적으로 불변으로 처리된다.

2. 어느 시점이든 파이프라인을 중단하고 출력을 파이프를 통해 less로 보내 원하는 형태의 출력이 나오는지 확인할 수 있다.

3. 특정 파이프라인 단계의 출력을 파일에 쓰고 그 파일을 다음 단계의 입력으로 사용할 수 있다.

가장 큰 제약은 단일 장비에서만 실행된다는 점이다. 이 점이 하둡 같은 도구가 필요한 이유다.

 

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

맵리듀스는 유닉스 도구와 비슷한 면이 있지만 수천 대의 장비로 분산해서 실행이 가능하다는 점이서 차이가 있다. 맵리듀스 작업은 입력을 수정하지 않기 때문에 출력을 생산하는 것 외에 다른 부수 효과는 없다.

맵리듀스 작업은 분산 파일 시스템상의 파일을 입력과 출력으로 사용한다. 하둡 맵리듀스 구현에서 이 파일 시스템은 HDFS(Hadoop Distribute File System)이라고 한다.

HDFS 외에도 GlusterFS, QFS등 다양한 분산 파일 시스템이 있다. 아마존 S3, 애저 Blob 저장소, 오픈스택 스위프트 같은 객체 저장소도 여러 면에서 유사하다.

HDFS는 비공유원칙을 기반으로 하는데 NASSAN 아키텍처에서 사용하는 공유 디스크 방식과는 반대다. 공유 디스크 저장소는 중앙 집중 저장 장치를 사용하는 데 맞춤형 하드웨어를 사용하거나 파이버 채널과 같은 특별한 네트워크 인프라를 사용하기도 한다. 반면 비공유 방식은 특별한 하드웨어가 필요 없고, 일반적인 네트워크에 연결된 컴퓨터면 충분하다.

각 장비에서 실행되는 데몬 프로세스로 구성된다. 다른 노드가 해당 장비에 저장된 파일에 접근 가능하게끔 네트워크 서비스를 제공한다. 네임노드(NameNode)라고 부르는 중앙 서버는 특정 파일 블록이 어떤 장비에 저장됐는지 추적한다. 따라서 HDFS는 개념적으로는 매우 큰 하나의 파일 시스템이고 데몬이 실행 중인 모든 장비의 디스크를 사용할 수 있다. 장비가 죽거나 디스크가 실패하는 경우에 대비하기 위해 파일 블록은 여러 장비에 복제된다. RAID와 유사하다.

HDFS는 확장성이 뛰어나다. 이를 이용한 데이터 저장과 접근 비용은 범용 하드웨어와 오픈소스 소프트웨어를 사용하기 때문에 동급 용량의 전용 저장소 장치를 사용하는 비용보다 훨씬 저렴하다. 그렇기 때문에 이런 대규모 확장이 실제로 가능하다.

 

맵리듀스 작업 실행하기

맵리듀스는 HDFS같은 분산 파일 시스템 위에서 대용량 데이터셋을 처리하는 코드를 작성하는 프로그래밍 프레임워크.

1. 입력 파일을 읽는다. 레코드로 쪼갠다.

2. 각 입력 레코드마다 매퍼 함수를 호출해 키와 값을 추출한다.

3. 키를 기준으로 키-값 쌍을 모두 정렬한다.

4. 정렬된 키-값 쌍 전체를 대상으로 리듀스 함수를 호출한다.

2단계와 4단계는 사용자가 직접 작성한 데이터 처리 코드다.  맵리듀스 작업을 생성하려면 다음과 같이 동작하는 매퍼와 리듀서라는 두 가지 콜백 함수를 구현해야 한다.

매퍼(Mapper)

모든 입력 레코드마다 한 번씩만 호출된다. 입력 레코드로부터 키와 값을 추출하는 작업이다. 각 입력으로 부터 생성하는 키-값 쌍은 빈 쌍을 포함해 원하는 만큼 생성 가능하다. 다음 레코드까지 상태를 유지하지 않기 때문에 각 레코드를 독립적으로 처리한다.

리듀서(Reducer)

매퍼가 생산한 키-값 쌍을 받아 같은 키를 가진 레코드를 모으고 해당 값의 집합을 반복해 리듀서 함수를 호출한다. 리듀서는 출력 레코드를 생산한다.

 

맵리듀스의 분산 실행

맵리듀스가 병렬로 수행하는 코드를 직접 작성하지 않고도 여러 장비에서 동시에 처리가 가능하다. 매퍼와 리듀서는 한 번에 하나의 레코드만 처리하고 입력이 어디서 오는지 출력이 어디로 가는지 신경 쓰지 않는다. 맵리듀스 프레임워크가 장비 간에 데이터가 이동하는 복잡한 부분을 처리하기 때문이다.

병렬 실행은 파티셔닝을 기반으로 한다. 작업 입력으로 HDFS상의 디렉토리를 사용하는 것이 일반적이고, 각 파일 또는 파일 블록을 독립된 맵 태스크에서 처리할 독립 파티션으로 간주한다.

매퍼가 입력 파일을 읽어서 정렬된 출력파일을 기록하기를 완료하면 맵리듀스 스케줄러는 매퍼에서 출력 파일을 가져올 수 있다고 리듀서에게 알려준다. 리듀서는 각 매퍼와 연결해서 리듀서가 담당하는 파티션에 해당하는 정렬된 키-값 쌍 파일을 다운로드 한다. 리듀서를 기준으로 파티셔닝 하고 정렬한 뒤 매퍼로부터 데이터 파티션을 복사하는 과정을 셔플이라 한다.

리듀스 태스크는 매퍼로부터 파일을 가져와 정렬된 순서를 유지하면서 병합한다. 병합된 이후 리듀서의 입력으로 들어갈 때는 서로 인접하게 된다.

리듀서는 키와 반복자를 인자로 호출하는데 이 반복자로 전달된 키와 동일한 키를 가진 레코드를 모두 훑을 수 있다.리듀서는 임의의 로직을 사용해서 이 레코드들을 처리하고 여러 출력 레코드를 생성할 수 있다. 이 출력 레코드는 분산 파일 시스템에 파일로 기록된다.

맵리듀스 워크플로

맵리듀스 작업 하나로 해결할 수 있는 문제의 범위는 제한적이다 따라서 맵리듀스 작업을 연결해 워크플로로 구성하는 방식은 꽤 일반적이다. 맵리듀스 작업 하나의 출력을 다른 맵리듀스 작업의 입력으로 사용하는 식이다. 프레임워크가 직접 지공하지 않기 때문에 첫 번째 작업은 HDFS상에 지정된 디렉토리에 출력하도록 설정하고 두 번째 작업은 해당 디렉토리를 입력으로 사용하도록 설정해야 한다. 두 작업은 완전히 독립적이다.

 

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

여러 데이터셋에서 한 레코드가 다른 레코드와 연관이 있는 것은 일반적이다. 관계형 모델에서는 외래키, 문서 모델에서는 문서 참조라 하고 그래프 모델에서는 간선이라 부른다. 양쪽 모두에 접근해야 하는 코드가 있다면 조인은 필수다. 비정규화 작업으로 조인을 줄일 수 있지만 일반적으로 완전히 제거하기는 어렵다.

적은 수의 레코드만 관련된 질의를 실행한다면 일반적으로 색인을 사용해 관심 있는 레코드의 위치를 빨리 찾는다. 하지만 맵리듀스에는 적어도 일반적으로 이야기하는 색인 개념이 없다. 입력 파일 전체 내용을 읽는데 데이터베이스에서 이 연산을 full table scan이라 부른다. 이때 색인을 이용하면 비용이 터무니없게 많이 든다. 대량의 레코드를 대상으로 집계연산을 하는 것이 일반적이다. 이런 경우 입력 전체를 스캔하는 건 상당이 합리적이다. 병렬 처리가 가능한 경우는 특히 그렇다.

일괄 처리에서 처리량을 높이기 위해서는 가능한 한 한 장비 내에서 연산을 수행해야 한다. 처리할 모든 레코드를 네트워크를 통해 임의 접근 요청을 하는 것은 너무 느리다. 원격 데이터베이스에 질의한다는 건 일괄 처리가 비결정적이라는 뜻이다.

데이터베이스의 사본을 가져와 분산 파일시스템에 넣는 방법이다. 그러면 사용자 데이터베이스가 같은 HDFS상에 존재하고 맵리듀스를 사용해 연관된 레코드끼리 모두 같은 장소로 모아 효율적으로 처리가 가능하다.

정렬 병합 조인

매퍼는 입력레코드로부터 키와 값을 추출하는 것이 목적이다. 맵리듀스 프레임워크에서 키로 매퍼의 출력을 파티셔닝해 키-값 쌍으로 정렬한다면 같은 사용자의 활동 이벤트와 사용자 레코드는 리듀서의 입력으로 서로 인접해서 들어간다. 매퍼 출력이 키로 정렬된 후에 리듀서가 조인의 양측을 정렬된 레코드 목록을 병합하기 때문이다.

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

맵리듀스 프로그래밍 모델은 올바른 장비로 데이터를 모으는 연산의 물리적 네트워크 통신 측면과 받은 데이터를 처리하는 애플리케이션 로직을 분리한다. 맵리듀스는 모든 네트워크 통신을 직접 관리하기 때문에 특정 장비가 죽는 것과 같이 부분적으로 실패가 발생하더라도 애플리케이션 코드 단에서 고민할 필요가 없다.

그룹화

같은 곳으로 관련 데이터를 모으는 일반적인 사용 유형은 GROUP BY절과 같이 특정 키로 레코드를 그룹화하는 것이다. 그리고 각 그룹 내에서 집계 연산을 한다.

매퍼가 키-값 쌍을 생성할 때 그룹화할 대상을 키로 하는 것이다. 파티션 및 정렬 프로세스가 같은 키를 가진 모든 레코드를 같은 리듀서로 모은다.

사용자 요청을 받는 웹 서버가 여러 개라면 특정 사용자의 활동 이벤트는 여러 서버로 분산돼 각각 다른 로그 파일에 저장된다. 세션 쿠키, 사용자 ID나 유사한 식별자를 그룹화 키로 사용해 특정 사용자 활동 이벤트를 모두 한 곳으로 모으면 세션화를 구현할 수 있다.

쏠림 다루기

불균형한 활성 데이터베이스 레코드를 린치핀 객체, 핫 키 라 한다. 상당한 쏠림 현상이 생긴다. 이런 현상을 핫스팟이라 한다. 즉 한 리듀서가 다른 리듀서보다 엄청나게 많은 레코드를 처리해야 한다는 뜻이다.

핫 키를 여러 리듀서에 퍼뜨려서 처리하게 하는 방법이다. 다른 조인 입력을 여러 리듀서로 복제하는 비용이 들지만 병렬화 효과가 훨씬 크다. 공유 조인(shared join)메서드가 이 기법과 비슷하다. 파티셔닝 된 데이터베이스에서 핫스팟을 경감시키기 위해 랜덤화를 사용하는 기법과도 비슷하다.

 

하둡과 분산 데이터베이스의 비교

HDFS는 파일 시스템이고 맵리듀스는 특별한 방식으로 구현된 유닉스 프로세스다.  처리 알고리즘과 병렬 조인 알고리즘은 대규모 병렬처리(MPP) 데이터베이스라 불리는 것에서 구현됐다.

맵리듀스와 가장 큰 차이점을 보면 MPP 데이터베이스는 장비 클러스터에서 분석 SQL 질의를 병렬로 수행하는 것에 초점을 두지만 맵리듀스와 분산 파일 시스템의 조합은 아무 프로그램이나 실행할 수 있는 운영체제와 비슷한 속성을 제공한다.

저장소의 다양성

데이터베이스는 특정 모델을 따라 데이터를 구조화해야 한다. 반면 분산 파일시스템의 파일은 어떤 데이터 모델과 인코딩을 사용해서도 기록할 수 있는 연속된 바이트일 뿐이다. MPP 데이터 베이스가 요구하는 세심한 스키마 설계는 중앙집중식 데이터 수집을 느리게 만든다. 원시 데이터를 수집하고 스키마 설계는 나중에 고민하면 데이터 수집의 속도가 올라간다.

하둡은 트랜잭션 처리 시스템에서 데이터를 원시 형태로 분산 파일 시스템에 덤프한다. 그 다음 맵 리듀스 작업은 데이터를 정리하고 관계형으로 변환한 후 데이터 분석을 위해 MPP 데이터 웨어하우스로 옮긴다. 모델링도 하지만 수집과는 분리된 단계다. 이런 디커플링은 분산 파일 시스템이 어떤 형식으로 부호화된 데이터든지 지원하기 때문에 가능하다.

 

처리 모델의 다양성

MPP 데이터베이스는 일체식 구조로서 디스크 저장소 레이아웃과 질의 계획, 스케줄링과 실행을 다루는 소프트웨어 조각들이 긴밀하게 통합된다. 전체 시스템은 설계된 질의 유형에 대해서 매우 좋은 성능을 얻을 수 있다. 반면 SQL질의로 모든 종류의 처리를 표현하지는 못한다.

맵리듀스를 이용하면 엔지니어는 자신이 작성한 코드를 대용량 데이터셋 상에서 쉽게 실행할 수 있다. HDFS와 맵리듀스가 있으면 그 위에 SQL 질의 실행 엔진을 구축할 수 있는데 하이브 프로젝트가 그런 역할을 한다.

맵리듀스와 MPP데이터 베이스를 비교할 때 설계 방식에서 큰 차이점 두 가지가 두드러진다. 결함을 다루는 방식과 메모리 및 디스크를 사용하는 방식이다. 일괄 처리는 온라인 시스템에 비해 결함에 덜 민감하다. 실패하더라도 즉시 사용자에게 영향을 주지 않으면서 언제든지 다시 실행할 수 있기 때문이다.

맵리듀스는 태스크 종료가 예상치 못하게 자주 발생하더라도 견딜 수 있게 설계됐다. 즉 하드웨어를 신뢰할 수 없기 때문이 아니라 프로세스를 임의로 종료할 수 있으면 연산 클러스터에서 자원 활용도를 높일 수 있기 때문이다.

 

맵리듀스를 넘어

모든 맵리듀스 작업은 다른 작업과 모두 독립적이다. 작업이 외부 세계와 만나는 주요 접점은 분산 파일 시스템 상의 입력과 출력 디렉토리다. 첫 번째 작업의 출력을 두 번째 작업의 작업의 입력으로 사용하려면 같게 설정해야 한다. 그리고 외부 워크플로 스케줄러에서 반드시 첫 번째 작업을 완료한 후에 두 번째 작업을 수행해야 한다.’분산 파일 시스템 상에 있는 파일들은 단순히 한 작업에서 다른 작업으로 데이터를 옮기는 수단, 중간 상태다. 파일로 기록하는 과정을 구체화(materialization)라 한다.

중간 상태를 완전히 구체화하는 맵리듀스 접근법은 유닉스 파이프에 비해 여러 단점이 있다.

1. 입력을 생성하는 모든 선행 작업이 완료됐을 때만 시작 가능하다.

2. 매퍼는 종종 중복되기도 한다.

3. 분산 파일 시스템에서 중간 상태를 저장하는 것은 중간 상태 파일들이 여러 장비에 걸쳐 복제됐다는 의미다.

데이터 플로 엔진

여러 처리 단계를 통해 데이터 흐름을 명시적으로 모델링 한다. 단일 스레드에서 사용자 정의 함수를 반복 호출해 한 번에 레코드 한 개씩 처리한다. 입력을 파티셔닝해 병렬화 한다. 한 함수의 출력을 다른 함수의 입력으로 사용하기 위해 네트워크를 통해 복사한다.

맵리듀스와 달리 이 함수들은 맵과 리듀스를 번갈아 수행하는 식의 규칙을 지킬 필요가 없고 더 유연한 방법으로 함수들을 조합할 수 있다. (: 데이터 추출해서 분배한다. 리듀스 : 출력물 계산)

내결함성

맵리듀스는 중간 상태를 모두 구체화(파일변환)하기 때문에 쉽게 내결함성을 확보한다. 태스크가 실패하더라도 다른 장비에서 재실행할 수 있고 파일 시스템으로부터 동일한 입력을 다시 읽을 수 있다.

데이터를 재연산할 때 중요한 점은 해당 연산이 결정적인지 아닌지 파악하는 것이다. 이미 다운스트림으로 보낸 데이터 중 일부를 잃었다면 이 질문은 매우 중요하다.

이처럼 전파되는 결함을 피하려면 연산자를 결정적으로 만드는 것이 좋다. 해시 테이블이나 확률 통계 알고리즘은 임의로 특정 순서를 보장하지 않는다. 고정된 시드를 사용해 의사 난수를 생성하는 방법이 있다.

정렬이 필요한 연산자는 적어도 일시적이라도 상태를 누적할 필요가 있다. 그러나 워크플로의 여러 다른 부분은 파이프라인 방식으로 실행이 가능하다.

 

정리

입력은 불변이고 출력은 (아직 알지 못하는)다른 프로그램의 입력으로 사용한다. 그리고 복잡한 문제도 한 가지 일을 잘하는작은 도구를 엮어서 해결한다. 프로그램과 다른 프로그램을 연결하는 단일 인터페이스는 파일과 파이프. 맵리듀스의 인터페이스는 분산 파일 시스템이다. 데이터플로 엔진은 파이프와 비슷한 자체 데이터 전송 메커니즘을 사용해 분산 파일 시스템에 중간 상태를 구체화하는 것을 피한다.

 

분산 일괄 처리 프레임워크가 해결해야 할 두 가지 중요한 문제

1. 파티셔닝 : 맵리듀스에서 매퍼는 입력 파일 블록에 따라 파티셔닝 된다. 매퍼의 출력은 재파티셔닝해 정렬하고 리듀서 파티션으로 병합한다.

2. 내결함성 :맵리듀스는 빈번히 디스크에 기록한다. 개별 태스크가 실패하더라도 전체 작업을 재수행하지 않고 쉽게 복구할 수 있다. 느려진다. 데이터플로 엔진은 중간 상태를 구체화하지 않고 메모리에 상태를 유지한다.

 

조인 알고리즘

1. 정렬 병합 조인 : 조인 키를 추출하는 매퍼를 통과한다. 파티셔닝, 정렬, 병합 과정을 마치면 같은 키를 가지는 모든 레코드는 하나의 리듀서에서 호출된다.

2. 브로드 캐스트 해시 조인 : 조인할 입력 두 개 중 하나가 상대적으로 작다면 파티셔닝 하지 않고 해시 테이블에 모두 적재할 수 있다.

3. 파티션 해시 조인 : 조인 입력 두 개를 같은 방식으로 파티셔닝하면(같은 키와 같은 해시 함수와 같은 파티션 수를 사용) 해시 테이블 방식을 각 파티션별로 독립적으로 사용할 수 있다.

 

일괄 처리 작업의 차별화된 특징은 입력을 수정하지 않고 입력을 읽고 출력을 생산한다는 점이다. 출력은 입력으로 부터 파생된다. 결정적으로 입력 데이터는 고정된 크기로 한정된다. 크기가 한정되기 때문에 작업은 입력 전체를 다 읽었는지 알 수 있고 그래서 결과적으로 작업을 종료 할 수 있다.

728x90
Comments