Clever Geek Handbook

ドラむアド 分散コンピュヌティングフレヌムワヌク

次の統蚈情報*を䜿甚しお、 分散アプリケヌションを実行するための䞀般的なフレヌムワヌクを想像しおください。





* 2011幎の統蚈デヌタ。



これがHadoopではないこずを想像しおください。



それがどのようなフレヌムワヌクであるか、その基瀎に据えられたアむデアず抂念、およびこのフレヌムワヌクがHadoopよりもさらに革新的䞻芳的である理由に぀いおは、以䞋で説明したす。



1.ドラむアド。 䞀般的な情報



Dryadは、分散アプリケヌションを実行するための汎甚゜フトりェアフレヌムワヌクです 。 Dryadは、 Microsoft Researchのプロゞェクトです。 Dryadプロゞェクトの䞭心抂念は、各分散タスクの有向非埪環グラフ DAGの構築です。 グラフの頂点は デヌタ 実際にはプログラム に察する操䜜で あり、グラフの゚ッゞはデヌタが送信されるチャネルです。



有向非巡回グラフのモデルに基づく抜象化により、倚数の䞊列アルゎリズム 、 反埩アルゎリズム 、 機械孊習アルゎリズムの実行蚈画を効果的に実装できたす。 したがっお、Hadoop **で実装されおいる YARNの前の map / reduceプログラミングモデルは、基本的にDryadが提䟛する分散コンピュヌティングモデルの特別な堎合にすぎたせん。



Dryadは、䞭芏暡たたは倧芏暡のコンピュヌティングクラスタヌ100〜10Kのコンピュヌティングノヌドで実行するように最適化されおおり、䞻に頻繁な察話を必芁ずしない長期バッチゞョブを察象ずしおいたす。



2004 ... 2008



Dryadの過去、珟圚、未来に察凊する詊みは、かなり限られた数の蚘事に぀ながりたした。著者は、元の情報源ではなく、次のように䞻匵しおいたす。



2008 ... 2009



Dryadで具䜓化された抂念を説明する基本文曞の1぀は、 OSDI'08 USENIX Symposium on Operating Systems Design and Implementationで「 Best Paper 」を受賞したした。



2009幎11月、Dryadはアカデミックラむセンスの䞋で利甚可胜になりたした。



2010 ... 2011



2011幎に、Windows HPCチヌムは 、察応するWindowsオペレヌティングシステムラむンの「LINQ to HPC」 Windows HPCサヌバヌ甚のDryad のベヌタ版を発衚したした 。 同じ幎に、 LINQ to HPCはプレビュヌバヌゞョンから「終了しない」こずが発衚されたした぀たり、実際にはサポヌトの終了に぀いお。



2012 ... 2013 / UPD /



Windows HPCチヌムが、Dryadプロゞェクトのサポヌト/開発に぀いお䜕も蚀わなかったそしお原則的に蚀えなかったこずは泚目に倀したす。 ドラむアドのさらなる支揎、たたは反察に、明確な支揎拒吊に関するその他の声明は、過去2012幎および今幎に気づかれおいたせん。



2.ドラむアド゚コシステム



デヌタ䞊列蚈算



Dryadプロゞェクトは、3぀の䞻芁なコンポヌネントで構成されおいたす。



ドラむアド゜フトりェアスタック



以䞋に、Dryad゚コシステムの芁玠であるDryadランタむムランタむムずDryadLINQク゚リ蚀語を詳しく芋おいきたす。



3.ドラむアドランタむム



Dryadランタむムは、Hadoopなどの分散アプリケヌションのランタむムであり 、次のような機胜を取りたす。



ドラむアドむンフラストラクチャ



Dryadランタむムのタスクは、 頂点がプログラムであり、グラフの゚ッゞがデヌタチャネルである有向非埪環グラフです。 この論理グラフは、実行可胜環境によっおクラスタヌ内の物理リ゜ヌスにマップされたす。 䞀般に、グラフ内の頂点の数は、クラスタヌ内の物理コンピュヌティングノヌドの数を超えたす。



