하둡 Hadoop 02-1 Data logistics

하둡 Hadoop 02-1 Data logistics

하둡 데이터 이동

하둡으로 데이터를 집어 넣고(Data Ingress) /  하둡에 들어 있는 데이터를 가져오는 작업(Data Egress)은

외부 시스템에서 내부 시스템으로 데이터를 옮기거나 그 반대로 옮기는 과정을 말한다.

하둡은 HDFS 및 맵 리듀스를 통해 저수준에서 Ingress 및 Egress를 지원한다.

파일은 HDFS 안으로 옮기거나 HDFS 밖으로 옮길 수 있으며, 데이터도 외부 데이터 소스에서 가져오거나

맵-리듀스를 활용해 외부 데이터 싱크로 보낼 수 있다.

위의 그림에서 하둡의 Ingress 및 Egress의 매커니즘을 볼 수 있다. 외부 시스템과 내부 시스템 사이에서 데이터를 전송한다.

데이터가 다양한 위치에서 여러 형태로 존재한다는 사실은 절차를 어렵게한다.

OLTP(온라인 업무 처리) 데이터베이스에 있는 데이터를 어떻게 가져오며, 수만 대의 서버에서 생산하는 로그 데이터를 어떻게, 또는 방화벽 뒤에 있는 바이너리 데이터와 어떻게 연동하는 것인가? 더 나아가 데이터를 주기적으로 옮기도록 데이터 Ingress 및 Egress 절차를 자동화하려면 어떻게 해야 할까?

자동화는 데이터의 정확하고 안전한 전송을 보장하는 데이터 정합성 모니터링과 더불어 데이터 이동 과정에 핵심적인 부분이다.

주요 Ingress 및 Egress 고려 요소

대용량 데이터를 하둡에 집어 넣거나 하둡에서 가져오는 작업은 일관성 보장, 데이터 소스 및 이동 위체 미치는 리소스 영향을 비롯해 여러 가지 해결해야 할 과제를 안고 있다.

설계 요소

멱등성

멱등적인(idempotent) 작업은 실행 횟수와 상관없이 항상 같은 결과를 내놓는다.

보통, 관계형 데이터베이스에서 삽입은 멱등적이지 않다.

삽입(Insert)을 여러 차례 실행하면 데이터베이스의 상태가 동일하게 유지되지 않기 때문이다.

그에 반해 업데이트(Update)는 같은 결과를 내놓으므로 종종 멱등적이다.

데이터를 사용할 때는 항상 멱등성을 고려해야 한다. 하둡에서 데이터 Ingress 및 Egress 작업을 할 때도 마찬 가지이다.

다음이 멱등성에 대한 중요한 질문이다.

> 분산 로그 컬렉션 프레임워크가 데이터 재전송을 얼마나 잘 처리하는 가?  

> 여러 개의 태스크가 병렬적으로 데이터베이스에 삽입하는 맵-리듀스 잡에서 멱등성을  어떻게 보장하는가?

취합

데이터 취합 과정에서는 여러 데이터 요소를 취합한다.

Data Ingress 과정에서는 데이터 취합이 도움될 수 있다.

수많은 작은 파일을 HDFS로 옮길 경우 네임 노드 메모리 부족이 일어날 수 있고, 맵-리듀스 실행 시간도

그만큼 느려지기 때문이다.

파일이나 데이터를 함께 취합할 수 잇는 기능은 이런 문제를 줄여주는 만큼 고려해야 할 요소이다.

데이터 형식 변형

데이터 형식 변형 과정에서는 한 데이터 형식을 다른 형식으로 변환한다.

종종 소스 데이터가 맵-리듀스 같은 툴에서 처리하기에 적합하지 않을 때가 있다.

예를 들어 소스 데이터가 여러 줄의 XML이나 JSON 형식이라면 전처리 절차를 고려하는게 좋다.

이런 전처리 과정에서는 현재 데이터를 줄별로 JSON이나 XML 엘리먼트로 분할할 수 있는 형태로 변환하거나 애브로(Avro) 같은 형식으로 변환하면 된다.

복구 가능성

작업이 실패하더라도 Ingress 또는 Egress 툴에서 재시도할 수 있는 기능을 말한다.

어떤 데이터 소스나 Data Sync 또는 하둡 자체도 100퍼센트 가용성을 보장할 수 없는 만큼 작업이 실패할 때 재시도할 수 있는게 중요하다.

정확성

