빅데이터

[빅데이터] 빅데이터 시작하기

jolocal 2024. 4. 22. 15:49
728x90

빅데이터

일단 데이터가 있고, 나중에 테이블을 설계하는 것이 빅데이터다.

 

오라클 공식 홈페이지에서는 3V를 말하지만 책에서 말하는 빅데이터는 위와 같다. 책의 이름이 빅데이터를 지탱하는 기술이다. 당연히 빅데이터를 취급하는데 여기에는 두가지 문제가 있는데 이 책에서는 2번에 집중한다.

 

1. 데이터의 분석 방법을 모른다.

2. 데이터 처리에 수고와 시간이 걸린다.

 

용어 정리

테이블의 칼럼 명과 데이터형, 테이블 간의 관계 등을 스키마(schema)라고 하며, 스키마가 명확하게 정의된 데이터를 구조화 데이터(structured data)라고 한다. 하지만 빅데이터는 항상 구조화된 데이터만 있는 것이 아니라, 자연어로 작성된 테스트 데이터와 이미지, 동영상 등의 데이터도 포함한다. 이를 비구조화데이터(unstructured data)라고 하며, 이 상태로는 SQL을사용해 집계할 수 없다. 한편 CSV,JSON,XML처럼 서식은 정해져있지만 칼럼수나 데이터 형은 명확하지 않은 데이터를 스키마리스 데이터(schemaless data)라고 한다. 대표적으로 mongoDB가 스키마리스 데이터에 대응하고 있다.  

 

1. 데이터 수집

빅데이터는 대부분의 경우 확장성이 높은 분산 스토리지(distributed storage)에 저장된다. 분산 형의 데이터베이스가 이용되는 경우도 있지만, 기본적으로 객체 스토리(object storage)에 저장된다. Haddop이라면 HDFS 클라우드 서비스라면 Amazon S3가 있다.

 

데이터의 읽고 쓰기를 다수의 하드웨어에 분산했기 때문에 데이터의 양이 늘어나도 성능이 떨어지지 않는다. 하지만 이 구조는 데이터양이 많을 때는 우수하지만, 데이터양이 적을 때는 비효율적이다. 100Byte의 작은 파일을 자주 읽고 쓰는 것은 데이터양에 비해 통신 오버헤드가 너무 크기 때문이다.

 

그렇다면 효율적인 파일 크기는 어느정도일까? 대략 1MB ~ 1GB사이다. 이보다 작은 데이터는 모아서 하나로 만들고 큰 데이터는 여러개로 나누는 것을 고려하자. 이렇게 수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 과정을 데이터 수집(data ingestion)이라고 한다. 여기에는 다음 과정이 포함된다.

 

  • 데이터 수집
  • 구조화 데이터 작성
  • 분산 스토리지 장기 저장

 

2. 데이터 전송

 

일반적으로 차례대로 전달해나가는 데이터로 구성된 시스템을 데이터 파이프라인 이라 한다. 데이터 파이프라인은 어디에서 데이터를 수집하며 무엇을 실현하고 싶은지에 의거해 만들어진다.

2-1. Bulk형 파이프라인

DB,파일 서버, 웹 서비스 등에서 각각의 방식(SQL,API 등)으로 정리해 데이터를 추출한다.

과거에 축적된 대량의 데이터가 이미 있거나 기존의 DB에서 데이터를 추출하고 싶을 때도 벌크형의 데이터 전송을 한다.

 

원래 데이터가 처음부터 분산 스토리지에 저장되어 있는 것이 아니라면 데이터 전송을 위한 ETL서버를 설치한다.

 

ETL 서버
구조화된 데이터 처리에 적합한 DW(데이터 웨어하우스)를 위한 ETL 도구와 오픈 소스의 벌크 전송 도구 또는 직접 작성한 스크립트 등을 사용해 데이터를 전송

 

2-2. Streaming형 파이프라인

지금 바로 생성되어 아직 어디에도 저장되지 않은 데이터는 그 자리에서 바로 전송해야 한다. ex) 웹 브라우저, 모바일 앱, 각종 디바이스 등. 이러한 데이터를 벌크 형 도구로 모으는 것은 불가능하므로, 스트리밍 형의 데이터 전송이 필요하다. 이렇게 끊임 없이 제공되는 데이터를 실시간으로 처리하는것을 스트림 처리 (Stream processing)라 한다.

 

