빅데이터 - 분석 기획 - 데이터 수집 및 저장 계획

빅데이터 저장시스템

대용량 데이터 집합을 저장하고 관리하는 시스템
사용자에게 데이터 제공 신뢰성과 가용성을 보장하는 시스템

파일 시스템 저장방식

빅데이터를 확장 가능한 분산 파일의 형태로 저장하는 방식
대표적으로 아파치 HDFS, 구글의 GFS 등
저사양 서버들을 활용
대용량, 분산, 데이터 집중형의 애플리케이션 지원
사용자들에게 고성능 장애 허용 시스템(fault-tolerance) 환경 제공

* 장애 허용 시스템(fault-tolerance) : 결함 감내 시스템이라고도 하며, 시스템을 구성하는 부품의 일부에서 결함(fault) 또는 고장(failure)이 발생하여도 정상적 혹은 부분적으로 기능을 수행할 수 있는 시스템

데이터베이스 저장방식

전통적인 RDBMS 시스템과 NoSQL DBMS 시스템 이용
대용량 데이터 저장 측면에서 NoSQL이 수평적 확장성, 데이터 복제, 간편한 API 제공, 일관성 보장등의 장점 보유

분산 파일 시스템

하둡 분산파일 시스템(HDFS)

Hadoop Distributed File System의 약자
분산 환경 컴퓨팅을 목표로 시작한 프로젝트로 분산 처리를 위한 파일 시스템
대용량 파일을 클러스터에 여러 블록으로 분산하여 저장
저장된 블록은 마지막 블록을 제외하고 모두 크기가 동일(기본 크기 64MB)
마스터(Master) 하나와 여러 개의 슬레이브(Slave)로 클러스터링 구성
- 마스터(Master)
  - 마스터 노드(Master Node), 네임 노드(Name Node)라고도 부름
  - 슬레이브를 관리하는 메타데이터와 모니터링 시스템 운영
- 슬레이브(Slave)
  - 슬레이브 노드(Slave Node), 데이터 노드(Data Node)라고도 부름
  - 데이터 블록 분산처리
데이터 손상을 방지하기 위해 데이터 복제 기법 사용

하둡의 장점

대용량의 비정형 데이터 저장 및 분석에도 효율적
클러스터링 구성을 통해 멀티 노드로 부하를 분산시켜 처리
개별적인 서버에서 진행되는 병렬처리 결과를 하나로 묶어 시스템의 과부하나 병목 현상을 줄임
장비를 증가시킬 수록 성능 향상
오픈소스로 무료로 사용 가능

분산 데이터 처리기술 - 맵리듀스(MapReduce)

분산 병렬 데이터 처리 기술의 표준
방대한 양의 데이터를 신속하게 처리하는 프로그래밍 모델로 효과적인 병렬 및 분산 처리 지원
런타임에서의 입력 데이터 분할, 작업 스케줄링, 노드 고장, 노드 간 데이터 전송 작업이 맵리듀스 처리 성능에 많은 영향을 받음

맵리듀스 처리단계
1단계	입력 데이터를 읽고 분할
2단계	분할된 데이터를 할당해 맵 작업 수행 후, 결과인 중간 데이터를 통합 및 재분할
3단계	통합 및 재분할된 중간 데이터 셔플(Shuffle)
4단계	셔플된 중간 데이터로 리듀스 작업 수행
5단계	출력 데이터 생성 후 맵리듀스 처리 종료

<이해를 위한 맵리듀스 예시, 출처:geeksforgeeks.org>

구글 파일 시스템(GFS)

엄청나게 많은 데이터를 보유해야하는 구글의 핵심 데이터 스토리지와 구글 검색 엔진을 위해 최적화된 분산 파일 시스템
마스터(Master), 청크 서버(Chunk Server), 클라이언트로 구성
- 마스터 : GFS 전체의 상태를 관리하고 통제
- 청크 서버 : 물리적인 하드디스크의 실제 입출력 처리
- 클라이언트 : 파일을 읽고 쓰는 동작을 요청하는 애플리케이션
파일들은 일반적인 파일 시스템에서의 클러스터들과 섹터들과 비슷
- 64MB로 고정된 크기의 청크들로 나누어서 저장
가격이 저렴한 서버에서도 사용되도록 설계
하드웨어 안정성이나 자료들의 유실에 대해 고려하여 설계
응답시간이 조금 길더라도 데이터의 높은 처리성능에 중점을 둠

NoSQL

RDBMS보다 유연한 데이터의 저장 및 검색을 위한 메커니즘 제공
대규모 데이터를 처리하기 위한 확장성, 가용성 및 높은 성능 제공
빅데이터 처리와 저장을 위한 플랫폼으로 활용

RDBMS와 NoSQL의 장단점 및 특성 비교

