빅데이터 플랫폼과 분석 생태계

핵심 요약

빅데이터 플랫폼은 특정 서버나 제품 하나가 아니다. 다양한 원천의 데이터를 안전하게 받아 보존하고, 배치 또는 스트림 방식으로 처리하며, 분석 결과를 API·보고서·대시보드·업무 시스템에 제공하는 전체 기술·관리 환경이다. 메타데이터, 품질, 접근 권한, 보존 정책, 모니터링은 특정 계층 하나가 아니라 전체 흐름에 적용된다.

모든 데이터를 같은 구조로 처리할 필요는 없다. 시간에 민감한 경보는 스트림 경로가, 완전성과 재현성이 중요한 정산은 원본 기반 배치 경로가 적합할 수 있다. 데이터웨어하우스는 통합·정제된 반복 분석에, 데이터레이크는 다양한 원본의 유연한 보존과 탐색에 상대적 강점이 있다. 두 접근 모두 메타데이터와 품질 관리가 필요하다.

플랫폼 설계의 핵심은 “가장 유명한 기술은 무엇인가?”가 아니라 “누가 어떤 데이터를 언제, 어느 품질 수준으로 사용하며 실패하면 어떻게 복구할 것인가?”를 먼저 답하는 것이다.

학습 목표

• 빅데이터 플랫폼의 계층과 횡단 관리 기능을 설명한다.
• 배치 처리와 스트림 처리의 적용 조건과 오류 통제를 구분한다.
• 데이터웨어하우스·데이터레이크·레이크하우스의 상대적 목적을 비교한다.
• 업무 요구에서 데이터 흐름과 기술 선택으로 이어지는 설계 순서를 판정한다.

1. 플랫폼의 계층과 데이터 흐름

데이터는 보통 원천 → 수집 → 저장 → 처리 → 분석 → 제공의 흐름을 거친다. 실제 플랫폼에서는 이 흐름을 오케스트레이션하고, 품질·보안·메타데이터·모니터링을 전 구간에 적용한다.

1.1 수집에서 확인할 것

수집 성공 메시지만으로 완전한 수집을 보장할 수 없다. 원천 건수나 이벤트 식별자와 비교해 누락을 확인하고, 재전송으로 같은 이벤트가 두 번 들어오는 상황을 통제해야 한다. 도착 순서가 실제 발생 순서와 다를 수 있다는 점도 고려한다.

1.2 저장에서 확인할 것

원본 보존 영역, 정제 영역, 분석·제공용 영역을 나눌 수 있다. 모든 원본을 무기한 저장하는 것이 정답은 아니다. 목적, 재처리 가능성, 규정, 비용에 맞춰 보존 기간과 접근 권한을 정한다. 파티셔닝은 자주 조회하는 기간·키와 데이터 분포를 고려해 설계한다.

1.3 처리에서 확인할 것

분산 처리는 데이터를 여러 작업으로 나누어 처리량과 확장성을 높일 수 있다. 반면 네트워크 전송, 작업 조정, 데이터 재분배, 장애 복구 비용이 생긴다. 데이터가 크다는 이유만으로 모든 작업을 분산화하지 않고 병렬화 이득이 추가 복잡성보다 큰지 판단한다.

1.4 분석·제공에서 확인할 것

분석에는 사용 데이터와 코드·모형·평가 결과의 버전을 남겨야 한다. 운영 시스템에 연결되는 결과는 승인 기준, 지연시간, 모니터링, 장애 시 대체 절차도 필요하다. 단순 보고서라면 모형 재학습 체계까지 항상 요구되는 것은 아니지만 기준 시점과 재현 근거는 남겨야 한다.

2. 배치 처리와 스트림 처리

두 방식은 배타적이지 않다. 스트림으로 빠른 임시 결과를 만들고, 원본을 이용한 배치 재계산으로 최종 결과를 확정할 수 있다.

이벤트 발생 시각과 도착 시각

이벤트가 실제로 발생한 시각과 플랫폼에 도착한 시각은 다를 수 있다. 통신 지연 때문에 늦게 도착한 이벤트를 단순히 다음 구간에 넣으면 실제 시간대의 집계가 왜곡된다. 스트림 처리에서는 어떤 시각을 기준으로 윈도우를 계산할지, 늦은 이벤트를 얼마 동안 허용하고 결과를 수정할지를 정해야 한다.

중복 이벤트도 고려한다. “한 번만 처리”라는 문구를 제품 기능처럼 외우기보다 이벤트 식별자, 멱등성 있는 처리, 체크포인트와 재처리 규칙으로 최종 결과의 중복 반영을 막는다고 이해한다.

3. 저장·분석 환경의 구분

스키마를 먼저 적용한다와 읽을 때 해석한다는 상대적 경향이지 절대 규칙은 아니다. 현대 플랫폼은 여러 방식을 혼합한다. 시험에서는 제품명이 아니라 반복 보고, 원본 보존, 탐색 유연성, 거버넌스 등 선택 조건을 본다.