데이터 전송 시에는 정확성을 검사해 데이터 전송 과정에서 데이터 훼손이 일어나지 않았는지 확인해야 한다.

이종 시스템과 연동하는 경우, 서로 다른 호스트, 네트워크, 프로토콜 사이에서 전송되는 데이터가 전송 과정에서 문제를 일으킬 확률이 그만큼 늘어난다.

저장 장치 같은 raw 데이터의 정확성을 검사하기 위해 자주 사용하는 방식으로는 CRC(Cyclic Redundancy Checks)가 있다. HDFS에서 블록 수준의 정합성을 유지할 때에도 CRC를 내부적으로 사용한다.

리소스 소비 및 성능

시스템의 리소스 사용량 및 시스템 효율을 측정하는 기준이 된다.

데이터의 양이 상당하지 않다면 Ingress-Egress 툴에서는 보통 심각한 시스템 로드(Resource 소비)를 일으키지는 않는다.

성능 측면에서는 툴에서 Ingress-Egress 작업을 병렬적으로 수행하는 지 확인하고, 병렬적으로 수행하는 경우 병렬 처리량을 조절하기 위해 어떤 메커니즘을 제공하는지 확인해야 한다.

예를 들어 데이터 소스가 배포용 데이터베이스라면 데이터를 불러오기 위해 많은 양의 동시 맵 태스크를 사용하지 말아야 한다.

모니터링

자동화된 시스템에서 기능이 예상대로 동작하는지 확인할 수 있게 해준다.

모니터링은 두 부분으로 나뉜다.

즉, Ingress-Egress에 관여하는 프로세스들이 살아 있는 지 확인하고,

소스 및 옮길 위치의 데이터가 예상대로 생성되는지 확인해야 한다.

하둡으로 데이터 옮기기

하둡에서 데이터와 연동할 때 첫 번째로 할 일은 하둡에서 데이터에 접근할 수 있게 하는 것

데이터를 옮길 때 사용하는 주된 방법

> HDFS 레벨에서 외부 데이터를 쓰는 방식(Push)

> 맵-리듀스 레벨에서 외부 데이터를 읽는 방식(Pull)

맵-리듀스에서 데이터를 읽으면 작업을 쉽게 병렬화할 수 잇고 내고장성을 확보할 수 있다는 장점이 있다.

하지만 맵-리듀스에서 모든 데이터에 접근할 수 있는 것은 아니다.

예를 들어 로그 파일의 경우 다른 시스템에 의존해 HDFS로 데이터를 전송해야 한다.

하둡으로 소스 데이터를 옮기는 Ingress 과정을 본다.

먼저 로그 파일, 반구조화된(semistructured) 파일 또는 바이너리 파일을 이어서 데이터베이스, HBase를 살펴본다.

하둡 - 로그 파일 Ingress

로그 데이터는 오랫동안 많은 애플리케이션에서 사용했지만, 하둡은 배포 시스템에서 생산하는 대용량의 로그 데이터를 처리할 수 있는 능력을 갖추고 있다.

네트워크 장비와 운영체제 부터 웹 서버와 애플리케이션에 이르기까지 다양한 시스템에서 로그 데이터를 생성한다.

이런 로그 파일은 시스템 및 애플리케이션이 어떻게 동작되고 사용되는지 에대한 소중한 혜안을 제공하는 귀중한 자료가 된다.

로그 파일은 주로 텍스트 형식으로 이뤄지고, 줄 중심이라는 공통점이 있어 처리하기가 쉽다.

Flume, Chukwa, Scribe 비교

Flume, Chukwa, Scribe는 HDFS를 로그 데이터의 데이터 싱크로 활용하는 로그 수집 및 배포 프레임워크다.

이들 프레임워크는 기능이 동일하다.

Flume

아파치 Flume은 스트리밍 데이터를 수집하기 위한 분산 시스템이다.

이 프로젝트는 인큐베이터 상태에 있는 아파치 프로젝트로, 본래 클라우데라(Cloudera)에서 개발했다.

Flume은 필요에 따라 조절할 수 있는 다양한 수준의 안정성과 전송 보장 기능을 제공한다.

Flume은 사용자 설정을 폭넓게 지원하며, 커스텀 소스 및 데이터 싱크를 추가할 수 있는 플러그인 아키텍처를 지원한다.

Chukwa

하둡의 아파치 하위 프로젝트로서, HDFS에서 데이터를 수집하고 저장할 수 있는 대규모 매커니즘을 제공한다.

이 프로젝트도 인큐베이터 상태다. Chukwa의 안정성 모델은 두 레벨을 지원한다.

