[빅데이터 기초3] - 빅데이터 저장,관리 그리고 처리기술 (NoSQL, Hadoop)

 

- 들어가며

 

  이번 포스팅에서는 빅데이터 기초2 포스팅에 이어 수집된 데이터들을 어떻게 저장하고 관리하는지

즉, 빅데이터와 관련된 데이터 저장기술 및 관리기술에 대해서 알아보도록 하겠습니다.

이번 포스팅도 마찬가지로 빅데이터들을 저장하고 관리하는 기술에 대한 소개정도이며 구체적인인 내용은

다른 포스팅에서 다루도록 하겠습니다.

​

​

- 데이터를 어떻게 저장해야할까?

여러분들은 데이터를 어떻게 저장하고 계신가요?

여러분의 컴퓨터 HHD나 SSD에만 저장하시는 분들도 있겠지만 외장하드, USB, 클라우드 등을 이용하시는 분들도 많을텐데요. 이렇게 개인적으로 사용하는 데이터들은 각자 그냥 어떠한 저장공간에 저장만하면 되겠지만

​

데이터를 조직단위에서 저장하고 관리하게 된다면 이렇게 저장공간에만 저장해서 꺼내쓰는 것은 상당히 비효율적이게 됩니다.

​1. DB(DataBase)

그래서 빅데이터에 관심이 있으신분들은 아마 DB(데이터베이스)에 대해서 공부하거나 한번쯤은 들어보셨을텐데요. 이렇게 조직단위에서는 DB에 데이터를 일정한 규격에 맞게 처리하여 DBMS를 통해 관리를 합니다.

그렇게 때문에 데이터쪽에 종사하고 계신분들은 SQL이라는 질의어를 기본적으로 다루고 계실겁니다.

​

DB​ (Database) : DB에 대해서 모르시는 분들은 DB는 데이터들을 일정한 규격화하여 모아놓은것이라고 생각하시면될 것 같습니다.

DBMS(DataBaseManagementSystem) : 데이터베이스를 관리하기위한 툴이라고 생각하시면 되겠습니다.

데이터베이스, SQL등은 다른 포스팅에서 더 자세하게 다루도록하겠습니다.

​

SQL은 RDBMS(DBMS는 거의 대부분RDBMS임)데이터 관리를 위해 설계된 전통적인 언어입니다.

당연히 기존의 RDBMS는 정형화된 데이터들을 저장하고 관리하기에는 적합하지만...

​

여러분들이 facebook, twitter, blog 등 SNS에 올린 사진,댓글,동영상,음원파일 ,게시물 등을 아무리 SQL을 잘한다고해도 DB에 넣을 수 있을까요?

​

댓글같은 경우는 어느정도 전처리를 통해서 DB에 넣는 것이 가능하긴 하겠지만 의미도 없을 것이며

동영상, 이미지파일, 음원파일 등등 다양한 데이터 종류들은 기존의 DB에 저장하여 관리하는 것이 불가능합니다.

그 외에도 하나의 서버로는 DB를 저장하고 관리하기 힘들정도로 많아진다면

기존의 RDBMS 들로 저장, 관리가 불가능해집니다.

​

앞선 포스팅에서 다뤘던 내용처럼 빅데이터란 기존의 데이터 저장 및 처리기술로 감당할 수 없는 데이터를 말한다는 것을 기억하시나요?

​

그래서 기존의 DB,DBMS, SQL 등 이러한 데이터베이스관련 툴들로 다루기 힘든 데이터들을 다루기위해 등장한 데이터 저장기술과 처리기술들에 대해서 알아보도록 하겠습니다.

​

​

2. NoSQL

NoSQL은 SQL에서 주로 다루던 관계형 데이터베이스가 복잡하게 관계형 구조를 짜야하고 스키마도 있고하니

편하게 문서형 데이터를 저장할 수 있는 방법이 없을까? 하고 나온기술이면서도 RDBMS 한계를 극복 할 수 있는 기술입니다. RDBMS의 한계점도 확인해보실까요?

​

#RDBMS의 한계점

① RDBMS는 데이터양이 너무 많아지면 RDB의 스키마에 맞춰 변경해서 넣으려면 매우 긴시간의 down time

(시스템이용불가시간)이 발생합니다.

② 스케일아웃의 한계 : RDBMS는 애초에 스케일 아웃을 염두에 두고 설계된 것이 아니기 때문에 관계 모델과 트랜잭션 연산, 일관성, 속성을 유지하면서 분산환경(스케일아웃)에서 RDBMS를 조작하는 것은 너무어렵습니다.

