하둡 완벽 가이드(4판): 데이터의 숨겨진 힘을 끌어내는 최고의 클라우드 컴퓨팅 기술

Part 1 하둡 기초

Chapter 1 하둡과의 만남

하둡이 어떻게 하다가 등장하게 되었는 지를 중점적으로 읽었다.

"빅데이터를 검색할 때 병렬적으로 처리하는 것이 효율적이다"라는 것을 중점적으로 내용을 봤다.

1.1 데이터!

조직은 더 이상 자신의 데이터만 관리해서는 안 된다. 미래의 성공은 다른 조직의 데이터에서 가치를 추출하는 능력에 달려 있기 때문이다.

정말 동감한다. 따라서 앞으로 데이터관련 직업의 가치는 더욱 상승할 것으로 예상된다.

1.2. 데이터 저장소와 분석

여러 개의 디스크에 데이터를 병렬로 쓰거나 읽으려면 몇몇 문제를 고려해야 한다. 첫 번째 문제는 하드웨어 장애다. 많은 하드웨어를 사용할수록 장애가 발생할 확률도 높아진다. 데이터 손실을 막기 위한 일반적인 방법은 데이터를 여러 곳에 복제하는 것이다. 여러 곳에 데이터의 복사본이 보관되어 있으면 시스템에 장애가 발생해도 다른 복사본을 바로 이용할 수 있게 된다. 이와 같은 방식으로 작동하는 것이 바로 RAID다. 나중에 살펴볼 하둡의 파일시스템인 HDFS는 조금 다른 접근 방식을 사용한다.

두 번째 문제는 분할된 데이터를 대부분의 분석 작업에서 어떤 식으로든 결합해야 한다는 것이다. 즉, 하나의 디스크에서 읽은 데이터를 다른 99개의 디스크에서 읽은 데이터와 결합해야 할지도 모른다는 것이다. 많은 분산 시스템이 다중 출처의 데이터를 병합하는 기능을 제공하지만, 정합성을 지키는 것은 매우 어려운 도전 과제다. 맵리듀스는 디스크에서 데이터를 읽고 쓰는 문제를 키-값 쌍의 계산으로 변환한 추상화된 프로그래밍 모델을 제공한다. 맵리듀스의 프로그래밍 모델은 다음 장에서 자세히 다룬다. 여기서 설명하고자 하는 핵심은 계산이 맵과 리듀스로 분리되어 있고, 그 둘 사이를 ‘혼합’해주는 인터페이스가 있다는 점이다. 맵리듀스도 HDFS처럼 안정성을 내장하고 있다.

요약하면 하둡은 안정적이고 확장성이 높은 저장 및 분석 플랫폼을 제공한다. 무엇보다 하둡은 범용 하드웨어에서 실행되고 오픈 소스이기 때문에 매우 저렴하다.

 

1.3 전체 데이터에 질의하기

맵리듀스의 접근법은 무차별 대입(brute-force) 방식처럼 보인다. 맵리듀스의 전제가 한 번의 쿼리로 전체나 상당한 규모의 데이터셋을 처리하는 것이기 때문이다. 하지만 이것이 바로 맵리듀스의 장점이다. 맵리듀스는 일괄 질의 처리기고, 전체 데이터셋을 대상으로 비정형(ad hoc) 쿼리를 수행하고 합리적인 시간 내에 그 결과를 보여주는 능력을 지니고 있다. 이것은 데이터에 대한 우리 생각을 변화시켰고 예전에 테이프나 디스크에 보관해두었던 데이터를 다시 불러냈다. 우리는 데이터를 통해 혁신의 기회를 얻게 되었다. 너무 오랜 시간이 걸려서 얻기 힘들었던 문제에 대한 해답을 이제는 얻을 수 있게 되었고, 새로운 문제와 새로운 통찰력으로 우리를 이끌고 있다.

1.4 일괄 처리를 넘어서

