[빅분기] PART1. 빅데이터 분석 기획 - 데이터 수집 및 저장 계획 - 데이터 적재 및 저장 (출제빈도 : 하)

   * 본문은 이기적에서 발행한 빅데이터분석기사 수험서를 공부하면서 작성된 글입니다. 시험 대비한 공부로, 암기가 필요한 부분을 요약/정리합니다.

PART1. 빅데이터 분석 기획

3. 데이터 수집 및 저장 계획

3-2. 데이터 적재 및 저장

※ 분산된 여러 서버에서 데이터를 수집하는 플랫폼과 저장 방법의 중요성이 커지고 있음.

1) 데이터 적재

수집된 데이터는 분석을 위한 '저장'시스템에 '적재'해야 함 

※ 저장시스템 : 관계형 DB, HDFS(분산파일시스템), NoSQL

* 데이터 적재 도구/방법

 ① 데이터 수집 도구를 이용 : 대표적으로 플루언티드 / 플럼 / 스크라이브 / 로그스태시 등이 있음

  - 플루언티드 : 오픈소스SW, 사용자의 로그를 JSON포맷으로 변환한 뒤 다양한 형태로 출력

  - 플럼 : 많은 양의 로그 데이터를 효율적으로 수집/취합/이동하기 위한 분산형SW

           SNS, E-mail 등 대량 이벤트 데이터 전송을 위해 주로 사용

  - 스크라이브 : 수많은 서버로부터 실시간 스트리밍 로그 데이터 집약하기 위한 서버

  - 로그스태시 : 다양한 소스에서 데이터 수집 및 변환 후 자주 사용하는 저장소

 ② NoSQL DBMS가 제공하는 도구를 이용

  - 로그 수집기처럼 많은 기능은 없지만 데이터가 csv 등의 텍스트라면 mongoimport와 같은 도구 사용 가능

  - 로그 수집기 처럼 데이터 수집 주기 등을 설정하여 사용할 수는 없음

 ③ 관계형 DBMS의 데이터를 NoSQL DBMS에 적재

  - 기존 운영중인 RDB에서 데이터 추출하여 NoSQL DB로 적재

  - 데이터 변형이 많으면 별도 프로그램 작성. 별로 없으면 SQLtoNoSQLimporter, Mongify 도구 활용

* 데이터 적재 완료 테스트

 ① 적재 데이터 유형 및 특성에 따른 체크리스트 작성

  - 정형 데이터 : 테이블 개수, 속성 개수, 데이터 타입 일치 여부, 레코드 수 일치 여부 등

  - 반/비정형 데이터 : 원천 데이터 테이블이 목적 저장 시스템에 맞게 생성되었는지, 레코드 수 일치하는지 등

 ② 데이터 테스트 케이스 개발 (적재가 정상 완료 되었는지 확인 시험)

  - 원천 데이터에서 특정 데이터 샘플링 → 목적 저장시스템에서 조회 테스트

  - 적재된 대량 데이터의 데이터 타입, 한글 문자 등 ASCII 코드가 아닌 문자열 정상 적재 여부 확인 등

  - 문자열↔숫자 정상 인식 확인 여부 (ex. 숫자인데 문자로 인식되는 경우(제품명), 문자인데 숫자로 인식되는 경우(날짜))

 ③ 체크리스트 검증 및 데이터 테스트 케이스 실행

  - ①체크리스트 ②테스트케이스 에 대해 검증을 실행 → 데이터 적재 결과 보고서

2) 데이터 저장

* 빅데이터 저장 시스템

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

분산 파일 형태로 저장하는 방식과 데이터베이스 시스템을 이용하는 방식이 있음

 ① 파일 시스템 저장 방식

  - 저사양 서버들을 활용해 대용량, 분산, 데이터 집중형 App을 지원. 사용자들에게 fault-tolerance 환경 제공

  - 확장 가능한 분산 파일 형태로 저장하는 대표적인 예로 Apache HDFS, 구글 GFS가 있음

 ② 데이터베이스 저장 방식

  - 정통적인 RDB를 이용하거나 NoSQL DB를 이용하는 방식이 있음. 최근에는 NoSQL방식이 선호되고 있음

  - NoSQL DB는 대용량 저장 측면에서 봤을 때 RDB보다 수평확장 / 데이터 복제 / 간편한 API / 일관성 보장

