Hello 은화!

YARN의 스케줄러 : FIFO , 캐퍼시티(가용량), 페어(균등) 스케줄러

1. FIFO

- 선입선출 스케줄러

- 장점 : 이해하기 쉽고, 설정이 필요없음

- 단점 : 공유 클러스터 환경에서는 적합하지 않음

          모든 자원 점유하면 다른 애플리케이션은 자기 차례가 올 때가지 계속 대기

2. 캐퍼시티 스케줄러

(1) 작동원리

     각 조직은 전체 클러스터의 지정된 가용량을 미리 할당받음

     각 조직은 분리된 전용 큐를 가지며 클러스터 가용량의 지정된 부분을 사용하도록 설정할 수 있음

     큐는 1단계 이상의 계층 구조로 분리할 수 있음 -> 다른 사용자 그룹 사이의 클러스터의 가용량 공유 가능

      (큐 내부에 있는 애플리케이션 스케줄링은 FIFO방식)

(2) 큐 배치

     애플리케이션의 종류마다 큐 배치 방법은 달라진다.

     큐 지정하지 않으면 기본 큐인 default에 배치됨 

     ex) 맵리듀스는 큐 이름 지정가능 , 지정한 이름 없을 시 제출 시점에 에러 발생

3. 페어 스케줄러

기본 스케줄러는 캐퍼시티 스케줄러라서 변경해야됨

(1) 작동원리

     실행 중인 모든 애플리케이션에게 동일하게 자원 할당 

     균등공유는 큐 사이에만 적용 가능

     (아래 그림은 사용자 B가 잡2, 3을 시작한 경우)

(2) 큐 설정

큐를 계층구조 설정 가능, 균등 공유의 비율을 정할 수 있음

(3) 큐 배치

규칙 기반 시스템을 이용하여 큐배치

큐를 명시적으로 지정하지 않으면 사용자 이름의 큐를 사용(없으면 자동 생성)

모든 애플리케이션을 동일한 큐에 저장하는 단순한 큐 배치 정책도 있음

(4) 선점 

선점 : 잡의 시작 시간을 어느 정도 예측 가능하게 만들기 위한 기능

        스케줄러가 자원의 균등 공유에 위배되는 큐에서 실행되는 컨테이너를 죽일 수 있도록 허용하는 기능

        큐에 할당된 자원은 균등 공유 기준을 반드시 따라야 함

       (중단된 컨테이너는 반드시 다시 수행되어야함 -> 전체적 효율성 떨어짐)

        최소 공유 선점 타임아웃, 균등 공유 선점 타임아웃 설정 해야됨 (기본값 설정 안되어있음)

4. 지연 스케줄링

  - YARN의 모든 스케줄러는 지역성 요청을 중요시 

  - 지연 스케줄링 : 원하는 노드를 조금 더 기다려서 할당받음 (클러스터의 효율성 증가)

                         캐퍼시티, 페어 스케줄러 모두 지연 스케줄링 기능 제공

(1) 작동원리

     모든 노드 매니저는 주기적으로 리소스 매니저에 하트비트 요청을 보냄

     하트비트를 통해 노드 매니저가 정보 주고 받음 (실행 중인 컨테이너의 정보, 새로운 컨테이너위한 가용한 자원)

        -> 하트비트는 애플리케이션이 실행할 컨테이너를 얻을 수 있는 중요한 스케줄링 기회

5. 우성 자원 공평성

   - 우성자원 공평성 : 각 사용자의 우세한 자원을 확인한 후 이를 클러스터 사용량의 측정 기준으로 삼음!

맵리듀스 1 - 맵리듀스 분산 구현

맵리듀스 2 - YARN을 이용한 구현

1. 맵리듀스 1

- 두 종류의 데몬 (잡의 실행을 제어하는 하나의 잡트래커, 하나 이상의 테스크트래커)

    → 잡 트래커 : 여러 태스크트래커에서 실행되는 태스크를 스케줄링함으로써 시스템에서 실행되는 모든 잡 조율

                        태스크 실패시 잡트래커는 다른 태스크 트래커에 그 태스크를 다시 스케줄링 함

        태스크 트래커 : 태스크를 실행하고 진행 상황을 잡트래커에 전송 

                               (잡트래커는 전체 진행상황 파악가능)

2. 맵리듀스2 ( YARN ) 

1) 맵리듀스 1, 2 차이