이처럼 다수의 클라이언트에서 작은 데이터가 계속 전송되는 방식을 message delivery라 한다. 이 방식은 전송되는 데이터 양에 비해 통신을 위한 오버헤드가 커지기 때문에 더 높은 성능의 서버가 필요하다.

2-3. Default형 파이프라인

 

1. 로그등의 RAW 데이터가 데이터 레이크에 저장된다.

 

  • 데이터 레이크
    WEB, APP 등 여러 곳에서 흘러들어오는 데이터가 쌓이는 호수가 데이터 레이크다. 즉, 데이터레이크란 비구조화 데이터를 분산 스토리지 등에 저장하고 그것을 분산 시스템에서 처리하는 것이 데이터 레이크의 개념이다.

 

2. 데이터 레이크에 저장된 데이터를 필요에 따라 추출(Extract)하고 변환(Transform)하고 저장(Load)해 데이터 웨어하우스에 저장한다.

  • 데이터 웨어하우스 : 업무에 있어서 중요한 데이터 처리에 사용되는, 즉 데이터에 근거한 의사 결정을 내리기 위해 사용되는 중앙 데이터 저장소

3. 의사 결정이 아닌 데이터 분석등의 목적을 위해 사용할 경우에는 필요한 데이터만을 추출해 데이터 마트에 구축한다.

  • 데이터 마트 : 작은 데이터 웨어하우스로 특정 목적을 위해 특정 조직, 팀에서 사용하는 것을 목적으로 하는 스토리지 시스템

2-4. 주의사항

데이터 전송의 신뢰성이 중요한 경우 가능한 한 벌크 형을 사용해야 한다. 스트리밍 형의 데이터 전송은 나중에 재실행하기가 쉽지 않다. 뭔가 문제가 발생했을 때 여러 번 데이터 전송을 재실행할 수 있다는 점이 벌크 형의 장점이다.

 

모바일 회선과 같은 신뢰성이 낮은 네트워크에서는 반드시 메시지의 중복이나 누락이 발생한다. 그것을 어떻게 처리할지는 도입하는 시스템에 따라 다르다.

 

일반적으로스트리밍 형의 데이터 전송에서는 중간에 중복 제거 방식을 도입하지 않는 한 항상 중복의 가능성이 있다. 빅데이터 시스템은 매우 높은 성능을 요구하기 때문에 아주 작은 중복은 무시하는 경향이 있지만 은행, 과금 등의 데이터 처럼 신뢰성이 중시되는 경우에는 벌크 형의 데이터 전송을 사용하자.

 

3. 데이터 저장

받아온 메시지를 저장하는 방법에 대해 알아보자

 

3-1. 분산 스토리지에 직접 쓰기

빅데이터를 위한 분산 스토리지에는 높은 확장성과 데이터를 구조화 하지 않고도 저장할 수 있는 유연성이 요구된다. 객체 스토리지는 임의의 파일을 저장할 수 있다는 점이 장점이지만, 몇몇 단점이 있다.

  1. 객체 스토리지 상의 파일은 교체하기 어렵다.
    1. 때문에 쓰기 빈도가 높은 데이터는 별도 RDB 에 저장하고 정기적으로 스냅샷을 하거나 다른 분산 데이터베이스에 저장하도록 한다.
  2. 객체 스토리지에 저장된 데이터를 집계하기까지 시간이 걸린다.
    1. 열 지향 스토리지를 만듦으로써 집계는 고속화되지만, 작성까지 시간이 걸린다. 데이터를 기록하고 곧바로 호라용하고자 하는 경우에는 실시간 집계와 검색에 적합한 데이터 저장소가 필요하다.

앞선 문제를 해결하기 위한 데이터 저장소를 NoSQL Database라 한다.

 

NoSQL 데이터베이스는 애플리케이션에서 처음에 데이터를 기록하는 장소로 이용된다. NoSQL Database 자체는 대량의 데이터를 집계하는 기능이 없는 것이 많아 데이터 분석을 위해서는 외부로 데이터를 추출해야 하지만 RDB등과 비교하면 읽기 성능이 매우 높아 쿼리 엔진에서 접속해도 성능 상의 문제가 발생하진 않는다.