*스케일아웃(Scaleout : 접속된 서버의 대수를 늘려 처리능력을 향상시키는 것)

​

이러한 RDBMS의 한계점을 해소하기 위해서 등장한 NoSQL은

Not only SQL이라는 뜻으로 단순히 기존 관계형 DBMS가 갖고 있는 특성뿐만 아니라

다른특성들을 부가적으로 지원하며 SQL 언어도 사용가능합니다.

​

이러한 NoSQL의 기술적 특징을 살펴보면 다음과 같습니다.

​

#NoSQL의 기술적 특징

1. 無 스키마 ​: RDBMS는 데이터의 관계를 Foreign Key 등으로 정의하고 join 등 관계형 연산을 하지만 그러한 SQL의 RDBMS와는 달리 데이터를 모델링하는 고정된 데이터 스키마 없이 Key값을 이용하여 다양한 형태의 데이터를 저장하고 접근하게 합니다. NoSQL은 관계를 정의하지 않는다는점!

​

2. 분산형 구조 : NoSQL은 분산형 구조를 통해 여러대의 서버에 분산하여 저장하고 상호복제하여 데이터 유실이나 서비스 중지에 대비 할 수 있습니다.

​

3. CAP이론 준수 : 분산형 구조는 일관성(Consistency), 가용성(Availability), 분산허용(Partitioning Tolerance)의 3가지 특징을 가지고 있고 CAP이론은 이 중 2가지만 만족할 수 있다는 이론입니다. NoSQL은 대부분이 이 CAP이론을 따르고 있습니다.

CAP 이론 개념

* 일관성(Consistency) : 분산된 노드 중 어느 노드로 접근하더라도 데이터 값이같아야 한다.

이는 분산된 환경에서 모든 노드가 같은 시점에 같은 데이터를 보여줘야한다는 뜻입니다.

 

* 가용성(Availability) : 클러스터링된 노드 중 하나 이상의 노드가 실패하더라도 정상적으로 요청을 처리할 수

있는 기능을 제공한다. 즉 일부 노드가 다운되어도 다른 노드에 영향을 주지 않아야 함

을 의미합니다.

*지속성(Partition Tolerance) : 노드 간에 통신하는 네트워크가 장애가 나거나 일부데이터를 손실해도 시스템

은 정상적으로 작동해야하는 것을 의미합니다.

​

#NoSQL 기술이 적용된 DB 종류( NoSQL DB의 종류)

1.Key-Value type DB

: Key와 Value의 쌍으로 데이터가 저장되는 유형의 DB로써 Amazon의 Dynamo Paper에서 유래되었습니다.

대표적으로 가장 많이 사용되는 Key-Value DB는 Amazon의 DynamoDB가 있다고 합니다.

이외에도 redis, memcached, Oracle Coherence 같은 key-value 타입의 DB 제품들도 있습니다.

​

2.Column type DB

: 이 기술이 적용된 DB도 여전히 Key를 사용하지만, Key가 여러 개의 컬럼을 가리키고 컬럼은 컬럼 패밀리라는 것에 의해 따라 정렬 되어진다고 합니다.

​

3. Document type DB

: Document 유형의 DB는 기본적으로 key-value DB의 차세대 버전인데요

이 유형의 DB도 기본적으로 Key-value DB와 비슷하다고 합니다.

이 유형의 모델에서는 반 정형화된 document들이 JSON과 같은 포맷으로 저장되어집니다.

대표적으로는 MongoDB, CouchDB가 있다고합니다.

​

4. Graph type DB

: RDB는 데이터를 적재하고 빠르게 조회하기 위한 관점에서 만들어진 반면 Graph DB는 이와 다른관점에서 나온 DB인데요, 오일러 그래프 이론에서 착안되었다고 합니다. SQL의 RDB에서 표현하기 어려운 데이터간의 연결관계들을 표현하는데 유용한 DB입니다.

만약 위 그림과 같은 연결관계를 RDB에서 표현하려고 한다면 상상도 못할정도로 힘든 작업이 될 겁니다.

하지만 GraphDB라면 쉽게 표현할 수 있다는 점이 장점입니다. 이런 GraphDB는 아무래도 Facebook, 카카오, Netflix 등에서 도입하여 사용중이라고 합니다.

​

이러한 Graph type의 DB로는 neo4j, Sones GraphDB 등이 있습니다.

​

3. HaDoop(하둡)

HaDoop은 가장 대표적인 빅데이터 저장시스템이라고 할 수 있는데요

대용량 데이터 처리를 위한 분산처리 프레임워크를 하둡이라고 합니다.

