[Big Data] 데이터 적재 및 저장

데이터 적재

1. 데이터 적재 아키텍처 수립

(1) 아키텍처 정의

• 요구사항을 구현하기 위한 기반 기술을 정의하는 과정
• 요구사항을 반영하여 하드웨어와 소프트웨어 아키텍처를 정의하는데, 이는 정보시스템 개발, 테스트, 이관을 위한 기술적 기반이 됨

(2) 빅데이터 적재 아키텍처 요구 정의

㉮ 장비 요구사항 정의

장비 규격 정의	설명
서버 장비 규격 정의	☞ 주요 서버는 분산 처리를 위한 네임 노드(Name Node), 데이터 노드(Data Node), 데이터 분석을 위한 분석 서버, 원천 데이터 획득을 위한 수집 서버 등이 있음
네트워크 장비 규격 정의	☞ 용도에 따라 라우터, 스위치 등으로 구성 ☞ 스토리지나 백업 장비를 위한 망 구성의 경우 SAN(Storage Area Network) 스위치 도입 고려 ☞ 물리적 포트 수를 고려하여 가용 수량을 결정하며, 대역 폭에 따라 네트워크 장비 용량 도출 ※ SAN은 서버와 스토리지를 저장 장치 전용 네트워크로 상호 구성하여 고가용성, 고성능, 융통성, 확장성을 보장하고 데이터를 블록 단위로 관리하는 기술을 의미함
스토리지 장비 규격 정의	☞ 용도에 따라 SAN, NAS(Network Attached Storage) 등에 대한 도입 검토 ☞ SAN 통합 스토리지를 구성하는 경우 볼륨 할당을 위해 RAID(Redundant Array of Independent Disks) 구성을 고려해야 하며, 통합 스토리지를 할당하는 서버의 경우 별도의 HBA(Host Bus Adapter), NIC(Network Interface Controller)가 필요 ☞ 최근 스토리지의 빠른 I/O 처리를 위해 SAS 디스크에서 Flash 디스크로 전환하고 있는 추세이므로, I/O 처리 속도 또한 스토리지 규격을 결정하는 중요한 요인 ※ NAS는 저장 장치와 서버를 직접 연결하는 것이 아니라 네트워크를 통해 스토리지에 접속하고, 파일 단위로 관리하는 스토리지를 의미함 ※ HBA는 호스트 컴퓨터의 버스와 광채널 회로 사이에 위치해 있는 입출력 어댑터로 두 채널 사이에서 정보 전달을 관리하는 역할을 수행함 ※ NIC은 컴퓨터를 네트워크에 연결하여 통신하기 위해 사용하는 하드웨어 장치인 랜카드를 의미함

㉯ 소프트웨어 도입 요구사항 정의

• 빅데이터 적재를 위한 소프트웨어 구성 요구사항 도출
• 자체적으로 시스템을 구축하는 온프레미스(On-premise)의 경우 상용 소프트웨어와 오픈 소스 소프트웨어 도입을 모두 고려
• 자체 구축이 아닌 경우 상용 클라우드 서비스를 고려할 수 있으며, 클라우드 서비스 이용 시 인프라 제공 수준에 따라 IaaS, PaaS, SaaS 유형 중 요구사항에 적합한 서비스 선택

㉰ 성능 요구사항 정의

대상	성능 요구사항 내용	세부 항목
서버	☞ 최적의 용량을 확보 ☞ 성능 관련 이슈 예방 방안	CPU, 메모리, 디스크, 프로세스, 커널, 파일 시스템, 네트워크 I/O
네트워크	☞ 네트워크에 연결된 장비와 호스트 간의 트래픽에 대한 예상치	대역폭, 전송 속도, 처리 속도
DBMS	☞ 데이터의 현황 데이터를 수집, 관리하고 경향을 분석한 용량 계획 반영	데이터 모델링, 응용 프로그램/SQL, 파라미터 설정, 인덱스 구성 등
응용 시스템	☞ 사용자 업무 관점에서 목표했던 서비스 수준의 유지 여부 파악 및 개선	응용 프로그램, 응용 플랫폼(WEB, WAS, EAI 등)의 응답 속도

㉱ 인터페이스 요구사항 정의