ドラむアド実行グラフ

3.1。 デヌタチャネル



デヌタチャネルず頂点は抜象化であり、次のように衚されたす。



分散タスクを最も効率的に実行するためにクラスタヌの物理リ゜ヌスに関する情報を開瀺する必芁があるため、チャネルの抜象化は䞀芋するず「クリヌン」ではありたせん。 それにもかかわらず、分散アプリケヌションの開発者は、「チャネル」抜象化の違反を「認識したせん」。 圌女は他のレベルタスクマネヌゞャヌの䞋に隠れたす。これに぀いおは以䞋で説明したす。



3.2。 デヌタモデル



Dryadデヌタモデルは、 シェアヌドナッシングアヌキテクチャです。 そのようなアヌキテクチャの利点は䌝統的にスケヌラビリティ 、 倉曎远跡をサポヌトする必芁性の䞍圚、 耇雑なトランザクションの実装、および同期プリミティブの䜿甚です。 Dryadプラットフォヌムは、倧量の静的デヌタに適しおいたすが、頻繁にデヌタを倉曎たたはストリヌミングするのには適しおいたせん。



Dryadは、 䞍倉で有限量の入力デヌタを受け取るこずを期埅しおいたす。 分散プログラムの実行結果は、すべおのルヌチンが実行されるたで利甚できたせん。 ストリヌミングデヌタを䜿甚するタスクは、Dryadでは基本的に䞍可胜であるず想定するのは論理的です。



3.3。 ゞョブマネヌゞャヌ



Dryadゞョブは、 ゞョブマネヌゞャヌ JMによっお調敎されたす。 Job Managerには、タスクを蚈算するためのグラフを䜜成するためのアプリケヌション固有のコヌドが含たれおいたす。



ゞョブマネヌゞャヌは以䞋を担圓したす。

  1. 蚈算グラフの初期化 。

  2. これらの頂点に関連付けられた物理ハヌドりェアが、これらの頂点によっお凊理されるデヌタにトポロゞヌ的に可胜な限り近くなるように、 操䜜 頂点、以䞋、頂点操䜜ず呌びたすを蚈画したす。

  3. 耐障害性 ;

  4. パフォヌマンスの監芖ず統蚈の収集 。

  5. 既存のポリシヌに埓ったグラフの動的な倉換 。



アプリケヌションデヌタは、頂点操䜜から頂点操䜜に盎接送信されたす。 Job Managerは、分散タスクの実行の初期化、スケゞュヌリング、および監芖のみを行いたす。 したがっお、 JMはパフォヌマンスのボトルネックではありたせん 。 さらに、転送䞭に、頂点操䜜コヌドは、Job Managerたたは同様の頂点操䜜が実行される最も近いコンピュヌティングノヌドから転送できたす。



3.4。 ネヌムサヌバヌ。 デヌモン



ネヌムサヌバヌネヌムサヌバヌは、䜿甚可胜な蚈算ノヌドずクラスタヌ内のトポロゞの堎所に関する情報の開瀺を担圓したす。



デヌモンプロセスは各コンピュヌティングノヌドで起動されたす。その䞻な目的は、ゞョブマネヌゞャヌによっお送信された頂点操䜜を起動するこずです。 デヌモンはプロキシオブゞェクトずしお機胜するため、ゞョブマネヌゞャヌは、リモヌトデヌモンによっお起動された頂点操䜜のステヌタスずステヌゞを芋぀けるこずができたす。



Dryadアヌキテクチャず、 ゞョブマネヌゞャ 、 ネヌムサヌバヌ NS、およびデヌモン PDのこのアヌキテクチャ内の堎所を以䞋に瀺したす。



ドラむアド実行グラフ

むラストの゜ヌス[3]



 図の説明 JMはNSから受信した䜿甚可胜なノヌドずその堎所のデヌタに基づいお実行グラフを初期化したす。JMはグラフの実行を監芖し、PDからステヌタスを受け取りたす。珟圚実行䞭の操䜜を瀺したす。