(프레임워크 : '설계와 구현을 재사용 하게끔 라이브러리들을 협업화 해놓은 Tool'이라고 이해하시면 될 것 같습니다.)

​

이러한 하둡의 특징을 살펴보면 다음과 같습니다.

​

#하둡의 특징

1. 하둡은 오픈소스 프로젝트이므로 소프트웨어 라이선스에 대한 비용부담이 없다

2. 구글의 파일시스템과 상당히 유사하다.

3. 하둡 분산 파일 시스템은 네트워크의 여러 서버에 존재하는 디스크들을 마차 하나의 디스크처럼 활용할 수 있다.

4. 일반적인 파일 시스템처럼 볼륨 기반으로 파일을 적재하거나 파일 단위로 저장하지 않고,

파일을블록 단위로 쪼개서 여러 서버에 분산하여 저장한다. -> 서버의 디스크 용량보다 큰 대용량 파일도 저장 가능

​

이러한 특징을 지닌 하둡의 장단점을 살펴보자면 다음과 같습니다.

​

#하둡의 장점

1. 손쉬운 확장

:기존의 장치는 미리 데이터의 크기를 예측해서 구축해야하고 한번 구축된 후에는 확장이 어려운 반면

하둡은 서버를 증설하여 노드를 설치/실행만 하면 용량이 자동으로 늘어납니다.

​

2. 메타 정보의 중앙 집중적관리

: 파일의 메타 정보를 네임 노드에서 중앙 집중적으로 관리하므로, 데이터 노드에 문제가 생기더라도 파일 손실