분산 KVS

Distributed Key-Value Store는 모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소를 말한다. 객체 스토리지도 넓은 의미에서는 분산 KVS의 일종이지만, 여기서는 좀 더 작은 데이터를 가정한다. 구체적으로 몇 KB정도의 데이터를 초당 수만 번 읽고 쓰는 경우다.

Amazon DynamoDB가 대표적이다. 데이터의 읽기 및 쓰기에 지연이 발생하면 곤란한 애플리케이션에 유용하다.

와이드 칼럼 스토어

분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것이다.

 

여기에는 내부적으로 행 키와 칼럼 명의 조합에 대해 값을 저장한다. 테이블에 새로운 행을 추가하는 것과 마찬가지로 칼럼도 얼마든지 추가할 수 있는 구조로 되어 있으며, 수억의 칼럼을 만들 수도 있다. 즉 하나의 테이블에 가로와 세로의 2차원에 데이터를 쓸 수 있다.

Google Colud Bigtable과 Apache Hbase, Apache Cassandra 등이 대표적이다.

도큐먼트 스토어

와이드 칼럼 스토어가 주로 성능 향상을 목표로 하는 반면, 도큐먼트 스토어에서는 주로 데이터 처리의 유연성을 목적으로 한다. 구체적으로 JSON처럼 복잡하게 뒤얽힌 스키마리스 데이터를 그대로희 형태로 저장하고 쿼리를 실행할 수 있도록 한다.

 

최대 장점은 스키마를 정하지 않고 데이터 처리를 할 수 있다는 점이다. 그래서 외부에서 들여온 데이터를 저장하는 데 특히 적합하다. 자체 개발한 애플리케이션 등에서는 명시적으로 스키마를 정하는 편이 좋은 점도 많으므로 도큐먼트 스토어는 주로 참고 시스템의 데이터 및 로그 저장등에 적합하다.

MongoDB가 대표적이지만 대량의 데이터를 집계하는데는 적합하지 않다.

4. 검색엔진

검색 엔진(search engine)은 NoSQL DB와는 조금 성격이 다르지만, 저장된 데이터를 쿼리로 찾아낸다는 점에서는 유사한 부분도 많고, 특히 텍스트 데이터 및 스키마리스 데이터를 집계하는 데 자주 사용된다.

 

검색 엔진의 특징은 텍스트 데이터를 전문 검색하기 위해 역 색인을 만드는 부분이다. 따라서 데이터를 기록하는 시스템 부하 및 디스크 소비량은 커지지만, 그 덕분에 키워드 검색이 훨씬 고속화된다.

 

역색인(Inverted index)
테스트에 포함된 단어를 분해하고 어떤 단어가 어떤 레코드에 포함되어 있는가 하는 인덱스를 먼저 만들어 둠으로써 검색을 고속화 하는 방식

두꺼운 CS책에서 thread에 대한 내용을 찾기 위해 책 가장 뒤에서 thread가 등장하는 페이지를 찾아 해당 페이지를 펴는 방식이다.

 

검색 엔진은 데이터의 집계에 적합하며, 특히 비정상적인 상태의 감지 및 보안 체크, 고객 서포트처럼 민첩성이 요구되는 용도에서 최근의 데이터를 보기 위해 사용된다.

 

검색 엔진은 장기적으로 데이터를 축적하기 보다는 실시간 집계 시스템의 일부로 이용된다.

예를 들어, 메시지가 배송된 데이터를 분산 스토리지에 저장하는 한편, 같은 데이터를 검색 엔진에도 전송하여 실시간 성이 높은 데이터 처리를 위해 활용한다.

 

Elasticsearch가 대표적이다. ElasticSearch는 자체 쿼리 언어에 의한 고급 집계 기능을 제공하고 있다. 열 지향 스토리지에도 대응하고 있어 그것만으로도 데이터를 집계하기 위한 기반이 된다.

 

중계 시스템에 전송하기

kafka, redis와 같은 message broker와 message queue드으이 중계 시스템에 전송한다. 이 경우 기록된 데이터는 일정한 간격으로 꺼내고 모아서 합계 분산 스토리지에 저장한다.