2) 맵리듀스 1의 한계 극복!!! 

  (1) 확장성 

       맵리듀스 1보다 큰 클러스터에서 실행가능 -> YARN은 10000노드와 100000태스크까지 확장 가능

  (2) 가용성

       YARN은 리소스 매니저, 애플리케이션 마스터로 분리되었기 때문에 HA서비스가 '분할 후 정복'문제로 바뀜

   (3) 효율성

       맵리듀스 1에서 각 태스크 트래커는 맵슬롯, 리듀스슬롯으로 구분하여 관리 (각각의 태스크에서만 사용가능)

       YARN은 슬롯 대신 일종의 리소스 풀로 관리

       -> 이득 : 리듀스 슬롯이 모자라서 리듀스 태스크가 계속 대기할 일은 없음

                   YARN은 잘 쪼개져 있기 때문에 필요한 만큼만 자원 요청가능

   (4) 멀티테넌시 (다중 사용자)

        가장 큰 장점!! -> 하둡이 맵리듀스를 뛰어넘어 다양한 분산 애플리케이션을 수용가능

YARN : 하둡의 클러스터 자원 관리 시스템

          클러스터의 자원을 요청하고 사용하기위한 API 제공

1. YARN 애플리케이션

 YARN은 장기 실행 데몬을 통해 서비스 제공

   1) 리소스 매니저

       클러스터 전체 자원의 사용량을 관리 (한개)

   2) 노드 매니저

       컨테이너를 구동하고 모니터링하는 역할 (모든 머신에서 실행됨)

        * 컨테이너 : 자원(메모리,cpu)의 사용 한도를 가진 특정 어플리케이션 프로세스는 컨테이너에서 실행됨

   3) YARN이 애플리케이션을 구동하는 방식

        (1) YARN 애플리케이션 제출

                 클라이언트는 YARN에서 애플리케이션을 구동하기 위해 리소스 매니저에 접속

                 애플리케이션 마스터 프로세스의 구동을 요청

        (2) 컨테이너 시작하기(2a), 구동(2b)

                 리소스 매니저는 컨테이너에서 애플리케이션 마스터를 시작할 수 있는 노드 매니저를 하나 찾음

                 * 애플리케이션 마스터가 딱 한번 실행될지는 애플리케이션에 따라 다름

                         ex) 한번 실행되는 경우 - 애플리케이션 마스터가 단순한 계산을 단일 컨테이너에서 수행하고

                                                          그 결과를 클라이언트에 반환한 후 종료되는 경우

                             여러번 실행되는 경우 - (3), (4) 과정 진행

        (3) 리소스 할당-하트비트(3), 컨테이너 시작하기(4a), 구동(4b)

                 리소스 매니저에 더 많은 컨테이너 요청(3)한 후 분산 처리를 수행함 (4a, 4b)

2. YARN 애플리케이션 - 자원요청

 - 다수의 컨테이너 요청시 각 컨테이너에 필요한 컴퓨터 자원의 용량, 요청에 대한 컨테이너의 지역성 제약도 표현

- YARN 애플리케이션은 실행 중에는 아무 때나 자원 요청을 할 수 있다. (2가지 방식)

      (1) 스파크 방식

             - 애플리케이션은 처음에 모든 요청을 함

             - 클러스터에서 고정 개수의 수행자를 시작함

       (2) 맵리듀스 방식

             - 애플리케이션은 유동적적인 접근이 필요한 경우에 애플리케이션의 요구에 따라 동적으로 자원 추가를 요청

             - 두 단계로 이루어짐 ( 처음에 필요한 맵 태스크 컨테이너 요청,

                                             But! 리듀스 태스크 컨테이너는 맵 태스크 실행 했을때만 가능)

3. YARN 애플리케이션 - 애플리케이션의 수명

 - 실행 시간보다는 사용자가 실행하는 잡의 방식에 따라 애플리케이션을 분류

   1) 첫 번째, 사용자의 잡 당 하나의 애플리케이션이 실행

          -  ex) 맵리듀스 잡

   2) 두 번째, 워크플로나 사용자의 잡 세션당 하나의 애플리케이션이 실행

          -  순차적으로 실행되는 잡이 동일한 컨테이너를 재사용할 수 있음(효율적)

          - 잡 사이에 공유 데이터를 캐싱할 수 있음 

         - ex) 스파크

   3) 세 번째, 서로 다른 사용자들이 공유할 수 있는 장기 실행 애플리케이션

          - 일종의 코디네이션 역할 

          -  ex) 아파치 슬라이더 - 클러스터에서 다양한 애플리케이션을 구동시키는 장기 실행 App마스터임

                  임팔라