위험 없이 관리가 가능합니다. (메타 정보?/ 메타 데이터란? : 다른 데이터를 설명하는 데이터를 말합니다.

3. 디스크 입출력과 네트워크 부하 분산

: 파일이 분산되어 저장되있기 때문에 입출력과 네트워크 등이 각 서버로 분산되는 효과가 있습니다.

4. 안정적인 데이터관리

: 파일의 복제본을 분산시켜 관리 할 수 있으므로 데이터의 안정성 확보가 가능합니다.

​

#하둡의 단점

1. 저장파일 수의 제한

: 파일의 메타 정보를 모두 네임노드에서 관리하기 때문에 네임 노드 서버의 메모리 크기만큼만 파일수가 제한됩니다.

​

2. 랜덤쓰기 지원불가, 즉 불변파일만 저장

: 파일은 한번 저장한 것은 변경되지 않는다고 가정하기 때문에 하둡은 파일을 저장하고 파일에 대해 스트리밍 방식의 읽기 요청 위주인 응용이나 배치 작업 등에 적합니다. 이러한 제약들 때문에 파일 처리를 주로하는 기존 솔루션이나 시스템을수정없이 하둡 분산 파일 시스템에 적용할 수 없습니다. 만약 변경이 필요하면 덮어쓰기를 해야합니다.

​

이렇게 하둡의 장단점을 알아보았습니다. 이번에는 이러한 하둡이 어떻게 구성되어있는지를 살펴보도록 할게요.

하둡의 장단점에서 나왔던 네임노드, 데이터 노드 라는 단어들이 하둡의 구성요소인데 이것들이 정확히 무엇인지 알아보도록 하겠습니다.

​

​

​

#하둡의 구성요소

하둡은 크게 2가지 구성요를 가지고 있습니다.

하나는 HDFS이고 다른 하나는 MapReduce인데요. 하나씩 살펴보도록 하겠습니다.

​

1. HDFS(Hadoop Distributed File System) = 분산저장기술

: HDFS는 하둡이라는 프레임워크를 위해 자바 언어로 작성된 분산 확장 파일 시스템입니다. HDFS는 여러 기계에 대용량 파일들을 나누어서 저장하는데 데이터들을 여러 서버에 중복해서 저장하는 역할을 합니다.

​

-HDFS의 구조

-1. 네임노드

: 파일 시스템의 네임스페이를 관리하는 서버라고 할 수있는데요.

트리, 모든파일과 디렉토리 구조, 액세스 권한 등과 같은 메타 데이터를 관리하는 서버를 네임노드 라고 합니다.

​

- 2. 보조 네임노드

: 네임노드의 장애복구를 위한 하둡의 매커니즘중에 하나로서 보조 네임노드의 주 역할은 에디트 로그가 너무 커지지 않도록 주기적인 네임스페이스 이미지를 에디트로그와 병합하여 새로운 네임스페이 이미지를 만드는 것이라고 하네요.

​

-3. 데이터 노드

: 데이터 노드는 파일 시스템의 실질적인 부분으로서 클라이언트나 네임노드의 요청이 있을 때,

블록을저장하고 탐색하며, 저장하고 있는블록의 목록을 주기적으로 네임노드에 보고하는 역할을 합니다.

 

이러한 하둡의 구성요소들을 전체 구성도 그림을 통해서 확인해보시면 이해하시는데 도움이 될 것 같습니다.

​

2. MapReduce = 분산처리 기술

MapReduce는 HDFS에 분산저장된 데이터들을 분산처리하는 기술입니다.

구글에서 발표한 대용량 데이터 처리를 위한 분산 프로그래밍 모델로서

MapReduce의 개념은 하나의 큰 데이터를 여러개의 조각으로 나누어 처리하는 Map단계와

처리된 결과를 하나로 모아서 취합한 후 결과를 도출해내는 Reduce단계로 구성되어 집니다.

​

#MapReduce의 데이터 처리 절차 알고리즘

1. 분할(Spliting) : HDFS의 각 데이터 셋을 라인단위로 분할합니다.

2. 매핑(Mapping) : 분할된 라인 단위의 데이터 셋을 Map함수에 전달하면

Map함수는 필요한 분석 대상만 추출합니다. (key, Value를 목적에 맞게 재지정)

이후 분석 대상의 값도 추출해주면 맵함수가 끝나면서 임시 데이터 결과가 메모리에 저장됩니다.

3. 셔플링(shuffling) : 메모리에 저장되어 있는 맵 함수의 출력 데이터를 key-value형태로 정렬하여 reduce함수에게 보냅니다.

4. 리듀싱(reducing) : 맵 함수로부터 받은 key-value들을 key기준으로 value값을 합계를 내어 출력합니다.

​

이 MapReduce를 예제를 통해 이해해보도록 하겠습니다.

​

​

​

​

다음의 그림에서처럼 HDFS의 저장된 데이터가 입력문서처럼 있을 때 Big, Data, Processing 각 3단어가 몇개나 있는지 빈도수를 구하라는 HDFS 클라이언트의 요청이 있을때 MapReduce를 통해서 다음과 같이 분산처리됩니다.

​

​

​

​

​

그럼 하둡이라는 프레임워크는 구성이 HDFS와 MapReduce 2개밖에 없나요?

위에서 말했듯이 하둡은 크게 HDFS와 MapReduce 2개의 구성요소를 가진다고 했는데 이 2가지외에도 다른

sub project들로 구성되어 있습니다.

하둡의 여러 서브프로젝트들

위 그림에서 보이는 것처럼 하둡은 비즈니스에 효율적으로 적용할 수 있게 하기 위해서 다양한 서브 프로젝트가 제공됩니다. 이러한 다양한 서브 프로젝트들의 모임을 '하둡 에코시스템(Hadoop-Eco System)'이라고 합니다.

​

하둡 코어프로젝트 : HDFS(분산저장), MapReduce(분산처리)

하둡 서브프로젝트 : 이외의 프로젝트들 -> 데이터 수집, 분석 등 데이터 처리와 관련된 것을 수행

​

하둡 에코시스템

​

마지막으로 하둡의 서브 프로젝트들에 대한 간단한 설명이 적힌 표를 보시면 언급드리지 않았던 부분도 있지만

이전 데이터 수집기술 포스팅에서 언급했었던 Cassandra, Chukwa같은 것들이 하둡의 subproject로 구성되어 있는 것을 확인할 수 있습니다.

​

이렇게 빅데이터들을 어떻게 저장하고 관리 및 처리를 하는지를 NoSQL과 Hadoop에 초점을 두어서 알아보았습니다. 이번 포스팅까지 총 빅데이터 기초1,2,3을 작성했는데요

​

기초1에서는 빅데이터의 배경, 정의, 특성

기초2에서는 빅데이터의 처리과정과 데이터 수집방법론

기초3에서는 수집한 데이터의 저장방법과 처리방법에 대해서 알아보았습니다.

​

이제 다음 포스팅에서부터는 이렇게 수집하고 저장하고 처리하는 방법을 알았으니

실제로 데이터를 분석하는 분석 방법론에 대해서 알아보도록 하겠습니다.

​

그럼 이번 포스팅은 여기서 마무리짓고, 추가적으로 드릴 말씀은 "글이 이런점에서 개선되었으면 좋겠다"

아니면 "어떠어떠한 내용이 더 궁금하다", "이러한 부분이 부족한거 같다"라는 피드백을 남겨 주시면

글을 개선하는데 큰 도움이 될 것 같습니다.

​

모쪼록 공부하시는분들에게 도움이 되셨으면 좋겠습니다.