웹 애플리케이션은 webserver안에서 message를 만들어 delivery한다. 이때 전송 효율을 높이기 위해 서버상에서 일단 데이터를 축적해 놓고 나중에 모아서 보내는 서버 상주형 로그 수집 서버인 Fluentd, Logstash 를 사용하기도 한다. 다른 방식으로는 javascript를 사용해 웹 브라우저에서 직접 메시지를 보내는 Web Event Tracking이 있다.

 

message delivery에 의해 보내진 데이터를 분산 스토리지에 저장할 때는 급격한 데이터 증가에 따른 디스크 성능의 한계를 고려해야 한다. 내가용성을 위해서는 어떻게든 쓰기 성능을 높여야 하는데 뭘 사용해야 할까?

 

메시지 브로커

데이터를 일시적으로 축적하는 중간층인 메시지 브로커(message broker)를 사용하면 쓰기 성능을 높일 수 있다. 오픈 소스의 경우 Apache Kafka가 유명하고, 클라우드 서비스라면 Amazon Kinesis등이 유명하다.

메시지 브로커는 높은 빈도로 데이터를 쓰는 것에 최적화되어 있으며, 여러 대의 노드에 부하 분산함으로써 성능을 끌어 올릴 수 있는 뛰어난 확장성을 구현하고 있다.

 

파이프 라인 설계는 대체로 요구 사항에 달려 있어 필요에 따라 시스템을 조합해야 한다. 쓰기 성능에 불안감이 없다면 메시지 브로커는 불필요하므로 클라이언트나 프런트 엔드에서 NoSQL DB에 직접 데이터를 써도 되고, 다소 중복이 허용된다면 중복 제거도 생략할 수 있다.

 

메시지 브로커와 신뢰성

메시지의 중복과 결손은 네트워크와 하드웨어의 일시적인 장애에 따라 발생한다. 가장 치명적인 케이스는 클라이언트에서 수신한 데이터가 손상되는 경우다. 재전송을 받을 수 있지만, 대신 중복의 가능성이 커진다.

메시지 브로커를 사용하면 쓰기 성능이 향상될 뿐 아니라 후속 처리를 안정화 하는데 도움이된다. 예를 들어, 분산 데이터베이스를 유지 보수로 중지하는 경우에도 메시지 브로커만 움직이고 있으면 데이터 수신에 손상을 입는 일은 없다.

하지만 메시지 브로커 자체에 장애가 일어날 수도 있다. 메시지 브로커 내에서 중복이 발생할 가능성이 있기 때문에 시스템을 설계할 때 성능과 신뢰성을 양립할 필요가 있다.

데이터 플로우

복잡한 텍스트 처리나 다단계의 데이터 처리를 그대로 분산 시스템의 내부에서 실행할 수 있는 시스템을 말한다.

ex) Google Cloud Dataflow, Apache Spark, Apache Flink

Batch형 데이터 플로우

3가지 플로우를 조합해 배치형의 데이터 파이프라인을 만들 수 있다.

데이터를 읽어 들이는 플로우

데이터 플로우로부터 읽어 들일 데이터는 안정된 분산 스토리지에 배치해야 한다. 개발 중에는 동일 데이터를 여러 번 읽어 들여 테스트 하므로 분산 스토리지에 복사된 데이터만을 이용한다. 외부 데이터 소스에 여러 번 접속하게 되면 성능 문제가 발생할 수 있기 때문이다.

위 그림처럼 데이터 플로우는 분산 스토리지에 저장된 데이터의 가공 및 열 지향 스토리지로의 변환 등 부하가 큰 처리를 실행하는 것이다.

 

데이터를 써서 내보내는 플로우

데이터 플로우 안에서 대량의 데이터를 외부에 전송하는것은 피해야 한다. 쓰기 작업에 오랜 시간이 걸리면, 아무리 기다려도 실행이 완료되지 않고 자원을 계속해서 소비하거나, 최악의 경우에는 쓰기 작업에 실패하여 처음부터 데이터 처리를 재실행해야 할 수 있기 때문이다.

위 그림처럼 데이터 플로우의 출력은 CSV 파일과 같이 취급하기 쉬운 형식으로 변환하여 일단 분산 스토리지에 써 넣는 편이 좋다.

 

데이터를 검색하는 플로우

두가지 검색 상황을 가정해보자.

1. 데이터 웨어하우스의 파이프라인: SQL을 MPP 데이터 베이스에서 실행하는 경우와

