[필기] 데이터 적재 및 저장

PART 01 · Chapter3 데이터 수집 및 저장 계획

 

적재
플루언티트(Fluentd)
NoSQL DBMS
저장시스템 선정
접근성 제어

---

01. 데이터 적재

• 데이터 적재 도구
  • 수집한 데이터는 빅데이터 분석을 위한 저장 시스템에 적재해야 함.
  • 적재할 데이터 유형과 실시간 처리 여부에 따라 관계형 DB, HDFS를 비롯한 분산파일시스템, NoSQL 저장 시스템에 데이터 적재 가능
  • 데이터 수집 도구를 이용한 데이터 적재
    • 로그 수집을 해야 하는 각 서버에 Fluentd를 설치 → 서버에서 로그 수집 → 로그 저장소로 전송
    • Fluentd의 로그 수집 구조는 가장 간단 구조로 로그 수집 에이전트 역할만 수행하지만, 이에 더해 각 서버에서 Fluentd에서 수집한 로그를 다른 Fluentd로 보내서 최적으로 로그 저장소에 저장하도록 설정 가능
    • 데이터 수집 도구
      • 플루언티드(Fluentd)
        • 트레저 데이터에서 개발된 크로스 플랫폼 오픈 소스 데이터 수집 소프트웨어
        • 사용자의 로그 → 다양한 형태로 입력받아 JSON 포맷으로 변환 → 다양한 형태로 출력
      • 플럼(Flume)
        • 많은 양의 로그 데이터 → 효율적으로 수집, 취합, 이동하기 위한 분산형 소프트웨어
        • 로그 데이터 수집과 네트워크 트래픽 데이터, 소셜 미디어 데이터, 이메일 메시지 데이터 등 대량의 이벤트 데이터 전송을 위해 사용
      • 스크라이브(Scribe)
        • 수많은 서버로부터 실시간으로 스트리밍되는 로그 데이터 집약시키는 서버
        • 클라이언트 사이드의 수정 없이 스케일링 가능하고 확장 가능
      • 로그스태시(Logstash)
        • 다양한 소스에서 데이터 수집해 변환 → 자주 사용하는 저장소
  • NoSQL DBMS가 제공하는 도구를 이용한 데이터 적재
    • 수집한 데이터가 CSV 등의 텍스트 데이터일 경우, mongoimport와 같은 적재 도구 사용해 데이터 적재 수행 가능
    • 로그 수집 도구를 쓰는 방식처럼 데이터 수집 주기 등을 환경설정하여 사용할 수 X
  • 관계형 DBMS의 데이터를 NoSQL DBMS에서 적재
    • 기존의 운영 중이던 관계형 데이터베이스로부터 데이터 추출 → NoSQL DB로 적재 가능
    • 데이터 변형이 많이 필요하면, 데이터 적재를 위한 프로그램 작성 → 적재 가능
    • 큰 변화 없이 적재한다면 SQLtoNoSQLimporter, Mongify 등의 도구를 사용 → 적재 가능
• 데이터 적재 완료 테스트
  • 데이터 적재 내용에 따라 체크리스트 작성
  • 데이터 테스트 케이스 개발
    • 데이터 테스트 케이스; 적재가 정상적으로 완료되었는지 확인하는 시험
  • 체크리스트 검증 및 데이터 테스트 케이스 실행

Q. 다음 SW 중 데이터 수집 목적으로 사용하기 어려운 것은?
1) 플럼
2) 스쿱
3) 플루언티드
4) HDFS → 분산 파일 시스템으로 데이터 저장 목적

 

Q. 빅데이터 관련 SW 중 성격이 다른 하나?
1) 플럼
2) 로그스태시(logstash)
3) 플루언티드
4) 하이브(Hive) → 하둡기반 저장소에 대한 질의처리를 담당하는 시스템 (나머지는 데이터 수집을 위한 SW)

 

02. 데이터 저장