맵리듀스의 강점은 기본적으로 일괄 처리 시스템이라는 것이고, 대화형 분석에는 적합하지 않다. 질의를 실행한 후 수 초 이내에 결과를 받는 것은 불가능하다. 일반적으로 질의를 처리하는데 1분 이상 걸리고, 사람들은 결과를 얻을 때까지 자리에 앉아서 계속 기다리기 힘들기 때문에 오프라인 용도로 적합하다고 볼 수 있다.

하둡의 생애를 보면 최초에는 일괄 처리를 위해 만들어졌으나 지금은 이를 벗어나 진화하고 있다. 실제로 ‘하둡’이란 단어는 HDFS와 맵리듀스만이 아닌 수많은 에코시스템 프로젝트를 지칭하는 말로 사용되기도 한다. 하둡 에코시스템은 분산 컴퓨팅과 대규모 데이터 처리를 위한 기반 시설이다. 에코시스템의 대부분은 오픈 소스 소프트웨어 프로젝트 커뮤니티의 지원을 담당하고 HTTP 서버 (프로젝트 이름으로 시작하는 도메인을 가짐. 예를 들면 pig.apache.org)를 제공하는 아파치 소프트웨어 재단 Apache Software Foundation 9에서 관리하고 있다. 온라인 접근을 지원하는 첫 번째 구성요소인 HBase는 HDFS를 기본 저장소로 하는 키-값 저장소다. HBase는 개별 행에 대한 온라인 읽기/쓰기와 산적한 데이터를 읽고 쓰는 일괄 처리를 둘 다 지원하기 때문에 애플리케이션을 구축하는 데 좋은 솔루션이 될 수 있다.

하둡의 새로운 처리 모델을 위한 진정한 조력자는 바로 하둡 2에 포함된 YARN(Yet Another Resource Negotiator)이다. YARN은 클러스터 자원 관리 시스템으로, 맵리듀스뿐만 아니라 어떤 분산 프로그램도 하둡 클러스터에 저장된 데이터를 처리할 수 있게 해준다. 

 

1.5 다른 시스템과의 비교

1.5.1 관계형 데이터베이스 관리 시스템

왜 여러 개의 디스크를 가진 데이터베이스를 이용하여 대규모 분석을 수행할 수 없는 것일까? 왜 하둡이 필요한가?

이러한 질문에 대한 답은 ‘탐색 시간은 전송 속도보다 발전이 더디다’는 디스크 드라이브의 또다른 특성에서 찾을 수 있다. 탐색은 데이터를 읽거나 쓸 때 디스크의 헤더를 디스크의 특정 위치로 이동시키는 조작이다. 이것이 바로 디스크 조작의 지연과 관계된 특징이라면 전송 속도는 디스크의 대역폭과 관련되어 있다.
만약 데이터 접근 패턴이 탐색 위주라면 데이터셋의 커다란 부분을 읽거나 쓰는 작업은 전송 속도에 좌우되는 스트리밍 조작보다 더 오래 걸릴 것이다. 반면 데이터베이스에 있는 일부 레코드를 변경하는 작업은 전통적인 B-트리 (관계형 데이터베이스에서 사용되는 자료 구조로,탐색을 수행하는 속도에 제한이 있다 )가 더 적합하다. 데이터베이스의 상당 부분을 변경할 때 B-트리는 데이터베이스를 재구성하기 위해 Sort/Merge를 사용해야 하므로 맵리듀스보다 효율적이지 못하다.

여러 면에서 맵리듀스는 RDBMS를 보완하는 것처럼 보인다. [표1-1]에서 두 시스템 간의 차이를 볼 수 있다. 맵리듀스는 비정형 분석과 같이 일괄 처리 방식으로 전체 데이터셋을 분석할 필요가 있는 문제에 적합하다. RDBMS는 상대적으로 작은 양의 데이터를 낮은 지연 시간에 추출하고 변경하기 위해 데이터셋을 색인하기 때문에 특정 쿼리와 데이터 변경에 적합하다. 맵리듀스는 데이터를 한 번 쓰고 여러 번 읽는 애플리케이션에 적합하지만, 관계형 데이터베이스는 지속적으로 변경되는 데이터셋에 적합하다고 할 수 있다