데이터 웨어하우스를 구축할 때는 로드되는 데이터를 만드는 부분가지가 데이터 플로우의 역할이다. 비구조화 데이터를 가공하여 CSV 파일 등을 만들어 분산 스토리지에 써 넣는다. 그 이후의 테스크 실행이나 SQL에 의한 쿼리의 실행은 워크플로우에 맡긴다.

 

2. 데이터마트의 파이프라인: SQL을 분산 시스템상의 쿼리 엔진에서 실행하는 경우

쿼리 엔진을 사용하여 데이터 마트를 구축할 경우에는 구조화 데이터를 만드는 부분까지가 데이터 플로우의 역할이다. 분산 스토리지 상의 데이터를 매일 반복되는 배치로 가공하여 열지향의 스토리지 형식으로 보관해둔다. 쿼리 엔진을 사용한 SQL 실행이나 그 결과를 데이터마트에 써서 내보내는 것은 워크 플로우에 맡긴다.

Streaming형 데이터 플로우

배치 처리를 중심으로 하는 데이터 파이프라인의 단점은 데이터가 분석할 수 있게 될 때까지 시간이 걸린다는 것이다. 집계 효율을 높이기 위해 열 지향 스토리지를 만들려 하면, 데이터를 모아서 변환하는 데 시간이 걸리기 때문이다.

 

여기서 실시간이란 대체로 이벤트 발생에서 몇 초 후에는 결과를 알 수 있는 것을 가리킨다. 이번 졸업 작품의 데이터 처럼 결과를 1시간 후에 알아도 된다면, 배치 처리로도 할 수 있으므로 스트림 처리는 필요 없다.

 

아래는 스트림 처리가 필요한 작업이다.

  • 시스템 모니터링
    • 서버와 네트워크 상태를 감시하고, 그 시간 추이를 그래프로 표시한다.
  • 로그 관리 시스템
    • OS의 시스템 이벤트나 로그 파일을 검색해서 비정상적인 상태라면 경고를 생성한다.

앞서서 여러 단말에서 전달받은 데이터를 분산 스토리지에 보관하는 부분부터 시작했던 프로세스가 배치 처리(Batch processing)라고 한다면, 분산 스토리지를 거치지 않고 처리를 계속하는 것이 스트림 처리(Stream processing)다. 그러므로 과거의 데이터에 관심이 있다면 배치 처리가 우수하고 앞으로 도달할 데이터 관심이 있다면 스트림 처리 쪽이 우수하다. 이 둘은 서로의 결점을 보완하는 관계다. 따라서 상황에 따른 선택이 문제 해결에 있어서 중요하다.

 

배치 처리와 스트림 처리 통합하기

배치 처리에서는 먼저 데이터가 있고, 그것을 작게 나눠서 DAG에 넣는다. 한편 스트림 처리에서는 끊임없이 데이터가 생성되며, 그것이 DAG안에 흘러들어옴에 따라 처리가 진행된다.

 

배치 처리와 같이 실행 시에 데이터 양이 정해지는 것을 유한 데이터(bounded data)라고 하고, 스트림 처리와 같이 제한이 없이 데이터가 보내지는 것을 무한 데이터(unbounded data)라고 한다. 이 둘 모두 데이터를 작게 분할해서 DAG에서 실행한다.

 

그래서 DAG를 사용한 데이터 플로우에서는 배치 처리와 스트림 처리를 동일하게 프로그래밍하는 것이 가능하다.

Spark는 원래 배치 처리를 위한 분산 시스템이었지만, Spark Streaming이라 불리는 기능이 통합되어 현재는 스트림 처리까지 취급하는 프레임 워크가 되었다. 이 Spark를 예로 들어보자.

 

SPARK

단어를 세는 Spark 배치 프로그램

// 파일로부터 데이터를 읽어들인다.
lines = sc.textFile("sample.txt")

// 파일의 각 행을 단어로 분해
words = lines.flatMap(lambda line: line.split())

// 단어마다의 카운터를 파일에 출력
words.map(lambda word: (word, 1))
	.reduceByKey(lambda a, b: a b)
    .saveAsTextFile("word_counts") // 여기서 실행 개시

 

단어를 세는 Spark 스트리밍 프로그램