• 빅데이터 저장시스템
  • 대용량 데이터 집합을 저장하고 관리하는 시스템으로 사용자에게 데이터 제공 신뢰성과 가용성을 보장하는 시스템
  • 파일 시스템 저장방식
    • 예) Apache HDFS, 구글의 GFS 등
    • 저사양 서버들을 활용 → 대용량, 분산, 데이터 집중형의 애플리케이션 지원 → 사용자들에게 고성능 fault-tolerance 환경을 제공하도록 구현
  • 데이터베이스 저장방식
    • 전통적인 관계형 데이터베이스 시스템 이용
    •  NoSQL 데이터베이스 시스템 이용
      • 대용량 데이터 저장 측면에서, 관계형 데이터베이스보다 수평적 확장성, 데이터 복제, 간편한 API 제공, 일관성 보장 등의 장점
• 분산 파일 시스템
  • 하둡 분산파일 시스템(HDFS)
    • 하둡; 아파치 진영에서 분산 환경 컴퓨팅을 목표로 시작한 프로젝트, 분산처리를 위한 파일 시스템
      • 대용량 파일 저장 기능 제공하는 분산파일 시스템과,
      • 저장된 데이터를 쉽고 빠르게 분석할 수 있는 컴퓨팅 플랫폼인 맵리듀스로 구성
    • 대용량 파일 → 클러스터에 여러 블록으로 분산하여 저장, 블록들은 마지막 블록을 제외하고 모두 크기 동일
    • Master 1개와 Slave 여러 개로 클러스터링되어 구성
      • Master Node; Name Node, 슬레이브 관리한느 메타데이터와 모니터링 시스템 운영
      • Slave Node; Data Node, 데이터 블록 분산처리
    • 데이터 손상 방지하기 위해 데이터 복제 기법 사용
  • 구글 파일 시스템(GFS; Google File System)
    • 엄청나게 많은 데이털르 보유해야하는 구글의 핵심 데이터 스토리지와 구글 검색 엔진을 위해 최적화된 분산 파일 시스템
    • Master, Chunk Server, 클라이언트로 구성
      • Master; GFS 전체 상태 관리, 통제
      • Chunk Server; 물리적 하드디스크의 실제 입출력 처리
      • 클라이언트; 파일 읽고 쓰는 동작 요청하는 application
    • 가격 저렴한 서버에도 사용되도록 설계 → 하드웨어 안정성이나 자료들의 유실에 대해 고려하여 설계되었고 응답시간이 조금 길더라도 데이터의 높은 처리성능에 중점을 둠.
• NoSQL
  • 전통적 관계형 DB보다 유연한 데이터의 저장 및 검색을 위한 매커니즘 제공
  • 대규모 데이터 처리하기 위한 확장성, 가용성 및 높은 성능 제공
  • 빅데이터 처리, 저장 위한 플랫폼으로 활용

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

• (이어서)
  • CAP 이론: 기존 데이터 저장 구조의 한계
    • 어떤 시스템이든 분산 컴퓨팅 환경의 특징 동시 만족하기 어렵다.
      • 일관성: 분산환경에서 모든 노드가 같은 시점에 같은 데이터 보여줘야 함.
      • 가용성: 일부 노드가 다운되어도 다른 노드에 영향 주지 않아야 함.
      • 지속성: 데이터 전송 중에 일부 데이터 손실하더라도 시스템은 정상 동작해야 함.

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

