Understading BigData(2)

Intro

학교 수강과목에서 학습한 내용을 복습하는 용도의 포스트입니다.
빅데이터 개념과 오픈소스인 아파치 하둡과 맵리듀스 및 스파크를 이용한 빅데이터 적용을 공부합니다.
맵 리듀스의 경우 사용하기에 다소 진입장벽이 있는편입니다.
스파크처럼 통합 환경을 제공하지 않아 원하는 유틸리티나 라이브러리를 별도로 연결해서 사용해야하기 때문입니다. 이를 해소하는 것이 스파크라는 분산 데이터 처리 통합 엔진입니다.
따라서 맵 리듀스로 먼저 공부해보고, 스파크로 넘어갑니다.

스파크 엔진의 경우 Java가 아닌 Scalar라는 언어로 사용하며, 기존 우리가 알고 있는 SQL을 통해 고급 질의가 가능하며, 시각화나 스트림 처리 및 기계학습등 까지의 높은 수준의 분석을 제공하는 통합 프레임 워크입니다.

빅데이터 컴퓨팅(분산시스템상의 분산처리 환경)의 기본 개념과 원리를 이해하고 이를 실습해보는 과정에서 2대 이상의 리눅스 클러스터 서버를 구축 및 활용할 것입니다.

빅데이터이해(1) 요약 보러가기

이번 주제는 아파치하둡 소개입니다.

지난시간 복습

빅데이터 파이프라인에 대한 소개를 했었습니다.
빅데이터란 단순히 Volume이 크다라는 것만 말하는것이아니라 variety 구조화, 비구조화 또는 json과 같은 반구조화된 데이터.. 실시간으로 계속 생성되는 데이터 velcoity 의 특징을 갖습니다.
3V라고 하지요.

지난 시간에는 구글의 빅데이터를 다루는 해결법도 살펴보았습니다.
일반 범용 컴퓨터를 클러스터삼아 파일을 컴퓨터에 각각 분산하여 저장하는 구글 파일시스템을 배웠습니다.
다양성을 위해서 NoSQL을 위한 데이터 저장소인 빅테이블도 배웠습니다.
또한 구글 파일시스템에 저장된 데이터를 병렬처리하기 위해 맵리듀스를 사용한다는 것을 배웠습니다.
맵리듀스는 각 노드에 분산된 데이터를 병렬처리하는 맵, 결과를 취합하는 목적의 리듀스함수로 이루어진다고 배웠습니다. 오늘 이 개념은 다시한번 다뤄볼 예정입니다.
그리고 우리가 빅데이터를 수집 처리하기 위해서는 파이프라인 과정을 거치게된다는 것을 배웠습니다.

오늘 배울 아파치하둡은 마찬가지로 분산파일시스템입니다.
아파치 하둡을 소개하기 전에 기존 로컬 파일시스템의 문제점을 살펴보고나서 하둡을 소개하고, 그와 관련된 여러 하둡 에코시스템들을 소개한 뒤 응용사례를 살펴보겠습니다.

로컬 파일 시스템의 문제점

기존의 로컬 파일 시스템의 경우 각 파일을 저장할 때 inode(메타 데이터 : 데이터에 대한 데이터)와 블록으로 구성합니다.

inode는 파일에 관한 속성을 말합니다.
예를 들어 파일 타입, 권한, 소유자, 파일 이름 등이 그 것들입니다.
파일이 저장된 데이터 블록의 위치를 가리키는 포인터도 포함하고 있습니다.
즉 쉽게 말해 파일에 관한 모든 정보를 가지고 있다고 보면 됩니다.

그리고 데이터블록에는 파일의 실제 내용이 저장되어있습니다.

기존의 로컬파일시스템의 경우에는 저장소가 고장나면 모든 파일의 데이터가 손실될 우려가 있어, 동일한 로컬 드라이브를 설치하여 미러링하는 기법으로 이를 보완하곤하지만, 그렇다해도 컴퓨터 자체가 고장날 수 있어 불안전합니다.
그래서 클라우드에 중요 파일들을 미러링해서 데이터를 관리하기도 합니다.

