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

다음과 같은 지식을 학습하고 정리합니다

• 벌크형, 스트리밍 형 데이터 전송
• 스트리밍형의 데이터 전송인 메시지 배송 구조와 트레이드오프
  • 성능을 얻고 신뢰성이 희생되는 경우 등
• 메시지 배송에 있어서 프로세스 시간과 이벤트 시간의 구별
  • 이벤트 시간을 고려한 최적화
• 데이터 색인을 통한 최적화
• NoSQL 데이터베이스의 몇 가지 특성과 구분
• 데이터 축적의 전반적인 플로우

4-1 벌크 형 스트리밍 형의 데이터 수집

데이터 전송에는 벌크 형과 스트리밍 형의 두 종류가 있음

각각의 방법으로 분산 스토리지에 데이터가 저장될 때까지의 흐름을 살펴보자.

객체 스토리지와 데이터 수집

• 빅데이터는 대부분의 경우 확장성이 높은 분산 스토리지에 저장됨
  • 분산 형의 데이터베이스가 이용되는 경우도 있지만 대량으로 파일을 저장하기 위한 객체 스토리지(object storage)가 기본이 됨
  • e.g. Hadoop이라면 HDFS, AWS에서는 Amazon S3

객체 스토리지의 데이터 저장 플로우

• 객체 스토리지는 다수의 컴퓨터를 사용해 파일을 여러 디스크에 복사함
  • 이에 따라 데이터의 중복화와 부하 분산을 지원하고 있음.
  • 따라서 일부 하드웨어가 고장나더라도 데이터가 손실되지 않음
  • → 장애 극복(Failover)이 가능하다
  • → 슬레이브(read replica)를 통한 **부하 분산으로 성능 저하를 방지**
• 주의점
  • 객체 스토리지의 구조는 데이터양이 많을 때 우수함. 하지만 소량이 데이터일 경우 비효율적임.
  • → 100바이트의 작은 파일을 자주 읽고 쓰는 것은 데이터양에 비해 통신 오버헤드가 너무 크기 때문에 적합하지 않음
  • 그럼 어느정도가 적합한데?
    • → 작은 규모일 때는 아무래도 비용을 생각해서 적절한 스토리지를 선택하고 데이터가 많은 빅데이터 정도면 객체 스토리지를 고려해라로 이해했음

데이터 수집

수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스를 데이터 수집(data ingestion) 이라고 한다. 여기에는 데이터 수집부터 구조화 데이터의 작성, 분산 스토리지에 대한 장기적인 저장 등이 포함된다.

→ 단순히 데이터를 무지성으로 저장하는 게 아니라 이를 실용적으로 관리하는 것이 중요하다.

• 빅데이터로 자주 다루는 것은 시계열 데이터이고 이 데이터는 시간이 지남에 따라 대량의 데이터가 쌓이게 된다.
• 데이터를 저장하는 것도 적절한 파일 사이즈로 저장하지 않으면 이 또한 성능 저하의 요인이 된다. 따라서 이를 적절하게 저장하여 효율을 높이는 것이 중요함.
  • e.g. 1테라바이트의 파일을 100Mbp의 회선으로 전송하면 약 24시간이 소됨.
• 그렇다면 어떤 데이터 크기가 적절할까?
  • 일반적으로 객체 스토리지에서 효율적으로 처리할 수 있는 파일 크기는 대략 1MB~1GB 범위이다.
    • 수시로 객체 스토리지에 작은 데이터를 기록하면 대량의 작은 파일이 생성됨
      • → 데이터를 적당히 모아서 하나의 큰 파일로 만들기
    • 너무 큰 데이터라면 적당히 나눠서 처리하기

벌크 형의 데이터 전송

• 전통적인 데이터 웨어하우스에서 사용된 벌크 형 방식은 말 그대로 이미 모아둔 큰 데이터를 옮기는 방식이다.
  • 따라서 이미 대량의 데이터가 축적된 경우나 기존 데이터베이스에서 데이터를 추출하고 싶은 경우에 벌크 방식으로 데이터를 전송한다.
