04. 빅데이터의 축적

안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다. 감사합니다.

 

 

 

이제 데이터를 수집하고 분산 스토리지에 저장하기까지의 프로세스를 공부해 볼 것이다.

 

우선 데이터의 종류는 크게 벌크형과 스트리밍 형이 있고, 이 형태에 따라 저장 프로세스의 차이가 크기 때문에, 이 둘을 나눠 공부/비교해 보겠다.

 

그리고, 요즘은 NoSQL에 데이터를 저장하는 트렌드가 있기 때문에, NoSQL에 데이터를 수집하기 위해 알아야 할 것들에 대해 공부해볼 것이다.

 

 

(이전 NoSQL 중 대표적인 MongoDB에 대한 웨비나를 들은 적이 있는데, MongoDB에 대해 추가적으로 알고 싶은 분들은 아래 정리해 둔 포스팅을 참고해주시기 바랍니다.)

https://eng-sohee.tistory.com/74

[웨비나] 'RDBMS에서 MongoDB로의 Replacement 전략과 사례' 를 들으며

 

목차

벌크 형의 데이터 수집

스트리밍 형의 데이터 수집

NoSQL DB 데이터 수집

 

---

 

 

01. 벌크 형의 데이터 수집

 

보통 데이터는 확장성이 높은 분산 스토리지에 저장한다. 이때, 보통 분산 형의 DB가 이용되는 경우보다 객체 스토리지가 더 많이 사용된다.

 

🔥 여기서 잠깐! 분산 스토리지/객체 스토리지란?

분산 스토리지: 데이터를 네트워크에 연결된 서버에 저장하는 기술. 
객체 스토리지: 구조화되지 않은 데이터의 대량 저장을 위한 데이터 스토리지 아키텍처. 객체 형태로 데이터 저장이 가능한 스토리지.

분산된 객체 스토리지 구조가 무조건적으로 좋을까?

그렇지 않다. 네트워크에 많이 분산되어있을 때 데이터 양이 너무 적으면 데이터 대비 통신 오버헤드가 너무 커질 수 있다.

객체 스토리지의 단점은?

파일을 넣으면 교체하기 어려워서 수시로 변경하기에는 올바르지 않다. 쓰기 빈도가 높으면 정기적 스냅숏을 하는 등의 작업이 필요하다.

벌크 형 데이터 수집이란?

데이터 베이스나 파일 서버 또는 웹 서비스 등에서 데이터를 정리해 수집하는 방법을 뜻한다. 과거에 축적된 대량 데이터가 이미 있는 경우에 쓰면 좋다.

 

 

1-1. Task의 크기

너무 많은 양의 데이터를 한 번에 전송하면 네트워크 전송에 시간이 걸려 예상치 못한 오류가 발생할 수 있다.

하지만 너무 적은 태스크로 분해하면, 효율이 떨어져 성능 저하의 요인이 된다. 

 

즉 전송할 데이터 태스크는 적당히 분해하는 게 좋고,
이 적당히라는 것이 상당히 어렵기 때문에 워크플로 관리 도구를 이용해 관리한다.

 

벌크형 데이터 전송이 필요할 때는 언제인가?
데이터 신뢰성이 중요한 경우에 실행한다.

(추가- 워크플로 관리 도구인 aphache airflow 와 결합해 사용하면 좋다.)

 

---

  

02. 스트리밍 형의 데이터 수집

데이터가 생성되는 즉시 수집되는 경우 발생하는 수집이다. 이를 메시지 배송이라고 한다.

 

앞서 설명했듯, 데이터는 너무 자잘하게 전송이 되면 오버헤드 이슈가 발생한다. 따라서 서버 성능이 무조건적으로 좋아야 한다. 이 문제를 해결하기 위해, 메시지 브로커를 사용한다.

 

메시지 브로커란?

일종의 버퍼역할이다.
로그 수집 소프트웨어(fluentd, logstash 등)가 데이터를 메시지로써 수집하면 메시지 배송에 성공한 데이터는 사라져 버려 나중에 다시 송신할 수 없다. fluentd에도 버퍼 메커니즘이 있지만, 메시지 배송 이후 발생된 에러로 데이터를 복구하긴 어렵다. 버퍼 역할을 위해 만들어진 소프트웨어가 아니기 때문이다.

쓰기 성능 한계 오류가 생기면 메시지 재전송되어야 할 경우가 생긴다. 즉 빈번한 쓰기가 생길 수 있다.

 

 

중개인은 데이터 생산자에 의해 메시지 브로커로 데이터가 전달되면(Push), 메시지 브로커가 임시 스토리지를 만들어 모은다. 그후 그것을 분산 스토리지로 전달(Pull)해 저장하는데, 이때 오픈 소스 메시지 브로커 종류가 Apache Kafka, Amazon Kinesis 등이 있다.

 

👉🏻 결론: 메시지 브로커는 쓰기 성능 불안을 해소하기 위한 도구다.

 

카프카가 무엇인지에 대해 공부했던 포스팅을 아래 넣도록 하겠다.

https://eng-sohee.tistory.com/62

05. 플럼과 카프카 개념+설치

.

 

 

 

모바일 실시간 데이터 전송 방법?

MBaaS(Mobile Backend as a Service) 등으로 데이터가 토픽 형태로 생성된다. Pub/Sub형 메시지 배송 즉 전달과 구독 배송 기반이다. 따라서 토픽을 구독하면 생성된 메시지가 도착한다. 토픽을 전달하면 구독 중인 모든 클라이언트에게 보내진다. 

 

 