또 다른 데이터 손실 요인으로는 인간의 실수입니다.
작업자가 실수로 삭제하는 경우가 있기 때문에 미러링은 직관적 해결책이 되지 못합니다.
그래서 이 문제를 방지하기 위해 백업 드라이브에 정기적으로 증분백업(incremental backup)을 하곤 합니다.
예를들어 리눅스의 resync 등의 명령어가 이에 해당합니다.

또 다른 요인으로는 저장공간 부족 현상입니다.
이에 대한 해결책으로 사용했던 방법은 바로 RAID(Redundant Array of Inexpensive Disks)를 이용하여 새로운 하드 드라이브를 파일 시스템에 추가하여 확장하는 방법입니다.

RAID는 0부터 7까지 있습니다. 각 레벨별로까지는 아니어도 간단히 살펴봅시다.

1. RAID-0
   하나의 HDD가 있을때 또다른 HDD를 설치하여 확장할 수 있습니다.
   이럴경우 디스크가 두개 있다고해서 Array라고 불려지는 듯 합니다.
   RAID-0을 채용한 경우 시스템 공간의 전체 크기는 모든 디스크 크기의 합이 됩니다.
   

2. RAID-1
   이전에 잠시 소개된 미러링기법이 이에 해당합니다.
   본래의 파일시스템이 있고 그 것을 그대로 복사한 또다른 디스크가 있는 경우에 해당합니다.
   RAID-1을 채용한 경우 전체 시스템 공간 크기는 똑같은 두개의 디스크 크기의 합입니다.
   

아파치 하둡

데이터손실의 우려 및 저장공간 부족의 우려가 있다는 것을 알 수 있습니다.
여러대의 컴퓨터에서 일관된 방식으로 파일시스템을 관리할 수 있다면 앞서 대두한 문제들을 해결할 수 있겠습니다.

여러 컴퓨터에서 분산해서 파일시스템의 관리를 운영하는 대표적인 오픈소스 분산파일시스템, 아파치 하둡을 소개합니다.

아파치 하둡은 빅데이터를 분산 저장하고 처리하기 위한 오픈 소스 프레임워크입니다.
특수 전용 HW가 아니라 일반 범용 머신들로 클러스터의 노드를 구성한다는 특징을 갖습니다.

원래의 대규모 데이터를 여러 컴퓨터에 나눠 저장하는데 고장에 대한 감내(fault tolerant)를 위해 redundancy로 구현됩니다.
쉽게 말해 복제하고 분산해서 저장해두는 것이죠.

하둡 분산 파일 시스템(Haddop Distributed File System, HDFS)

HDFS는 고장감내 구현을 위해 아래와 같이 동작하게됩니다.
디폴트로 데이터가 3번 복제(replication)됩니다.
노드가 통째로 망가지는 경우를 대비하여 최소한 하나는 다른 노드(컴퓨터)에 위치하도록 합니다.
물리적 디스크는 노드와 클러스터로 구성됩니다.

하나의 큰파일이 여러개의 노드에 분산되어 저장되는 것이 분산파일시스템의 구성입니다.

HDFS는 일반 파일시스템과 마찬가지로 블록단위로 데이터가 복제되며 읽기, 쓰기를 수행하게 됩니다.

대개 블록의 크기를 설정할수는 있지만 64MB~128MB 정도의 크기를 갖습니다.

예를들어 1TB의 파일이 있다면 블록단위로 분할이 되고, 노드에 복제되며 분산되어 저장됩니다.

하둡은 분산파일 시스템으로 HDFS를 이용하며, 분산 처리를 위해서 Map Reduce를 이용합니다.

구글에서도 빅데이터 처리를 위해 Map Reduce를 사용했다는 점 기억나시죠?

