[빅분기] CH3. 데이터 수집 및 저장 계획_데이터 적재 및 저장
24.03.17
01. 데이터 적재
1) 데이터 적재 도구
- 수집한 데이터는 저장 시스템에 적재해야 함! 적재할 데이터의 유형과 실시간 처리 여부에 따라 다름
① 데이터 수집 도구를 이용한 데이터 적재
- 로그 수집을 해야 하는 각 서버에 Fluentd를 설치하면 서버에서 로그를 수집해서 중앙 로그 저장소로 전송함
- 플루언티드(Fluentd): 트레저 데이터에서 개발된 크로스 플랫폼 오픈 소스 데이터 수집 소프트웨어!
: 사용자의 로그를 다양한 형태로 입력받아 JSON 포맷으로 변한 뒤 다양한 형태로 출력함!
- 플럼(Flume): 많은 양의 로그 데이터를 효율적으로 수집, 취합, 이동하기 위한 분산형 소프트웨어
: 로그 데이터 수집과 네트워크 트래픽 데이터, 소셜 미디어 데이터, 이메일 메시지 데이터 등 대량의 이벤트 데이터 전송에 사용됨
- 스크라이브(Scribe): 수많은 서버로부터 실시간으로 스트리밍되는 로그 데이터를 집약시키기 위한 서버
: 클라이언트 사이드의 수정 없이 스케일링 가능하고 확장이 가능!
- 로그스태시(Logstash): 다양한 소스에서 데이터를 수집해 변환한 후 자주 사용하는 저장소
② NoSQL DBMS가 제공하는 도구를 이용한 데이터 적재
- 로그 수집기를 이용한 방법처럼 많은 기능 사용 X, 수집한 데이터가 CSV 등의 텍스트 데이터라면 mongoimport와 같은 적재 도구 사용
- 로그 수집 도구를 쓰는 방식처럼 데이터 수집 주기 등을 환결성정해 사용할 수 X
③ 관계형 DBMS의 데이터를 NoSQL DBMS에서 적재
2) 데이터 적재 완료 테스트
① 데이터 적재 내용에 따라 체크리스트를 작성
② 데이터 테스트 케이스를 개발
③ 체크리스트 검증 및 데이터 테스트 케이스 실행
02. 데이터 저장
1) 빅데이터 저장시스템
① 파일 시스템 저장방식: 빅데이터를 확장 가능한 분산 파일의 형태로 저장하는 방식의 대표적의 예) 아파치HDFS, 구글의 GFS
② 데이터베이스 저장방식: 전통적인 관계형 데이터베이스 시스템 이용, NoSQL 시스템 이용
→ NoSQL 데이터베이스는 대용량 데이터 저장 측면에서 봤을 때 관계형 데이터 베이스보다 수평적 확장성, 데이터 복제, 간편한 API 제공, 일관성 보장 등의 장점
2) 분산 파일 시스템
① 하둡 분산파일 시스템(HDFS)
- 아파치 진영에서 분산 환경 컴퓨팅을 목표로 시작한 프로젝트
- HDFS는 클러스터에 여러 블록으로 분산해 저장, 블록들은 마지막 블록을 제외하고 모두 크기 동일
- 마스터 하나와 여러 개의 슬레이브로 클러스터링 되어 구성
- 마스터노드(네임노드): 슬레이브를 관리하는 메타데이터와 모니터링 시스템 운영
- 슬레이브노드(데이터노드): 데이터 블록을 분산 처리
- 데이터 손상을 방지하기 위해 데이터 복제 기법 사용
<하둡의 장점>
- 대용량의 비정형 데이터 저장 및 분석에도 효율적
- 클러스터 구성을 통해 멀티 노드로 부하를 분산시켜 처리
- 개별적인 서버에서 진행되는 병렬처리 결과 하나로 묶어 시스템 과부하나 병목 현상을 줄여줌
- 하둡은 장비를 증가시킬 수록 성능이 향상됨, 오픈소스 하둡은 무료로 사용 가능
<맵리듀스>
- Input → Splitting → Mapping → Shffling → Reducing → Final result
- 맵리듀스 패턴의 종류: 단어 세기 / 그룹화 / 조인 / 필터링 / 인버트 인덱스 / 최대최소값 / 통계
② 구글 파일 시스템(GFS)
- 구글 검색 엔진을 위해 최적화된 분산 파일 시스템
- 마스터, 청크 서버, 클라이언트로 구성
- 마스터: GFS 전체의 상태를 관리하고 통제
- 청크 서버: 물리적인 하드디스크의 실제 입출력을 처리
- 클라이언트: 파일 읽고 쓰는 동작을 요청하는 애플리케이션
3) NoSQL
① NoSQL 개요
- 전통적인 관계형 데이터베이스보다 유옇낳 데이터 저장 및 검색을 위한 매커니즘 제공, 확장성, 가용성 및 높은 성능을 제공
| 구분 | 장,단점 | 특성 |
| RDBMS | - 데이터 무결성과 정확성 보장 - 정규화된 테이블과 소규모 트랜잭션이 있음 - 확장성에 한계있음 - 클라우드 분산 환경에 부적합 |
- UPDATE, DELETE, JOIN 연산이 가능 - ACID 트랜잭션이 있음 - 고정 스키마 있음 |
| NoSQL | - 데이터의 무결성과 정확성을 보장하지 않음 - 웹 환경의 다양한 정보를 검색, 저장 가능 |
- 수정, 삭제를 사용하지 않음(입력으로 대체) - 강한 일관성은 불필요 |
② CAP 이론: 기존 데이터 저장 구조의 한계
- 일관성(Consistency): 분산 환경에서 모든 노드가 같은 시점에 같은 데이터를 보여줘야 함
- 가용성(Availabilty): 일부 노드가 다운되어도 다른 노드에 영향을 주지 않아야 함
- 지속성(Partition Tolerance): 데이터 전송 중에 일부 데이터를 손실하더라도 시스템은 정상 동작해야 함
| 구분 | 설명 | 적용 예 |
| RDBMS | 일관성(C)와 가용성(A)를 선택했음 | 트랜잭션 ACID 보장(금융 서비스) |
| NoSQL | 일관성(C)이나 가용성(A) 중 하나를 포기하고, 지속성(P)를 보장함 |
C+P형: 대용량 분산 파일 시스템(성능 보장) A+P형: 비동기식 서비스(아마존, 트위터 등) |
③ NoSQL의 기술적 특성
| 특성 | 내용 |
| 無 스키마 | - 데이터를 모델링하는 고정된 데이터 스키마 없이 키 값을 이용해 다양한 형태의 데이터 저장 및 접근 가능 - 데이터 저장 방식은 크게 열, 값, 문서, 그래프 등의 네 가지 기반으로 구분 |
| 탄력성 | - 시스템 일부에 장애가 발생해도 클라이언트가 시스템에 접근 가능함 - 응용 시스템의 다운 타임이 없도록 하는 동시에 대용량 데이터의 생성 및 갱신 - 질의에 대응할 수 있도록 시스템 규모와 성능 확장 용이, 입출력의 부하 분산도 용이 |
| 질의 기능 | - 수십 대에서 수천 대 규모로 구성된 시스템에서도 데이터의 특성에 맞게 효율적으로 데이터를 검색, 처리할 수 있는 질의 언어, 관련 처리 기술, API를 제공 |
| 캐싱 | - 대규모 질의에도 고성능 응답 속도를 제공할 수 있는 메모리 기반 캐싱 기술을 적용하는 것이 중요 - 개발 및 운영에도 투명하고 일관되게 적용할 수 있는 구조 |
④ NoSQL의 데이터 모델
- NoSQL의 데이터 저장 방식에 따라 키-값 구조, 칼럼기반 구조, 문서기반 구조로 구분
- 키-값 데이터베이스
: 키와 값의 쌍으로 저장하는 데이터 모델에 기반을 둠, 관계형 데이터베이스보다 확장성 뛰어나고 질의응답 시간이 빠름, 아마존의 DynamoDB가 효시, Redis같은 In-memory방식이 대표적
- 특징: 가장 간단한 데이터 모델 / 범위질의는 사용이 어렵 / 응용 프로그램 모델링이 복잡
- 열기반 데이터베이스
: 데이터를 로우가 아닌 칼럼기반으로 저장, 칼럼과 로우는 확작성 보장을 위해 여러 개의 노드로 분할되어 저장,
구글의 Bigtable이 칼럼기반 데이터베이스의 효시, Cassandra, HBase, HyperTable 등이 대표적
- 특징: 연관된 데이터 위주로 읽는데 유리한 구조 / 하나의 레코드를 변경하려면 여러 곳을 수정해야 함 / 동일 도메인의 열 값이 연속되므로 압축 효율이 좋음 / 범위의 질의에 유리
- 문서기반 데이터베이스
: 문서 형식의 정보를 저장, 검색, 관리하기 위한 데이터베이스, 키-값 데이터베이스보다 문서의 내부 구조에 기반을 둠,
MongoDB, SimpleDB, CouchDB가 대표적
- 특징: 문서마다 다른 스키마가 있음, 레코드 간의 관계 설명이 가능, 개념적으로 RDBMS와 비슷
4) 빅데이터 저장시스템 선정을 위한 분석
① 기능성 비교분석
- 데이터 모델: 데이터를 테이블로 정리하고 사용하는데 무리가 없으면 RDBMS 필요, MongoDB는 RDBMS보다 유연한 스키마 활용
- 확장성: 확장성에는 열기반 데이터베이스가 가장 뛰어남
- 트랜잭션 일관성: 데이터 수정, 삭제 등의 작업이 빈번하게 일어나는 환경에서는 중요도 높지만, 배치중심의 하둡 기반 분석환경에서는 중요도 그리 높지 않음! 일관성 중요하면 RDBMS, 그렇지 않으면 NoSQL
- 질의 지원: MongoDB가 우수한 질의 인터페이스 지원, CouchDB도 괜찮음, Redis도 풍부한 질의기능 제공,
HBase나 HyperTable은 자체 질의지원 기능 제공 X, Hive를 통해 SQL과 유사한 형탤의 질의기능 사용할 수 있다는 장점이 있음
- 접근성: MongoDB 접근하기 위한 드라이버 다양, CouchDB는 웹 통신 지원하는 프로그래밍 언어면 다 사용 가능,
Redis, HBase, HyperTable, Cassandra는 대부분의 프로그래밍 언어에서 연결 가능하도록 언어 바인딩 지원
② 분석방식 및 환경
③ 분석대상 데이터 유형
④ 기존 시스템과의 연계
5) 데이터 발생 유형 및 특성
① 데이터 실시간 서비스 데이터 개요
- 대상 데이터의 용량, 실시간 여부, 정형, 비정형 등 유형 및 요건을 파악해 빅데이터 저장 계획 수립에 반영
- 실시간으로 처리해야 하는 데이터를 스트리밍 데이터로 통칭하는데 대용량의 특성과 무중단 서비스를 보장하는 저장 체계를 구축해야 함
- 실시간 처리 시스템: 스파크, 스톰 등 실시간 대용량 데이터 처리에 특화되어 있음
② 대용량 실시간 서비스 데이터 저장
- 실시간 서비스를 웹 페이지로 제공하는 것이 필요한 환경 = Redis
6) 안정성과 신뢰성 확보 및 접근성 제어계획 수립
① 빅데이터 저장시스템 안정성 및 신뢰성 확보
② 접근성 제어계획 수립