[2024.03.03] chapter4. 빅데이터의 축적 (1) - MY

[chominyeong]

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

👉 객체 스토리지

빅데이터는 대부분 확장성이 높은 '분산 스토리지(distributed storage)'에 저장된다. 기본이 되는 것은 대량으로 파일을 저장하기 위한 '객체 스토리지(object storage)'다.
ex. Hadoop - HDFS , 클라우드 서비스 - Amazon S3

• 객체 스토리지에서의 파일 읽고 쓰기는 네트워크를 거쳐서 실행한다. 내부 처리에는 다수의 물리적인 서버와 하드디스크가 있다. 데이터는 항상 여러 디스크에 복사되기 때문에 일부 하드웨어가 고장 나더라도 데이터가 손실되진 않는다.
• 객체 스토리지의 구조는 데이터양이 많을 때는 우수하지만, 소량의 데이터에는 비효율적이다. 100바이트의 작은 파일을 자주 읽고 쓰는 것은 객체 스토리지에 적합하지 않다. 데이터양에 비해 통신 오버헤드가 너무 크기 때문이다.

👉 데이터 수집

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

• 작은 데이터 → 하나의 큰 파일로
  • 시간과 함께 생성되는 데이터인 시계열 데이터를 수시로 객체 스토리지에 기록하면 대량의 작은 파일이 생성된다. 이는 시간이 지남에 따라 성능을 저하시키는 요인이 되므로, 작은 데이터는 적당히 모아서 하나의 큰 파일로 만듦으로써 효율을 높인다.
• 큰 데이터 → 적당히 나누기
  • 파일이 지나치게 커도 문제가 된다. 파일 크기가 증가하면 네트워크 전송에 시간이 걸린다. 만일 1테라바이트의 파일을 100Mbp의 회선으로 전송하면 약 24시간이 소요된다. 따라서 거대한 데이터는 적당히 나눔으로써 문제 발생을 줄인다.
• 빅데이터 처리
  • 나중에 처리하기 쉽도록 준비해야 한다. 객체 스토리지에서 효율적으로 처리할 수 있는 파일 크기는 대략 1메가바이트~1기가바이트이다. 이 범위보다 작은 데이터는 모아서 하나로 만들고, 큰 데이터는 복수로 나눈다.
    
    
    

벌크 형 데이터의 전송

ETL 서버의 설치 필요성

• 전통적인 데이터 웨어하우스에서 사용된 방식

• 데이터베이스나 파일 서버 또는 웹 서비스 등에서 각각의 방식(SQL, API) 으로 정리해 데이터를 추출한다.

• 과거에 축적된 대량의 데이터가 이미 있는 경우나 기존의 데이터베이스에서 데이터를 추출하고 싶을 때 벌크 형의 데이터 전송을 한다.
  

• 데이터 전송을 위한 'ETL 서버(ETL server)'를 설치한다.

• ETL 서버에는 구조화된 데이터 처리에 적합한 데이터 웨어하우스를 위한 ETL 도구와 오픈 소스의 벌크 전송 도구 또는 손수 작성한 스크립트 등을 이용해 데이터를 전송한다.

ETL이란

ETL은 추출(Extract), 변환(Transform), 로드(Load)를 나타내며 조직에서 여러 시스템의 데이터를 단일 데이터베이스, 데이터 저장소, 데이터 웨어하우스 또는 데이터 레이크에 결합하기 위해 일반적으로 허용되는 방법

• 파일 사이즈의 적정화는 비교적 간단
  • ETL 프로세스는 하루마다 또는 1시간 마다 간격으로 정기적인 실행을 하므로 그동안 축적된 데이터는 하나로 모은다.
  • 만약 위 방식이 아니라면 전송 방법을 검토한다. 예를 들어, 100개의 파일을 전송하는데 100번의 전송을 반복하고 있다면 한 번의 전송에 모든 파일을 포함하도록 변경한다.
  • 너무 많은 양의 데이터를 한꺼번에 전송하는 것도 위험하다. 너무 큰 데이터라면 전송 도구 쪽에서 나눌 수 있다. 몇 테라바이트에 이르는 데이터를 한 번에 전송하려고 하면 몇 시간 후에 디스크가 넘쳐나서 오류가 발생한다.
  • 따라서 데이터양이 많을 때는 한 달씩이나 하루 단위로 전송하도록 작은 태스크로 분해해 한 번의 태스크 실행이 커지지 않도록 조정한다. 워크플로 관리 도구를 사용하면 이러한 태스크 실행을 쉽게 관리할 수 있다.
• 데이터 전송의 워크플로
  • 데이터 전송의 신뢰성이 중요한 경우에는 벌크 형 도구를 사용한다. 스트리밍 형은 나중에 재실행하기가 쉽지 않다. 벌크 형을 사용하면 문제가 발생했을 때 여러 번 데이터 전송을 재실행할 수 있다.
    
    
    

스트리밍 형 데이터의 전송

