PinterestのHadoopインフラ

http://engineering.pinterest.com/post/92742371919/powering-big-data-at-pinterest

1 comment | 2 points | by WazanovaNews 3年弱前 edited


Jshiike 3年弱前 edited | ▲upvoteする | link

Pinterestもものすごい規模になってきましたね。

1日当たり20TBの新しいデータ。Amazon S3には約10PBが保存されている。

同社ではこのデータの処理にHadoopを利用していますが、

  • 毎日100人以上が、Quoboleが提供するダッシュボードを使って、2,000件以上のジョブを実行。
  • 3,000個のノードで構成される6つのHadoopクラスタを利用。エンジニアは数分で専用のクラスタが立上げ可能。
  • 毎日のログデータは、200億件。約1TBに達する。
  • このグラフによると、Pinterest全体のMapReduceクラスタのデータ処理総数/日は、800TBに近づいている。

Hadoopで自社サービスを立ち上げるための要件

Hadoopは、クラウドの利用や非エンジニアユーザの使用を前提にしたつくりではないので、Pinterest内で社員が使いこなせるソリューションにするために、まずはそのソリューションに期待する要件をまとめています。

  1. 隔離されたマルチテナント: Mapreduceには要件や設定項目が異なる様々なアプリがある。エンジニアは他の社員のジョブに影響を与えることなく、自分に必要なカスタマイズをこなせる環境が必要。

  2. 弾性: バッチ処理では、数千個のノードのクラスタを一気に利用したり、中断やデータの損失なくスケールダウンできるような弾性がほしい。

  3. マルチクラスタサポート: 単一のHadoopを水平にスケールさせることはできるが、完璧な隔離/弾性を実現するのは難易度が高いし、プライバシー/セキュリティ/コストなどのビジネス要件を考慮すると、マルチクラスタをサポートすべき。

  4. 一時的なクラスタのサポート: クラスタの立上げはリーズナブルな時間で完了し、必要な期間だけ維持し、更には手動での設定なしでジョブの全機能を使えるようにすべき。

  5. 簡単なソフトウェアのデプロイ: OSから、Hadoopレイヤ、そしてジョブ専用のスクリプトに至るまで、エンジニアが様々なレイヤをカスタマイズできるシンプルなインターフェースが必要。

  6. 共有のデータストア: クラスタ間をまたいだデータのアクセスは必須。

  7. アクセス権のコントロール: Oauthなどの既存の認証を使って、簡単にアクセス権を付与/変更できる仕組み。

トレードオフと実装

上記の要件を実装にあたっての、トレードオフと選択も紹介してくれています。

  • ディスクI/Oと比較して、S3のネットワークI/Oはそれほど遅くないことがわかったので、ネットワークI/Oのオーバヘッドを許容することで、データの保管と計算を切り分けることができた。このおかげで、データの読込みや同期を心配することなく、各クラスタはS3という一つのデータストアを参照できる(概念図)ようになり、マルチクラスタのサポートが実現できた。データストアについての懸念がなくなると、クラスタのリセットや削除も気軽にできるので、オペレーションも簡単にできる。スポットでノードを立てて、低コストで計算を走らせるような使い方も可能。
  • Hiveのメタストアを、Hadoopジョブ全体のデータカタログとして利用(概念図)。他のSQLツールのように、"show table" "describe table" "show partitions" などのクエリを走らせることができる。このほうがファイルをディレクトリ表示してアウトプットを確認するよりも、かなりシンプルに見やすくできる。しかも、MySQLがベースなので、スピードも早くデータの整合性もよい。S3がファイルのリスティングが遅く、しかも結果整合性を採用しているので、その点をHiveがうまく補完してくれている。
  • Hadoopのアプリは個々の要件や依存関係が様々なので、カスタマイズとセットアップ/スピードのバランスがうまくとれるフレキシブルな仕組みが必要。そこで三つのレイヤに環境を分ける(概念図)ことで、1,000ノードのジョブの立上げを45分から最短5分に短縮した。
    • Baked API: HadoopライブラリやNLPライブラリのように、依存サイズが大きくインストールに時間がかかる場合、イメージを事前にインストールする。Hadoopサービスの事業者ではこれに対応できないところが多い。
    • Automated Configuration (Masterless Puppet): ノードのカスタマイゼーションのほとんどはPuppetが担っている。Pinterestの場合に困るのが、新しいノードを本番システムに追加すると、同時にPuppetマスターから設定を取得しようとするので、マスターのノードが処理しきれずに障害になるケースがでること。これを回避するために、Puppetクライアントを "masterless" とし、S3から設定を取得してPuppetマスターと同期できるようにした。(概念図
    • Runtime Staging on S3: ほとんどのMapReduceジョブのカスタマイズは、jars / ジョブ設定 / カスタムコードを伴う。エンジニアは開発環境で対処し、他のジョブに影響を与えずに、任意のHadoopクラスタに展開しなければいけない。柔軟性、スピードと隔離性のバランスをとるために、S3上に各エンジニア専用のワーキングディレクトリを用意した。ジョブが実行されると、ワーキングディレクトリが立ち上がり、S3から必要な依存関係情報が取得される。(概念図

executorの抽象レイヤ

最初は、Hadoopジョブの実行にAmazon Elastic MapReduce (EMR) を利用していたが、数百ノードにスケールしてくると安定しなくなってきた。また、EMR独自のバージョンのHiveにも限界を感じた。しかし、既にEMR上にかなりのアプリを構築していて、ジョブのロジックとEMRの仕様が複雑に絡んでいたので、新しいシステムにどのアプリをどう統合するかは難しい問題であった。そこで、executorインターフェースを用意し、EMR独自のロジックはEMRExecutorに移行した。インターフェースには、"run_raw_hive_query(query_str)" "run_java_job(class_path" などのメソッドを実装した。この仕組み(概念図)を利用することで、ダウンタイムを最小限にした新システムへの段階的な移行と、HadoopそのものやHadoopサービス事業者の機能を取り込むことを平行して進めることができた。

Quboleの採用

最終的にはEMRからQuboleに移行。EMRと比較して、30%-60%早いスループットを実現した。Quboleを採用してよかったポイントとしては、

  • 一つのクラスタで数千のノードに水平にスケールできる。
  • 24/7サポート
  • Hiveとのインテグレーションがしっかりしている。
  • 非エンジニアのために、Google Oauth ACLとHive Web UIが用意されている。
  • シンプルなexecutor抽象化レイヤのAPIとマルチクラスタサポートを提供。
  • プレミアムサポートを払えば、Baked APIのカスタマイゼーションに対応。
  • スポットのインスタンスへのサポート
  • S3結果整合性への対応
  • スムーズなクラスタの自動スケール

#pinterest #hadoop #qubole

Back