[논문 리뷰] Fast Data in the Era of Big Data: Twitter's Real-Time Related Query Suggestion Architecture

Gilad Mishne, Jeff Dalton외 3명|arXiv (Cornell University)|2012. 10. 27.

Cloud Computing and Resource Management참고 문헌 50인용 수 8

한 줄 요약

이 논문은 브레이킹 뉴스 상황에서 하루 10분 이내로 응답해야 하는 요구사항을 충족하기 위해 Hadoop 기반 배치 처리 아키텍처에서 시작해, 메모리 기반 스트림 처리 엔진으로 진화한 트위터의 실시간 관련 쿼리 제안 및 철자 교정 시스템을 제시한다. 주요 기여는 Hadoop가 저지연, 실시간 데이터 처리에 부적합하다는 실용적 사례 연구이며, '빅' 데이터와 '패스트' 데이터를 모두 처리할 수 있는 통합 플랫폼의 필요성을 주장한다.

ABSTRACT

We present the architecture behind Twitter's real-time related query suggestion and spelling correction service. Although these tasks have received much attention in the web search literature, the Twitter context introduces a real-time "twist": after significant breaking news events, we aim to provide relevant results within minutes. This paper provides a case study illustrating the challenges of real-time data processing in the era of "big data". We tell the story of how our system was built twice: our first implementation was built on a typical Hadoop-based analytics stack, but was later replaced because it did not meet the latency requirements necessary to generate meaningful real-time results. The second implementation, which is the system deployed in production, is a custom in-memory processing engine specifically designed for the task. This experience taught us that the current typical usage of Hadoop as a "big data" platform, while great for experimentation, is not well suited to low-latency processing, and points the way to future work on data analytics platforms that can handle "big" as well as "fast" data.

연구 동기 및 목표

• 브레이킹 뉴스 발생 직후 수분 내에 실시간 관련 쿼리 제안을 제공하는 데 도전하는 것 — 기존 웹 검색에서는 이를 충족하지 못함.
• Hadoop 기반 배치 처리가 실시간 쿼리 제안 및 철자 교정에 저지연 요구사항을 충족하지 못한 이유를 조사하는 것.
• 동적이고 급격히 변화하는 쿼리 관계를 위한 10분 미만의 응답 시간을 지원하는 맞춤형 메모리 기반 처리 엔진을 설계하고 구현하는 것.
• Hadoop가 속도 중심 워크로드에 대해 가지는 아키텍처적 및 성능적 한계를 부각하고, '빅' 데이터와 '패스트' 데이터를 모두 효율적으로 처리할 수 있는 통합 플랫폼의 필요성을 주장하는 것.
• 생산 규모 시스템에서 실시간 데이터 처리를 위한 실무적 통찰을 제공하기 위해, 동일한 시스템의 두 번째 버전을 개발하면서 얻은 교훈을 강조하는 것.

제안 방법

• 트위터 로그 데이터의 쿼리 동시 발생 패턴을 계산하기 위해 Pig를 사용하는 Hadoop 기반 분석 스택을 사용해 배치 처리를 수행.
• 실시간 쿼리 제안 및 철자 교정을 위한 저지연 처리를 위해 Hadoop 파이프라인을 대체할 맞춤형 메모리 기반 스트림 처리 엔진으로 전환.
• 새로운 트윗이 도착함에 따라 실시간으로 쿼리 관계 점수를 유지하고 업데이트하는 상태 기반 스트림 처리 아키텍처를 구현.
• 메모리 기반 데이터 구조를 활용해 밀리초 수준의 업데이트를 가능하게 하여 고처리량, 저지연 트윗 스트림 처리를 지원.
• 예를 들어 브레이킹 뉴스 발생 시 갑작스러운 쿼리 폭증을 감지하고, 수분 내에 관련 쿼리 제안을 동적으로 조정할 수 있도록 시스템을 설계.
• 전체 재처리 없이도 실시간 이벤트 처리와 점진적 계산을 조합해 최신 상태의 쿼리 관계를 유지하는 방법을 사용.

실험 결과

연구 질문

• RQ1 Hadoop 기반 배치 처리가 실시간, 저지연 쿼리 제안 시스템에 적용되었을 때의 성능 및 지연 한계는 무엇인가?
• RQ2 브레이킹 뉴스 발생 후 10분 이내로 관련 쿼리 제안을 제공할 수 있도록 시스템을 아키텍처링할 수 있는 방법은 무엇인가?
• RQ3 실시간 데이터 분석에 있어 배치 처리(Hadoop)와 스트림 처리(메모리 기반 엔진) 간의 아키텍처적 트레이드오프는 무엇인가?
• RQ4 기존 스트림 처리 엔진(예: Storm, S4)이 장기간에 걸친 대규모 역사적 분석 및 대용량 데이터에 대한 복잡한 임의의 쿼리를 얼마나 잘 처리할 수 있는가?
• RQ5 '빅 데이터'(용량)와 '패스트 데이터'(속도) 워크로드를 모두 효율적으로 처리할 수 있는 통합 데이터 처리 플랫폼을 설계하기 위해 필요한 설계 원칙은 무엇인가?

주요 결과

• 초기 Hadoop 기반 구현은 브레이킹 뉴스에 대한 실시간 응답을 위해 요구되는 10분 이내 지연 시간 목표를 충족하지 못해 생산 환경에서 효과적으로 기능하지 못함.
• Hadoop의 설계가 배치 처리에 최적화되어 있어 디스크 I/O 의존성과 장시간의 작업 사이클을 갖기 때문에, 저지연 실시간 데이터 처리에는 본질적으로 부적합함.
• 맞춤형 메모리 기반 처리 엔진은 지연 시간을 10분 이내로 감소시켜 주요 뉴스 이벤트 동안 시기적절한 관련 쿼리 제안을 가능하게 함.
• 배치 중심 시스템과 실시간 데이터 요구사항 간의 아키텍처적 불일치로 인해 Hadoop에서 메모리 기반 스트림 엔진으로의 전환은 필수적이었음.
• Storm, S4와 같은 기존 스트림 처리 엔진은 장기적인 역사적 분석 및 대용량 데이터에 대한 복잡한 임의의 쿼리 기능을 내장하고 있지 않음.
• '빅 데이터'(용량)와 '패스트 데이터'(속도) 워크로드를 효과적으로 처리하기 위해 배치 분석(Hadoop)의 강점과 메모리 기반 엔진의 스트림 처리 능력을 결합한 통합 데이터 처리 플랫폼이 필요함.