• 내부 연계, 외부 연계 대상 시스템을 고려하여 인터페이스 요구사항 정의
• 데이터 수집 단계에서는 원천 데이터 대상이 외부(웹 사이트 페이지, SNS 등)에 위치하는지, 내부(접속 로그, CRM 등)에 위치하는지에 따라 인터페이스 방식이 상이
• 데이터 분석 및 활용 단계에서는 가공된 데이터를 사용자 시스템으로 전송하기 위한 ETL 시스템의 추가 도입 고려

(3) 빅데이터 적재 하드웨어 아키텍처 정의

㉮ 서버 노드 아키텍처 정의

구분	설명
네임 노드 구성 정의	☞ 파일 시스템의 Metadata(디렉터리 구조, Access 권한 등)를 관리하는 서버로 실제 작업 대상 데이터를 블록 단위로 나누어 데이터 노드에 분배하는 역할 수행
데이터 노드 구성 방안 정의	☞ 실제 데이터 저장 및 처리가 수행되는 노드로 데이터 노드에 저장되는 정보는 기본 3개 노드에 복제되어 저장되며, 필요에 따라 복제되는 노드 수를 늘릴 수 있음

• 단일 네임 노드와 다수의 데이터 노드로 구성되는 것이 보통이지만, 네임 노드가 단일 장애 지점(Single Point of Failure)이 되므로, 보조 네임 노드를 구성하여 이중화로 구성할 수 있음

㉯ 데이터 아키텍처 정의

• 빅데이터 플랫폼에서는 기존 시스템에서 일반적으로 사용되는 RDB외에도 NoSQL, 분산 파일 시스템 등의 다양한 데이터 기반 아키텍처를 구성함
• 데이터 아키텍처에서는 가장 핵심적인 요소로 처리하고자 하는 데이터의 유형과 성격을 검토함
• 정형화된 데이터 항목 혹은 엄격한 트랜잭션을 요구하는 데이터를 처리하기 위해서는 관계형 데이터베이스가 적합하며, 멀티미디어 콘텐츠나 문서 정보 같은 비구조적인 데이터를 처리하는 데에는 NoSQL 적용을 고려해야 함
• 빅데이터 아키텍처 기술요소는 분산 파일 시스템, 데이터베이스 클러스터, NoSQL, 병렬 DBMS, 네트워크 구성 저장 시스템, 클라우드 파일 저장 시스템이 있음

㉰ 네트워크 아키텍처 정의

구분	설명
목표 시스템 네트워크 구성 정의	☞ 빅데이터 플랫폼의 전체 네트워크 구성 정의 ☞ 수집 및 처리 대상이 되는 데이터양에 따라 네트워크 대역폭을 고려해야 하며, 시스템 용도에 따라 네트워크 대역을 구분
개별 장비 네트워크 환경 정의	☞ 네임 노드, 데이터 노드, 응용 시스템 서버 및 데이터베이스 서버 등 빅데이터 플랫폼을 구성하는 개별 장비에 대한 네트워크 환경 구성 정의 ☞ 필요에 따라 각 서버는 1개 이상의 네트워크 인터페이스 카드(NIC)를 장착하며, 개별 NIC는 단일 포트 혹은 이중화 포트를 이용하여 가용성 확보

(4) 빅데이터 적재 소프트웨어 아키텍처 정의

㉮ 기반 소프트웨어 정의

구분	설명
하둡 도입 검토	☞ 빅데이터 플랫폼의 핵심인 분산 파일 시스템과 분산 병렬 처리를 하는 맵리듀스로 구성된 오픈 소스 ☞ 빅데이터 기반 프레임워크로 가장 널리 사용
인 메모리 데이터베이스 도입 검토	☞ 데이터를 저장하는 스토리지가 메인 메모리를 이용하는 방식의 데이터베이스 관리 시스템 ☞ 인 메모리 데이터베이스는 상대적으로 접근 속도가 높은 성능을 보이며, 검색 및 조회 알고리즘은 더 단순함
데이터 분석 플랫폼 적용 검토	☞ 수치화된 정형 데이터를 활용한 전통적인 분석 방법에서 발전하여 대용량의 데이터로부터 패턴 인식, 텍스트 마이닝, 소셜 분석 등의 기법을 이용하여 표면적으로 드러나지 않는 데이터 간 관련성 분석 및 필요 정보 추출
데이터 시각화 적용	☞ 데이터 시각화는 빅데이터 분석 결과를 사용자가 쉽게 이해할 수 있도록 시각적으로 표현하는 기법 ☞ 데이터의 정확한 분석만큼 중요한 것이 데이터의 의미를 전달하는 과정인 만큼 다양한 데이터 시각화 기법을 통해 효과적인 정보 전달 가능

