빅데이터를 지탱하는 기술 - Chapter4 빅데이터의 축적

벌크 형과 스트리밍 형의 데이터 수집 - 4.1

---

객체 스토리지

• 빅데이터는 확장성이 높은 분산스토리지에 저장하지만, 기본은 대량으로 파일 저장을 위한 객체스토리지이다. ex)HDFS, Amazon S3
• 다수의 컴퓨터를 사용하여 파일을 여러 디스크에 복사 → 데이터의 중복화 부하분산 실현
• 네트워크를 통해 읽기 때문에 작은 파일을 자주 읽고 쓰는건, 통신 오버헤드가 크다.

데이터의 수집

• 시계열 데이터는 적당히 모아서 하나의 큰 파일로 만든다.
• 너무 큰 파일을 나눠서 처리한다.
• 단순 수집이 아닌 처리하기 쉽도록 위의 규칙을 지킨다.
• 수집 - 가공 - 구조화 - 분산스토리지의 장기적인 저장이 데이터 수집이다.

벌크 형 데이터 전송

• 생성
  • 파일 서버, 웹 서비스에서 다양한 방식(SQL, API)으로 정리해 데이터를 추출하는 경우
  • 기존 DB에서 추출도 벌크 형 전송이다.
  • 데이터가 분산 스토리지에 있는 경우를 제외하고, 데이터 전송을 위한 ETL서버를 설치한다.
    • ETL서버에서 구조화된 데이터 처리에 적합한 DW를 위한 ETL 도구 & 벌크 전송 도구 & 작성한 스크립트를 이용하여 데이터를 전송한다.
• 저장, 전송 팁
  • 한번에 많은 량의 데이터를 보내지말고, 너무 크다면 나눠서 보내라 → 워크플로 관리 도구
  • 스트리밍 처럼 계속 동작하지 않기에 워크플로 관리 도구와 궁합이 좋다. → 신뢰성이 좋아짐
  • 실패한 작업, 데이터 결손 등의 문제해결에 좋다.

스트리밍 데이터 전송

• 생성
  • 다수의 클라이언트에서 계속해서 작은 데이터가 전송 된다 → 메시지 배송
  • 통신 오버헤드가 커서 서버성능이 좋아야한다.
• 저장, 전송 팁
  • 작은 데이터 쓰기에 적합한 NoSQL → Hive(쿼리엔진) → 데이터 읽기 조합
  • 메세지 큐와 브로커를 사용해서 중계 시스템을 거쳐서 분산 스토리지에서 저장하기
• 웹 브라우저에서의 메시지 배송
  • 데이터 전송 효율을 위해 서버상에서 축적해놓고 보내기 → Fluentd, Logstash(서버 상주형 로그 수집)
  • 웹 브라우저에서 직접 메시지 보내기(다른 서버 전송되거나, API경유) → 웹 이벤트 트랙킹
• 모바일 앱으로부터의 메시지 배송
  • HTTP 프로토콜을 사용하므로 웹 브라우저와 동일, 서버를 직접 마련하지 않고 MBaaS라는 백엔드 서비스 이용하여 DB에 저장하고 후에 저장된 것을 벌크 형 도구로 꺼낸다.
  • SDK의 내부에 축적하다가 온라인 상태 때 보내는 경우도 있다.
• 디바이스로부터의 전송
  • MQTT라는 TCP/IP를 사용하는 프로토콜

메세지를 가장 처음 받는 서버를 프론트라고하고, 프론트에서 받은 것을 메세지 브로커로 전송하고나서 어려운 문제를 처리한다.

 

메세지 배송의 트레이드 오프 - 4.2

---

메시지 브로커

• 메세지 배송으로 보내진 데이터를 분산 스토리지에서 빈번하게 쓰면서 디스크가 한계가 될 경우에 도움을 준다.
• 분산스토리지 성능을 올리지 않고, 배송되는 데이터를 일시적으로 축적하는 시스템이다. ex 카프카 키네시스
• 푸쉬,풀 형
  • 푸쉬로 메세지 브로커에 보내고, 풀로 일정한 크기를 파일로 만들어 분산스토리지로 푸쉬한다.
