지금까지 텍스트 데이터를 구조화하고 대화식으로 집계하는 흐름을 살펴봤다. 이제는 이를 여러 컴퓨터에 배포하기만 하면, 빅데이터를 집계하기 위한 최소한의 준비가 된 것이다.
실제 운용 시에는 클라우드 서비스 등을 이용해 시스템을 구축하는 경우가 많다. 앞으로는 시스템 구축 시 다양한 옵션 중 무엇을 선택해야 할지를 생각해보고자 한다.
| 완성한 비정규화 테이블의 고속 집계가 필요할 때, MPP 데이터베이스
MPP 데이터베이스의 특징
| 구조 | 스토리지와 계산 노드가 일체화된 구조 |
| 처리 방식 | SQL 기반으로 대규모 데이터 병렬 처리 |
| 성능 | 완성된 비정규화 테이블에 대해 고속 집계 가능 |
| 확장성 | 수평 확장이 가능하여 대용량 데이터에 적합 |
| 초기 설정 | ETL 과정을 통해 데이터를 구조화한 뒤 사용 |
| 활용 예시 | Amazon Redshift, Google BigQuery 등 |
| 한계점 | 유연한 프로그래밍이나 복잡한 워크플로에는 부적합 |
MPP 데이터베이스가 적합한 경우
- BI 도구와 연동하여 정형화된 리포트를 반복적으로 조회해야 할 때
- 이미 정리된 비정규화 테이블에 대해 빠른 집계가 필요한 상황
- SQL 기반 분석이 대부분인 환경에서 성능을 극대화하고 싶을 때
- 데이터 웨어하우스 제품이나 클라우드 기반 분석 플랫폼을 고려 중일 때
- 시각화 중심의 대시보드용 데이터 마트를 만들고 싶을 때
MPP 데이터베이스는 수십억 건의 정규화된 거래 데이터를 하루 단위로 집계해 임원에게 보고할 KPI 리포트를 생성할 때 적합하다.
예를 들어, 이커머스 업계에서 월간 매출 리포트 자동화 업무를 수행해야 한다고 생각해보자.; 월별/브랜드별 매출 데이터를 확인하기 위해 매일 아침 9시 자동으로 생성되는 리포트를 받아야 한다. 이런 경우 MPP 데이터베이스를 이용하는 게 좋다. 수십억 건의 정규화된 주문/상품/고객 데이터를 빠르게 집계할 수 있고, BI 도구 연동도 쉽기 때문이다.
| 대용량 텍스트 데이터를 안정적으로 처리하려면? Hive를 써야 하는 이유
Hive 쿼리 엔진의 특징
| 기반 기술 | Hadoop 기반 분산 쿼리 엔진 |
| 처리 방식 | 대규모 배치 처리에 적합 |
| 특징 | 확장성과 내결함성을 중시함 |
| 장점 | 불안정한 환경에서도 안정적으로 작동, 대용량 텍스트 처리에 강점 |
| 단점 | 실시간성 부족, 처리 속도가 느림 |
| 확장 기술 | Tez 기반 실행 가능 (MapReduce 대체) |
| 사용 예 | 텍스트 데이터를 가공하거나 열 지향 스토리지 생성 시 유리 |
Hive가 적합한 경우
- 수천 대의 저사양 노드에서 안정적인 배치 처리가 필요한 경우
- 대규모 텍스트 파일을 전처리하거나 변환해야 할 때
- 데이터 처리 중 일부 노드 장애가 발생해도 전체 흐름을 유지해야 할 때
- 속도보다는 확장성과 견고함이 중요한 상황
- 열 지향 스토리지로 변환 전, 데이터를 구조화하거나 정제할 필요가 있을 때
Hive는 HDFS에 쌓인 대용량 텍스트 로그를 열 지향 포맷으로 변환해 배치 집계해야 할 때 유리하다. 따라서 처리 시 시간이 오래 걸려도 무방한 정기 리포트 형태에 적합하다.
통신사에서 1년치 통화 로그 요약을 집계해야 하는 상황이 있다. 장기 고객 혜택 기획을 위해 텍스트 형태의 통화 로그(수십 TB)를 분석해 이용 패턴을 추출해야 한다. 이 과정은 텍스트 기반 로그를 ORC로 변환해 배치 집계를 수행해야 하는 경우에 해당한다. 성능보다는 확장성과 안정성을 중시하기 때문에, 주기적인 대규모 분석에 적합하다.
| Presto : 대화형 분석에 최적화된 초고속 쿼리 엔진
Presto의 특징
| 주요 특징 | 속도 중심, 대화형 쿼리에 특화, 표준 SQL 준수 |
| 장점 | 실행 속도 매우 빠름다양한 스토리지와 연동 가능즉시 분석에 적합 |
| 단점 | 리소스 소비 많음 → 과부하 시 다른 쿼리 대기ETL 처리 부적합 |
| 적합한 데이터 | 정형 데이터, 단기 분석용, 빠른 피드백이 필요한 쿼리 |
| 주요 사용 예시 | 대시보드, 실시간 리포트, SQL 기반 데이터 탐색 |
Presto가 적합한 경우
- 데이터 탐색이나 대화형 쿼리를 빠르게 실행하고 싶을 때
- 다양한 데이터 소스를 SQL로 통합 분석하고 싶을 때
- 즉각적인 결과 피드백이 중요한 상황 (대시보드, 임시 분석 등)
- 실행 시간이 짧은 단발성 쿼리가 많은 경우
실시간 대시보드를 조회해야 한다면? Presto를 사용하는 것이 좋다. Presto를 활용하면 유저 행동 데이터를 수 초 단위로 집계해 운영자가 보는 모니터링 대시보드에 표시할 수 있다. 메모리 위에서 빠른 처리가 가능하기 때ㅜㅁㄴ이다.
금융사에서 거래 이상 징후를 실시간으로 파악해야 한다고 생각해보자. 고객의 카드 결제 데이터를 수 초 단위로 조회해서 이상 패턴이 있으면 알림을 띄워야 한다. 이런 경우 빠른 쿼리 응답이 핵심이기 때문에 Presto를 활용하는 것이 좋다. Hive의 메타 데이터도 그대로 활용할 수 있어 유용하다.
| 유연한 분산 처리 파이프라인을 위해 Spark
Spark의 특징
| 분류 | 분산 시스템 기반 데이터 처리 프레임워크 |
| 쿼리 방식 | Spark SQL 가능 (하지만 SQL 특화는 아님) |
| 주요 장점 | - 하나의 스크립트 내에서 ETL → 집계 → 출력까지 처리 가능- 유연한 프로그래밍 기반 처리 가능 |
| 처리 방식 | 인메모리 기반 대화형 처리, 배치 처리 모두 가능 |
| 확장성 | 클러스터 기반 확장 가능 |
| 사용자 대상 | 데이터 과학자, 엔지니어 (프로그래밍 가능자 중심) |
| 적합한 환경 | 복잡한 파이프라인 구성, 텍스트 처리, 캐시/메모리 최적화 필요한 환경 |
Spark가 적합한 상황
- 단순 SQL 쿼리보다는 복잡한 데이터 흐름을 하나의 스크립트로 처리하고 싶을 때
- ETL → 구조화 → 집계 작업을 한 번에 처리해야 할 때
- 대용량 로그/텍스트 데이터 처리에 유리한 프레임워크가 필요할 때
- 메모리 관리 등 고급 사용자 제어가 중요한 분석 환경에서
- SQL만으로는 부족하고 프로그래밍 기반 유연성이 필요할 때
- 데이터 처리 과정을 코드로 명확히 추적/제어하고 싶은 경우
여러 광고 플랫폼에서 수집한 비정형 로그를 통합해 머신러닝 학습용 Feature를 추출해야 하는 상황을 떠올려보자. 예를 들어, 광고 클릭 로그, 상품 정보, 유저 행동 데이터를 결합해 <다음 클릭 예측 모델>의 학습 데이터를 만드는 경우다. 이처럼 다양한 소스를 연결하고, 복잡한 전처리를 수행해야 할 땐 SQL만으로는 한계가 있다.
Spark는 대규모 ETL 작업에 최적화되어 있고, SQL과 PySpark를 병행해 사용할 수 있어 유연한 흐름 제어가 가능하다. 따라서 이런 분석 환경에서는 Spark가 적합한 선택이다.
| 정리
데이터를 어떻게 처리하고 분석할 것인지는 사용하는 프레임워크에 따라 큰 차이를 만든다. 각 도구들은 고유한 강점을 가지기 때문에, 분석 목적과 데이터 특성에 따라 선택이 달라진다. 결국 중요한 것은 무엇을 위해, 어떤 데이터를 어떻게 다룰 것인지를 고민해보는 것이다. 상황에 맞는 도구를 선택하는 것이 더 빠르고 효율적인 분석의 출발점이다.
'Database' 카테고리의 다른 글
| [Database] 벌크형 vs 스트리밍형 : 데이터를 움직이는 두 가지 방식 (6) | 2025.08.03 |
|---|---|
| [Database] 분산 처리 프레임워크 (5) 데이터 마트의 구축 (3) | 2025.07.30 |
| [Database] 분산 처리 프레임워크 (4) 대화형 쿼리 엔진 Presto의 구조 (3) | 2025.07.30 |
| [Database] 분산 처리 프레임워크 (3) 구조화부터 비정규화까지: Hive로 완성하는 데이터 마트 구축 A to Z (1) | 2025.07.29 |
| [Database] 분산처리 프레임워크 (2) Hadoop이란? 개념부터 동작 원리까지 (1) | 2025.07.28 |