// 1초마다 스트림 처리를 한다.
sc = SparkContext("local[2]", "NetworkWordCount")
ssc = StreamingContext(sc,1)

// TCP 포트 9999로 부터 데이터를 읽어들인다.
lines = SSC.SOCKETtEXTsTREAM("localhost", 9999)

// 입력의 각 행을 단어로 분해한다.
words = lines.flatMap(lambda line: line.split())

// 단어별 갯수를 콘솔에 출력한다.
words.map(lambda word: (word,1))
	.reduceByKey(lambda a, b: a + b)
    .print()
    
// 스트림 처리를 시작한다.
ssc.start()

 

스트림 처리의 문제와 해결방안

아래는 스트림 처리의 두가지 잠재적 문제이다.

 

1. 틀린 결과를 어떻게 수정할 것인가?

스트림 처리는 새롭게 도달한 데이터를 처리하기 때문에 버그나 일시적인 장애 등으로 잘못된 데이터를 처리할 수 있다.

 

2. 늦게 전송된 데이터 취급은 어떻게 할 것인가?

메시지 배송(message deliver)에는 지연이 발생하는데, 집계가 종료된 후에 지연된 데이터가 도착하면 결과가 부정확해질 수 밖에 없다.

 

전통적인 해결방법은 스트림 처리와는 별개로 배치 처리를 실행해 배치 처리의 결과가 옳다고 하는 것이다. 이것을 발전시킨 방법으로 람다 아키텍처(lambda architecture)가 있다.

 

  • 모든 데이터는 반드시 배치 레이어(batch layer)에서 처리한다.
    • 대규모 배치 처리를 실행할 수 있지만 시간이 오래 걸린다.
  • 배치 처리 결과는 서빙 레이어(serving layer)에서 처리한다.
    • 배치 처리 결과(배치 뷰)에 접근한다.
  • 스트림 처리는 스피드 레이어(speed layer)에서 처리한다.
    • 다른 경로로 스트림 처리를 하기 위해 사용한다. 처리 결과는 실시간 뷰에 저장된다. 실시간 뷰는 배치 뷰가 업데이트될 동안까지만 이용되고, 오래된 데이터는 순서대로 삭제된다.

배치 뷰와 실시간 뷰 모두를 조합시키는 형태로 쿼리를 실행한다. 최근 24시간의 집계 결과는 실시간 뷰를 참고하여 그 이전의 데이터에는 배치 뷰를 사용할 수 있다. 이 조합에 의해 배치처리와 스트림 처리의 결점을 보완하고자 하는 것이 람다 아키텍처다. 결국 배치 처리만 안정되게 동작하고 있다면 스트림 처리를 다시 실행할 필요가 없다.

 

람다 아키텍처에서는스피드 레이어와 배치 레이어가 동일한 처리를 구현하고 있기 때문에 효율이 좋지 않다.

그래서 배치 레이어와 서빙 레이어를 완전히 제거해 스피드 레이어만 남기는 대신, 메시지 브로커의 데이터 보관 기간을 충분히 길게 해 문제가 발생했을 때 메시지 배송 시간을 과거로 다시 설정하는 카파 아키텍처 또한 사용된다. 

 

두 코드를 비교해보면 데이터를 읽고 쓰는 초기화 부분에서 차이가 있을 뿐, 데이터 처리의 중심부 (Map 처리와 Reduce 처리)는 똑같다는 것을 알 수 있다.

분산 데이터 처리기술

분산 스토리지에 수집된 데이터는 명확한 스키마를 갖지 않는 것이 많다. 따라서 스키마를 명확하게 한 테이블 형식의 구조화 데이터로 변환하는 것이 필요하다. 일반적으로 구조화 데이터는 데이터의 압축률을 높이기 위해 열 지향 스토리지로 저장한다. 이 과정, 즉 비구조화 데이터를 읽어 들여 열 지향 스토리지로 변환하는 과정에서는 데이터의 가공 및 압축을 위해 많은 컴퓨터 리소스가 소비되는데 여기서 사용되는 것이 하둡 과 스파크 등의 분산 처리 프레임워크다.

하둡(Hadoop)

하둡은 단일 소프트웨어가 아니라 분산 시스템을 구성하는 다수의 소프트웨어로 이루어진 집합체이다.

 

  • 분산 파일 시스템 : hdfs
  • 리소스 관리자 : yarn
  • 분산 데이터 처리 : mapreduce