• 메시지 라우팅
  • 메시지 브로커에서 받고 여러 소비자가 Pull 하는 구조이다. 자주가져가면 스트림처리가 된다.

메시지 배송의 신뢰성 문제

• 신뢰성이 낮은 네트워크에서는 중복, 결손이 발생 한다.
• 대부분 하나를 보장하며 시스템 설계
  • at most once : 메시지는 무조건 한번 전송 → 결손
  • exactly once : 메시지는 손실되거나 중복 없이 한번 전송
  • at least once : 메시지는 확실히 전송 되나 여러번 전송 될 수 있다. → 중복

중복 제거의 비용

• TCP에서는 메시지에 시퀀스가 있지만, 분산 시스템에서는 사용되지 않는다.
• 제거 방법들
  • 오프셋
  • 고유ID에 의해 제거
  • 종단간의 신뢰성→모든 과정을 at least once로 통일하고, 경로의 말단에서 중복제거 한다.

데이터 수집의 파이프라인

위의 과정이 완료되고 데이터를 구조화해 열 지향 스토리지로 변환하면, 데이터 분석에 적합한 스토리지가 완성된다.

• 쓰기 성능이 상관없다면 메세지 브로커 필요없이 NoSQL에 그대로 쓴다
• 중복이 상관없다면, 중복 제거도 생략한다.
• 데이터 집계에 쿼리엔진 사용할 경우 구조화된 데이터를 열 지향 스토리지 형식으로 객체 스토리지에 저장
• or MPP DB 사용하는 경우 여기에 저장

 

시계열 데이터의 최적화 - 4.3

---

프로세스 시간과 이벤트 발생 시간은 다른 문제의 해결

• 시계열 인덱스
  • 카산드라 같은 분산 데이터베이스를 이용. 짧은 범위에 유용하다
  • 장기적으로 대량 데이터 집계시, 분산DB가 아니라 열 지향 스토리지를 지속적으로 만들어야한다.
• 조건절 푸쉬다운
  • 일정 기간을 모아 정렬해서 열지향 스토리지로 변환한다. → 풀스캔을 피할 수 있다.
  • 너무 빈번한 주기로 만들지는 말자.
• 이벤트 시간으로 분할
  • 데이터 수집은 프로세스 시간을 사용하고, 데이터마트를 이벤트 시간에 의해 정렬하며 정기적으로 치환한다.

 

비 구조화 데이터의 분산 스토리지 - 4.4

---

분산스토리지

• 확장성과 유연성이 요구
• 기본은 객체스토리지로 임의의 파일을 저장 할 수 있다.
• 쓰기 빈도가 높다면, RDB에 저장해 스냅샷 or 다른 분산데이터베이스에 저장한다.
• 중요한 데이터 처리
  • 기본적으로 트랜젝션 처리가 가능한 DB사용
  • 대부분 일반적인 RDB라도 충분하다
  • RDB가 모자라면 분산데이터베이스를 검토한다.
• 객체스토리지 단점
  • 파일 교체하기 힘들다.(로그파일은 괜찮다)
  • 저장된 데이터 집계까지 열지향 스토리지의 구축 등 시간이 걸린다.
• 이러한 단점을 극복하고 특정 용도에 최적화된 데이터베이스를 NoSQL데이터베이스라고 한다.

NoSQL 특징

• 일반적으로 애플리케이션에서 처음에 데이터를 기록하는 장소로 이용
• 자체 대량 데이터 집계 기능이 대부분 없어, 분석을 위해 외부로 데이터 추출
• RDB등과 비교해 읽기 성능이 높아 쿼리 엔진에서 접속해도 성능상 문제 발생 확률 낮다. → 애드 혹 분석에도 사용
• 트랜잭션 처리의 ACID 성질을 다 지키면서 분산 시스템 구축하기가 힘들다
  • 일관성, 가용성, 분단내성의 세 가지중 하나가 희생된다

NoSQL 종류

• 분산 KVS - Amazon DynamoDB
• 와이드 칼럼 스토어 - 카산드라
• 도큐먼트 스토어 - MongoDB
• 검색엔진 - Elasticsearch, Splunk