구분	장/단점	특성
RDBMS	- 데이터 무결성과 정확성 확보 - 정규화된 테이블과 소규모 트랜잭션 존재 - 확장성의 한계 - 클라우드 분산 환경에 부적합	- UPDATE, DELETE, JOIN 연산 가능 - ACID 트랜잭션 존재 - 고정 스키마 존재
NoSQL	- 데이터 무결성과 정확성 보장 X - 웹 환경의 다양한 정보 검색, 저장 가능	- 수정, 삭제 사용 X, 입력으로 대체 - 강한 일관성 불필요

* ACID : Atomicity, Consistency, Isolation, Durability의 앞글자를 딴 줄임말, 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질

* 원자성(Atomicity) : 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력

* 일관성(Consistency) : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미

* 독립성(Isolation) : 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미

* 지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미

CAP 이론

기존 데이터 저장 구조의 한계로 파생된 분산 데이터베이스 시스템의 이론
분산 컴퓨팅 환경의 특징 세 가지
- 어느 시스템이든 이 세 가지 특성을 동시에 만족하기 어려움
- 일관성(Consistency) : 분산 환경에서 모든 노드가 같은 시점에 같은 데이터를 보여줘야 함
- 가용성(Availability) : 일부 노드가 다운되어도 다른 노드에 영향을 주지 않아야 함
- 지속성(Partition Tolerance) : 데이터 전송 중에 일부 데이터를 손실하더라도 시스템은 정상 동작해야 함

구분	설명	적용 예
RDBMS	- 일관성과 가용성 선택	- 트랜잭션 ACID 보장 (금융 서비스)
NoSQL	- 일관성, 가용성 중 하나 포기 - 지속성 보장	- 일관성+지속성: 대용량 분산 파일 시스템(성능 보장) - 가용성+지속성:비동기식 서비스(아마존, 트위터 등)

NoSQL의 기술적 특성

ACID 특성 중 일부만을 지원하는 대신 성능과 확장성을 높이는 특성 강조
스키마가 존재하지 않음
- 데이터를 모델링하는 고정된 데이터 스키마 없이 키 값 이용, 다양한 형태의 데이터 저장 및 접근
- 데이터 저장 방식은 크게 열, 값, 문서, 그래프 등 네가지로 구분
탄력성(Elasticity)
- 시스템 일부에 장애가 발생해도 클라이언트가 시스템에 접근 가능
- 응용 시스템의 다운 타임이 없도록 하는 동시에 대용량 데이터 생성 및 갱신
- 질의에 대응할 수 있도록 시스템 규모와 성능 확장 용이
- 입출력의 부하를 분산시키는데 용이한 구조
질의(Query) 기능
- 대규모로 구성된 시스템에서도 데이터의 특성에 맞게 효율적으로 데이터 검색, 처리
  - 질의 언어, 관련 처리 기술, API 제공
메모리 기반 캐싱(Caching) 기술 적용
- 대규모 질의에도 고성능 응답 속도 제공
- 개발 빛 운영에도 투명하고 일관되게 적용

NoSQL의 데이터 모델

데이터 저장 방식에 따라 키-값 구조, 컬럼기반 구조, 문서기반 구조로 구분
키-값(Key-Value) 데이터베이스
- 데이터를 키와 그에 해당하는 값의 쌍으로 저장하는 데이터 모델 기반
- RDBMS보다 확장성이 뛰어나고 질의 응답시간 빠름
- 대표적으로 아마존의 DynamoDB, 인-메모리 방식의 Redis
열기반(컬럼기반, Column-oriented) 데이터베이스
- 데이터를 행(로우)이 아닌 컬럼기반으로 저장하고 처리하는 데이터베이스
- 열과 행은 확장성을 보장하기 위해 여러 개의 노드로 분할되어 저장되어 관리
- 대표적으로 구글의 Bigtable, Cassandra, HBase, HyperTable
문서기반(Document-oriented) 데이터베이스
- 문서 형식의 정보를 저장, 검색, 관리하기 위한 데이터베이스
- 키-값 데이터베이스보다 문서의 내부 구조에 기반을 둔 복잡한 형태의 데이터 저장 지원 및 최적화
- 대표적으로 MongDB, SimpleDB, CouchDB

데이터 모델	설명
키-값 저장 구조	- 가장 간단한 데이터 모델 - 범위 질의 사용 어려움 (단, DB에서 지원하면 사용 가능) - 응용 프로그램 모델링 복잡
문서 저장 구조	- 문서마다 다른 스키마 존재 - 레코드 간 관계 설명 가능 - 개념적으로 RDBMS와 비슷
열 기반 저장 구조	- 연관된 데이터 위주로 호출하기 좋은 구조 - 하나의 레코드 변경 시, 관련된 레코드 함께 수정 - 동일 도메인의 열 값이 중복이므로 높은 압축 효율 자랑 - 범위 질의에 유리