㉯ 빅데이터 적재 소프트웨어 아키텍처 정의

• 빅데이터 적재에 필요한 소프트웨어 아키텍처를 정의함
• 데이터 수집 단계에서는 외부 데이터 획득을 위한 크롤러, 내부 데이터 획득을 위한 ETL 등을 고려할 수 있고, 데이터 적재를 위한 DBMS는 RDB, NoSQL 등을 정의할 수 있음

2. 데이터 적재

① 데이터 적재 특징

• 빅데이터 분석에 필요한 데이터를 수집한 후에는 수집한 데이터를 빅데이터 시스템에 적재해야 함
• 적재할 빅데이터의 유형과 실시간 처리 여부에 따라 RDBMS, HDFS, NoSQL 저장 시스템에 데이터를 적재할 수 있음
• 여러 데이터 소스에서 데이터를 수집해 오기 위해, 데이터 소스를 처리하고, 분산된 여러 서버에서 데이터를 수집하는 데이터 수집 플랫폼과 저장 방법의 중요성이 점점 더 확대되고 있음

② 데이터 적재 도구

• 수집된 데이터는 NoSQL DBMS가 제공하는 적재 도구를 이용하여 직접 적재하거나, 플루언티드, 플럼, 스크라이브, 로그스태시와 같은 데이터 수집 도구를 이용하여 적재함

도구	설명
플루언티드 (Fluentd)	☞ 트레저 데이터(Treasure Data)에서 개발된 크로스 플랫폼 오픈 소스 데이터 수집 소프트웨어 ☞ 주로 루비 프로그래밍 언어로 작성
플럼 (Flume)	☞ 많은 양의 로그 데이터를 효율적으로 수집, 집계 및 이동하기 위해 이벤트(Event)와 에이전트(Agent)를 활용하는 분산형 로그 수집 기술
스크라이브 (Scribe)	☞ 다수의 서버로부터 실시간으로 스트리밍되는 로그 데이터를 수집하여 분산 시스템에 데이터를 저장하는 대용량 실시간 로그 수집 기술
로그스태시 (Logstash)	☞ 모든 로그 정보를 수집하여 하나의 저장소(DB, Elasticsearch 등)에 출력해주는 시스템

데이터 저장

1. 빅데이터 저장기술

• 빅데이터 저장 시스템은 대용량 데이터 집합을 저장하고 관리하는 시스템으로 대용량의 저장 공간, 빠른 처리 성능, 확장성, 신뢰성, 가용성 등을 보장해야 함
• 메타데이터를 별도의 전용 서버로 관리하는 비대칭형(Asymmetric) 클러스터 파일 시스템이 개발되고 있으며, 이 시스템은 메타데이터에 접근하는 경로와 데이터에 접근하는 경로가 분리된 구조를 가짐
• 빅데이터 저장기술 분류는 아래와 같음

기술	내용	제품
분산 파일 시스템	☞ 컴퓨터 네트워크를 통해 공유하는 여러 호스트 컴퓨터의 파일에 접근할 수 있게 하는 파일 시스템	☞ 구글 파일 시스템(GFS) ☞ 하둡 분산 파일 시스템(HDFS) ☞ 러스터(Lustre)
데이터베이스 클러스터	☞ 관계형 데이터베이스 관리 시스템으로 하나의 데이터베이스를 여러 개의 서버상에 구축하는 시스템	☞ 오라클 RAC ☞ IBM DB2 ICE ☞ MSSQL, MySQL
NoSQL	☞ 전통적인 RDBMS와 다른 DBMS를 지칭하기 위한 용어로 데이터 저장에 고정된 테이블 스키마가 필요하지 않고 조인 연산을 사용할 수 없으며, 수평적으로 확장이 가능한 DBMS ☞ ACID 요건을 완화하거나 제약하는 특징	☞ 구글 빅테이블 ☞ HBase ☞ 아마존 SimpleDB ☞ 마이크로소프트 SSDS ☞ Cloudata ☞ Cassandra
병렬 DBMS	☞ 다수의 마이크로프로세서를 사용하여 여러 디스크에 대한 질의, 갱신, 입출력 등의 데이터베이스 처리를 동시에 수행하는 데이터베이스 시스템	☞ VoltDB ☞ SAP HANA ☞ Verica ☞ Greenplum ☞ Netezza
네트워크 구성 저장 시스템	☞ 서로 다른 종류의 데이터 저장 장치를 하나의 데이터 서버에 연결하여 전체적으로 통합하여 데이터를 저장, 관리	☞ SAN ☞ NAS
클라우드 파일 저장 시스템	☞ 클라우드 컴퓨팅 환경에서 가상화 기술을 활용한 분산 파일 시스템	☞ Amazon S3 ☞ OpenStack Swift