• 데이터 전송의 신뢰성이 중요한 경우에는 가능한 한 벌크 형 도구를 사용해야 한다.
  • 스트리밍 형은 데이터 전송을 재실행하기가 쉽지 않고 신뢰성이 떨어진다.
  • 벌크 형 방식은 문제가 발생했을 때 비교적 쉽게 데이터 전송을 재실행 할 수 있다.
  • 이런 점에서 벌크 형은 워크플로 관리 도구와의 궁합이 뛰어나다.
• 주의
  • 벌크 형이라고 데이터를 무조건 한 번에 전송하는 건 아니다.
  • 너무 큰 데이터를 한 번에 옮기면 작업이 무거워서 오류가 나는 경우가 생긴다.
    • → 이런 경우는 데이터를 나눠서 전송해야 한다.
• 데이터가 처음부터 분산 스토리지에 저장되어 있는 것이 아니라면 데이터 전송을 위한 ETL server가 필요하다.
  • ETL server는 구조화된 데이터 처리에 적합한 데이터 웨어하우스를 위한 ETL 도구와 오픈 소스 또는 손수 작성한 스크립트 등을 이용하여 데이터를 전송한다.

데이터 전송의 워크플로

• 데이터 전송에 워크플로를 사용할 수도 있다.
  • e.g. 이 데이터가 적재되면 데이터 분석을 위한 data mart를 생성해주세요. 등
• 매일 마스터 데이터의 스냅샷과 신뢰성이 중시되는 과금 데이터 전송 등의 경우 다른 배치 처리와 함께 워크플로의 일부에 포함하는 것이 좋다.
• 스트리밍 방식은 특성상 실시간으로 동작하기 때문에 워크플로우 일부로 실행하지 않는다.

스트리밍 형의 데이터 전송

스트리밍 형은 말 그대로 실시간으로 데이터를 전송하는 방식이다.
스트리밍이라고 하면 거창한 말처럼 느껴지지만, 사실 데이터 저장을 위해 API를 계속 호출하는 것과 다름이 없다.
하지만 이 호출 과정에서 전송 실패, 데이터 중복 그리고 디바이스 케이스 등을 고려해야 한다.

 

스트리밍 형 데이터 전송의 플로우

 

• 보통 스트리밍 형과 같은 데이터 전송 방식을 메시지 배송(message delivery) 이라고 한다.
  • 메시지 배송 시스템은 전송되는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구한다.
• 메시지 큐, 메시지 브로커와 같은 중계 시스템을 통해 데이터를 전송할 수도 있다.
  • 이런 경우 기록된 데이터를 일정 간격으로 꺼내고 모아서 분산 스토리지에 저장한다.
  • 메시지 큐, 메시지 브로커와 같은 시스템을 이용하면 장애 극복(failover), 실패한 메시지(dead letter) 재전송 관리에 대해 이점을 가져갈 수 있다.
  • 대표적으로 메시지 큐는 Amazon SQS, 메시지 브로커는 Apache Kafka 등이 있다.
• 주로 작은 데이터를 전송하는데 사용된다.
  • e.g. 사용자의 행동 분석을 위한 이벤트 추적이나 서버 로그 적재
  • 다양한 요구사항이 있을 수도 있고 항상 트레이드오프를 고려해서 이에 적절한 솔루션을 선택하는 게 중요하다.
  • 큰 데이터를 전송하는 것에 메시지 브로커를 적절한 솔루션이라고 보기에는 어렵다.

4-2 메시지 배송의 트레이드 오프(성능 vs 신뢰성)

클라이언트의 수가 많아지면 스트리밍 형의 메시지 배송은 성능과 신뢰성을 모두 만족하기 어렵다.
메시지 브로커를 기반으로 하는 메시지 배송 구조와 그 한계에 대해 알아보자

 

• 클라이언트가 많아지고 메시지의 양이 많아지만 스토리지에 write 부하가 많이 걸리게 된다.
• 이런 경우 부하를 줄이기 위해 데이터를 일부 모아서 write 해서 개선할 수 있는데, 이 때 메시지 브로커를 사용해볼 수 있다.
  • 대표적인 메시지 브로커로는 Apache Kafka, Amazon Kinesis 등이 있다.