이렇게 3가지 기본 구성 요소로 되어 있고, 그 외 프로젝트 hive,spark는 하둡 본체와는 독립적으로 개발되어 hadoop을 이용한 분산 애플리케이션으로 동작한다.

 

그렇다고 모든 분산 시스템이 hadoop에 의존하는것은 아니다. 일부만 사용하거나 전혀 사용하지 않을 수도 있다. 예를 들어 분산 파일 시스템으로 hdfs, 리소스 관리자는 mesos, 분산 데이터 처리에는 spark를 사용할 수도 있는데, 이처럼 다양한 소프트웨어 중에서 상황에 맞는 것을 선택하고 그것들을 조합함으로써 시스템을 구성하는 것이 하둡을 중심으로 하는 데이터 처리의 특징이다.

 

hdfs

하둡에서 처리되는 대부분의 데이터는 hdfs에 저장된다. 이는 네트워크에 연결된 파일 서버와 같은 존재이지만, 다수의 컴퓨터에 파일을 복사하여 중복성을 높인다는 특징이 있다.

yarn

한편 cpu나 메모리등의 계산 리소스는 리소스 매니저인 yarn에 의해 관리된다. yarn은 애플리케이션이 사용하는 cpu와 메모리를 컨테이너라 불리는 단위로 관리한다. 하둡에서 분산애플리케이션을 실행하면 yarn이 클러스터 전체의 부하를 보고 비어있는 호스트부터 컨테이너를 할당한다. 

mapreduce 

mapreduce도 yarn상에서 동작하는 분산 애플리케이션 중 하나이며, 분산 시스템에서 데이터 처리를 실행하는데 사용된다. 이는 자바 프로그램을 실행시킬 수 있으므로 비구조화 데이터를 가공하는데 적합하다. 이를 대체하기 위해 아파치 tez또한 개발되었다. mapreduce대신 tez를 사용하면 더 빠른 집계가 가능하다. 그래도 MapReduce의 구조를 살펴보는것은 의미가 있다.

 

 

MapReduce의 구조

텍스트 파일에 포함된 단어를 세는 처리를 생각해보면 그 과정은 아래와 같다.

 

1. 원본 데이터: 데이터데이트

2. 분한된 데이터: 데이  터데  이트

3. 단어별로 그 수를 카운트: (데,1)(이,1)  (터,1)(데,1)  (이,1)(트,1)

4. 단어별 합계 계산 : (데,2)(이,2)(트,1)

이 과정이 분할된 데이터를 처리하는 첫번째 단계인 Map

 

5. 결과 출력 : 데 = 2, 이 = 2, 트 = 1

이 과정이 3번에서 처리한 결과를 모아 집계하는 단계인 Reduce

 

이렇게 Map과 Reduce를 반복하면서 원하는 결과를 얻을 때 까지 계속해서 데이터를 변환해나가는 구조가 MapReduce 다.

 

MapReduce의 한계

맵리듀스는 맵과 리듀스의 하나의 사이클이 끝나지 않으면 다음 처리로 이동하지 않는다. 그러므로 맵과 리듀스를 반복해야 하는 복잡한 데이터 처리에서는 한 사이클에서 다음 사이클로 넘어가는 대기 시간이 길어진다.

 

물론 Map과 Reduce를 반복한다는 사고방식은 최신 기술에서도 유효하지만, 초기 MapReduce의 구현은 쓸데없는 것이 많아서 요즘에는 자주 샤용되지 않는다.

 

MapReduce를 대신할 프레임워크

Spark, Hive on Tez 등 최신 프레임워크에 공통으로 들어가는 것이 DAG(Directed Acyclic Graph)라 불리는 데이터 구조다. DAG는 번역하면 방향성 비순환 그래프이다.

 

쉽게 기존의 맵 리듀스를 관광 열차로 DAG를 개인 차량으로 보면 된다. 기존의 맵 리듀는 관광 열차에 손님을 꽉 채워서 한 섬의 투어가 끝나면 다른 섬으로 다시 관광 열차를 꽉 채워 이동했지만, DAG에서는 한 섬의 투어가 끝난 손님은 개인 차량으로 다른 섬으로 이동시킨다. 때문에 관광 열차에 손님이 타는 시간, 즉 하나의 사이클이 끝나지 않으면 당므 처리로 이동하지 않는 대기시간을 없앤다.

 