(1) 구글 파일 시스템(Google File System) 

• GFS는 구글의 대규모 클러스터 서비스 플랫폼의 기반이 되는 파일 시스템
• 파일을 고정된 크기(64MB)의 청크들로 나누며 각 청크와 여러 개의 복제본을 청크 서버에 분산하여 저장함
• GFS의 구성요소는 아래와 같음

구분	설명
클라이언트 (Client)	☞ 파일에 대한 읽기/쓰기 동작을 요청하는 애플리케이션으로 POSIX 인터페이스를 지원하지 않으며, 파일 시스템 인터페이스와 유사한 자체 인터페이스를 지원 ☞ 여러 클라이언트에서 원자적인 데이터 추가(Atomic Append) 연산을 지원하기 위한 인터페이스 지원 ※ POSIX(Portable Operating System Interface)은 이식 가능 운영 체제 인터페이스를 의미하는 것으로 상호 간에 다른 unix os의 공통 API를 정리해서 이식성이 높은 unix 응용 프로그램을 개발하기 위해 IEEE가 책정한 애플리케이션 인터페이스 규격을 의미함
마스터 (Master)	☞ 단일 마스터 구조로 파일 시스템의 이름 공간(Name Space), 파일과 청크의 매핑 정보, 각 청크가 저장된 청크 서버들의 위치정보 등에 해당하는 모든 메타데이터를 메모리상에서 관리 ☞ 주기적으로 청크 서버의 하트비트(Heartbeat) 메시지를 이용하여 청크를 재복제하거나 재분산하여 상태를 관리 ※ 하트비트는 주로 이중화 장비 또는 마스터 장비에 적용되며 상대편 노드(Node)가 동작하고 있는지를 주기적으로 점검하는 작업을 의미함
청크 서버 (Chunk Server)	☞ 로컬 디스크에 청크를 저장 ☞ 클라이언트가 청크 입출력을 요청하면 청크 서버가 처리 ☞ 주기적으로 청크 서버의 상태를 하트비트 메시지로 마스터에게 전달

• GFS는 클라이언트가 GFS 마스터에게 파일을 요청하면, 마스터는 저장된 청크의 매핑 정보를 찾아서 해당 청크 서버에 전송을 요청하고, 해당 청크 서버는 클라이언트에게 청크 데이터를 전송하는 구조를 가짐

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

• 수십 테라바이트 또는 페타바이트 이상의 대용량 파일을 분산된 서버에 저장하고, 저장된 데이터를 빠르게 처리할 수 있게 하는 분산 파일 시스템임
• 저사양의 다수의 서버를 이용해서 스토리지를 구성할 수 있어 기존의 대용량 파일 시스템(NAS, DAS, SAN 등)에 비해 비용관점에서 효율적임
• HDFS는 블록 구조의 파일 시스템으로 파일을 특정 크기의 블록으로 나누어 분산된 서버에 저장됨
• 블록 크기는 64MB에서 하둡2.0부터는 128MB로 증가됨
• HDFS의 구성요소는 아래와 같음

