[論文レビュー] Fast Data in the Era of Big Data: Twitter's Real-Time Related Query Suggestion Architecture

Gilad Mishne, Jeff Dalton+3 more|arXiv (Cornell University)|Oct 27, 2012

Cloud Computing and Resource Management参考文献 50被引用数 8

ひとこと要約

この論文では、急上昇する出来事の際の10分未満の遅延要件を満たすために、Hadoopベースのバッチ処理アーキテクチャからカスタムメモリ内ストリーム処理エンジンへ進化した、Twitterのリアルタイム関連クエリ提案およびスペル訂正システムを提示している。主な貢献は、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がボリュームではなく速度駆動ワークロードに対して抱えるアーキテクチャ的・パフォーマンス的制限を強調し、『ビッグ』データと『ファスト』データの両方を効果的に処理できる統合プラットフォームの必要性を提唱すること。
• 生産規模システムにおけるリアルタイムデータ処理の教訓を強調した、同じシステムの2回目の反復構築から得た実用的知見を共有すること。

提案手法

• Twitterログデータのクエリ共起パターンを計算するために、Pigを用いたHadoopベースのアナリティクススタックをバッチ処理で使用した。
• Hadoopパイプラインを、低遅延、リアルタイムクエリ提案およびスペル訂正を目的としたカスタムメモリ内ストリーム処理エンジンに置き換えた。
• 新しいツイートが到着するたびにクエリ関連性スコアをリアルタイムで維持・更新する状態保持型ストリーム処理アーキテクチャを実装した。
• メモリ内データ構造を活用して、サブ秒未塔の更新を可能にし、ツイートストリームの高スルーレート・低遅延処理を支援した。
• 急増するクエリ（例：急上昇ニュース）を検出・応答できるように、関連クエリ提案を数分以内に動的に適応する仕組みを設計した。
• 完全再処理を回避するために、リアルタイムイベント処理とインクリメンタル計算の組み合わせを用いて、最新のクエリ関連性を維持した。

実験結果

リサーチクエスチョン

• RQ1 リアルタイムで低遅延を要するクエリ提案システムに適用した場合、Hadoopベースのバッチ処理にどのようなパフォーマンス的・遅延的制限があるか？
• RQ2 急上昇ニュース発生後10分以内に関連クエリ提案を提供できるように、システムをどのようにアーキテクチャ設計すればよいか？
• RQ3 バッチ処理（Hadoop）とストリーム処理（メモリ内エンジン）の間には、リアルタイムデータアナリティクスにおいてどのようなアーキテクチャ的トレードオフがあるか？
• RQ4 既存のストリーム処理エンジン（例：Storm, S4）は、長期間にわたる大規模な履歴アナリティクスおよび大容量データに対する複雑なアドホッククエリをどの程度処理できるか？
• RQ5 『ビッグデータ』（ボリューム）と『ファストデータ』（ボリューム）の両方のワークロードを効率的に処理できる統合データ処理プラットフォームを設計するにあたり、必要な設計原則は何か？

主な発見

• 初期のHadoopベースの実装では、急上昇ニュースへのリアルタイム対応に必要な10分未塔の遅延目標を達成できず、生産環境での利用に不適切であった。
• Hadoopのバッチ処理設計—特にディスクI/O依存性と長いジョブサイクル—は、低遅延、リアルタイムデータ処理に根本的に不適切である。
• カスタムメモリ内処理エンジンにより、遅延を10分未塔に低減し、主要なニュースイベント時におけるタイムリーな関連クエリ提案を可能にした。
• バッチ指向のシステムとリアルタイムデータ要件との間のアーキテクチャ的不一致が原因で、Hadoopからメモリ内ストリームエンジンへの移行が不可避であった。
• Storm や S4 などの既存のストリーム処理エンジンは、長期間にわたる履歴アナリティクスや大規模データ量に対する複雑なアドホッククエリをネイティブにサポートしていない。
• 『ビッグ』データ（ボリューム）と『ファスト』データ（ボリューム）の両方を効果的に処理できる、バッチアナリティクス（Hadoop）とストリーム処理（メモリ内エンジン）の長所を統合した統合プラットフォームの構築が、今後不可欠である。