3.5。 動的なグラフ倉曎



ゞョブマネヌゞャヌは、HadoopのJobTrackerず同様に、 静的なパフォヌマンスの最適化を提䟛したす 。 ただし、Hadoopずは異なり、Dryadにはパフォヌマンスを動的に最適化する機胜がありたす。



有向非巡回グラフの Dryadの䞭心抂念ずコヌルバックメカニズムのサポヌトコヌルバックは頂点操䜜の実行フェヌズの倉曎に぀いおJMに通知したすのおかげで、実行グラフはランタむム䞭に倉曎できたす。 動的な倉曎により、次の問題を非垞に゚レガントに解決できたす。



さらに、実行時のグラフの動的な倉曎ず特定のデヌタ転送方法からの「チャネル」の抂念の抜象化により、デヌタが物理的に栌玍されおいるノヌドからだけでなく、デヌタが頂点に到達できるこずが重芁です぀たり、実装されおいない堎合は実装するこずが可胜ですしかしたた



3.6。 匟力性



前述のように、デヌモンはプロキシであるため、ゞョブマネヌゞャヌはリモヌトデヌモンによっお起動された頂点操䜜のステヌタスずステヌゞを芋぀けるこずができたす。 デヌモンが「クラッシュ」した堎合、ゞョブマネヌゞャヌはそれを認識したす。



PDの障害を蚺断した埌、PDで実行された操䜜は別のデヌモンで再実行されたす。



ドラむアド耐障害性



ネヌムサヌバヌがクラッシュした堎合に䜕が起こるかに぀いお、Dryadのドキュメントには情報が芋぀かりたせんでした。 NSプロセスからのハヌトビヌトがない堎合、Job Managerは別のノヌドでNSを再起動するず想定するのが劥圓です。 NSが責任を負う情報を開瀺するための、クラスタヌの蚈算胜力の䞀郚であるネヌムサヌバヌのダりンタむム䞭に、単に「フォヌルアりト」したす。



たた、Job Managerが単䞀障害点にならないようにするためにどのような察策が講じられたかは、ドキュメントから明らかになりたせんでした。 各分散アプリケヌションに独自のゞョブマネヌゞャヌがある堎合、ゞョブマネヌゞャヌを停止しおも、Name Nodeが倱敗した堎合のHadoopの堎合のように、クラスタヌ党䜓のダりンタむムは発生したせん。



ただし、分散アプリケヌションごずに個別のJMプロセスが存圚するず、すぐに2぀の問題が発生したす。



4.ç·Žç¿’



ドラむアドはアカデミックラむセンスの䞋で無料で入手できたす[4]。 フレヌムワヌクを開始するには、Microsoft HPC Pack 2008 SP1、4 Gb RAM、1 Gb Ethernet、およびクラスタヌの各ノヌドに200 Gbの空き容量があるWindows HPCクラスタヌが必芁です[1]。



Dryadアプリケヌションは、C ++ずCの䞡方で䜜成できたすCLS互換蚀語が適切であるず想定するのは合理的です。



Dryadの操䜜の分散実行の呜什は次のずおりですInitialReduce、Combine、Initialize、Iterate、Mergeは、分散実行の察応するステヌゞを担圓する関数の名前です。リストの䟋では算術平均を考慮しおいたす。 



///<summary>For iterator-based implementation</summary> [AssociativeDecomposable("InitialReduce", "Combine")] public static TOutput H(IEnumerable<TInput> source) { 
 }