구분	설명
네임 노드 (Name Node)	☞ HDFS 상의 모든 메타데이터를 관리하며 마스터/슬레이브 구조에서 마스터 역할 수행 ☞ 데이터 노드들로부터 하트비트를 받아 데이터 노드들의 상태를 체크하는데, 하트비트 메시지에 포함된 블록 정보를 가지고 블록의 상태 체크
보조네임 노드 (Secondary Name Node)	☞ HDFS 상태 모니터링을 보조 ☞ 주기적으로 네임 노드의 파일 시스템 이미지를 스냅샷으로 생성
데이터 노드 (Data Node)	☞ HDFS의 슬레이브 노드로 데이터 입출력 요청을 처리 ☞ 데이터 유실 방지를 위해 블록을 3중으로 복제하여 저장

(3) 러스터(Lustre)

• 클러스터 파일 시스템(Cluster File System Inc.)에서 개발한 객체 기반의 클러스터 파일 시스템임
• 계층화된 모듈 구조로 TCP/IP, 인피니밴드(InfiniBand) 같은 네트워크를 지원함
• 인피니밴드는 무한대역폭의 줄임말로 대용량 데이터 처리를 위한 고성능 컴퓨팅과 기업용 데이터 센터에서 사용되는 스위치 방식의 통신 연결 방식을 의미함
• 러스터의 구성요소는 아래와 같음

구분	설명
클라이언트 파일 시스템	☞ 리눅스 VFS(Virtual File System)에서 설치할 수 있는 파일 시스템 ☞ 메타데이터 서버와 객체 저장 서버들과 통신하면서 클라이언트 응용에 파일 시스템 인터페이스를 제공
메타데이터 서버	☞ 파일 시스템의 이름 공간과 파일에 대한 메타데이터를 관리
객체 저장 서버	☞ 파일 데이터를 저장하고, 클라이언트로부터의 객체 입출력 요청을 처리 ☞ 데이터는 세그먼트라는 작은 데이터 단위로 분할해서 복수의 디스크 장치에 분산시키는 기술인 스트라이핑 방식으로 분산, 저장

(4) 데이터베이스 클러스터(Database Cluster)

• 하나의 데이터베이스를 여러 개의 서버상에 분산하여 구축하는 것을 의미함
• 데이터를 통합할 때, 성능과 가용성의 향상을 위해 데이터베이스 파티셔닝(Database Partitioning) 또는 클러스터링을 이용함
• 데이터베이스 시스템을 구성하는 형태에 따라 단일 서버 파티셔닝과 다중 서버 파티셔닝으로 구분함
• 데이터베이스 클러스터는 아래와 같이 구분함

종류	설명
공유 디스크 클러스터 (Shared Disk Cluster)	☞ 데이터 파일은 논리적으로 데이터 파일을 공유하여 모든 데이터에 접근 가능하게 하는 방식 ☞ 데이터 공유를 위해 SAN과 같은 네트워크 장비가 있어야 함 ☞ 모든 노드가 데이터를 수정할 수 있어, 동기화 작업을 위한 채널이 필요 ☞ 높은 수준의 고가용성을 제공하므로 클러스터 노드 중 하나만 살아 있어도 서비스가 가능
무공유 클러스터 (Shared Nothing Cluster)	☞ 무공유 클러스터에서 각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 이 파일들은 노드 간에 공유하지 않음 ☞ 노드 확장에 제한이 없지만, 각 노드에 장애가 발생할 경우를 대비해 별도의 FTA(Fault-Tolerance)를 구성해야 함 ※ FTA는 시스템에 고장이 발생하더라도 모든 기능 또는 기능 일부를 기존과 같이 유지하는 기술을 의미함

• 데이터베이스 클러스터 종류는 아래와 같음

종류	설명
Oracle RAC	☞ Oracle RAC는 공유 클러스터에 해당되므로, 클러스터의 모든 노드에서 실행되며 데이터는 공유 스토리지에 저장 ☞ 고가용성과 확장이 쉬운 장점이 있음
IBM DB2 ICE (Integrated Cluster Environment)	☞ DB2는 CPU, 메모리, 디스크를 파티션별로 독립적으로 운영하는 무공유 방식의 클러스터링 지원 ☞ 독립적으로 운영되므로 하나의 노드에 장애가 발생하면 복구할 수 있도록 공유 디스크 방식을 사용해서 가용성 보장
SQL Server	☞ SQL Server는 연합(Federated) 데이터베이스 형태로 여러 노드로 확장할 수 있는 기능 제공 ☞ 가용성을 확보할 수 있도록 페일오버(Failover)를 제공하지만, Active-Active가 아닌 Active-Standby 방법을 사용
MySQL	☞ 비 공유형으로 메모리 기반 데이터베이스의 클러스터링 지원 ☞ 관리, 데이터, MySQL 노드로 구성 ☞ 데이터는 동기화 방식으로 복제되며, 이 작업을 위해 데이터 노드 간에는 별도의 네트워크 구성