1. 파일 읽기

위의 그림은 클라이언트가 HDFS, 네임노드, 데이터노드와 상호작용하는 것을 보여준 것이다.

                                                     FSDataInputStream - 파일 탐색을 지원하는 입력 스트림

1. 열기

     클라이언트는 HDFS가 DistributedFileSystem 인스턴스인 FileSystem 객체의 open() 메서드를 호출하여 파일을 연다

2. 블록 위치 얻기

      DistributedFileSystem은 파일의 첫 번째 블록 위치를 파악하기 위해 RPC를 사용하여 네임노드를 호출

      이때, 클러스터의 네트워크 위상에 따라 클라이언트와 가까운 순으로 데이터 정렬됨

            (클라이언트 자체가 데이터노드고 해당 블록의 복제본 소유시 클라이언트는 로컬 데이터노드에서 데이터 읽음)

      DistributedFileSystem은 클라이언트가 데이터를 읽을 수 있도록 FSDataInputStream을 반환

3. 읽기

      FSDataInputStream은 데이터노드와 네임노드의 I/O를 관리하는 DFSInputStream을 래핑

      클라이언트는 스트림을 읽기위해 read() 메서드 호출

4~5. 블록 읽기

    파일의 첫번째 블록의 데이터노드 주소를 저장하고 있는 DFSInputStream은 가장 가까운 데이터노드와 연결

    해당 스트림에 대해 read() 메서드를 반복적으로 호출하면 데이터노드에서 클라이언트로 모든 데이터 전송됨

    블록의 끝에 도달하면 DFSInputStream은 데이터노드의 연결을 닫고 다음 블록의 데이터노드를 찾음

-> 새로운 블록 읽을 때 마다 DFSInputStream은 데이터노드와 새로 연결함

    클라이언트는 다음 블록의 데이터노드 위치를 얻기 위해 네임노드를 호출 => 2~(4,5) 반복

6. 닫기

    모든 블록을 읽었으면 FSDataInputStream의 close() 메서드 호출

=> 핵심! 클라이언트는 데이터를 얻기위해 데이터노드에 직접적으로 접촉,

            네임노드는 각 블록의 적합한 데이터노드를 안내

2. 파일 쓰기

파일생성 -> 데이터입력 -> 파일닫기

1. 생성

    클라이언트는 DistributedFileSystem의 create()를 호출하여 파일 생성

2. 생성

    DistributedFileSystem은 파일시스템의 네임스페이스에 새로운 파일 생성하기 위해 네임노드에 RPC요청을 보냄

    블록에 대한 정보 보내지 않음

   네임노드는 요청한 파일과 동일한 파일이 존재하는지, 클라이언트가 파일을 생성할 권한이 있는지 등 검사를 수행

             -> 검사통과시 네임노드는 새로운 파일의 레코드 생성,

                 검사실패시 파일 생성 실패, 클라이언트의 IOException이 발생

  DistributedFileSystem은 클라이언트가 데이터를 읽을 수 있도록 FSDataOutputStream을 반환

3. 쓰기

    FSDataOutputStream은 데이터노드와 네임노드의 I/O를 관리하는 DFSOutputStream을 래핑

    클라이언트가 데이터를 쓰면 DFSOutputStream이 일함!

4. 패킷쓰기

    (1) 클라이언트가 데이터를 쓰면(3단계) DFSOutputStream은 데이터를 패킷으로 분리하고,

       데이터 큐(내부 큐)로 패킷을 보냄

    (2) DataStreamer는 데이터 큐에 있는 패킷을 처리

    (3) 네임노드에 복제본을 저장할 데이터노드의 목록 요청

          -> 데이터노드 목록에 포함된 노드는 파이프라인 형성 (목록의 개수 = 파이프라인 속 노드 개수)

    (4) DataStreamer는 파이프라인의 첫 번째 데이터노드로 패킷전송

    (5) 첫 번째 데이터노드는 각 패킷을 저장한 후 파이프라인의 두 번째 데이터노드로 보냄

    (6) 쭉쭉쭉 마지막노드까지 보냄

5. ack패킷

    DFSOutputStream은 데이터노드의 승인 여부를 기다리는 ack 큐(내부 패킷 큐)를 유지함

    ack 큐에 있는 패킷은 파이프라인의 모든 데이터노드로부터 ack 응답을 받아야 제거됨

