구글이 데이터 분야에 끼친 영향
구글 검색 엔진의 등장
- 1998년, 래리 페이지와 세르게이 브린이 구글 검색 엔진 발표
- 기존 검색 엔진(알타비스타, 야후, Ask Jeeves 등)은 웹 페이지의 텍스트 기반 랭킹 방식 사용
- 스팸 페이지 문제 발생
- 구글은 페이지 간의 링크를 분석하여 중요한 페이지를 검색 순위에 반영
- "페이지 랭크(PageRank)" 알고리즘 도입
- 논문 발표 이후 바이두, 얀덱스 등 차세대 검색 엔진 등장
- 2004년 세계 최고의 검색 엔진으로 자리 잡으며 급성장
- 2004년 IPO 상장 ($23B)
- 2021년 기준 기업 가치 $1.41T 도달
- Google Ads를 통한 검색 마케팅 플랫폼 확장
- 안드로이드 개발로 모바일 생태계 주도
- YouTube 인수 후 스트리밍 시장 장악
- 개발자 커뮤니티에 큰 영향을 미친 논문 및 오픈소스 활동
페이지 랭크(PageRank) 개요
- 논문: The PageRank Citation Ranking (1998)
- 웹 페이지의 중요도를 계산하는 방식
- 더 중요한 페이지는 더 많은 링크를 받음
- 중요한 페이지가 링크를 건 다른 페이지도 중요도가 높음
- 대규모 컴퓨팅 인프라가 필요하여 구글만이 실행 가능했던 기술
- 구글 검색 엔진 아키텍처 논문 공개:
- The Anatomy of a Large-Scale Hypertextual Web Search Engine (1998)
- 링크 텍스트 및 원문 페이지 중요도 고려
검색 엔진의 데이터 처리 방식 - 인덱스 업데이트
기술적 진보와 빅데이터 시대의 도래
- 검색 엔진은 대량의 데이터를 필요로 함
- 수백 조 개의 웹페이지 크롤링
- 텍스트 기반 색인 생성
- 페이지 랭크 계산
- 최적의 검색 결과 추출
- 다국어 지원 및 사용자 로그 분석
- 주요 기술 발전
- 동의어 검색
- 통계 기반 번역
- 자동 완성 기능
- 구글이 발표한 핵심 논문:
- 이 논문을 기반으로 오픈소스 프로젝트 하둡(Hadoop) 개발
- 빅데이터 처리 혁신
- 오픈소스 생태계 활성화
- 머신러닝 및 인공지능 발전 가속화
검색 기술과 검색 마케팅의 결합 - 구글 애드워즈
- 검색 광고의 발전
- 오버추어의 검색어 경매 방식은 수동 개입이 필요하여 비효율적
- 구글은 검색어 경매 및 광고 시스템을 자동화하여 운영
- 광고 성과 기반 노출 빈도 조정
구글의 논문 발표 이후 주요 기술 혁신
- AlphaGo (딥마인드)
- TensorFlow (머신러닝 프레임워크)
- Kubernetes (컨테이너 오케스트레이션)
- Transformer Architecture (자연어 처리 혁신)
- BERT (Bidirectional Encoder Representations from Transformers)
데이터 처리의 발전 단계
데이터 처리의 일반적인 단계
- 데이터 수집(Data Collection)
- 데이터 저장(Data Storage)
- 데이터 처리(Data Processing)
- 서비스 효율을 높이거나 의사 결정을 더 과학적으로 수행
데이터 저장 시스템의 변천
데이터 처리의 고도화
- 초기에 배치 처리 방식이 일반적이었음.
- 배치 처리는 대량의 데이터를 일정 주기마다 처리하는 방식.
- 서비스가 고도화되면서 실시간 데이터 처리가 중요해짐.
- 실시간(Realtime) vs 준실시간(Semi-Realtime)
- 다수의 데이터 소비자가 실시간으로 데이터를 활용해야 하는 요구 증가
처리량(Throughput) vs 지연시간(Latency)
- 처리량(Throughput): 단위 시간 동안 처리할 수 있는 데이터 양 (배치 시스템에 중요)
- 지연시간(Latency): 데이터가 처리되는 데 걸리는 시간 (실시간 시스템에 중요)
- 대역폭(Bandwidth) = 처리량 × 지연시간
SLA(Service Level Agreement)
- 서비스 품질, 성능, 가용성을 정의하는 계약
- 사내 시스템 간 SLA 예시:
- 업타임(Uptime): 99.9% = 연간 약 8시간 45.6분의 다운타임 허용
- API SLA: 평균 응답 시간 0.5초 이하 유지
- 데이터 시스템 SLA: 데이터 신선도(Freshness) 유지
데이터 처리 방식
배치 처리
- 일정 주기로 데이터를 한꺼번에 처리 (Daily, Hourly, 5분 단위 등)
- 처리량(Throughput)이 중요
- 주요 기술 스택
- 분산 파일 시스템: HDFS, S3
- 분산 처리 시스템: MapReduce, Hive, Presto, Spark SQL
- 워크플로우 관리: Apache Airflow
실시간 처리
- 실시간 데이터 스트림을 지속적으로 처리
- 낮은 지연시간(Latency)이 중요
- 주요 기술 스택
- 메시지 큐: Kafka, Kinesis, Pub/Sub
- 스트리밍 엔진: Spark Streaming, Flink, Samza
- 실시간 분석: Druid, ClickHouse
람다 아키텍처(Lambda Architecture)
- 배치 처리와 실시간 처리를 함께 운영하는 하이브리드 모델
데이터 실시간 처리의 장점과 단점
장점
- 즉각적인 인사이트 제공
- 운영 효율성 향상
- 실시간 대응 (보안, 사기 탐지 등)
- IoT 및 센서 데이터 활용
- 실시간 협업 및 커뮤니케이션
단점
- 시스템 복잡도 증가
- 운영 비용 상승 (데이터 유실 방지 필요)
- DevOps와 긴밀한 연계 필요
Realtime vs Semi-Realtime
- Realtime
- 초단위 반응, 이벤트 중심 아키텍처
- 동적, 반응형 처리
- Semi-Realtime
- 마이크로 배치 방식
- 처리 속도와 리소스 효율성 균형 유지
실시간 데이터 종류와 사용 사례
Events are Everywhere
온라인 서비스 (Online Service)
- 사용자 행동 데이터(Funnel Data)
- Product Impressions, Clicks (Click Stream), Purchase 등
- 회원가입 과정 (회원등록 버튼 클릭 → 상세정보 입력 → 등록 버튼)
- 페이지 뷰 및 성능 데이터(Page Views & Performance Data)
- 페이지별 렌더링 시간 기록 → 문제 발생 시 원인 분석 가능
- 디바이스 타입별(데스크탑, 모바일 등) 성능 데이터 분석
- 페이지별 에러 발생 시 이벤트 로깅
- 사용자 이벤트
- 회원 가입, 로그인, 방문자 발생 등의 사용자 행동 데이터
- 데이터 수집, 저장 및 활용을 위해 이벤트 데이터 관리팀이 조직되기도 함
리테일 비즈니스 (Retail Business)
- 재고 업데이트 이벤트: 재고 추가 또는 품질 변화 반영
- 주문 이벤트: 주문 배치, 상태 업데이트 및 주문 처리 과정 반영
- 배송 이벤트: 배송 상태 및 위치 업데이트
IoT (Internet of Things)
- 센서 데이터: 온도, 습도, 압력 등 IoT 장치에서 수집하는 측정값
- 장치 상태 업데이트: 온라인/오프라인 상태, 배터리 잔량 등의 정보 업데이트
- 알람 이벤트: 동작 감지, 특정 임계값 초과 등 조건 충족 시 트리거 발생
실시간 데이터 활용 사례
실시간 리포팅 (Real-time Reporting)
- A/B 테스트 분석
- 마케팅 캠페인 대시보드
- 인프라 모니터링
실시간 경보 (Real-time Alerting)
- 이상 거래 탐지 (Fraud Detection)
- 실시간 광고 입찰 (Real-time Bidding)
- 원격 환자 모니터링 (Remote Patient Monitoring)
실시간 예측 (Real-time Prediction)
- 개인화 추천 시스템
실시간 데이터 처리의 주요 도전 과제
실시간 데이터 처리 단계
- 이벤트 데이터 모델 정의
- 이벤트 데이터 전송 및 저장
- 이벤트 데이터 처리
- 이벤트 데이터 관리 및 모니터링
이벤트 데이터 모델 정의
- 최소한 Primary Key와 Timestamp가 필요
- 사용자 정보 및 이벤트 관련 세부 정보 포함 가능
예시: 결제 API 데이터 모델
{
"TransactionID": "100001",
"CreatedTime": 150149860000,
"SourceAccountID": "131100",
"TargetAccountID": "151837",
"Amount": 3000
}이벤트 데이터 전송 및 저장
- Point-to-Point 방식
- Many-to-Many 연결 필요
- Throughput보다 Low Latency가 중요한 경우 사용 가능
- API 기반으로 작동하는 시스템에서 흔히 사용됨
- 다수의 Consumer가 존재하면 데이터를 중복 전송해야 함
- Messaging Queue 방식
- 중간 데이터 저장소를 두어 생산자와 소비자를 분리 (Decoupling)
- 다수의 Consumer가 쉽게 데이터를 처리 가능
- Kafka, RabbitMQ 등 사용
Backpressure(배압) 문제
- 실시간 스트리밍 시스템에서는 데이터가 일정 속도로 생성됨 (Producer)
- 하지만 때때로 데이터 유입량이 급격히 증가할 수 있음
- 다운스트림(Consumer)에서 데이터를 즉시 처리하지 못하면 메모리 사용량 증가 → 시스템 장애 발생 가능
- 해결책
- Messaging Queue 도입: Consumer가 처리할 수 있을 만큼 데이터를 큐에 보관
- 적절한 버퍼 크기 설정: 하지만 완벽한 해결책은 아님
- Auto-scaling 적용: Consumer 수를 동적으로 조정
이벤트 데이터 처리 모델
- Point-to-Point 방식
- Consumer 부담이 큼 → 실시간으로 데이터를 처리해야 함
- 데이터 유실 가능성이 높음
- Low Throughput, Low Latency 특성
- Messaging Queue 방식
- Micro-batch 형태로 짧은 주기로 데이터 처리 (Spark Streaming 등 활용)
- 다수의 Consumer가 데이터를 동시에 처리 가능 → 확장성 우수
- 운영 및 유지보수가 상대적으로 쉬움
'Kafka & Spark Streaming' 카테고리의 다른 글
| Spark Streaming과 Kafka 연동 (0) | 2025.02.22 |
|---|---|
| Kafka 기본 프로그래밍 (0) | 2025.02.22 |
| Kafka 주요 기능과 설치 및 간단한 실습 (1) | 2025.02.21 |
| Kafka소개 (0) | 2025.02.21 |