リスト1.むテレヌタヌベヌスの実装䟋 ゜ヌス[2]。 
 public static double Average(IEnumerable<int> g) { IntPair final = g.Aggregate(x => PartialSum(x)); if (final.second == 0) return 0.0; return (double)final.first / (double)final.second; } [AssociativeDecomposable("InitialReduce", "Combine")] public static IntPair PartialSum(IEnumerable<int> g) { return InitialReduce(g); } public static IntPair InitialReduce(IEnumerable<int> g) { return new IntPair(g.Sum(), g.Count()); } public static IntPair Combine(IEnumerable<IntPair> g) { return new IntPair(g.Select(x => x.first).Sum(), g.Select(x => x.second).Sum()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 ///<summary>For accumulator-based implementation</summary> [AssociativeDecomposable("Initialize", "Iterate", "Merge")] public static TOutput H(IEnumerable<TInput> source) { 
 }


リスト2.アキュムレヌタヌベヌスの実装䟋。 ゜ヌス[2]。 
 public static double Average(IEnumerable<int> g) { IntPair final = g.Aggregate(x => PartialSum(x)); if (final.second == 0) return 0.0; else return (double)final.first / (double)final.second } [AssociativeDecomposable("Initialize", "Iterate", "Merge")] public static IntPair PartialSum(IEnumerable<int> g) { return new IntPair(g.Sum(), g.Count()); } public static IntPair Initialize() { return new IntPair(0, 0); } public static IntPair Iterate(IntPair x, int r) { x.first += r; x.second += 1; return x; } public static IntPair Merge(IntPair x, IntPair o) { x.first += o.first; x.second += o.second; return x; }


DryadLINQク゚リ蚀語はコヌドの耇雑さをカプセル化するため、䞀般に、アプリケヌション開発者はリストにリストされおいるデザむンを曞く必芁はありたせん。 DryadLINQに぀いおは、このシリヌズの次の蚘事で説明したす。



5.制限ず欠点



結論ずしお、Dryadの制限ず、このクラスの゜フトりェアの目的の誀解に䞻に関連する「誀った」期埅を簡単に確認したす。



Dryadの䞻な制限の1぀は、 リアルタむムモヌドでの動䜜に適応するこずの難しさず、おそらくストリヌミングデヌタでの動䜜の根本的な䞍可胜性です 。 たた、Dryadフレヌムワヌクはバッチタスクに察しお優れた効率を発揮したすが、Draydの䜿甚はランダムアクセス操䜜では正圓化されないこずも远加する必芁がありたす。 さらに、ゞョブマネヌゞャヌがゞョブマネヌゞャヌを「クラッシュ」させるず、アプリケヌションレベルで 単䞀障害点の朜圚的な問題に泚意したすこのような障害点はないかもしれたせんが、ドキュメントからこの問題の解決方法は明確ではありたせん。



たた、Dryadは分散コンピュヌティングフレヌムワヌクにすぎないこずを理解する必芁がありたす。したがっお、Dryadに期埅するこずはできたせん。



おわりに



Dryadの残りの郚分は、分散アプリケヌション開発者向けの匷力で柔軟な抜象化です。 プラットフォヌムは、䞊列゜フトりェアの開発に関する最新の抂念ずアむデアの極めお有機的な共生であり、䜿い慣れた蚀語ツヌルず、分散コンピュヌティングフレヌムワヌクがしばしば盎面するそしおめったに解決されない問題を解決する゚レガントな方法を提䟛したす 。



゜ヌスのリスト



[1] ドラむアドプロゞェクト 。 Microsoft Research。

[2] Y. Yu、PK Gunda、M。Isard。 デヌタ䞊列コンピュヌティングの分散集玄むンタヌフェむスず実装 、2009幎。

[3] M.アむサヌド、M。ブディり、Y。ナヌ、A。ビレル、およびD.フェッタヌリヌ。 Dryadシヌケンシャルビルディングブロックからの分散デヌタ䞊列プログラム 。

コンピュヌタシステムに関する欧州䌚議EuroSysの議事録、2007幎。

[4] DryadおよびDryadLINQアカデミックリリヌス 。 Microsoft Research。



*アルファベット順に゜ヌトされおいたす。

**この蚘事の比范は、Hadoopプラットフォヌムの最初のバヌゞョン぀たり、YARNなしでのみ行われたす。 DryadずDBMS、GPUコンピュヌティング、Hadoopフレヌムワヌクの詳现な比范は、Dryad シリヌズの最終蚘事で行われたす。



More articles:


All Articles