6. 닫기

    데이터 쓰기를 완료할 때 클라이언트는 스트임에 close() 메서드를 호출

    close()메서드 : 데이터노드 파이프라인에 남아 있는 모든 패킷을 플러시하고 승인이 나기를 기다림

7. 완료

    모든 패킷이 완전히 전송되면 네임노드에 '파일완료' 신호를 보냄

        (네임노드는 DataStreamer를 통해 블록 할당 요청을 받았기 때문에

          파일의 블록 구성을 알고있으며, 최소한의 블록 복제가 완료되면 최종적으로 성공 신호 반환)

3. 병렬복사 (distcp)

위의 내용은 단일-스레드 접근

distcp : 병렬로 다량의 데이터를 하둡파일시스템으로 복사하기 위한 프로그램

          hadoop fs -cp 대체..

1) HDFS 클러스터 균형 유지

   - 데이터를 HDFS로 복사할 때는 클러스터의 균형을 고려

           -> HDFS는 클러스터 전반에 걸쳐 파일 블록이 고르게 분산되었을 때 가장 잘 동작하기 때문에 

HDFS : 범용 하드웨어로 구성된 클러스터에서 실행되고

         스트리밍 방식의 데이터 접근 패턴으로 대용량 파일을 다룰 수 있도록 설계된 파일 시스템

         특징 - 매우 큰 파일

                - 스트리밍 방식의 데이터 접근

                - 범용 하드웨어

1. HDFS 개념 - 블록

1) HDFS의 블록   

   - 블록 크기 : 한번에 읽고 쓸 수 있는 데이터의 최대량 (HDFS의 블록의 크기 = 128MB)

   - HDFS의 파일은 특정 블록 크기의 청크로 쪼개지고, 각 청크는 독립적으로 저장됨

2) HDFS 블록의 특징

   - HDFS의 블록은 데이터가 블록크기보다 작은 데이터일 경우 전체 블록크기에 해당하는 하위 디스크 모두 점유X

                     (보통은 모두 점유)

          -> ex) 블록 128MB, 데이터 1MB인 경우 1MB의 디스크만 사용

   - 블록은 내고장성, 가용성을 제공하는 데 필요한 복제 구현시 편함

   - 블록 추상화의 장점 : > 파일 하나의 크기가 단일 디스크의 용량보다 더 커질 수 있음

                                > 파일단위보다는 블록단위로 추상화를 하면 스토리지의 서브시스템을 단순하게 만들 수 있음

1. HDFS 개념 - 네임노드와 데이터노드

HDFS 클러스터는 네임노드-데이터노드로 구성되어 있음

1) 네임노드

   - 파일시스템의 네임스페이스를 관리

   - 파일시스템 트리와 그 트리에 포함된 모든 파일과 디렉터리에 대한 메타데이터 유지

   - 파일에 속한 모든 블록이 어느 데이터노드에 있는지 파악

   - 파일시스템의 모든 파일과 각 블록에 대한 참조 정보를 메모리에서 관리

2) HDFS 클라이언트

   - 사용자를 대신해서 네임노드와 데이터노드 사이에서 통신하고 파일시스템에 접근

3) 데이터노드 (실질적 일꾼)

    - 디스크에 저장된 블록을 읽음

    - 클라이언트나 네임노드의 요청이 있을 때 블록을 저장하고 탐색하며,

      저장하고 있는 블록의 목록을 주기적으로 네임노드에 보고함

4) 네임노드의 장애복구 기능 (두가지 방법)

    첫번째, 파일 시스템의 메타데이터를 지속적인 상태로 보존하기 위해 파일로 백업

    두번째, 보조 네임노드 운영 ( 보조 네임노드는 주 네임노드와 조금 다르게 동작함 )

* 보조 네임노드

   역할  - 에디트 로그가 너무 커지지 않도록 주기적으로 네임스페이스 이미지를 에디트 로그와 병합하여

                새로운 네임스페이스 이미지를 만드는 것

           - 주 네임노드에 장애가 발생할 것을 대비하여 네임스페이스 이미지의 복제본을 보관함

             ( 복제본에 대한 시간차 문제는 추후에 다룰 예정)

   필요 스펙 : 병합작업 수행을 위해 보조네임노드는 충분한 CPU, 큰 메모리(네임노드와 비슷한 용량)