푸쉬 형과 풀 형

 

• 위 그림에 보이듯 제어 주도권이 어디에 있는지에 따라 메시지 배송 방식이 푸쉬 형과 풀 형으로 나뉜다.
• 이는 구현 방식에 따라 나뉘니 메시지 브로커를 선택하기 전에 잘 살펴보자
  • 송신 측의 제어로 데이터를 보내는 방식이 푸시(push)형
  • 수신 측의 제어로 데이터를 가져오는 것을 풀(pull)형
    • 데이터를 모아서 pull하기 때문에 파일 사이즈 적정화에 도움이 됨
• 메시지 브로커는 데이터의 쓰기 속도를 조정하기 위한 완충제 역할이고 푸쉬 형과 풀 형으로 메시지 배송의 타이밍을 조절한다.
• 메시지 브로커의 구조에서의 역할 정의
  • 메시지 브로커에 데이터를 push 하는 생성자(producer)
  • 데이터를 pull해서 소비하는 소비자(consumer)

메시지 라우팅

• 메시지 브로커에 저장된 메시지는 여러 consumer가 읽을 수 있다. 이 경우 데이터가 복사되어 여러 경로로 분기되기 때문에 메시지 라우팅(message routing)이라고 한다.
  • 이를 통해 많은 producer에서 오는 대량의 메시지를 즉각적으로 어떤 consumer에게 전송하면서 동시에 다른 consumer는 데이터 적재 효율화를 위해 데이터를 모아두었다가 한 번에 저장할 수도 있다.
  • 즉, consumer는 서로의 존재를 모르고 의존성이 격리되어 있기 때문에 다른 consumer를 추가하는 게 자유롭다.
    • → 확장성이 높다.

메시지 배송의 신뢰성 문제

실시간 메시지 배송과 같은 스트리밍 구조에서는 성능 문제 외에도 신뢰성(reliability) 문제는 피할 수 없다.

• 분산 시스템에서는 네트워크 장애 등으로 인해 오류 발생이 필연적인데, 이것도 신뢰성 문제에 한 몫한다.
  • 메시지는 전송됐을 수 있지만 consumer에서 오류가 발생해 작업이 실행되지 않았을 수도 있다.
  • 그래서 이런 경우는 작업 consumer의 완료를 보장하기 위해 메시지를 받았다는 표시를 consumer가 메시지 브로커에게 전송하는 구조를 가져갈 수도 있다.
• 따라서 우리는 각 상황에 맞게 트레이드오프를 고려해서 신뢰성 문제를 해결해야 하는데, 대표적인 해결책은 다음과 같다.
  • at most once (최대 한 번)
    • 메시지는 한 번만 전송. 도중에 전송에 실패해서 사라질 가능성이 있다.
  • exactly once (정확히 한 번)
    • 메시지는 손실되거나 중복 없이 정확히 한 번만 전달된다.
    • 분산 시스템에서는 여러 개의 노드가 존재하기 때문에 exactly once를 보장하기 위해서는 한 곳에 모여서 데이터를 중계하는 과정이 필요하다.
      • 이를 중계하는 시스템을 보통 코디네이터(coordinator) 라고 부른다.
      • 하지만 모든 분산 시스템에서는 역시 네트워크 장애와 코디네이터에도 장애가 발생할 수 있기 때문에 항상 존재한다고 가정할 수 없다.
        • 보통 이런 경우는 합의(consensus) 라는 과정을 거치게 되는데 이건 분산 시스템 설계에서 어려운 문제 중 하나이다.
  • at least once (적어도 한 번)
    • 메시지는 확실히 전달되지만 같은 값이 여러 번 전달되어 중복될 수 있다.
    • 따라서 중복 제거는 클라이언트에 맡긴다.
      • 대부분의 메시지 배송 시스템에서는 at least once를 지원한다.
        e.g. Apache Kafka
• 메시지 배송 도구가 신뢰성에 대해 아무런 보장을 하지 않을 수도 있다.
  • e.g. 자바스크립트에 의한 데이터 수집은 웹페이지를 닫는 것만으로 작동이 중지되기 때문에 이벤트가 유실될 수 있다.