• (이어서) 
  • NoSQL 기술적 특성
    • 고전적 RDBMS의 주요 특성을 보장하는 ACID 특성 중 일부만을 지원하는 대신 성능과 확장성을 높이는 특성 강조
      • ACID; 원자성, 일관성, 고립성, 지속성
    • 無 스키마
      • 데이터를 모델링하는 고정된 데이터 스키마 없이 키 값을 이용 → 다양한 형태의 데이터 저장 및 접근 가능
      • 데이터 저장 방식은 크게 열, 값, 문서, 그래프 등의 네 가지 기반 구분
    • 탄력성
      • 시스템 일부에 장애가 발생해도 클라이언트가 시스템에 접근 가능
    • 질의 기능
      • 수십 대~수천 대 규모로 구성된 시스템에서도 데이터 특성에 맞게 효율적으로 데이터 검색, 처리할 수 있는 질의 언어, 관련 처리 기술, API 제공
    • 캐싱
      • 대규모 질의에도 고성능 응답 속도 제공할 수 있는 메모리 기반 캐싱 기술을 적용하는 것이 중요
  • NoSQL의 데이터 모델
    • 데이터 저장 방식에 따라 키-값 구조, 칼럼기반 구조, 문서기반 구조로 구분
    • 키-값 DB
      • 데이터를 키와 그에 해당하는 값의 쌍으로 저장하는 데이터 모델에 기반을 둠.
      • 단순한 데이터 모델 기반 → RDBMS보다 확장성이 뛰어나고 질의 응답 시간이 빠름.
      • 아마존의 DynamoDB가 효시 → Redis와 같은 In-memory 방식의 오픈소스 DB가 대표적
    • 열기반(칼럼기반) DB
      • 데이터를 low가 아닌 column 기반으로 저장하고 처리하는 DB
      • column과 low는 확장성 보장하기 위해 여러 개의 노드로 분할 저장
      • 구글의 Bigtable이 효시 → 파생된 Cassandra, HBase, HyperTable 등이 대표적 칼럼기반 DB
    • 문서기반 DB
      • 문서 형식의 정보를 저장, 검색, 관리하기 위한 DB
      • 키-값 DB보다, 문서 내부 구조에 기반을 둔 복잡한 형태의 데이터 저장을 지원하고 이에 따른 최적화가 가능하다는 장점
      • 대표적; MongoDB, SimpleDB, CouchDB

▲ NoSQL 분류

데이터 모델	설명	제품 예
키-값 저장 구조	- 가장 간단한 데이터 모델 - 범위 질의는 사용이 어려움. (DB 지원시 사용 가능) - 응용 프로그램 모델링 복잡	- DynamoDB(아마존) - Redis
열 기반 저장 구조	- 연관 데이터 위주로 읽는데 유리한 구조 - 하나의 레코드 변경하려면 여러 곳 수정해야 함. - 동일 도메인의 열 값이 연속 → 압축 효율이 좋음. 범위 질의 유리	- Bigtable(구글) - Cassandra(아파치) - HBase - HyperTable
문서 저장 구조	- 문서마다 다른 스키마 - 레코드 간 관계 설명 가능 - RDBMS와 개념적으로 비슷	- SimpleDB(아마존) - CouchDB(아파치) - MongoDB

 

▲ NoSQL DB 제품 및 특징

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

 

• 빅데이터 저장 시스템 선정을 위한 분석
  
  • 분석방식 및 환경
    • 빅데이터 저장 방식; 파일 시스템 형식으로 저장 / NoSQL 저장시스템 사용 / RDBMS에 기반 둔 데이터 웨어하우스 방식
    • 필요로 하는 분석 및 검색결과 → 상시로 온라인 형식으로 필요한지 / 분석가를 통해 별도의 프로세스를 거쳐 제공받는지 등을 구분 → 저장 방식과 환경 선택
  • 분석대상 데이터 유형
    • 기업 내외부에서 발생하는 기업 데이터인가, IoT 환경에서 발생하는 데이터인가 혹은 기타 다양한 바이오 분야에서 취급되는 데이터인가에 따라서 빅데이터 저장시스템 선택
  • 기존 시스템과의 연계
    • 저장 대상 데이터 유형이 테이블로 정의가능한 형태이고 기존 RDBMS 기반 데이터 웨어하우스가 도입된 형태 → 기존 시스템 그대로 활용
    • 기존에 HDFS만을 활용해 빅데이터 저장시스템이 구축 → SQL-like 분석환경 구축하고자 할 때 → HBase 추가 도입 권장
    • 빅데이터 분석 애플리케이션이 키-값 쌍 처리 위주로 시스템이 구현되어 있다면 Redis 등 도입
    • IoT 데이터처럼 데이터가 지속적+실시간 발생 수집하는 시스템 환경 → key-value, DB나 확장성이 중요한 요소일 때 → Cassandra와 같이 확장성 보장된 칼럼 기반 DB 선정
  • 기능성 비교분석