관계형 데이터베이스와 하둡 시스템의 차이는 점점 불분명해지고 있다. 최근 관계형 데이터베이스는 방향은 다르지만 하둡의 개념을 포함하기 시작했으며, 하둡 시스템의 하이브는 맵리듀스에서 벗어나 점차 대화형으로 발전하고 있으며 색인이나 트랜잭션과 같은 기능을 추가하고 있기 때문에 전통적인 RDBMS와 점점 닮아가고 있다.

하둡과 RDBMS의 다른 차이점은 데이터셋 내부에서 처리되는 구조의 양이다. 정형 데이터(structured data)는 XML 문서나 미리 정의된 특정 스키마를 가진 데이터베이스 테이블과 같이 형식이 정의된 항목으로 구조화되어 있다. 이것은 바로 RDBMS의 영역이다. 반정형 데이터(semi-structured data)는 정형 데이터에 비해 스키마가 유연하거나 심지어 생략될 수 있다. 따라서 데이터 구조에 대한 최소한의 규칙만 있으면 된다. 예를 들어 그리드 형태의 셀 구조로 된 스프레드시트는 셀 자체에 어떤 형태의 데이터도 담을 수 있다. 비정형 데이터(unstructured data)는 어떠한 내부 구조도 없다. 예를 들어 일반 텍스트나 이미지 데이터가 그렇다. 하둡은 처리 시점에 데이터를 해석하도록 설계되어 있기 때문에 비정형 데이터나 반정형 데이터도 잘 처리할 수 있다. 읽기 시점 스키마(schema-on-read)라 불리는 이러한 특성은 유연성을 제공하고 데이터를 불러오는 비용이 많이 드는 단계 (RDBMS에서 필요한)도 피할 수 있다. 하둡은 단순히 파일만 복사하면 된다.관계형 데이터는 무결성을 유지하고 중복을 제거하기 위해 주기적으로 정규화(normalize)된다. 정규화는 하둡에서 문제가 되는데, 하둡은 비지역 연산으로 레코드를 읽고, 하둡의 핵심 전제는 고속의 순차적 읽기와 쓰기를 수행하는 것이기 때문이다.

웹 서버의 로그는 정규화되지 않은 레코드셋의 좋은 예다. 예를 들어 클라이언트의 호스트명은 같은 클라이언트가 여러 번 나와도 매번 완전하게 표시된다. 그리고 이런 종류의 모든 로그파일은 하둡으로 분석하기 매우 적합하다. 또한 하둡은 관계형 데이터베이스보다 많이 사용되지는 않지만 조인을 수행할 수 있다.

맵리듀스와 다양한 하둡의 처리 모델은 데이터의 크기에 따라 선형으로 확장된다. 데이터는 분할되고 맵과 리듀스와 같은 기본 함수는 분리된 파티션에서 병렬로 데이터를 처리할 수 있다. 만일 입력 데이터의 크기가 두 배라면 작업은 두 배 느리게 수행될 것이다. 하지만 클러스터의 크기가 두 배가 된다면 그 작업은 기존보다 더 빠르게 수행될 것이다. 일반적으로 관계형 데이터베이스의 SQL 쿼리는 그렇지 못하다.

1.5.2 그리드 컴퓨팅

하둡은 가능하면 계산 노드에 데이터를 함께 배치한다. 따라서 데이터가 로컬에 있기 때문에 접근도 빠를 수밖에 없다. ‘데이터 지역성(data locality)’으로 알려진 이러한 특성이 바로 하둡에서 데이터 처리의 핵심이고, 좋은 성능을 내는 이유이기도 하다. 데이터 센터의 환경에서 가장 중요한 자원은 네트워크 대역폭이라는 점을 확실히 인식해야 한다. 데이터를 이리저리 복사해보면 쉽게 네트워크 링크를 포화 상태로 만들 수 있다. 하둡은 네트워크 토폴로지를 명확하게 모델링하는 방법으로 네트워크 대역폭을 보존하기 위해 많은 노력을 기울였다. 네트워크를 고려한 이러한 배치 방식은 하둡에서 CPU를 많이 사용하는 분석에 지장을 주는 것은 아니다.