(5) NoSQL(Not Only SQL)

• NoSQL은 전통적인 RDBMS와 다른 DBMS를 지칭하기 위한 용어로 데이터 저장에 고정된 테이블 스키마가 필요하지 않고 조인 연산을 사용할 수 없으며, 수평적으로 확장이 가능한 DBMS임
• 관계형 모델을 사용하지 않는 데이터 저장소 또는 인터페이스이며, 대규모 데이터를 처리하기 위한 기술로 확장성, 가용성, 높은 성능을 제공함
• 스키마-리스(Schema-less)로 고정된 스키마 없이 자유롭게 데이터베이스의 레코드에 필드를 추가할 수 있음
• NoSQL의 특성은 아래와 같음

특성	설명
Basically Available	☞ 언제든지 데이터는 접근 가능해야 함 ☞ 분산 시스템이기 때문에 항상 가용성을 중시
Soft-State	☞ 노드의 상태는 내부에 포함된 정보에 의해 결정되는 것이 아니라 외부에서 전송된 정보를 통해 결정되는 속성 ☞ 특정 시점에서는 데이터의 일관성이 보장되지 않음
Eventually Consistency	☞ 일정 시간이 지나면 데이터의 일관성이 유지되는 속성 ☞ 일관성을 중시하고 지향

• NoSQL의 유형은 아래와 같음

유형	설명
Key-Value Store	☞ Unique 한 Key에 하나의 Value를 가지고 있는 형태 ☞ 키 기반 Get/Put/Delete를 제공하는 빅데이터 처리 가능 DB
Column Family Data Store	☞ Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는 DB로 테이블 기반, 조인 미지원, 컬럼 기반, 구글의 BigTable 기반으로 구현
Document Store	☞ Value의 데이터 타입이 Document라는 타입을 사용하는 DB ☞ Document 타입은 XML, JSON, YAML과 같이 구조화된 데이터 타입으로, 복잡한 계층 구조를 표현할 수 있음
Graph Store	☞ 시맨틱 웹(Semantic Web)과 온톨로지(Ontology) 분야에서 활용되는 그래프로 데이터를 표현하는 DB

• NoSQL은 CAP(Consistency, Availability, Partition Tolerance) 이론을 기반으로 함 
• CAP 이론은 분산 컴퓨팅 환경은 Consistency, Availability, Partition Tolerance 중 두 가지만 만족할 수 있다는 이론임
• NoSQL의 제품 종류는 아래와 같음

종류	설명
구글 빅테이블	☞ 구글 클라우드 플랫폼에서 데이터 저장소로 사용 ☞ 공유 디스크 방식으로 모든 노드가 데이터, 인덱스 파일 공유 ☞ row는 n개의 Column-Family를 가질 수 있음 ☞ 같은 컬럼 키에 대해 다른 여러 버전의 타임스탬프가 존재할 수 있음 ☞ 빅테이블의 SPOF(Single Point of Failure)는 마스터이며, 분산 락 서비스를 제공하는 Chubby를 이용해 마스터 장애 시 가용한 노드를 마스터로 변경 ※ SPOF는 시스템의 구성요소 중 하나의 구성요소가 동작하지 않으면 전체 시스템이 중단되는 요소를 의미함
HBase	☞ HDFS를 기반으로 구현된 컬럼 기반의 분산 데이터베이스 ☞ RDBMS와 달리 수평적으로 확장성이 있어 큰 테이블에 적합 ☞ 단일 행의 트랜잭션을 보장
Simple DB	☞ 아마존의 데이터 서비스 플랫폼으로, 웹 애플리케이션에서 사용하는 데이터의 실시간 처리를 지원 ☞ 아마존의 다른 플랫폼 서비스와 같이 사용
SSDB (SQL Server Data Service)	☞ 고가용성 보장 ☞ 데이터 모델은 테이블과 유사한 컨테이너, 레코드와 유사한 엔티티로 구성 ☞ 컨테이너의 생성/삭제, 엔티티의 생성/삭제, 조회, 쿼리 등의 API를 제공하고 SOAP/REST 기반의 프로토콜 지원