NoSQL 데이터베이스 제품 및 특징

DynamoDB (아마존)
- 하드웨어 프로비저닝, 복제, 설정 패치, 사용하는 응용 프로그램에 따른 DB 자동 분할 기능 등 지원
- 기본 데이터 모델은 속성, 항목, 테이블로 구성
- 모든 데이터는 SSD에 저장
Redis (Redis Labs)
- 메모리 기반의 키-값 저장 공간
- NoSQL이지만 인-메모리 솔루션으로 분류
- 다양한 데이터 구조 지원
- 메모리에 저장된 내용을 지속시키기 위해 파일로 싱크하는 기능 제공
MongoDB (MongoDB)
- 크로스 플랫폼 문서기반 데이터베이스
- 방대한 양의 데이터에서 낮은 관리 비용과 사용 편의성 목표로 개발
- 저장의 최소 단위는 문서로, RDBMS의 테이블과 비슷한 컬렉션이라는 곳에 수집
- 자동-샤딩(Auto-sharding)을 이용한 분산 확장 가능
  - 샤딩 : 데이터를 분할하여 다른 서버에 나누어 저장하는 과정
- 기존 DBMS의 범위 질의, 보조 인덱스, 정렬 등 연산과 맵리듀스 등 집계 연산 지원
CouchDB (아파치)
- 인터페이스가 JavaScript로 구성된 문서 기반 데이터베이스
- 독립된 도큐먼트들의 컬렉션으로 정의
- MongoDB보다 제공 질의, 확장성, 버전 관리 등에서 우수한 성능 제공
- 문서단위의 ACID 속성 지원
- 다중 버전 동시 동작 제어 기능을 제공하여 데이터가 여러 시점에서 접근할 때의 문제 발생률 해결
SimpleDB (아마존)
- 웹애플리케이션에서 사용하는 데이터의 실시간 처리 지원
- 도메인, 아이템, 속성, 값으로 구성되는 데이터 모델 사용
- 초 단위로 지연 동기화되는 'Eventual Consistency' 정책 사용
  - 트랜잭션 종료 후 데이터가 모든 노드에 즉시 반영되지 않음
Cassandra (아파치)
- 키-값 구조의 DBMS, 페이스북에 적용하여 사용
- 토큰링 배경의 키 구간 설정으로
HBase (아파치)
- Hadoop 데이터베이스, 하둡 파일 시스템 위에 설치
- 데이터 모델 : 열 집합 기반의 저장소로 구성
- 테이블 구조 : 행, 열 그룹, 열 이름, 타임스탬프를 이용
- 읽기와 수정 즉시 실행, 맵리듀스 연산은 일괄 처리 방식 지원
Hypertable (Zvents Inc.)
- C++ 언어로 개발
- 열 그룹과 타임스탬프 개념 사용
- HQL이라는 SQL과 비슷한 명령어 제공
- RDBMS와 기능 유사
- C++ API 완벽 제공
- Java로 개발된 HBase보다 성능 우수
Bigtable (구글)
- 구글 클라우드 플랫폼에서 사용
- 열(컬럼) 기반 데이터 저장 구조
- 공유 디스크 방식으로 모든 노드가 데이터, 인덱스 파일 공유
- 하나의 행(row)은 n개의 열-집합(Column-Family)을 가짐

빅데이터 저장시스템 선정을 위한 분석

기능성 비교 분석

데이터 모델

데이터를 테이블로 사용하고 무리가 없으면?
- RDBMS 필요 / NoSQL 필요 없음
유연한 스키마를 활용하여 문서 중심의 데이터 모델로 전환하고 싶으면?
- MongoDB 필요 / RDBMS보다 훨씬 유연한 스키마 구조
웹기반 시스템을 구축하고 싶다면?
- Apache CouchDB 필요 : 문서 기반의 데이터베이스
  - 데이터 저장소에 대한 인터페이스로 RESTful HTTP 지원
단순 키-값 쌍을 저장하여 대규모 사용자와 부하 분산을 위한 안정적인 분산 저장소가 필요하다면?
- Dynamo, Redis 필요
극단적인 확장성을 보장하고 싶다면?
- Cassandra, HyperTable, HBase 필요 : 열-집합(Columns-Family) 중심의 데이터베이스

확장성

가장 뛰어남
- 열-기반 데이터베이스 : HBase, Cassandra, HyperTable
약간 뒤처짐
- 인메모리 방식 데이터 베이스 : Redis
- 문서 기반 데이터베이스 : MongoDB, CouchDB

트랜잭션 일관성