• 결국 각 요구사항에 맞게 적절한 솔루션을 선택하고 데이터 중복에 대비해야 한다면 그에 맞게 시스템을 설계하는 것이 중요하다.

4-3 시계열 데이터의 최적화

스트리밍 형의 메시지 배송에서는 메시지가 도착할 때까지의 시간 지연이 문제다.
늦게 도달하는 데이터가 집계 속도에 미치는 영향에 관해 알아보자

프로세스 시간과 이벤트 시간

• 프로세스 시간(process time)은 실제 서버에서 처리한 시간.
• 이벤트 시간(event time)은 이벤트가 생성된. 즉, 메시지가 생성된 시간을 말한다.
• 네트워크나 시스템 특성 상 프로세스 시간과 이벤트 시간에 큰 차이가 있을 수 있다.
• 보통 데이터 분석의 대상이 되는 것은 이벤트 시간인데, 이 시간 차이로 인해서 성가신 문제들이 존재한다.

프로세스 시간에 의한 분할과 문제점

• 예를 들어 모바일 앱의 활동 사용자 수(Active User)를 집계하는 케이스를 생각해보자.
• 이 경우 늦게 클라이언트 상황에 따라 늦게 서버에 도착하는 데이터가 있을 수 있다.
  • 즉, 늦게 도착하는 데이터에 의해 과거의 집계 결과가 매일 조금씩 바뀔 수 있다.
  • 따라서 실제에 가까운 집계 결과를 얻기 위해서는 이벤트 시간보다 며칠 정도 지난 시점에서 데이터를 집계해야 한다.

아래 이미지를 보면 1월 1일에 대부분의 이벤트는 서버에 당일에 도착하지만 그 이전에 생성된 이벤트도 꽤 보이는 걸 볼 수 있다.

따라서 이벤트 시간과 프로세스 시간에는 차이가 있다는 점을 기억하자.

 

분산 스토리지에서의 데이터 분산

한편, 분산 스토리지 상에서는 데이터를 넣는 단계에서는 이벤트 시간이 아니라 프로세스 시간을 사용하는 것이 보통이다.

• 하지만 데이터 분석은 이벤트 시간 기준으로 하기 때문에 집계 시에 데이터를 적절하게 가져오는 것이 중요하다.
  • 그리고 이벤트 시간은 데이터를 조회해야만 알 수 있으므로 결국 데이터를 모두 로드해야한다.
• 다수의 파일을 모두 검색하는 풀 스캔은 시스템의 부하를 높이는 요인이므로 하는 것이 좋다.

분산 스토리지의 풀 스캔은 어떻게 피할 수 있을까?

풀 스캔을 피할 수 있는 방법을 한 번 알아보자.

시계열 인덱스

• 이벤트 시간을 기준으로 인덱스를 생성해서 풀 스캔을 피하고 데이터를 효율적으로 조회할 수 있다.
• 보통 시계열 인덱스(time-series index)라고 부른다.
• 인덱스는 데이터 효율을 개선하는 전형적인 방법이다.

조건절 푸쉬 다운

• 데이터를 미리 읽기 좋게 변형(정렬)해둬서 조회 조건절과 함께 최소한의 데이터만 읽도록 하는 최적화를 조건절 푸시 다운(predicate pushdown)
  • 데이터를 정렬해두는 건 인덱스에서 사용하는 조회 최적화와 비슷한 원리다.
• 매일 한 번씩 새로 도착한 데이터를 배치 처리로 읽기 좋게 변환한다.
  • 위 이미지는 데이터를 정렬한 후 열 지향 스토리지로 변환하는 모습이다.
• 단, 빈번한 쓰기는 최적화의 효과를 낮춘다는 사실을 기억하자.
  • 요구사항에 맞게 데이터 배치 처리 주기를 적절하게 설정해야 한다.
  • 또한 이벤트 시간 기준을 잘게 분산하는 것도 데이터 로드가 빈번해지므로 효율이 안 좋아질 수 있다.
    • 따라서 열 지향 스토리지의 경우 짧은 주기로 만드는 것은 좋지 않다.