데이터레이크도 메타데이터, 카탈로그, 소유자, 품질 수준, 접근 정책이 필요하다. 원본 형식으로 저장했다는 이유로 의미와 품질이 자동으로 보장되지는 않는다.

4. 횡단 관리와 비기능 요구사항

기능이 동작해도 요구한 시간 안에 결과가 나오지 않거나 장애 복구가 불가능하면 플랫폼은 목적을 달성하지 못한다. 성능·품질·비용·보안을 함께 모니터링해야 한다.

5. 요구사항에서 기술 선택까지

플랫폼 설계는 다음 순서로 접근한다.

1. 사용자와 의사결정 정의: 누가 어떤 결과를 어디에 사용하는지 정한다.
2. 지연시간·품질 기준 정의: 결과가 필요한 시점, 허용 오류, 기준 시점을 정한다.
3. 데이터 원천 확인: 형식, 양, 유입 속도, 권한, 품질, 변경 가능성을 확인한다.
4. 데이터 흐름과 복구 설계: 수집·저장·처리·제공 경로와 재처리 기준을 설계한다.
5. 계층별 방식과 기술 선택: 배치·스트림, 저장 구조, 분산 처리 여부를 선택한다.
6. 운영 지표와 책임 정의: 지연·누락·오류·비용·품질과 담당자를 정한다.

제품을 먼저 선정하면 요구사항을 제품 기능에 억지로 맞추기 쉽다. 기술 선정은 데이터 흐름과 운영 기준을 정의한 뒤 수행한다.

6. 사례 적용

상황: 온라인 서비스가 클릭 이벤트를 초당 수만 건 수집한다. 추천 화면은 최근 5분 행동을 반영해야 하고, 매출 정산은 다음 날 정확히 완료되어야 한다.

요구 분리

• 추천: 짧은 지연시간, 최근 이벤트의 연속 집계가 중요하다.
• 정산: 전체 범위의 완전성, 기준 시점, 재현성이 중요하다.

설계 판단

• 수집 단계에서 이벤트 식별자, 중복, 늦은 도착, 누락을 관리한다.
• 추천용 최근 행동은 이벤트 발생 시각 기준의 스트림 윈도우로 계산한다.
• 원본 이벤트는 권한과 보존 기간을 적용해 저장한다.
• 정산은 원본을 기준으로 배치 재계산하고 마감 기준 시점을 기록한다.
• 스트림 임시 결과와 정산 확정 결과의 목적·정확성 수준을 구분한다.

결론: 배치와 스트림을 조합하는 구조가 적합하다. 추천용 임시 집계를 회계 정산의 유일한 근거로 사용하면 서로 다른 정확성·재현성 요구를 혼동하게 된다.

플랫폼은 제품 이름의 목록이 아니라 데이터가 수집·저장·처리·분석되어 제공되는 계층 구조다. 거버넌스·보안·메타데이터·품질·관측성은 어느 한 계층의 부속 기능이 아니라 전체 흐름을 가로지른다.

이벤트 발생 시각을 $t_e$, 플랫폼 도착 시각을 $t_a$, 결과 제공 시각을 $t_o$라 하면 대표 지연은 다음처럼 분리할 수 있다.

배치는 정해진 창의 데이터를 모아 처리하고 스트림은 이벤트 도착에 가깝게 연속 처리한다. 스트림에도 늦은 도착·순서 뒤바뀜·중복이 존재하므로 워터마크와 재처리 전략이 필요하다.

시험 판단 포인트

• 플랫폼은 수집·저장·처리·분석·제공 계층과 횡단 관리 기능의 결합이다.
• 배치는 범위를 묶어 재계산하는 데, 스트림은 시간 민감한 이벤트를 연속 처리하는 데 상대적 강점이 있다.
• 스트림에서는 중복·순서·지연 이벤트·상태·윈도우를 고려한다.
• 데이터웨어하우스는 통합·정제된 반복 분석에, 데이터레이크는 다양한 원본의 유연한 보존·탐색에 상대적 강점이 있다.
• 데이터레이크도 메타데이터·품질·소유자·접근 정책이 필요하다.
• 분산 처리는 확장성을 높일 수 있지만 통신·조정·재분배·복구 비용이 생긴다.
• 기술보다 사용자, 지연시간, 품질, 데이터 흐름, 복구와 운영 지표를 먼저 정의한다.

자주 틀리는 부분

• 플랫폼을 특정 제품이나 저장 장치 하나와 같은 뜻으로 보지 않는다.
• 데이터가 크다는 이유만으로 모든 계층을 분산화하지 않는다.
• 스트림 결과가 배치 결과보다 언제나 정확하다고 보지 않는다.
• 이벤트 발생 시각과 플랫폼 도착 시각을 같은 것으로 가정하지 않는다.
• 데이터레이크는 스키마·품질·거버넌스가 필요 없다고 판단하지 않는다.
• 확장성·가용성·일관성·내구성을 같은 개념으로 혼동하지 않는다.