2. HDFS 개념 - 블록캐싱

   블록캐시 : 빈번하게 접근하는 블록파일을 '오프-힙 블록캐시'라는 데이터 노드 메모리에 캐싱할 수 있음 

   캐시 풀- 캐시지시자 : 이것을 추가하면 특정파일을 캐싱하도록 명령할 수 있음

                               캐시풀 - 캐시 권한이나 자원의 용도를 관리하는 관리 그룹의 역할을 함

3. HDFS 개념 - HDFS 페더레이션(연합체)

  - 네임노드의 메모리 확장성을 위해 HDFS 페더레이션을 활용

  - 각각의 네임노드가 파일시스템의 네임스페이스 일부를 나누어 관리하는 방식, 새로운 네임노드 추가 가능

          ex) A네임노드는 '/user' 하위 디렉터리 관리, B네임노드는 '/share' 하위 디렉터리 관리

  - 각 네임노드는 네임스페이스 불륨과 블록 풀을 관리

4. HDFS 개념 - HDFS 고가용성

1) 고가용성

활성대기 상태로 설정된 한 쌍의 네임노드로 구현됨, 활성 네임노드에 장애 발생시 대기 네임노드가 역할을 대신함

2) 고가용성이 필요한 이유

   '1-4 네임노드의 장애복구 기능'에서 말한 두 가지 방법에도 문제점이 있음

   새로운 네임노드 재구동까지는 총 3단계를 거쳐야함

                                      (1) 네임스페이스 이미지 메모리에 로드

                                      (2) 에디트 로그 갱신

                                      (3) 전체 데이터노드에서 충분한 블록 리포트를 받아 안전모드 벗어나기

              위의 3단계는 시간이 30분 이상 걸릴 수 있음 -> 그동안은 시스템 먹통됨 -> 큰일!!!!!!!!

   추가) 고가용성을 사용한다해도 1분정도 걸림

          -> 이유 ? 시스템이 활성 네임노드에 장애가 발생했다고 판단하는 시간 ( 매우 신중해야됨) 

3) NFS, QJM 

   고가용성 공유 스토리지를 위해 NFS필러 or QJM 을 선택

   - QJM : HDFS 전용 구현체, 고가용성 에디트 로그를 지원하기 위한 목적으로 설계 (HDFS의 권장 옵션)

              저널노드 그룹에서 동작, 각 에디트 로그는 전체 저널 노드에 동시에 쓰여짐

              (일반적으로 저널노드는 3개)

             주키퍼와 유사

 4) 장애복구와 펜싱

   장애복구 컨트롤러 : 대기 네임노드를 활성화시키는 전환 작업을 관리 

    - 우아한 장애복구 vs 우아하지 못한 장애복구

       우아한 장애복구 : 정기적인 유지관리를 위해 관리자가 수동으로 초기화 (두개의 네임노드가 서로 역할을 바꿈)

       우아하지 못한 장애복구 : 장애가 발생한 네임노드가 자신이 아직도 활성 네임노드라고 착각함

                                        -> 이때 펜싱을 사용하여 활성 네임노드 죽임! (시스템 손상시키면 안되니까..) 

맵리듀스 : 여러 노드에 태스크를 분배하는 방법

              맵단계와 리듀스단계가 있음 (각 단계는 입력과 출력으로 키-값의 쌍을 가짐)

1. 맵단계, 리듀스단계

 데이터는 키-값 쌍으로 변환괴어 맵함수에 입력됨

  맵 함수의 출력 = 리듀스 함수의 입력

2. 맵리듀스 소스코드!

  1) 맵 함수

      맵 함수는 추상map() 메서드를 정의하는 Mappper클래스로 구현됨

      Mapper 클래스는 제네릭 타입, 네개의 정규타입 매개변수를 가짐 ( 입력키, 입력값, 출력키, 출력값)

2) 리듀스 함수

     리듀스 함수는 Reducer를 사용하여 정의 (맵 함수와 비슷)

3) 잡

    job 객체는 잡 명세서(잡 수행하는 방법 정의한 것)를 작성함

   하둡 클러스터에서 잡을 실행하는 단계:

                   1. 코드를 JAR파일로 묶기

                               - 하둡은 클러스터의 해당 머신에 JAR파일을 배포

                   2. Job 객체 생성시 입력과 출력 경로를 지정

                               - 입력경로 지정시 FileInputFormat-addInputPath()호출하여 지정

                               - 출력경로 지정시 FileInputFormat-setOutputPath()호출하여 지정

                                 (리듀스 함수가 출력파일 저장할 디렉터리)

                  3. 입출력 데이터 타입 지정

                              - setMapperclass(), setReducerClass() 메서드 사용

                  4. 맵리듀스 함수를 정의한 클래스 지정

                             - waitForCompletion() 메서드 : 잡 제출 후 잡이 모두 끝날 때까지 기다림