하나는 End-to-End 안정서 모델이고, 다른 하나는 Latency를 최소화하는 고속 경로 전달(fast-path delivery) 모델이다. HDFS에 데이터를 쓰고 난 후 Chukwa는 맵-리듀스 잡을 실행해 데이터를 별도 스트림으로 역다중화(demultiplex)한다. Chukwa에서는 시스템 성능을 시각화해주는 웹 인터페이스인 HICC(하둡 인프라스트럭처 케어 센터) 툴도 제공한다.

Scribe

Scribe는 기초적인 스트리밍 로그분산 서비스로서, Facebook 페이스북에서 개발했으며 폭 넓게 사용 중이다.

로그를 수집하는 Scribe 서버는 모든 노드에서 실행되며, 로그를 중앙 Scribe 서버로 전송한다.

Scribe는 HDFS, 일반 파일 시스템, NFS를 비롯한 여러 데이터 싱크를 지원한다. Scribe는 서버가 다운스트림 서버에 접근할 수 없을 때 로컬 디스크에 영속화하는 파일 기반 매커니즘을 통한 안정성 모델을 제공한다.

Flume이나 Chukwa와 달리 Scribe에는 로그 데이터를 가져올 수 잇는 편의 매커니즘이 전혀 없다. 대신 사용자가 직접 소스 데이터를 로컬 시스템에서 구동 중인 Scribe 서버로 스트리밍 해야 한다.

예를 들어 아파치 로그 파일을 Push하고 싶다면 로그 데이터를 Scribe 서버로 전송하는 데몬을 작성해야 한다.

https://github.com/facebook/scribe

전반적으로 이들 툴 사이에는 큰 기능상의 차이점은 별로 없다.

다만 Scribe에서는 End-to-end 전송 보장 기능을 제공하지 않는다는 점이 큰 차이점일 뿐이다.

또 Chukwa와 Scribe의 주된 단점으로는 문서화 부족을 꼽을 수 잇다.

여기서는 Flume을 선택했다. Flume의 중앙화 설정, 유연한 안정성 및 장애 극복 모드, 메일링 리스트의 인기도 있기 때문이다.

Flume을 활용한 HDFS로의 시스템 로그 발행

여러 서버의 애플리케이션 및 시스템에서 생산하는 수많은 로그 파일에 중요한 정보가 있다.

이런 정보를 분석하려면, 하둡 클러스터로 로그 파일을 옮기는 작업을 해야 한다.

데이터 수집 프로그램인 Flume을 활용해 리눅스 로그 파일을 HDFS에 집어넣고, 분산 환경에서 Flume을 실행하는 데 필요한 설정을 살펴보고, 안정성 모드에 대해서도 살펴보자

위 그림에서 전체 Flume 배포 환경을 볼 수 있다. 이 환경은 네 개의 주요 컴포넌트(Component)로 이뤄진다.

컴포넌트

> 노드: 데이터 소스에서 데이터 싱크로 데이터를 옮기는 Flume 데이터 경로

에이전트와 컬렉터는 많은 데이터 소스를 효율적이고 안정적으로 처리할 수 있게 배포한

단순 Flume 노드일 뿐이다.

> 에이전트: 로컬 호스트(local host)에서 스트리밍 데이터를 수집해 컬렉터에게 전달한다.

> 컬렉터: 에이전트가 보낸 데이터를 취합해 HDFS에 데이터를 쓴다.

> 마스터: 설정 관리 작업을 수행하고 안정적인 데이터 흐름을 돕는다.

위 그림에서 또한 데이터 소스와 데이터 싱크도 볼 수 있다.

데이터 소스는 다른 곳으로 전송하려는 데이터가 들어 있는 위치를 스트리밍 한다.

이런 위치의 에로는 애플리케이션 로그 및 리눅스 시스템 로그, 커스텀 데이터 소스로 지원할 수 있는 비텍스트 데이터 등이 있다.

데이터 싱크는 해당 데이터의 목적지로서, HDFS, 플랫 파일, 커스텀 데이터 싱크로 지원할 수 있는 임의의 데이터 타깃이 될 수 있다.

Flume을 의사 분산 모드로 실행한다. Flume 컬렉터, 에이전트, 마스터 데몬을 단일 호스트에서 실행한다.

우선 CDH3 설치 가이드를 통해 Flume, Flume 마스터, Flume 노드 패키지를 설치해야 한다.

관련 블로그 포스트입니다.

하둡 Flume