(6) 빅데이터 저장 고려사항

① 빅데이터 저장 제품 검토

• 빅데이터 저장을 위한 제품을 검토하기 위해 사용자 요구사항을 분석
• 요구사항 분석은 요구사항 수집하고, 이를 분석하여 명세하고 검증을 통해 확정하는 아래의 4단계로 수행

단계	설명	예시
요구사항 수집(도출)	☞ 문서나 인터뷰를 통해 수집하거나 기존 시스템 분석을 통해 요구사항을 수집	☞ 제안요청서(Request For Proposal) ☞ 포커스 그룹 인터뷰(Focus Group Interview) ☞ 설문 ☞ 워크숍
요구사항 분석	☞ 기능, 비기능 데이터 및 기타 요구사항을 분석	☞ 데이터 유형 ☞ 데이터 업데이트 주기
요구사항 명세	☞ 요구사항을 문서화하여 정리하는 과정 ☞ 메타 정보, 변경 이력, 요구사항 목록으로 구성	☞ 사용자 요구 명세서
요구사항 검증	☞ 요구사항 명세서를 배포하고 검토 회의를 통해 검증	☞ 요구사항 리뷰 및 검토 회의

② 기존 시스템 기술 검토 절차 수립

• 저장대상 데이터의 유형이 대부분 테이블로 정의될 수 있는 형태이고 기존에 RDBMS 기반의 데이터 웨어하우스가 도입된 형태라면 기존 시스템을 그대로 활용하여 빅데이터를 저장함
• 기존에 HDFS만을 활용하여 빅데이터 저장시스템이 구축되어 있으나, SQL-like 분석환경을 구축하고자 한다면 HBase를 추가로 도입하는 것을 권장함

③ 데이터 저장의 안정성, 신뢰성 확보 방안 수립

방안	설명
용량산정	☞ 빅데이터 저장 시스템의 안정성 및 신뢰성을 확보하고 보장하기 위해 저장 계획 수립단계에서 용량산정이 필요 ☞ 조직의 빅데이터 활용 목적에 부합하는 현재와 향후 증가 추세를 추정 반영하여 빅데이터 저장 용량을 산정하여 계획하고 전체 저장 시스템 구축계획에 반영하는 것은 필수적임 ☞ 데이터, 아카이브 및 여유율 등을 고려하여 적정 디스크 용량 계획을 산정
데이터 파악	☞ 저장대상이 되는 데이터의 유형, 크기, 저장방식 및 기간 등을 파악
시스템 구축 방안	☞ 프라이빗 클라우드(Private Cloud), 퍼블릭 클라우드(Public Cloud)와 같이 안정성 및 신뢰성을 고려한 시스템 구축방안을 계획

④ 유형별 데이터 저장방식 수립

• 빅데이터 요구사항 분석 단계에서 요구사항에 따른 수집 및 저장이 필요한 데이터를 유형별로 분류하고 수집 주기 등의 특성을 분석하여야 함
• 요구사항에 따라 수집 및 저장관리가 필요한 데이터 종류를 데이터 유형별로 분류하고, 해당 데이터를 저장 관리하기에 적합한 저장 시스템을 선택해야 함

⑤ 저장방식 결정

• 빅데이터 저장시스템을 선정할 때에는 아래와 같은 사항을 고려해야 함

고려요소	설명
저장기술의 기능성	☞ 데이터 모델이 무엇인지 고려 ☞ 확장성 고려 ☞ 트랜잭션의 일관성이 중요한 분야에서는 RDBMS를 선택
분석 방식 및 환경	☞ 온라인 상시 또는 배치기반 방식 고려 ☞ 파일 시스템 형식, NoSQL, DW으로 구성할지 고려
분석 대상 데이터 유형	☞ 기업 내/외부 데이터 고려 ☞ 데이터 발생량/속도 고려 ☞ 데이터의 Volume, Velocity, Variety를 고려
기존 시스템과의 연계	☞ 운영 시스템과 연계

• 빅데이터 저장시스템 선정을 위한 분석 과정을 통해 검토된 항목은 선정 결과서에 작성하여 공유함