Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

Starfish: Hadoopでの自己調節データ解析

原文:Starfish: Self-tuning data analytics with Hadoop

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2011/08/30 14:00

 この前の月曜日に、デューク大学のShivnath Babuの講義を聴講しました。(原文:Starfish: Self-tuning data analytics with Hadoop、2011/07/01投稿)

 本稿はデータベースソフトウェア「SQL Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。図など、部分的に英語のままになっていますが、製品のSQL Anywhere自体は完全に日本語化されていますのでご安心ください。
※編集部注:掲載しているブログ内容は執筆時点での情報のため、現在とは異なる場合があります。

 講義の内容は「MADDER、およびStarfishによるHadoopでの自己調節データ解析(MADDER and Self-tuning data analytics on Hadoop with Starfish)(PDF)」というものです。一言で言えば、Starfishプロジェクトが目指しているのは、Hadoopシステム用の自己調節および自己管理技術を開発することであり、SQL Anywhereをはじめとする自己管理型リレーショナルデータベースシステムが抱える課題の多くは、Hadoopシステムの課題と対応しています。

 Starfishの論文とソースコードはApacheラインセンスの下で公開されており、こちらで見ることができます。

 次に、Shivnathの講義中に私が書き留めたメモを示します(スライド(PDF)はこちらで見ることができます)。

  • 大規模データ解析は、多くの場合、Google、Yahoo!、Facebook、eBayといった企業のコンテキストで使用される。しかし、Web規模のデータは他の領域でも同様に見られるものであり、科学者、ジャーナリスト、経済学者、生物学者、物理学者、システム研究者などは、だれでも「大規模データ」の問題を抱えている。データ量の大きさだけではなく、ワークロードの複雑さも問題になる。代表的な例としては、計算や集計、さらにテキストやイメージの処理がある。

  • 「Madder」は「狂気」を意味する「Mad」の変化形だが、もとを正せばカリフォルニア大学バークレー校のJoe Hellersteinたちの命名に由来する。「Madder」は、Magnetic、Agile、Deep、Data-lifecycle-aware、Elastic、およびRobustの頭文字を並べたもので、それぞれの意味は次のとおり。
    • Magnetic(磁石のように引きつける) ― システムへのデータの入力が容易である。
    • Agile(機敏な) ― 変更(データおよび要件、またはそれらの一方)が容易である。
    • Deep(深遠な) ― あらゆる種類の解析をサポート。MapReduceプログラムはJava、Python、Rで記述でき、PigJaqlのようなインターフェイスも使用可能。
    • Data-lifecycle-aware(データライフサイクル対応の) ― 数量化が困難である。情報に対するデータ処理に関し、すべてのフェーズを考慮する。たとえば、ロードだけでなく処理、アーカイブ化なども含む。
    • Elastic(柔軟な) ― 実際のワークロードに合わせてリソースとコストを適応させる。
    • Robust(堅牢な) ― 想定外のイベントが発生したり、ワークロードが増大したときであっても、機能の低下が適切である。
  • Hadoopクラスターの調節の問題には以下の内容が含まれる。(1)ジョブレベルのMapReduceの構成、(2)ワークフローの最適化、(3)ワークロードの管理、(4)データレイアウトの調節、および(5)クラスターのサイズ設定。

  • MapReduceジョブは、4組の要素として表すことができる。つまり、ジョブ j = < プログラム p, データ d, リソース r, 構成 c >となる。しかし、Hadoopには190個以上の構成パラメータがあり、潜在的な選択肢の範囲には、Mapタスク数、Reduceタスク数、MapタスクおよびReduceタスク間のパーティショニング量、メモリ割り当てなどが含まれる。構成パラメータの数が多すぎるので、最適な実行が問題になる可能性がある。

  • Starfishは、Profiler、What-ifエンジン、およびオプティマイザという3つのコンポーネントで構成されている。Profilerは、MapReduceジョブを実行して、タスクの各フェーズ(読み取り、マップ、収集、スピル、マージ)の情報を記録したジョブプロファイル(簡潔な実行概要)を収集する。What-ifエンジンは、j = < p, d, r, c >というジョブのプロファイルに基づいて、j' = < p, d', r', c' >というジョブのプロファイルを見積もる。オプティマイザは、実行計画を列挙しつつ、最適化空間を効率的に分析する。

  • 実行プロファイルの生成は、測定を通じて行うことも、What-ifエンジンを通じて行うこともできる。測定を通じてプロファイルを生成することには、以下の3つの目的がある。(1)オフ時のオーバーヘッドをゼロにし、オン時のオーバーヘッドを最小限にする、(2)Hadoop自体の修正を必要としない、(3)Java/Python/Ruby/C++で書かれたMapReduceプログラムを修正なしでサポートする。

  • プロファイル方法: プロファイル収集は動的でオンデマンドな計装。「イベント、条件、アクション」のルールをJavaで指定し、これによってMapReduceジョブの実行のタスクフェーズをモニターする。現在、この処理にはBTrace(Hadoopの内部はJavaで実装)が使用されている。この計装により、mapとreduceの両方の段階で各JVMの生プロファイルデータの取得が可能になる。Mapタスクを数多く含むジョブの場合には、オーバーヘッドの量を軽減するためにサンプリングが使用される。もたらされるオーバーヘッドの全体的な割合は5%から30%の間であり、ワークロード全体のうちのどの程度の部分がプロファイル収集の対象になるかに応じて変化する。

  • What-ifエンジンは、ジョブプロファイルを受け取り、さらに仮説的なプロパティ、リソース、および構成設定を受け取って、仮想ジョブプロファイルを作成する。現在のStarfishでは、この動作はさまざまなプログラム間で一般化されておらず、分析はシミュレーションを通じて行われる。最終的な目的は、What-ifエンジンをHadoop自体に組み込むことである。

  • Starfishで回答が得られるWhat-If問題の例:
    1. Reduceタスクの数が20から40に変わった場合、ジョブjの実行時間はどのように変化するか。
    2. Mapのパフォーマンスは圧縮によってどのような影響を受けるか。データの量が40%増加した場合はどうか。

     これはあくまで目的を達成するための手段にすぎない。Starfishの目的はJob Optimizerに到達することであり、j = < p, d', r' >という仮説的なジョブについての最適な構成設定を見出すことである。

  • 実験の結果が明確に示しているように、コストベースの最適化に基づくWhat-if分析は、決まりきった「経験的知識」をHadoop構成に適用するよりも有用である。ただし、Starfishは動的な実行時適応処理を(まだ)サポートしていない。これをサポートすれば、全体的なパフォーマンスが飛躍的に改善されるはずである。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • Glenn Paulley(Glenn Paulley)

    カナダ オンタリオ州 ウォータールー R&amp;DセンターにてSQL Anywhere 開発における Director of Engineering としてクエリ・オプティマイザなどの開発をリードしている。 ・IvanAnywhere

バックナンバー

連載:Glenn Paulley氏 データベース関連ブログ 翻訳記事

もっと読む

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5