이벤트 시간에 의한 분할

• 이벤트 시간을 이용해서 테이블 파티셔닝을 해볼 수도 있다.
  • 이렇게 분할된 테이블을 시계열 테이블(time-series table) 이라 한다.
  • 시계열 테이블을 이용하면 위와 같은 모습이 된다.

데이터 마트를 이벤트 시간으로 정렬하기

• 이벤트 시간으로 정렬된 데이터 마트를 만들어서 집계 작업을 효율화 할 수도 있다.

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

NoSQL 데이터베이스를 활용하면 데이터를 단순히 모아서 저장할 뿐만 아니라 애플리케이션에서 온라인으로 이용하거나 실시간으로 집계할 수도 있다.

NoSQL 데이터베이스의 몇 가지 특징을 알아보자.

• 빅데이터를 위한 분산 스토리지에는 확장성과 데이터를 구조화하지 않고도 저장할 수 있는 유연성이 요구된다.
• 그 중 기본이 되는 객체 스토리지는 임의의 파일을 저장할 수 있다는 장점이 있지만 단점도 많다.
• 객체 스토리지는 데이터를 수시로 변경하는 용도로는 적합하지 않다.
  • 파일을 써넣으면 통째로 교체해야하기 때문에 파일을 교체하기 어렵다.
  • 즉, 쓰기 빈도가 낮은 요구사항에 적합하다.
  • 그래서 쓰기 빈도가 높은 데이터는 별도 RDB에 저장하고 정기적으로 스냅샷을 하거나 다른 분산 데이터베이스에 저장한다.
• 보통 중요한 데이터는 트랜잭션 처리에 대해 고려된 데이터베이스에 기록하는 것이 원칙인데, 스트리밍 형의 메시지 배송 등은 트랜잭션 처리가 보장되지 않는다.
  • 일반적인 RDB라도 충분한 쓰기 성능을 얻을 수 있지만, 불충분한 경우 분산 데이터베이스를 고려해보는 것도 좋다.
• 또한 객체 스토리지는 쓰기 작업이 오래 걸려서 데이터를 집계할 수 있게 되기까지 시간이 소요된다.
  • 실시간 집계와 검색이 필요하다면 다른 적합한 데이터 저장소 고려가 필요하다.

이러한 문제를 해결하기 위해 특정 용도에 최적화된 NoSQL 데이터베이스들이 등장했다.

• e.g. 분산 KVS, 와이드 칼럼 스토어, 도큐먼트 스토어, 검색 엔진

분산 KVS

분산 KVS(distributed Key-Value Store)는 모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소이다.

• 객체 스토리지도 넓은 의미에서 분산 KVS의 일종이지만, 여기서는 좀 더 작은 데이터를 가정한다.
  • e.g. 몇 KB 정도의 데이터를 초당 수만 번 읽고 쓰는 경우
• 분산 KVS는 구현이 다양한데 보통 한 failover를 위한 구조들이 설계에 포함되어 있다.

Amazon DynamoDB

• DynamoDB는 항상 안정된 읽기 쓰기 성능을 제공하도록 디자인된 분산형 NoSQL 데이터베이스다.
  • 하나 또는 두 개의 키에 연결하는 형태로 임의의 스키마리스 데이터를 저장할 수 있게 구성되어 있다.
  • JSON과 같이 중첩된 데이터 구조도 취급할 수 있어서 간단한 분산 KVS라기보다는 도큐먼트 스토어로도 사용될 수 있다.
• DynamoDB는 P2P 형 분산 아키텍처로 구성되어있다.
  • 미리 설정한 초 단위의 요청 수에 따라 auto scaling이 가능해서 읽기 및 쓰기에 지연이 발생하면 곤란한 application에 유용하다.
• DynamoDB는 다른 AWS 분석 서비스와 호환이 쉽다.
  • Amazon EMR, Amazon Redshift 등과 결합해서 Hive에 의한 배치 처리를 실행하거나 데이터 웨어하우스에 데이터를 전송할 수 있다.
  • DynamoDB Streams를 사용하면 데이터 변경을 이벤트로 외부에 전송해 실시간 스트림 처리를 할 수도 있다.
    • Kinesis Stream이라는 서비스도 있는데 이건 데이터베이스는 아니고 단순 메시지 브로커이다.

