> [!abstract] 概要 > 大規模データのスケーラブルな分析は、Facebook の複数のチーム(エンジニアリング部門と非エンジニアリング部門の双方)の中核的な機能である。 > 全社のアナリストによるアドホック分析やビジネスインテリジェンス用ダッシュボードの作成だけでなく、Facebook のサイト機能の一部も大規模データの分析に基づいている。 > これらの機能は、Facebook 広告主向け Insights のような単純なレポートアプリケーションから、友達推薦のようなより高度なものまで広がっている。 > 増え続けるデータ上でこの多様な利用事例を支えるには、費用対効果よく拡張できる柔軟な基盤が重要である。 > Facebook では要件に対応するため、複数のオープンソース技術を利用・開発・貢献してきた。Scribe・Hadoop・Hive は、Facebook のログ収集・格納・分析基盤の礎を形成している。 > 本論文では、これらのシステムを組み合わせて、15PBを超えるデータ(圧縮後2.5PB)を格納し、毎日60TBを超える新規データ(圧縮後10TB)をロードするデータウェアハウスを実装した方法を示す。 > 設計判断の動機、この解決策の能力、日々の運用で直面する課題、今後取り組む機能と改善について議論する。 ## 論文情報 - タイトル: Data Warehousing and Analytics Infrastructure at Facebook - 著者: Ashish Thusoo、Dhruba Borthakur、Raghotham Murthy(本文PDFの著者欄では Raghu Murthy)、Zheng Shao、Namit Jain、Hao Liu、Suresh Antony、Joydeep Sen Sarma - 媒体: SIGMOD '10、2010年6月6〜10日、米国インディアナ州インディアナポリス - 公式ページ: [Meta Research](https://research.facebook.com/publications/data-warehousing-and-analytics-infrastructure-at-facebook/) - 原本: [[.raw/papers/data-warehousing-and-analytics-infrastructure-at-facebook.pdf]] ## 概要 本論文は、Facebook が Scribe・Hadoop・Hive を組み合わせて構築した大規模データウェアハウスの設計と運用経験を報告する。 主題は個々のアルゴリズムの新規性ではなく、ログと業務データを収集し、圧縮・公開し、アドホック分析と期限付きバッチ処理へ同時に提供する基盤全体の設計である。 ## 問題設定 Facebook では、広告レポートやビジネスインテリジェンスだけでなく、推薦モデルの訓練、仮説検証のための一回限りの分析など、性質の異なる処理が同じデータ基盤へ投入される。 一日に約10,000ジョブが投入され、ジョブごとに並列化度、実行時間、必要資源、データ提供期限が異なる。 データ量も急増しており、論文執筆時点の取り込み量は圧縮後で毎日10〜15TB、6か月前は5〜6TBだった。 したがって、基盤にはコモディティハードウェアでの水平拡張、異なるSLAへの対応、処理パターンごとの最適化、アドホック利用による本番処理への干渉防止が必要になる。(Source: [[.raw/papers/data-warehousing-and-analytics-infrastructure-at-facebook.txt]] §1) ## 提案手法 ### データフローアーキテクチャ 入力は、Facebookサイトに関するデータを持つフェデレーテッドMySQL層と、Webサーバーが生成するログの二系統である。 MySQL由来のデータは広告のカテゴリや広告主の情報のようなディメンションデータに、Web由来の操作ログは広告の表示・クリックやFacebookページへのファン登録のようなファクトデータに対応する。 WebサーバーのログはScribe-Hadoop(scribeh)クラスタへ送られ、Scribeサーバーがログを集約してHDFSファイルへ書き出す。 scribehクラスタはWeb層のデータセンタに配置され、毎日30TBを超える非圧縮データを受け取るため、主なボトルネックはネットワークである。 5〜15分間隔で動くコピー処理が新規ファイルを圧縮してHive-Hadoopクラスタへ移送し、ローダーがログをHiveテーブルの時間パーティションとして公開する。 生のHDFSファイルは外部テーブルとして先に参照可能にし、日次ロード時に小さなファイルをまとめたネイティブHiveテーブルへ移行する。 MySQL層のデータは、マスターへ負荷をかけないよう複製層を日次スクレイプし、障害時にはサーバー単位で再試行する。読み出せないサーバーについては前日のデータを使い、強い一貫性より負荷回避と日次ダンプの完成を優先する。 この流れを図1に示す。Scribe-Hadoopクラスタから本番Hive-Hadoopクラスタへデータを集約し、本番クラスタからアドホックHive-HadoopクラスタへHiveレプリケーションを行う構成である。 ![[_attachments/data-warehousing-and-analytics-infrastructure-at-facebook/fig01-data-flow-architecture.png]] (図1. WebサーバーとフェデレーテッドMySQLを入力とし、Scribe-Hadoopクラスタ、本番Hive-Hadoopクラスタ、アドホックHive-Hadoopクラスタを経て分析へ渡すデータフロー。論文 Figure 1。) ### 低レイテンシーとクラスタ分離 ログは生成から5〜15分で生のHDFSファイルになるが、ネイティブHiveテーブルへのロードは日次である。 この差を埋めるため外部テーブルを使い、直近データへの早期アクセスと日次のファイル統合を両立する。 一方、広告レポートなど期限の厳しい処理は本番クラスタで実行し、低優先度のバッチ処理と歴史データのアドホック分析は別クラスタで実行する。 アドホックジョブを本番クラスタから隔離することで、悪いクエリが資源を占有して本番ジョブを飢餓状態にする危険を抑える。 本番クラスタで変更されたHiveテーブルは、コマンドロガーをHiveの実行前フックとして組み込んだレプリケーション処理によりアドホッククラスタへ複製する。 ### 格納と圧縮 歴史データを保持するアドホッククラスタでは容量が恒常的な制約になる。 主なデータセットはgzipで圧縮し、通常6〜7倍の圧縮率を得る。 さらにHiveへPAXの格納レイアウトに基づく行列圧縮を実装し、Hadoop SequenceFile上の通常のgzipと比べて10〜30%の容量削減を得た。 この圧縮は一部のベンチマークでCPU利用率もわずかに改善し、少数の列だけを読むクエリでは明確な改善をもたらした。 HDFSの標準的な3重複製は容量を消費するため、2つのデータコピーと2つの誤り訂正符号コピーによって実効2.2コピーに抑える消失訂正符号(Hadoop RAID)も検討した。 同一ラック内のノード間帯域は100MB/sあり、論文のクラスタではネットワークがジョブのボトルネックになりにくかったため、複製数を減らすことによるデータ局所性低下を許容できる場合があった。 ### HDFSのファイル数とNameNode アドホッククラスタには約1億個のファイルとブロックがあり、HDFS NameNodeのヒープサイズは48GBに設定されていた。 小さなファイルが増えるとNameNodeが保持するファイル・ブロック対応表のメモリ圧力が増すため、ファイル連結によるアーカイブ、選択性の高いクエリの出力連結、`HiveCombinedFileInputFormat`によるMapタスク数削減を行う。 これらはジョブのレイテンシーを多少犠牲にして、メタデータ管理と下流処理の負荷を抑える設計である。 ### Hiveによる高水準分析 HiveはHadoop上のデータウェアハウスフレームワークであり、Facebookで作成された後にHadoopサブプロジェクトとして公開された。 MapReduceが多様なジョブを表す最低限の共通基盤である一方、低水準すぎて生産的なパイプライン作成には向かないという観察から、SQL・表・列・パーティションの抽象化をHadoop上へ導入した。 HiveQLを受け取るDriverは、メタストアの表・パーティション情報を使ってMapReduceジョブ列とHDFS操作へ変換する。 パーティション述語によるファイル枝刈り、述語プッシュダウン、未使用列の枝刈り、データ偏りに対する部分集約、結合順序の変更、Map側結合、バケット結合などを計画へ組み込む。 UDF・UDTF・`TRANSFORM/MAP/REDUCE`、独自型、独自データ形式も利用でき、SQLで表しにくい変換にも対応する。 図2は、Hiveのコマンドライン・Webインターフェース、JDBC/ODBC、Thrift Server、Driver、Metastoreと、HadoopのJobTracker・NameNode・DataNode/TaskTrackerの関係を示す。 ![[_attachments/data-warehousing-and-analytics-infrastructure-at-facebook/fig02-hive-system-architecture.png]] (図2. HiveのDriver・Metastore・各種インターフェースと、MapReduce・HDFSを含むHadoop層の接続。論文 Figure 2。) ### データ発見とジョブ依存関係 アドホックHive-Hadoopクラスタには2万を超えるテーブルがあり、毎月数百人が問い合わせるため、データそのものの発見が課題になる。 Facebookは、利用者が表・列の説明を追加・修正し、検索タグやプロジェクト名を付ける協調的なメタデータ編集を採用した。 さらにクエリログからデータ系譜を抽出し、あるデータセットの元データと、ある表から派生したデータセットを辿れるようにした。 最近その表を頻繁に問い合わせた専門利用者もクエリログから特定し、HiPalのクエリセッション内で質問できるようにした。 定期バッチの依存関係・変換・監視はPython製のDatabeeで指定し、データセットや他のDatabeeジョブへの依存、完了時間・レイテンシー・中間段階の統計を記録する。 ### 資源共有 アドホック分析は短い応答時間と試行錯誤を求め、定期バッチは期限までの予測可能な実行時間を求める。 Hadoopジョブは資源を得た後に横取りできなかったため、長時間の定期ジョブが短いアドホックジョブを遅延させる問題があった。 そこでHadoop Fair Share Schedulerを使い、利用者ごとにプールを割り当て、プール間で資源を公平に共有した。 定期ジョブには最低資源量を持つ専用プールを与え、アドホックジョブにはCPU・メモリ使用量を監視する資源認識型の制御を追加した。 ノードの閾値を超えた場合は既存タスクを停止し、CPU・メモリに余裕があるノードだけへ新しいタスクを配置する。 データ局所性を使う待機も導入したが、小規模ジョブには適さないため無効化し、MapとReduceの同時スケジューリングなどを使い分けた。 物理的な本番・アドホッククラスタ分離は利用率を下げる場合があるものの、厳格な期限の予測可能性を守る実用的な選択だった。 ## 新規性 本論文の新規性は、Scribe・Hadoop・Hiveという個別技術の提案ではなく、ログ収集、分散格納、SQL分析、データ発見、資源共有、運用監視を一つの会社規模のデータウェアハウスへ接続した点にある。 特に、Hadoopの低水準なMapReduceをHiveの表・パーティション・SQLで包み、非エンジニアリング部門も大規模分析へ参加できるようにした点と、アドホック分析の民主化によって生じた資源隔離・メタデータ発見・ファイル数爆発の副作用まで同じ運用報告で扱った点が特徴である。 ## 実験設定・運用規模 これは制御されたベンチマーク論文ではなく、Facebookの本番データウェアハウスを数年間運用した経験報告である。 基盤はコモディティハードウェア上のScribe、HDFS、Hadoop MapReduce、Hiveで構成され、入力はフェデレーテッドMySQLとWebログである。 論文の主要な規模値は、約10,000ジョブ/日、15PB超の格納データ(圧縮後2.5PB)、毎日60TB超の新規データ(圧縮後10TB)、1億個近いファイル・ブロック、2万超のHiveテーブルである。 評価対象は、データ到着遅延、圧縮率、ファイル数とNameNodeメモリ、クエリ生産性、ジョブの資源共有、クラスタの稼働状態であり、単一の総合性能指標には集約していない。(Source: [[.raw/papers/data-warehousing-and-analytics-infrastructure-at-facebook.txt]] §§1–6) ## 実験結果 - ログは生成から5〜15分で生HDFSファイルとして利用可能になり、日次ローダーによるネイティブHiveテーブル化との間を外部テーブルが埋めた。 - gzipは多くのデータセットで6〜7倍の圧縮率を示し、PAXに基づく行列圧縮は通常のgzipと比べてさらに10〜30%の容量削減を示した。 - HDFSの3重複製に代えて消失訂正符号で実効2.2コピーにする方式は、テストデータで有望な結果を示したが、データ局所性低下とのトレードオフを伴った。 - Hiveは、専門家がMapReduceで数時間から数日かけて書く処理を、SQLとHiveQLでは数分で表現できるようにした。 - HiPalは、クエリ進捗・結果の閲覧・CSVの入出力・エラーの検査とデバッグをWeb UIへまとめ、非エンジニアリング利用者を含むアドホック分析を広げた。 - Fair Share Scheduler、CPU・メモリ監視、専用プール、クラスタ分離の組み合わせにより、対話的ジョブと期限付きバッチの共存を支えた。ただしタスクの横取りを有効にしていないため、資源共有だけでは既存長時間タスクによる飢餓を解消できなかった。 ## 考察 この報告が示す中心的な設計判断は、全処理を単一の汎用クラスタへ押し込むことではなく、データの到着段階、ジョブのSLA、履歴データの保持期間、資源の局所性を分けて扱うことである。 外部テーブルは生データの早期可用性を与えるが、日次のネイティブテーブル化まで小さなファイルと未圧縮データが残る。 クラスタ分離は本番ジョブの予測可能性を高めるが、片方がアイドルでも他方の待ち行列を直接救えない。 複製数を減らす消失訂正符号は容量を節約するが、データ局所性を弱める。 Hiveの高水準抽象化は利用者を増やすが、利用者が増えるほどメタデータ、ファイル数、スケジューリング、悪いクエリの隔離が新たな運用課題になる。 ## 強み / 弱点・課題 ### 強み - 15PB級の実運用規模と、毎日のデータ到着・ジョブ投入・テーブル数を具体的に報告している。 - ログ収集から利用者向け分析、監視、資源割り当てまでを一つのデータフローとして説明している。 - 生データの早期公開、日次の圧縮・統合、厳格な本番SLA、アドホックな探索という相反する要求を、外部テーブル・クラスタ分離・プール制御で分解している。 ### 弱点・未解決課題 - 比較対象を置いた再現可能なベンチマークではなく、Hive導入前後の性能差や総保有コストを体系的に評価していない。 - タスクの横取りを使わないFair Shareは新規ジョブの割り当てには効くが、既に資源を使う長時間ジョブによる飢餓を残す。 - ログの連続取り込み、MySQLの増分スクレイプ、複数データセンタへのフェデレーション、動的クラウドは将来課題として提示され、完成した方式の評価はない。 - 図1のPDF本文には自動生成された参照エラー文(`Error! Reference source not found`)が残っており、本文テキストの該当箇所は図1のキャプションと前後の説明で補った。 ## 出典 - [[.raw/papers/data-warehousing-and-analytics-infrastructure-at-facebook.pdf]] - [[.raw/papers/data-warehousing-and-analytics-infrastructure-at-facebook.txt]] - [Meta Research: Data warehousing and analytics infrastructure at Facebook](https://research.facebook.com/publications/data-warehousing-and-analytics-infrastructure-at-facebook/)