* 분산 파일 시스템

 ① 하둡 분산파일 시스템(HDFS : Hadoop Distributed File System)

  이미지 출처 : 갈아먹는 머신러닝 (https://yeomko.tistory.com)

  - Hadoop : Apache에서 분산 환경 컴퓨팅을 목표로 시작한 프로젝트

  - HDFS : 분산 처리를 위한 파일 시스템. 대용량 파일을 여러 블록으로 분산하여 저장. (기본 크기 64MB)

  - 마스터(네임) 노드와 여러 개의 슬레이브(데이터) 노드로 클러스터링 되어 있음

    ※ 마스터 - 슬레이브 관리용 메타데이터, 모니터링 시스템 운영 / 슬레이브 - 데이터 블록을 분산 처리

  - 데이터 손상 방지를 위해 데이터 복제 기법 사용

  - 분산 데이터 처리를 위해 맵리듀스(MapReduce) 기법 활용

    ※ 구글에서 발표한 방법을 하둡 프로젝트에서 구현, 입력을 여러 조각으로 나눠 처리 후 결합하는 방식

  [장점]

   - 대용량의 비정형 데이터 저장 및 분석에 효율적임

   - 클러스터링 구성을 통해 부하를 분산시켜 처리

   - 개별 서버에서 진행되는 병렬처리 결과를 하나로 묶어 시스템 과부하나 병목현상 감소

   - 장비를 증가시킬수록 성능이 향상 됨

   - 무료 (오픈소스)

 ② 구글 파일 시스템(GFS : Google File System)

  이미지 출처 : jinh2352.log (https://velog.io/@jinh2352/Google-File-System-2-Architecture)

   - 구글이 엄청나게 많이 보유한 핵심 데이터 스토리지와 구글 검색 엔진을 위한 최적화된 분산 파일 시스템

   - 마스터(Master)-청크(Chunk)-클라이언트(Client) 로 구성

     ※ 마스터 - 전체 상태 관리 및 통제 / 청크 - 물리적 HDD 입출력 처리 / 클라이언트 - 파일 읽기/쓰기App

   - 저렴한 서버에서도 사용 가능하도록 설계되어 HW안전성 + 자료 유실 대비 + 높은 처리 성능

* NoSQL

 ① 개요

  - 전통적인 RDB보다 유연한 저장 및 검색 메커니즘 제공

  - 대규모 데이터 처리 위한 확장성, 가용성, 높은 처리/저장 성능을 가진 플랫폼으로 활용

  - SQL 쿼리를 지원하기도 해서 Not Only SQL로 불리기도 함.

 ② CAP 이론 : 기존 데이터 저장 구조의 한계 (2002년 버클리 대학 에릭 브루어 교수가 발표한 이론)

  - 분산 컴퓨팅 환경의 특징을 세 가지로 정의, 어떤 시스템이든 세가지 동시 만족 어려움

  - 일관성(Consistency) : 분산 환경에서 모든 노드가 같은 시점에 같은 데이터 보여줘야 함.

  - 가용성(Availability) : 일부 노드가 다운되어도 다른 노드에 영향을 주지 않아야 함.

  - 지속성(Partition Tolerance) : 데이터 전송 중 일부 데이터 손실하더라도 시스템은 정상 동작 필요

 ③ NoSQL 기술적 특징

  - RDBMS의 주요 특성을 보장하는 ACID특성 중 일부만 지원하는 대신 성능과 확장성이 높다

    ※ ACID(원자성, 일관성, 고립성, 지속성) : DB 트란잭션이 안전하게 수행되는 것을 보장하기 위한 성질

  - 無스키마 : 데이터 모델링하는 고정된 스키마 없이 키값을 이용해 다양한 형태의 데이터 저장/접근 가능

    ※ 데이터 저장 방식은 열 / 값 / 문서 / 그래프 등 네 가지를 기반으로 구분

  - 탄력성(Elasticity) : 장애가 발생해도 클라이언트가 시스템에 접근 가능 + 대용량 데이터 생성/갱신. 

    질의에 대응하기 위해 시스템 규모 및 성능 확장 용이. 입출력 부하 분산에 용이한 구조

  - 질의(Query) 기능 : 대규모 시스템에서도 효율적 데이터 검색/처리 할 수 있는 쿼리, 관련기술, API 제공

  - 캐싱(Caching) : 대규모 질의에도 고성능 응답 속도 제공할 수 있는 기술

 ④ NoSQL 데이터 모델 : 저장 방식에 따라 키-값 구조, 칼럼기반 구조, 문서기반 구조로 구분

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

 ① 기능성 비교 분석 : 데이터 모델 / 확장성 / 트랜잭션 일관성 / 질의 지원 / 접근성 관점 비교

    ↓ 분석예시 ↓

    [데이터 모델]

    - 테이블로 정리하는데 무리 없다면 굳이 NoSQL사용하지 않고 RDBMS사용

    - RDBMS에서 문서 중심 DB로 전환하는데 MongoDB 좋음

    - 웹기반 문서 DB 구축 시 Apache CouchDB 가 RESTful HTTP 지원하기 때문에 좋음

    - 단순히 안정적인 key-value 분산 저장소가 필요할 경우 Dynamo나 Redis

    [확장성]

    - 극단적 확장성 보장받기 위해 Cassandra, HyperTable, HBase (column family 중심)

    - Redis(인메모리 방식) 이나 MongoDB, CouchDB는 확장성이 약간 뒤쳐짐

    [트랜잭션 일관성]

    - 데이터 수정/삭제 등의 작업이 빈번히 일어나는 환경에서 중요도 높음 (RDBMS)

    - 배치 중심의 하둡 기반 분석환경에서는 중요도 그리 높지 않음 (NoSQL)

    [질의 지원]

    - MongoDB는 SQL과 유사한 문법을 기반하여 우수한 I/F 지원

    - CouchDB도 뷰 개념을 이해하고 활용하면 MongoDB에 뒤처지지 않음

    - key-value DB의 대표격인 Redis도 우수한 I/F 지원

    - HBase나 HyperTable은 자체 질의 기능 없음. Hive를 통하면 SQL과 유사한 기능 사용 가능

    [접근성]

    - MongoDB는 현존하는 주류 라이브러리 대부분 지원

    - CouchDB는 웹 통신 지원하는 언어라면 모두 사용 가능

    - 기타 Redis, HBase, HyperTable, Cassandra는 대부분 언어 연결 가능하도록 바인딩 지원

 ② 분석방식 및 환경

  - 빅데이터 저장방식 : 파일시스템 / NoSQL / 데이터 웨어하우스(RDBMS 기반)

  - 필요로 하는 분석 및 검색 결과가 상시 온라인 인지, 별도 프로세스를 거쳐 받을지 등을 구분해 선택

 ③ 분석대상 데이터 유형

  - 내부의 기업데이터인지, IoT 데이터인지 등에 따라 Volume / Velocity / Variety / Veracity 고려해 선택

 ④ 기존 시스템과의 연계 (★)

  - 저장 대상이 테이블로 저장될 수 있고, 기존에 RDBMS 도입되어있다면 그대로 활용

  - 기존에 HDFS만을 활용해 구축되어있으나 SQL-like 환경 구축하고자 한다면 HBase 추가 도입 권장

  - 분석 App.이 키-값 쌍으로 구현되어 있다면 Redis 등 도입하는 것이 좋음

  - IoT처럼 실시간 수집 환경이라면 key-value DB

  - 데이터 확장성이 중요한 요소라면 Cassandra와 같이 확장성 보장된 칼럼기반 DB

* 데이터 발생 유형 및 특성

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

  - 용량 / 실시간 여부 / 저형 / 비정형 등 유형및 요건 파악하여 저장 계획 수립에 반영 필요

  - 대용량 데이터 실시간 처리 필요 없을때는 하둡 기반 대용량 데이터 처리 시스템 선택

  - 대용량 실시간 처리 데이터(스트리밍 데이터) → 무중단 서비스 보장하는 저장 체계 구축 필요

    ex. IoT센서데이터, 네트워크 모니터링 데이터, 에너지 데이터, 통신 데이터, 웹 로그, 생산 데이터 등

  - 스파크(Spark), 스톰(Storm) 이 대표적. (배치 기반의 하둡 보다 실시간 처리에 특화)

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

  - 스트리밍 데이터의 수집/처리에 특화된 시스템과 연계가 필수

  - 스톰/스파크는 저장소가 없음으로 스톰으로 전처리 후 외부 저장 시스템(NoSQL, RDBMS)과 연동 필수

  - 실시간 서비스를 웹 페이지로 제공하는 경우 Redis와 같은 메모리 기반 저장 시스템 사용하기도 함

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

 ① 빅데이터 저장시스템 안정성 및 신뢰성 확보

  - 저장 계획 수립단계에서 용량 산정이 필요. (현재와 향후 증가 추세를 추정)

 ② 접근성 제어계획 수립

  - 저장 시스템 사용자 및 관리자 유형 / 역할 / 기능을 정의하고 각각의 제어계획 수립 필요