와이드 칼럼 스토어

와이드 칼럼 스토어(wide-column store)는 분산 KVS를 발전 시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것이다.

• e.g. Google Cloud Bigtable, Apache HBase, Apache Cassandra
• 와이드 칼럼 스토어에서는 내부적으로 행 키와 칼럼 명의 조합에 대해 값을 저장한다.
  • 테이블에 새로운 행을 추가하는 것과 마찬가지로 칼럼도 얼마든지 추가할 수 있다.
• 와이드 칼럼 스토어는 하나의 테이블에 가로와 세로의 2차원 데이터를 저장한다는 점이 특징이다.

Apache Cassandra

• 아파치 카산드라는 내부적인 데이터 저장소로 와이드 칼럼 스토어를 이용하면서도 CQL이라 불리는 높은 수준의 쿼리 언어가 구현되어 있다.
  • CQL은 SQL과 비슷해서 사용성이 좋다.
  • 다음은 CQL 쿼리의 예시이다.

• 테이블을 만드는 것에서 눈치 챈 사람도 있겠지만 구조화된 데이터만 취급할 수 있다.
  • 카산드라의 INSERT는 upsert(insert or update)로 동작해 동일한 키를 가진 레코드가 존재하면 덮어쓰는 특징이 있다.
• P2P 형의 분산 아키텍처를 갖고 있다.
  • 지정한 키에 의해서 결정한 노드에는 해당 키와 관련된 모든 값을 저장한다.
  • 따라서 다수의 독립적인 키가 있는 경우에 처리를 잘 분산할 수 있다.
• 와이드 칼럼 스토어도 데이터를 집계하는 것에는 적합하지 않다.
  • 집계를 위해서는 분산된 모든 노드에서 데이터를 모아야 하기 때문.
  • Hive, Presto 그리고 Spark 등의 쿼리 엔진은 모두 카산드라로 부터의 데이터 로드에 대응하고 있으며 데이터 분석을 위해 쿼리 엔진을 사용해야 한다.

도큐먼트 스토어

• 와이드 칼럼 스토어가 주로 성능 향상을 목표로 하는 반면, 도큐먼트 스토어(document store) 는 데이터 처리의 유연성을 목적으로 한다.
  • 구체적으로는 JSON처럼 복잡하게 뒤얽힌 스키마리스 데이터를 그대로의 형태로 저장하고 쿼리를 실행할 수 있을 정도로 데이터 처리에 유연하다
  • 간단한 분산 KVS도 JSON 텍스트를 저장할 순 있지만 복잡한 쿼리를 할 수 있다고 말할 수는 없다.
  • 도큐먼트 스토어는 배열과 연상 배열(Map) 같이 중첩된 데이터 구조에 대해 인덱스를 만들거나 도큐먼트 일부만을 치환하는 식의 쿼리를 쉽게 실행할 수 있다.
• 장점
  • 스키마를 정의하지 않고 데이터를 처리할 수 있다. (schema less, 유연성)
    • 외부에서 들여온 데이터를 저장하는 데 특히 적합함
    • 자체 개발한 애플리케이션 등에서는 명시적으로 스키마를 정하는 편이 좋은 점도 많으므로 도큐먼트 스토어는 주로 참고 시스템의 데이터 및 로그 저장 등에 적합함.

MongoDB

• 몽고디비는 오픈 소스 분산형 도큐먼트 스토어이다.
• 신뢰성을 희생하는 경우가 많지만 간편함 때문인지 인기가 좋다.
• 몽고디비는 여러 노드에 데이터를 분산할 수 있지만, 대량의 데이터를 집계하는 데 적합하지 않다.
  • 데이터 분석이 목적인 경우에는 역시 쿼리 엔진이 필요하다.

검색 엔진