하둡의 분산처리를 위한 맵리듀스 알고리즘은 맵, 셔플, 리듀스의 3단계로 구성됩니다.

각각의 다른 컴퓨터상에서 노드마다 분산되어 저장된 데이터 다시 말해, 각 노드에 저장되어있는 데이터를 파티션이라고 부르는데 Map을 통해 모든 파티션으로부터 병렬처리한 후에 그 처리된 결과를 가지고(보통 key값으로 그들을 구분) 셔플을 통해 뒤섞은 후 reduce단계를 거쳐서 처리된 결과를 통합하여 최종 수행되게됩니다.

물론 reduce 단계에서도 병렬처리되는 경우도 있다고 합니다만 기본적으로는 위 세 단계를 거친다고 이해하시면 되겠습니다.

다시 한번 자세히 살펴봅시다.

1. 맵
   데이터를 분할하고, 맵함수를 적용하여 key-value 쌍을 생성합니다.
   이 key값을 기준으로해서 통합하거나 셔플하는 것입니다.
   

2. 셔플
   맵단계 출력의 key-value 쌍들을 정렬하고 분할하여 리듀스 단계로 전달합니다.
   한 노드의 결과를 다른노드의 결과로 정렬해서 보내는 단계로, 네트워크에 부하가 많이 발생하는 단계입니다.
   그래서 셔플단계는 분산처리의 성능을 좌우하게됩니다.
   

3. 리듀스
   각 분할에 대해 리듀스 함수를 적용하는 단계로 분할 정복(divide and conquer) 기반의 알고리즘으로 취합되어 온 큰 작업을 여러개로 분할하고 다시 서로 합쳐서 최종 결과를 도출합니다.
   

맵리듀스 알고리즘의 이해를 위한 예제

특정 책에 있는 모든단어를 카운트한다고 합시다.
분산파일시스템에 저장이 되어야겠죠. 하둡은 먼저 데이터 파일들을 분할해서 데이터 노드들에 분배해 저장합니다.

여기까지 데이터 입력이 끝났으면 각 노드별로 처리를 해야하는데 이 과정이 바로 맵단계입니다.
입력문자열을 토큰화하여 모든 단어에 대한 key-value 쌍을 출력합니다.
이때 key값은 특정단어가 될 것이며, value값은 1로 초기화된다고 합시다.
여기까지는 각 컴퓨터에서 이루어질 것인데, 이 값을 reduce로 넘겨주기위한 셔플단계를 거치게 됩니다.

셔플단계에서는 각 컴퓨터에서 센 단어들 중에서 중복된 같은 단어들이 있다면 병합한 후에 그 병합된 key-value 쌍을 전해줍니다.
여기서 헷갈리시면 안됩니다.
모든 노드들을 병합하는 것은 리듀스때 하는 일이고 셔플에서는 각 노드별로 이루어지는 작업입니다.
한 노드상에서 병합할 수 있는 것들을 병합하는 것입니다.
우연히 한 노드안에서 the라는 단어가 세 번이 나왔을 수도 있으니까요!

리듀스단계에서는 다른 노드의 맵 결과들을 취합하여 통합합니다.
각 키값에 대해서 다른 여러개의 노드들이 계산한 모든 단어들을 통합시킵니다.

최종적으로 취합된 카운트 값을 분산파일 시스템에 저장하면 됩니다.

하둡 에코 시스템

위에서 배운 핵심적인 HDFS(데이터저장구현)와 MapR(데이터처리구현) 말고도 그 데이터들을 처리하고 분석하기 위한 여러가지 응용프로그램들을 제공합니다.

그 처리 응용들의 일부를 하둡 에코 시스템이라고 부릅니다.
ex) Dril, Flume, HBase, Hive, Mahout, Oozie, pig, Spark, Sqoop, Yam, Zookeeper etc

파이프라인 단계의 과정을 기준으로 몇가지 에코시스템을 알아봅시다.