어떻게 보면 DAG는 데이터 플로우 그 자체가 아닐까? 데이터의 입출력을 모두 하나의 DAG로 기술할 수 있기 때문이다.

 

한편 hive는 sql등의 쿼리 언어에 의한 데이터 집계를 목적으로 하는 쿼리 엔진이다. 쿼리를 자동으로 mapreduce프로그램으로 변환하는 소프트웨어로 개발되었다. 이들은 대량의 데이터를 배치 처리하기 위해 한정된 리소스를 유효하게 활용하는 시스템이다. 이와 반대로 대화형의 쿼리 실행을 목표라 사용할 수 있는 리소스를 최대한 활용해 쿼리를 실행하는 대화형 쿼리 엔진인 impala와 presto가 있다.

 

하둡에서는 이처럼 성질이 다른 쿼리 엔진을 목적에 따라 구분한다, 대량의 비구조화 데이터를 가공하는 무거운 배치처리에는 높은 처리량(throughput)으로 리소스를 활용할 수 있는 하이브를 이용항며 이렇게 완성된 구조화 데이터를 대화식으로 집계하고자 할 때는 지연이 적은 impala와 presto를 사용한다.

스파크(Spark)

 

한편 대량의 메모리를 활용하여 고속화를 실현하는 스파크는 가능한한 많은 데이터를 메모리상에 올려 빠른 데이터 처리를 실현하는 분산 데이터 처리 엔진이다.

 

스파크는 하둡을 대체하는 것이 아니라 Mapreduce를 대체하는 존재다. 여기에는 sql로 쿼리를 실행하기 위한 spark sql과 스트림 처리를 수행하기 위한 spark streaming이라는 기능이 처음부터 포함되어 있다. 따라서 대규모 배치처리 뿐만 아니라 sql에 의한 대화형 쿼리 실행과 실시간 스트림 처리에 이르기까지 널리 이용되고 있다.

 

프레임워크 선택

  • Hive
    • Hive는 데이터양에 좌우되지 않는 쿼리 엔진이다.
    • Hadoop상의 분산 애플리케이션은 원래부터 높은 확장성과 내결함성을 목표로 설계되어 있다. Hive는 그 연장 선상에서 개발된 쿼리 엔진으로 대규모 배치 처리를 위해 주로 사용된다.
    • 텍스트 데이터를 가공하거나 열 지향 스토리지를 만드는 등의 무거운 처리는 처리 시간이 길어지므로 Hive에서 실행하는 것이 적합하다.
  • Presto
    • Presto는 속도를 중시하는 대화식 쿼리 엔진이다.
    • 표준 SQL을 준수하고 있으며 일상적인 데이터 분석을 위해 자주 사용된다. Hadoop뿐만 아니라 MySQL과 카산드라, 몽고DB등 많은 데이터 스토어에 대응하고 있어 모든 데이터를 SQL로 집계할 수 있다.
    • 단시간에 대량의 리소스를 소비해 빠른 속도를 만들기 때문에 텍스트 처리가 중심이 되는 ETL 프로세스 및 데이터 구조화에는 적합하지 않다.

  • Spark
    • Spark는 분산 시스템을 사용한 프로그래밍 환경이다.
    • ETL 프로세스에서 SQL에 이르기 까지의 일련의 흐름을 하나의 데이터 파이프라인으로 기술할 수 있다. 즉 Hive에 의한 데이터 구조화와 Presto에 의한 SQL의 실행 모드를 하나의 스크립트 안에서 실행할 수 있다는 것이 장점이다.
    • Spark는 인메모리의 데이터 처리가 중심이다. 때문에 데이터를 어떻게 관리하느냐가 중요하다. 여러번 이용하는 데이터를 캐시에 올려놓거나, 디스크에 스왑(swqp)시킴으로써 메모리를 해제하는 등 메모리의 사용을 개발자가 어느정도 제어할 수 있다.
    • 이처럼 Spark는 프로그래밍 환경이므로, 일단 사용법을 익혀두면 ETL 프로세스이거나 머신러닝 같은 모든 데이터 처리에 사용할 수 있다.

정리

728x90