2-1. 메시지 배송 방법 종류

• at most one : 딱 한번 메시지 전송
• exactly once : 메시지는 손실 및 중복 없이 한 번만 전송
• at least once : 메시지는 확실히 전송(중복 가능)

 

at most one : 딱 한번 배송되므로 오류 생기면 메시지를 빠트릴 가능성이 있다.

 

종류만 보면 excatly once 가 좋아 보이지만, 양 쪽의 통신내용을 보장하기 위한 코디네이터가 필요한데, 이 코디네이터의 부재 및 오류의 경우에 대처할 수 없고, 코디네이터 판단에 너무 많은 의존을 할 수밖에 없기 때문에 사용하지 않는다.

 

 

따라서 at least once를 많이 쓴다. 즉, 메시지 중복될 가능성 고려하여 시스템을 구축한다. 멱등성을 고려하면 된다.

 

중복 제거는 높은 비용의 오퍼레이션이 발생하지 않는가?

전송한 각 파일 안의 시작 위치(=오프셋)로 분리해 중복되면 같은 오프셋에 덮어쓴다.
혹은 고유 ID에 의해 중복을 제거한다.
👉🏻이는 수많은 ID 관리 이슈가 있다. 최근에 받은 ID만 기억하고 그보다 늦게 온(오류 때문에) 중복은 허용한다. 이래도 대부분은 빅데이터라 퍼센트 관점에서 99% 신뢰도는 달성된다. SQL 등으로 중복을 제거한다. 아니면 Cassndra 혹은 ElasticSearch는 데이터 쓸 때 고유 ID 지정해야 하는 DB 특징이 있으므로 아예 이런 DB를 쓰는 것도 방법이 되겠다.

 

 

결론은, 중복이 되더라도 데이터는 무조건 수집한다. 중복 처리는 나중에 하면 된다는 것이 기본 전제다.

중복 제거 후, 열 지향 스토리지로 변환하면 데이터가 완성된다.

 

🔥 열지 향스토리지란?

데이터를 행으로 저장하지 않고 열로 저장하는 방식. 행은 하나의 feature를 load 할 때도 모든 값을 load해와야 하는데, 열은 그렇지 않기 때문에 효율적이다.

열지향 스토리지 참고 문서: https://ko.vvikipedla.com/wiki/Column-oriented_DBMS

 

 

이벤트 시간과 프로세스 시간 처리 방법

프로세스 시간: 데이터를 수집한 시간
이벤트 시간: 데이터가 발생한 시간

일반적으로 프로세스 시간을 기준으로 데이터를 수집하고, 이벤트 시간에 대한 인덱스를 만든다.
예를 들어 Cassandra에서는 시계열 인덱스에 대응하는 분산 DB이므로 이런 것을 이용한다.

여기서 잠깐! 조건절 푸시다운이란?
필요한 최소한의 데이터만을 읽도록 하는 최적화 방법이다. 즉, 풀 스캔을 피하는 방법이다.

 

---

03. NoSQL DB 데이터 수집

NoSQL 이란, 테이블 간 관계를 정의하지 않고 하나의 테이블로 구성되어 있는 데이터 베이스다.

이 종류는 크게 분산 KVS, 와이드 칼럼 스토어, 도큐먼트 스토어, 검색엔진이 있다.

 

 

3-1. 분산 KVS

모든 데이터를 키값 쌍으로 저장하도록 설계한 데이터 저장소. 예시로는 DynamoDB가 있다.

 

Key를 지정하는 이유?
부하의 분산을 위해서다. 키값이 주어지면 어느 노드에 배치할지 결정한다. 노드 간 부하를 균등하게 분산해서 성능을 조절한다.

DynamoDB의 특징?
P2P형의 분산 아키텍처를 가지고 있어 초단위의 요청수에 따라 노드가 증감되는 특징이 있다.

 

 

 

3-2. 와이드 칼럼 스토어

분산 KVS를 발전시켜, 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것을 말한다.

예시로는 HBase나 Cassandra, Google Cloud Bigtable이 있다. 

하나의 테이블에 가로와 세로의 2차원에 데이터를 쓸 수 있도록 하였다. 이는 열처럼 칼럼도 얼마든지 추가가 가능하다.

 

 

 

 

3-3. 도큐먼트 스토어

다른 NoSQL은 성능 향상을 목표로 하는 반면, 이는 데이터 처리의 유연성을 목적으로 처리한다.

예를 들어 json 같은 스키마 리스 데이터를 그대로의 형태로 저장하고 쿼리를 실행하는 것이 이에 해당한다. 

즉, 스키마를 정할 필요가 없다. 대표적으로는 MongoDB가 있다.

 

 

 

 

3-4. 검색엔진

noSQL과 성격이 다르지만 저장된 데이터를 쿼리로 찾는 데에서는 유사하다. 검색엔진의 특징은 텍스트 데이터 전문 검색을 위해 역 색인을 만드는 부분이다.

 

 

역 색인이란?

텍스트에 포함된 단어를 분해하고 어떤 단어가 어떤 레코드에 포함되어 있는가에 대한 인덱스를 먼저 만들어서 검색을 고속화한다.
예시로는 구글 빅쿼리(Big Query)가 있다.

 

즉 검색엔진은 데이터 찾기에 특화돼있다. 예시로는 ElasticSearch가 있다. ElasticSearch는 아무것도 지정하지 않으면 모든 필드에 색인이 만들어진다는 특징이 있다고 한다. 이에 대한 개념은 추후 더 자세히 공부해볼 것이다.