하둡은 데이터가 로컬에 있어 접근이 빠르다. 또한, 하둡은 네트워크 대역폭을 보존한다.

하둡의 데이터 처리는 최상위 수준에서만 동작한다. 개발자는 내부적인 데이터 흐름에 신경 쓰지않아도 되며 맵리듀스의 키-값 쌍과 같은 데이터 모델의 관점에서만 생각하면 된다.

대규모 분산 컴퓨팅에서 수많은 프로세스를 조율하는 것은 엄청난 과제다. 가장 어려운 점은 원격 프로세스가 실패했는지 정상인지 알 수 없을 때와 같은 부분 실패에 현명하게 대처하는 것과 전체적인 계산의 진행을 이어가는 것이다. 맵리듀스와 같은 분산 처리 프레임워크는 실패한 태스크를 자동으로 감지하여 장애가 없는 머신에 다시 배치하도록 구현되어 있기 때문에 개발자는 실패에 대해 크게 고민하지 않아도 된다. 이러한 일이 가능한 이유는 맵리듀스가 태스크 간의 상호 의존성이 없는 비공유(shared-nothing) 아키텍처이기 때문이다. 매퍼의 출력이 리듀서로 전송되기 때문에 상호 의존성이 없다는 것은 조금 지나치게 단순화한 것으로 볼 수 있다. 하지만 맵리듀스 시스템은 모든 것을 통제할 수 있다. 맵리듀스는 실패한 맵을 다시 실행하는 것보다는 실패한 리듀서를 재실행하는 데 주력한다. 리듀서는 필수적인 맵의 출력을 반드시 다시 추출해야하고, 그것이 불가능하다면 상응하는 맵을 다시 실행해야 하기 때문이다. 개발자의 관점에서 보면 태스크의 실행 순서는 중요하지 않다. 이와 달리 MPI 프로그램은 자신의 체크포인트와 장애 복구를 명확하게 관리해야 한다. 이렇듯 MPI는 개발자에게 더 많은 제어권을 주지만 프로그램을 작성하는 것은 그만큼 더 힘들다.

CHAPTER 3 하둡 분산 파일시스템

3.1. HDFS 설계

네트워크로 연결된 여러 머신의 스토리지를 관리하는 파일시스템을 분산 파일시스템이라고 한다.

3.2. HDFS 개념

분산 파일시스템에 블록 추상화의 개념을 도입하면서 얻게 된 몇몇 이득이 있다. 첫 번째 이득은 파일 하나의 크기가 단일 디스크의 용량보다 더 커질 수 있다는 것이다. 하나의 파일을 구성하는 여러 개의 블록이 동일한 디스크에만 저장될 필요가 없으므로 클러스터에 있는 어떤 디스크에도 저장될 수 있다. 실제 그런 일이 발생할 가능성은 거의 없지만 HDFS는 클러스터의 전체 디스크를 모두 채울 정도로 큰 파일 하나를 저장하는 것도 가능하다.

두 번째 이득은 파일 단위보다는 블록 단위로 추상화를 하면 스토리지의 서브시스템을 단순하게 만들 수 있다는 것이다. 단순화는 모든 시스템이 추구하는 이상이지만 특히 분산 시스템에서는 장애 유형이 너무나도 다양하기 때문에 더욱 중요하다. 블록을 다루는 스토리지의 서브시스템은 스토리지 관리를 단순화하기 쉽고 (블록은 고정 크기고 저장에 필요한 디스크 용량만 계산하면 된다 ) 메타데이터에 대한 고민을 덜 수 있다. 블록은 단지 저장된 데이터의 청크일 뿐이고 권한 정보와 같은 파일의 메타데이터는 블록과 함께 저장될 필요가 없으므로 별도의 시스템에서 다루도록 분리할 수 있다