3. 시스템 속 맵리듀스

    1) 맵리듀스 잡

       정의 : 맵리듀스 잡은 클라이어트가 수행하는 작업의 기본 단위

               입력데이터, 맵리듀스 프로그램, 설정 정보로 구성되어 있음

               하둡은 잡을 맵 태스크, 리듀스 태스크로 나누어 실행

                (각 태스크는 YARN을 이용하여 스케줄링, 여러노드에서 실행됨, 실패시 재할당&실행)

  2) 입력 스플릿(스플릿)

       하둡에서 잡을 입력하기위해 스플릿이라는 고정크기 조각으로 분리 (보통 스플릿 기본크기는 128 MB)

       각 스플릿마다 하나의 맵태스크를 생성, 스플릿의 각 레코드를 사용자 정의 맵 함수로 처리함

3) 데이터 흐름 - 맵

      - a :  동일 노드에 가용슬록이 있는 경우

             HDFS내의 입력 데이터가 있는 노드에서 맵태스크를 실행 (데이터 지역성 최적화)

      - b :  동일 노드에 가용슬롯이 없는 경우

             잡 스케줄러는 동일 랙에 속한 다른 노드에서 가용 슬롯을 찾음

     - c :  동일 랙에 가용슬롯이 없는 경우

             외부 랙의 노드 선택 (랙 사이 네트워크 전송 불가피)

4) 데이터 흐름 - 리듀스

    맵 태스크의 결과는 로컬디스크에 저장, 리듀스 태스크의 결과는 HDFS에 저장 (다른 복제본은 로컬, 외부 랙에 저장)

   위의 그림과 같이 다수의 리듀스 태스크가 있는 경우 리듀스 수만큼 파티션을 생성, 맵의 결과를 각 파티션에 분배함

5) 컴바이너 함수 

컴바이너 함수 : 맵과 리듀스 테스크 사이의 데이터 전송을 최소화 하기위한 맵의 결과를 처리하는 함수

                      컴바이너 함수의 출력 = 리듀스 함수의 입력

(주의! 컴바이너 함수가 리듀스 함수를 완전히 대체할 수 없음! 적용 여부를 검토한 후에 사용해야됨)

• 이 블로그 내의 하둡 내용은 하둡 완벽 가이드(지음: 톰 화이트, 옮김: 장형석 외 3명 출판: 한빛미디어) 내용을 요약및 참고한 것입니다. 
• 제가 이해한 대로 정리한 내용이기에 본문의 내용과 상이할 수 있습니다. 

1. 하둡이란?

- 하둡 에코시스템 : 분산 컴퓨팅과 대규모 데이터 처리를 위한 기반 시설

<RDBMS와 맵리듀스>

2. 하둡과 RDBMS

    - 하둡과 RDBMS의 차이점 : 데이터셋 내부에서 처리되는 구조의 양

    - 하둡은 읽기시점 스키마!  : 처리시점에 데이터를 해석하도록 설계되어 있기 때문에 유연함

                                       (하둡은 단순히 파일만 복사하면 됨)

3. 하둡과 그리드컴퓨팅

    - 그리드컴퓨팅 : 연결된 서로 다른 기종의 컴퓨터들을 하나로 묶어 가상의 대용량 고성능 컴퓨터를 구성하여

                        고도의 연산 작업 or 대용량 처리를 수행하는 것

   - 그리드 컴퓨팅은 네트워크 대역폭때문에 느림 

          -> 하둡은 계산노드에 데이터를 합께 배치! (데이터가 로컬에 있기 때문에 빠름)

          -> 데이터 지역성 (맵리듀스는 매우 높은 네트워크 대역폭을 가진 단일 데이터 센터에 있는
                                  신뢰성 높은 전용 하드웨어에서 수분, 수 시산 내에 job을 실행할 수 있도록 설계됨)

   - 하둡은 내부적인 데이터 흐름에 신경쓰지 않아도 되고

      분산 처리 프레임워크(맵리듀스..)는 실패한 태스크를 자동으로 감지하여

      장애가 없는 머신에 재배치하도록 구현되어 있기 때문에 개발자는 신경안써도됨

        -> 비공유 아키텍처(맵리듀스는 태스크 간의 상호 의존성이 없음)