1. Apache Zookeeper
2. YARN(Yet Another Resource Negotiator)
3. Apache Sqoop
4. Apache Oozie
5. Apache Spark
6. Apache HBase
7. Apache Pig
8. Apache Hive
9. Apache Drill
10. Apache Mahout

Apache Zookeeper

하둡을 실행하면 하둡 관리자는 최초 만나게되는 응용인 Zookeeper를 사용하여 클러스터를 관리합니다. 또한 하둡 관리자는 각 클러스터에 실행되고 있는 MapR이나 YARN의 버전을 파악하고 있어야합니다.

클러스터의 각 노드들 사이의 서비스를 관리하고 조정하는 용도의 아파치 주키퍼는 하둡에서 처음 실행되는 서비스이며, 서비스들 간의 동기화를 담당하며, 장애 상황 판단 및 복구를 제공합니다.
또한 네임서비스를 통한 부하 분산도 제공하며 기타 환경 설정 관리를 모두 담당하는 아주 기본적인 응용이라고 할 수 있습니다.

YARN(Yet Another Resource Negotiator)

하둡 클러스터의 각 응용에 자원을 할당(물론 분산처리)하고 모니터링합니다.

예전에는 MapR만을 사용했을테니 초기에는 MapR만을 지원했겠지만, 현재는 YARN의 클러스터 리소스 관리를 통해서 다양한 응용들이 하둡 클러스터 자원의 공유할 수 있도록 지원합니다.

배치 뿐아니라 Interactive, Online 상에서도 가능하도록 지원합니다.

결국 아파치 주키퍼와 YARN은 모든 응용에서 사용해야하는 필수적인 응용이라고 볼 수 있습니다.

하지만 여기서 소개한 두 가지 말고도 작업 기술을 한다거나 데이터 수집단계에서 사용할 수 있는 응용으로서 Flume, Oozie, Sqoop등이 있습니다. Java, python, scala라는 프로그래밍 언어를 통해 작업을 기술할 수도 있구요.

Apache Flume

하둡 클러스터에 스트리밍 데이터를 수집하는 역할의 오픈소스 서비스입니다.

cf) 스트리밍데이터의 예 : 시스템 로그, 웹 서버 로그, SNS 피드 etc

Apache Sqoop

외부 데이터 저장소(기존의 RDBMS, NoSQL 데이터 등) 데이터를 가져와서 하둡 파일 시스템에 저장하거나 또는 그 반대로 내보낼 수 있게 하는 응용입니다.

Apache Oozie

하둡의 워크 플로우를 생성하고 스케줄링하는 툴입니다.
하둡상에서 응용을 작성할 때 여러가지 응용과 작업 단계를 거치는 복잡한 작업을 할 것이므로 체계적으로 스케줄링을 해줄 필요가 있습니다.
워크플로우에는 직렬/병렬 작업 모두 가능하며, 자바나 스크립트 뿐 아니라 여러 응용들에 대한 다수의 수행 작업도 포함될 수 있습니다.

데이터 수집이 끝나면 분석처리 이전에 가공 등의 처리작업을해야하는데, 아파치 스파크와 HBase, Pig등의 응용을 이용할 수 있습니다.

Apache Spark

분산 컴퓨팅 클러스터에서 범용 데이터 분석을 수행하는 프레임워크로서 수행된 결과 자체를 메모리상에 캐시된 데이터를 사용하여 반복적인 작업을 MapR보다 빠르게 처리할 수 있습니다.
스칼라나 파이선 자바로 응용을 작성할 수 있습니다.

Apache HBase

지난 시간에 잠시 소개되었던 응용인데요, 구글의 빅테이블 모델을 따라 개발된 NoSQL을 위한 오픈소스 데이터베이스 입니다.

시스템 측정 값, 사용자 클릭 등과 같은 대용량 데이터를 행과 열에 기반하여 저장하며, 채팅이나 이메일 등과 같은 일관성이 없는 값들을 갖는 데이터를 열에 저장합니다.
웹 응용이나 검색 색인과 같이 랜덤 읽기/쓰기 접근이 연속으로 발생하는 데이터도 저장할 수 있습니다.