• 검색 엔진(serch engine)은 텍스트 데이터 및 스키마리스 데이터를 집계하는 데 자주 사용된다.
• 텍스트 데이터를 전문 검색하기 위해 역 색인(index)을 만드는 특징이 있다.
  • 데이터를 기록하는 시스템 부하 및 디스크 소비량은 커지지만 키워드 검색이 훨씬 고속화된다.
  • 대부분의 NoSQL 데이터베이스가 성능 향상을 위해 색인 작성을 제한하고 있는 것과는 다르게 검색 엔진은 적극적으로 색인을 만들어 데이터를 찾는 것에 특화되어 있다.
    • fyi; 색인(index)는 데이터 쓰기 시에 재구성이 필요하므로 성능이 저하된다.
• 검색 엔진은 데이터의 집계에 적합하다.
  • 특히 비정상적인 상태의 감지 및 보안 체크, 고객 서포트처럼 민첩성이 요구되는 용도에서 최신 데이터를 보기 위해 사용된다.
• 검색 엔진은 장기적으로 데이터를 축적하기보다는 실시간 집계 시스템의 일부로 이용된다.
  • e.g. 메시지 브로커를 사용할 경우 데이터를 분산 스토리지에 따로 저장하고 검색 엔진에도 전송하여 실시간성이 높은 데이터 처리를 위해 활용한다.
• 대표적으로 Elasticsearch, Splunk, Apache Solr가 있다.

Elasticsearch

지금 기준으로 엘라스틱서치는 오픈 소스 검색 엔진 중 가장 인기있다.

보통 ELK 스택 혹은 Elastic 스택이라고 불리는 로그 수집 소프트웨어 Logstash, 시각화 소프트웨어 Kibana와 함께 사용된다.

• 엘라스틱서치는 임의의 JSON 데이터를 저장할 수 있다.
• 아무것도 지정하지 않으면 모든 필드에 색인이 만들어진다.
  • 필요에 따라 스키마를 결정해서 색인을 무효화하는 식의 튜닝이 필요하다.
  • 대부분의 검색 엔진에서 이런 옵션을 지원한다 e.g. solr
• 텍스트 데이터에서는 역 색인이 구축된다.
• 색인이 생성되기 때문에 간단한 도큐먼트 스토어보다 비교적 쓰기 부하가 크다
• 자체 쿼리 언어를 통해 고급 집계 기능을 제공한다.
  • 열 지향 스토리지에도 대응하고 있어 그것만으로도 데이터를 집계하기 위한 기반이 된다.
  • SQL과는 조금 달라서 사람이 직접 작성하기에는 복잡할 수 있다. 그래서 Kibana와 같은 인터페이스나 프로그램 안에서 호출하는 식으로 사용한다.

클라이언트의 시계가 고장났을 수 있다

• 데이터를 확인해보면 가끔 1% 미만의 데이터의 이벤트 시간이 과거에서 미래로 널리 분포하고 있는데 이는 클라이언트의 시계에 문제가 있기 때문이다.
• 이런 데이터의 분포가 넓으면 분산 스토리지에 대량의 작은 파일이 생성되고 그 파일을 읽고 쓰는 것에 의해서 성능이 저하된다.
• 이러한 문제를 미리 방지하기 위해 먼 과거나 미래의 시간을 포함한 데이터는 그것을 분산 스토리지에 넣기 전에 제거하는 것이 좋다.

요약

데이터를 모아서 분산 스토리지에 저장하기까지 데이터 수집의 흐름에 대해 알아봤다 이를 키워드로 요약해보자

• 데이터 전송
  • 벌크 형
  • 스트리밍 형
• 메시지 배송 방식과 트레이드오프
  • 메시지 브로커
    • producer
    • consumer
  • 메시지 배송의 신뢰성 문제와 해결 방안
    • most once
    • exactly once
    • at least once
• 데이터 색인을 통한 최적화
  • 시계열 인덱스
  • 데이터 미리 정렬해두기(조건절 푸쉬 다운)
  • 데이터 마트 구조 활용하기
• NoSQL 데이터베이스 등 분산 스토리지
  • 분산 KVS
  • 와이드 칼럼 스토어
  • 도큐먼트 스토어
  • 검색 엔진

 

출처

https://www.yes24.com/Product/Goods/66277191