구분	내용
데이터 모델
확장성	- HBase, Cassandra, HyperTable과 같은 column-oriented DB가 확장성 뛰어남. - Redis와 같은 인메모리 방식의 DB와 MongoDB, CouchDB와 같은 document DB는 약간 뒤처짐.
트랜잭션 일관성	- 데이터 수정, 삭제 등 작업이 빈번하게 일어나는 환경에선느 중요도가 높지만, 배치중심 하둡 기반 분석환경에서는 중요도가 그리 높지 않음. - 트랜잭션의 일관성이 중요한 분야 → RDBMS 선택 (그렇지 않으면, NoSQL 선택)
질의 지원	- MongoDB; SQL과 유사한 문법에 기반 → 쉽게 학습 가능한 우수한 질의 인터페이스 지원 - CouchDB도 MongoDB에 비해 뒤처지지 않으며, 뷰 개념 이해하고 활용하면 간편 - key-value DB의 대표 격인 Redis도 풍부한 질의기능 - HBase나 HyperTable은 자체 질의지원 기능은 제공 X. Hive를 통해 SQL과 유사한 질의기능 사용 가능
접근성	- MongoDB 접근 드라이버 다양. 현존하는 주류 라이브러리용 드라이버 대부분 지원 - CouchDB는 웹통신 지원하는 프로그래밍 언어라면 다 사용이 가능 - Redis, HBase, HyperTable, Cassandra는 대부분 프로그래밍 언어에서 연결이 가능토록 언어 바인딩 지원

 

• 데이터 발생 유형 및 특성
  
  • 대용량 실시간 서비스 데이터 개요
    • 일반적으로 실시간으로 처리해야 하는 데이터를 스트리밍 데이터로 통칭 → 대용량 특성과 무중단 서비스 보장하는 저장 체계 구축
    • 대표적; Spark, Storm 등. 배치 기반의 대용량 데이터 처리에 특화된 하둡 시스템보다 실시간 대용량 데이터 처리에 특화
    • IoT 데이터(센서, 네트워크 모니터링, 에너지 관리 분야, 통신 데이터, 웹 로그, 주식 데이터나 생산현장에서 발생하는 데이터 등이 해당)
  • 대용량 실시간 서비스 데이터 저장
    • Storm(대표적인 실시간 빅데이터 처리 시스템)을 사용 → 저장소가 벗어 외부 저장 시스템과의 연동이 필수적
    • 다양한 소스의 로그로부터 데이터가 발생하는 환경 → 스톰으로 데이터 전처리한 후, HDFS나 MongoDB, Cassandra, HBase와 같은 NoSQL을 저장소로 사용하거나, 데이터 정규화하여 일반 RDBMS를 저장소로 사용 가능
    • 스파크 → 외부 빅데이터 저장 시스템과의 연계 필수적
    • 실시간 서비스를 웹 페이지로 제공하는 것이 필요한 환경 → Redis와 같은 메인 메모리 저장 시스템을 저장소로 활용 가능
• 안정성과 신뢰성 확보 및 접근성 제어계획 수립
  
  • 빅데이터 저장시스템 안정성 및 신뢰성 확보
  • 접근성 제어계획 수립
    • 저장 시스템의 사용자와 관리자 유형, 역할 및 기능을 정의하고 각각 해당하는 제어계획 수립

Q. 다음 NoSQL DB 중 데이터 저장 구조가 나머지와 다른 하나?
1) HBase
2) Cassandra
3) Bigtable
4) DynamoDB → 키-값 데이터 모델 사용 (나머지는 컬럼기반 데이터모델 사용)