자바 언어로 Hbase 응용을 작성할 수 있습니다.

Apache Pig

데이터를 분석하는 플랫폼입니다.
Pig Latin이라는 데이터플로우 스크립트 언어 또는 파이선, 자바, 자바스크립트, 루비 등의 언어를 이용하여 스크립트를 MapR 프로그램 시퀀스로 변환해줍니다.

나중에 실습해보면 알게되겠지만, 우리가 직접 MapR 프로그램을 작성하는 것이 쉽지 않기때문에 스크립트 언어로써 작성하면 Pig가 MapR 프로그램으로 변환을 해주는 것이죠.

Apache Hive

데이터를 분석하기 위한 하둡 에코 시스템으로는 Hive나 Drill, Mahout 등이 있는데요,
데이터 마이닝, 추출, 정규화, 필터링, 집계, 질의, 해석, 도식화, 머신러닝을 이용한 예측을 할 수 있도록 합니다.

이중 Apache Hive는 하둡상에서 구축되는 데이터웨어하우스(여러 다양한 소스의 데이터를 저장하는 중앙저장소) 인프라스트럭처입니다.
기본적으로 하둡상에서는 맵리듀스 프로그램을 작성해줘야하는데 HiveQL이라는 SQL과 같은 질의언어를 사용하여 대신 작성해주는 역할을 한다고 보시면 됩니다.

Apache Drill

빅데이터 탐색을 위한 질의 엔진입니다.
SQL을 사용하여 HDFS나 Hive에 저장된 구조화, 반구조화, 비구조화 데이터들에 대한 동적 질의를 수행해주는 응용입니다.

Apache Mahout

DL말고 고전적인 ML 알고리즘을 지원하는 라이브러리입니다.
대규모 빅데이터를 알고리즘에 적용하여 추천 등과 같은 예측을 시도합니다.
참고로 DL의 경우는 별도의 프레임워크를 사용해줘야하는데 Apache Spark를 결합해 사용하면 됩니다.

응용 사례

이해를 돕기 위해서 개발 응용 사례를 살펴보겠습니다.

1. 데이터 웨어하우스 최적화(Data Warehouse Optimization) 사례

2. 추천 엔진(Recommendation Engine)

3. 대규모 로그 분석(Large-Scale Log Analysis)

데이터 웨어하우스 최적화(Data Warehouse Optimization) 사례 — 데이터 웨어하우스란 다양한 소스의 데이터(각 부서별 데이터 저장소 등)를 저장하는 중앙 저장소입니다.
이처럼 분산 운영되는 다양한 데이터소스를 통합하여 관리해줄필요가 있는데요, 그러려면 공통의 구조화된 형식으로 데이터를 변환하여 저장해줘야겠지요?

그래서 ETL(Extract, Transform, Load)을 거치는게 우선입니다.

데이터 웨어하우스의 스키마와 일치하도록 변환하는 과정을 거치는 것입니다.
하지만 3V 특성때문에 ETL 처리 비용이 증가하고 있습니다.

온라인 쇼핑 업체는 상품의 판매와 관련하여 발생되는 모든 정보의 이해를 원합니다.
즉, 메타데이터를 추적하고 많은 고객에 대한 평가와 감성분석(sentiment analysis)의 연관성을 알고자 합니다.

보통 크기, 중량, 색상, 제조업자 등의 상품 관련 정보를 JSON과 같은 구조화 또는 반구조화 형식으로 기술합니다.

반면 감성분석으로 소셜미디어 데이터를 활용하는데 이러한 데이터는 반구조화 또는 비구조화된 데이터로 저장이나 처리가 어렵습니다.

또 다른 문제로는 속도입니다.
데이터가 수시로 변하기 때문입니다.

기업의 데이터 웨어하우스에서 빈번한 데이터의 변경은 처리비용 및 시간을 증대합니다.