데이터 수정, 삭제 등의 작업이 빈번하게 일어나는 환경 : 중요도 높음, RDBMS 사용
배치중심의 하둡 기반 분석환경 : 중요도 낮음, NoSQL 사용

질의 지원

MongoDB : SQL과 유사한 문법 기반, 쉽게 학습 가능, 우수한 질의 인터페이스 지원
CouchDB : MongoDB와 유사, 뷰 개념을 이해하고 활용하면 간편
Redis : 풍부한 질의 기능 제공
HBase, HyperTable : 자체 질의지원 기능 제공하지 않음, Hive를 통해 유사 SQL 질의기능 사용 가능

접근성

MongoDB : 접근 드라이버 아주 다양, 현존 주류 라이브러리용 드라이버 대부분 지원
CouchDB : 웹 통신을 지원하는 프로그래밍 언어일 경우 사용 가능
Redis, Hbase, HyperTable, Cassandra : 대부분의 프로그래밍 언어에서 연결 가능 (언어 바인딩 지원)

분석방식 및 환경

빅데이터 저장 방식
- 빅데이터를 파일 시스템 형식으로 저장하는 방식
- NoSQL 저장시스템을 사용하는 방식
- RDBMS에 기반을 둔 데이터 웨어 하우스 방식
저장 방식과 환경 선택 고려사항
- 필요한 분석 및 검색결과가 상시로 온라인 형식으로 필요한지 여부
- 분석가를 통해 별도의 프로세스를 거쳐 제공받아야 하는지의 여부

분석대상 데이터 유형

빅데이터 저장시스템 선택 고려사항
- 기업 내외부에서 발생하는 기업 데이터
- IoT 환경에서 발생하는 데이터
- 기타 다양한 과학, 바이오, 의학분야에서 취급되는 데이터
- 데이터의 volume, velocity, variety, veracity 등

기존 시스템과의 연계

기존 시스템 그대로 활용 및 저장
- 저장 대상 데이터의 유형이 대부분 테이블로 정의될 수 있는 형태
- 기존 RDBMS 기반의 데이터 웨어하우스가 도입된 형태
HBase 추가 도입 권장
- 기존에 HDFS만 활용하여 빅데이터 저장시스템 구축된 형태
- SQL-like 분석 환경 구축 희망하는 형태
Redis 도입 권장
- 빅데이터 분석 애플리케이션이 키-값 쌍 처리 위주로 시스템이 구현된 형태
Cassandra와 같은 확장성이 보장된 열 기반 데이터베이스 권장
- IoT 데이터처럼, 다양한 데이터가 지속해서 실시간 발생하는 것을 수집하는 시스템 환경
- 데이터베이스나 확장성이 중요한 요소의 환경

데이터 발생 유형 및 특성

대용량 실시간 서비스 데이터 개요

빅데이터 저장 계획 수립
- 대상 데이터의 용량, 실시간 여부, 정형, 비정형 등 유형 및 요건 파악
저장 체계 구축
- 일반적으로 실시간 처리해야하는 스트리밍 데이터
- 대용량의 특성과 무중단 서비스를 보장
실시간 데이터 처리
- 스파크, 스톰 등 사용 : 실시간 데이터 처리를 위해 사용, 실시간 대용량 처리에 특화
- IoT에서 발생하는 센서 데이터, 네트워크 모니터링 데이터, 에너지 관리 분야 데이터, 통신 데이터, 웹 로그, 주식 데이터나 생산현장에서 발생하는 데이터 등
  - 하둡은 배치 기반의 대용량 데이터 처리에 사용

대용량 실시간 서비스 데이터 저장

스톰(Storm) 사용 가정 시
- 저장소가 없으므로 외부 저장 시스템과의 연동 필수
- 다양한 소스의 로그로부터 데이터 발생 환경
  - 스톰 : 데이터 전처리
  - NoSQL : 저장소에 저장
  - RDBMS : 정규화된 데이터일 경우 저장소로 사용 가능
스파크(Spark) 사용 가정 시
- 저장소가 없으므로 외부 저장 시스템과의 연동 필수
- 실시간 서비스를 웹 페이지로 제공하는 환경
  - 스파크 : 데이터 전처리
  - Redis : 메인 메모리 저장 시스템을 저장소로 사용

안정성과 신뢰성 확보 및 접근성 제어계획 수립

빅데이터 저장 시스템 안정성 및 신뢰성 확보
- 보장하기 위한 저장 계획 수립 단계에서 용량 산정 필요
- 용량 산정에는 향후 증가 추세 추정 반영
접근성 제어계획 수립
- 저장 시스템의 사용자와 관리자 유형, 역할 및 기능 정의
- 각각에 해당하는 제어계획 수립

참고

저작자표시 동일조건

빅데이터 - 분석 기획 - 데이터 수집 및 저장 계획 - 데이터 저장