계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데이터 전송
지금 바로 생성되어 어디에도 저장되지 않은 데이터는 그 자리에서 바로 전송해야 한다. 대다수 데이터는 통신 장비 및 소프트웨어에 의해 생성되고, 네트워크를 거쳐서 전송된다. 이 경우 스트리밍 형의 데이터 전송이 필요하다.
ex. '웹 브라우저', 스마트 폰의 '모바일 앱', 센서 기기등의 각종 '디바이스'에서 데이터를 수집하는 경우

• 다수의 클라이언트에서 계속해서 작은 데이터가 전송된다. 이러한 데이터 전송 방식을 일반적으로 '메시지 배송(message delivery)'이라고 한다. 메시지 배송 시스템은 전송되는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구한다.
• 보내온 메시지를 저장할 때는 작은 데이터 쓰기에 적합한 NoSQL 데이터베이스를 이용한다. 이 경우 Hive와 같은 쿼리 엔진으로 NoSQL 데이터베이스에 연결해 데이터를 읽을 수 있다.
• 또는 분산 스토리지에 직접 쓰는 것이 아니라, '메시지 큐(message queue)'와 '메시지 브로커(message broker)' 등의 중계 시스템에 전송할 수 있다. 이 경우 기록된 데이터는 일정한 간격으로 꺼내고 모아서 함께 분산 스토리지에 저장한다.

'웹 브라우저'에서의 메시지 배송

① 자체 개발한 웹 애플리케이션에서는 웹 서버 안에서 메시지를 만들어 배송

• 전송 효율을 높이기 위해 서버상에서 일단 데이터를 축적해 놓고 나중에 모아서 보낸다.
• Fluentd, Logstash와 같은 상주형 로그 수집 소프트웨어 자주 사용됨
  ② 자바스크립트를 사용하여 웹 브라우저에서 직접 메시지를 보냄 → '웹 이벤트 추적(web event tracking)'
• 사용자 측면에서 보면 HTML 페이지에 태그를 삽입만 하면 되므로 각종 액세스 분석 서비스 및 데이터 분석 서비스 등에서 사용되고 있다.
• 수집된 데이터는 그대로 다른 서버로 전송되거나 API 경유로 함께 취득해 그것을 분산 스토리지에 저장해 다른 데이터와 조합한 분석이 가능하다.

'모바일 앱'으로부터의 메시지 배송

① 백 엔드 데이터 저장소에 저장한 데이터를 벌크 형 도구를 사용해서 꺼낸다.

• 모바일 앱은 통신 방법만 보면 HTTP 프로토콜을 사용하는 클라이언트 중 하나이므로 메시지 배송 방식이 웹 브라우저와 동일하다.
• 모바일 앱에서는 서버를 직접 마련하는 것이 아니라 MBaaS(Mobile Backend as a Service) 라는 백 엔드의 각종 서비스를 이용할 수도 있다.
  ② 모바일 앱에 특화된 앱세스 해석 서비스를 통해 이벤트 데이터를 수집한다.
• 이 경우 서비스에서 제공되는 모바일 용의 편리한 개발 키트(SDK)를 사용하여 메시지를 보낸다.
• 모바일 앱은 오프라인이 되는 경우도 많으므로 발생한 이벤트는 일단 SDK의 내부에 축적되고 온라인 상태가 되었을 때 모아서 보내도록 만들어져 있다.
  모바일 회선은 통신이 불안정하고 통신 오류에 따른 메시지 재전송이 여러 번 발생한다. 그 결과 데이터가 중복될 가능성도 높아 특정한 중복 제거의 구조가 필요하다. SDK를 도입할 경우에는 데이터의 중복에 대해 어떤 대책이 이루어지고 있는지 확인하는 것이 좋다.

'디바이스'로부터의 메시지 배송

• MQTT(MQ Telemetry Transport)는 TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나이며, 일반적으로 'Pub/Sub 형 메시지 배송(Pub/Sub message delivery)'이라는 구조를 가진다.
  • Pub : 전달(publish), Sub : 구독(subscription) → 채팅 시스템이나 메시징 앱 또는 푸시 알림 등의 시스템에서 자주 사용되는 기술
• MQTT는 먼저 관리자에 의해 토픽(topic)이 만들어진다. 메시지를 송수신하기 위한 대화방 같은 것으로, 그 토픽을 구독하면 메시지가 도착하게 되고, 그 토픽을 전달하면 구독 중인 모든 클라이언트에 보내진다.
  • 이러한 메시지의 교환을 중계하는 서버를 'MQTT 브로커(MQTT broker)'라고 하고, 메시지를 수신하는 시스템을 'MQTT 구독자(MQTT subscriber)'라고 한다.
• MQTT에서 데이터를 수집하려면 먼저 토픽을 작성하고 그것을 구독한다. 그리고 각 디바이스가 토픽에 메시지를 전달하는 프로그램을 작성하고 나면 MQTT가 정하는 규칙에 따라 배송이 이루어진다. MQTT의 특징 중 하나로서 네트워크에서 분리된 경우에도 나중에 재전송하는 구조가 프로토콜 수준에서 고려되고 있다.
  
  
  

📍