기존의 질의 방식(SQL) 및 기법들을 그대로 활용하면서 효율적인 비용으로 확장 가능한 솔루션을 어떻게 구축할까요?

하둡은 데이터웨어하우스에서 ETL 과정을 분리하여 최적화된 솔루션을 제공합니다.

기존의 저장된 것들은 그대로 이용하고 추출 및 변환 단계는 Flume이나 Pig등을 이용해 하둡 클러스터 상에서 하게 되는 것이죠.

이렇게 하게되면 데이터 웨어하우스에는 변환된 데이터를, 원래데이터는 원래 형식 그대로 하둡 클러스터에 저장하는 것입니다.

추천 엔진(Recommendation Engine) 사례

쇼핑 사이트는 개별 고객의 취향에 맞는 상품을 적절한 시점에 추천해야합니다.
그래서 머신러닝 알고리즘을 적용하곤 합니다.

추천을 위해 사용하는 고전적인 머신러닝 알고리즘으로는 협업필터링(collaborative Filtering)이 있습니다.

협업 필터링 알고리즘은 서로 다른 사용자들 사이의 선호도를 비교하여 추천이나 예측에 사용되는 모델을 생성합니다.

쉽게 말해 스타워즈를 좋다고 평가한 bob에게 똑같이 스타워즈를 좋다고 평가한 sued와 tom이 동시에 좋다고 했던 인디아나존스를 추천해주는 모델이라고 보면 됩니다.

이러한 ML 모델을 적용해보기 위해서는 과거 사용자의 선호 히스토리를 나타내는 대규모 데이터 셋을 오프라인으로 하둡 클러스터에 적재합니다.

여느 ML 모델 구축시에 그렇듯 test, train 데이터로 나눠주고요.

이들 데이터셋이 협업 필터링 모델을 학습에 사용되고, 생성된 모델에 대한 평가를 진행합니다.

이 때 Apache Spark나 Mahout과 같은 머신러닝 응용 어플리케이션을 사용하여 추천시스템을 구축합니다.

물론 사용자 데이터가 추가될수록 모델의 성능은 좋아지고 추천은 효과적이겠지요.

대규모 로그 분석(Large-Scale Log Analysis) 사례

사용자의 웹사이트 사용 패턴을 파악하기 위해 클릭 스트림 데이터를 로그파일에 저장합니다.

예를 들어 서버의 로그는 컴퓨터 시스템의 사용자 접속이나 사용한 응용프로그램, 에러 등과 같은 시스템과 응용의 이벤트를 기록하게됩니다.

서버 로그의 경우 특정 기간동안 수집되어 실시간으로 분석한 후 저장공간의 한계 상 폐기하게 됩니다.
그러다보니 향후 유용하게 활용될 수 있는 데이터가 손실됩니다.
하지만 이벤트 발생일시와 시간단위로 조직화되어서 중첩된 형식으로 저장되기 때문에 SQL과 같은 분석툴로는 중첩 데이터 등은 처리가 어렵습니다.
효율적인 비용으로 모든 히스토리의 대규모 로그들을 저장하고 분석하는 새로운 로그 분석 기법이 필요합니다.

Apahe Drill은 효율적인 비용으로 다양한 소스로 부터의 반구조화된 대규모 로그 데이터를 배치로 분석하거나 실시간으로 분석할 수 있습니다.

뿐만아니라 이러한 데이터들을 클러스터에 저장해두면 머신러닝 및 통계 분석으로 데이터를 분석하여 이상 행동 패턴을 감지하여 서버해킹을 탐지하는 등의 지능적이고 유용한 정보를 제공할 수 있습니다.

또한 서버특정이 아닌 이러한 히스토리 데이터들은 포렌식 분석 또는 조사(과학수사, 범죄 규명)을 수행할 수 있습니다.

개인이 공부하고 포스팅하는 블로그입니다. 작성한 글 중 오류나 틀린 부분이 있을 경우 과감한 지적 환영합니다!