JP6825103B2

JP6825103B2 - 計算リソース割り振り

Info

Publication number: JP6825103B2
Application number: JP2019528471A
Authority: JP
Inventors: ジャッキーチュクケイチュー; スティーブンジェイ．シュミット; ボーワン
Original assignee: アビニシオテクノロジーエルエルシー
Priority date: 2016-12-08
Filing date: 2017-12-06
Publication date: 2021-02-03
Anticipated expiration: 2037-12-06
Also published as: EP3552104B1; CA3043974C; US20180165129A1; CN110050261A; CN110050261B; EP3552104A1; US20200257556A1; AU2017373882B2; US10445137B2; AU2017373882A1; WO2018106772A1; JP2020502641A; CA3043974A1

Description

関連出願の相互参照
本出願は、２０１６年１２月８日に出願された米国特許出願第６２／４３１，５０５号に対する優先権を主張する。

本明細書は、計算システムにおける計算リソースの割り振りに関する。

計算システム上で動作するアプリケーションは、これを行うために計算システムの計算リソースの一部分を必要とする。したがって、計算システムは、その上で動作するアプリケーションへの計算システムのリソース割り振りを管理しなければならない。アプリケーションに割り振られるリソースのいくつかの例としては、計算システムのメモリの一部分へのアクセス、ファイルデータへのアクセス、および必要とされる量の処理パワーへのアクセスが挙げられる。

分散計算システムにおいては、協働してデータ処理アプリケーションを動作させる１つ以上のクラスタ内に含まれる多数のサーバの間で、計算リソース（データ記憶および処理リソースを含む）が分散している。いくつかの例では、分散計算システムは、計算システム上におけるアプリケーションの実行をスケジュールするとともに、アプリケーションへの計算システムの分散リソースの割り振りも管理する、集中リソースマネージャを用いる。このようなリソースマネージャの１つが「ＨａｄｏｏｐＹＡＲＮ」である。

一般態様１では、計算リソースマネージャから、複数のプログラム部分を有するコンピュータプログラムを計算システム内で実行するための計算リソースを要求するための方法であって、本方法は、プログラム部分のそれぞれのものに関連付けられた計算リソースの目標量を指定する情報を記憶することであって、各プログラム部分は、そのプログラム部分が計算システム内で実行されることを可能にする、計算リソースマネージャによって許可された、許可された計算リソースを用いる、記憶することと、要求を計算することであって、要求は、要求の複数のセットとして計算リソースマネージャへ提出するための、コンピュータプログラムを計算システム内で実行するための計算リソースを求めるものであり、要求の各セットは、要求の初期セットを除いて、要求の複数のセットのうちの以前に提出された１つ以上のセットが、計算リソースマネージャによって複数のプログラム部分による使用のために許可された場合にのみ、計算リソースマネージャによって処理されることになる、計算することと、を含み、計算することは、要求の初期セットを形成すること、および要求の初期セットの後に計算リソースマネージャによる処理のための要求の１つ以上の追加のセットを形成すること、を含み、要求の追加のセットのうちの要求の少なくとも１つのセットが、１つ以上のプログラム部分の最小充足セット内にある複数のプログラム部分のうちの少なくとも１つのプログラム部分のための部分要求を含み、複数のプログラム部分の各プログラム部分が、各プログラム部分の、以前に要求された計算リソースの量を、各プログラム部分の関連目標計算リソース量で除した、それぞれの充足率に関連付けられ、プログラム部分は、その関連充足率が複数のプログラム部分の全てにわたって関連充足率の最小値である場合には、最小充足セットのメンバであり、部分要求は、部分要求が許可された後には、最小充足セット内の各プログラム部分が、部分要求が許可される前の最小充足セット内の１つ以上のプログラム部分の各々についての充足率より大きく、且つ依然として１より小さい充足率を有することになるような量の計算リソースを要求する、方法が提供される。

部分要求が、この部分要求が許可された後には、最小充足セット内の各プログラム部分が、最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率より依然として小さい充足率を有することになるような量以下である量の計算リソースを要求する、態様１に係る態様２。

部分要求が、この部分要求が許可された後には、最小充足セット内の各プログラム部分が、最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率と少なくとも同じ大きさである充足率を有することになるような量以上である量の計算リソースを要求する、態様１または２に係る態様３。

部分要求が、この部分要求が許可された後には、最小充足セット内の各プログラム部分が、最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率と少なくとも同じ大きさである充足率を有することになるような量以上である量の計算リソースを要求する、態様１〜３のうちのいずれか１つに係る態様４。

要求の初期セットがプログラム部分ごとの最小要求を含み、各最小要求は、プログラムの対応する部分を実行するために必要とされる最小量の計算リソースを要求する、態様１〜４のうちのいずれか１つに係る態様５。

プログラム部分のうちの少なくとも１つが計算リソースの固定目標量に関連付けられ、プログラム部分のうちの少なくとも１つが計算リソースの可変目標量に関連付けられ、計算リソースの固定目標量に関連付けられたプログラム部分ごとの最小要求が、計算リソースの完全な目標量に対応する全要求であり、計算リソースの可変目標量に関連付けられたプログラム部分ごとの最小要求が、計算リソースの完全な目標量未満に対応する部分要求である、態様１〜５のうちのいずれか１つに係る態様６。

計算リソースの可変目標量に関連付けられたプログラム部分ごとの最小要求が、計算リソースの単一のユニットに対応する部分要求であり、計算リソースの各可変目標量は、計算リソースの完全な目標量を等しいサイズの複数のユニットに分割する計算リソースの細分性を単位として規定される、態様１〜６のうちのいずれか１つに係る態様７。

要求の少なくとも１つのセット内の少なくともいくつかの要求が、互いに異なるサイズの計算リソースの量に対応する、態様１〜７のうちのいずれか１つに係る態様８。

複数のプログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量を指定する情報を記憶することが、少なくとも１つのプログラム部分について、ユーザ入力に少なくとも部分的に基づいて、少なくとも１つのプログラム部分の、計算リソースの関連目標量を決定することを含む、態様１〜８のうちのいずれか１つに係る態様９。

計算リソースが複数の計算ノードにわたって分散している、態様１〜９のうちのいずれか１つに係る態様１０。

プログラム部分のうちの少なくともいくつかが、それらの許可された計算リソースが複数の計算ノードのうちの特定の１つ以上の計算ノードから得られることを必要とする、態様１〜１０のうちのいずれか１つに係る態様１１。

要求の複数のセットの要求の各セットの各要求に関連付けられた計算リソースが、複数の計算ノードの単一の計算ノードから得られなければならない、態様１〜１１のうちのいずれか１つに係る態様１２。

プログラム部分のうちの少なくともいくつかが、１つ以上のデータソースからのデータ項目を処理するように構成されており、本方法が、１つ以上のデータソースからのデータ項目に少なくとも部分的に基づいてプログラム部分の各々のための計算リソースの目標量を決定することをさらに含む、態様１〜１２のうちのいずれか１つに係る態様１３。

１つ以上のデータソースからのデータ項目に少なくとも部分的に基づいてプログラム部分の各々のための計算リソースの目標量を決定することが、プログラム部分ごとに、プログラム部分の単一のインスタンスに関連付けられた計算リソースを、プログラム部分によって処理されるべきデータ項目ごとのプログラム部分に関連付けられた計算リソースの目標量に加算することを含む、態様１〜１３のうちのいずれか１つに係る態様１４。

要求の複数のセットの要求の各セットの各要求が、複数のプログラム部分のうちの特定のプログラム部分の単一のインスタンスによって必要とされる計算リソースを要求する、態様１〜１４のうちのいずれか１つに係る態様１５。

複数のプログラム部分のうちの第１のプログラム部分が、要求の複数のセットからの複数の要求に関連付けられる、態様１〜１５のうちのいずれか１つに係る態様１６。

要求の初期セットに応答して、要求の初期セットのうちの１つ以上の要求が充足されなかったとの指示を受信し、応答に基づいてプログラムの実行を中止することをさらに含む、態様１〜１６のうちのいずれか１つに係る態様１７。

一般態様１８では、コンピュータ可読媒体は、計算リソースマネージャから、計算システム内で、複数のプログラム部分を有するコンピュータプログラムを実行するための計算リソースを要求するためのソフトウェアを記憶し、ソフトウェアは、計算システムに態様１〜１７のうちのいずれかに係る方法を遂行させるための命令を含む。

一般態様１９では、計算リソースマネージャから、複数のプログラム部分を有するプログラムを計算システム内で実行するための計算リソースを要求するための計算システムであって、この計算システムは、プログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量を指定する情報を記憶するデータ記憶システムと、態様１〜１７のうちのいずれかに係る方法を遂行するように構成された少なくとも１つのプロセッサと、を含む、計算システムが提供される。

上述の態様および後述される条項は以下の利点のうちの１つ以上を含むことができる。

利点の中でもとりわけ、諸態様は、別のプログラム部分の計算リソースが枯渇している間に、データ処理コンポーネントのうちのいずれも、それが必要とするよりも多くの計算リソースを割り振られないよう、計算システムの計算リソースを、データ処理グラフなどのコンピュータプログラムの、データ処理コンポーネントなどのプログラム部分に割り振る。それゆえ、本明細書に記載されている諸技法は、計算システムの他の計算リソースがデータ処理タスクに全面的に従事していないにもかかわらず、データ処理タスクによって過負荷状態になり得る計算システムの計算リソースの機能停止を低減する。それゆえ、これらの技法は、データ処理グラフなどのコンピュータプログラムを実行する計算システムの計算リソースのより効率的な利用に寄与し、ひいては、計算システムの適切な内部機能を向上させ、これを確実にする。本明細書に記載されている諸技法の別の技術的効果は、計算システム上で実行されるデータ処理グラフなどのコンピュータプログラムに対する効果である。例えば、計算システムの計算リソースの全体として釣り合いのとれた割り振りを促進することによって、データ処理グラフなどの、より多数のコンピュータプログラムが並行して実行することができ、および／またはデータ処理グラフなどのコンピュータプログラムの一部が、実行に必要とされる計算システムの必要計算リソースを獲得するために同じほど長く待たなくてもよいおかげで、より早く開始することができる。

本発明の他の特徴および利点は、以下の説明、図、および請求項から明らかになるであろう。

この発明の概要は、発明を実施するための形態においてさらに後述される概念の選択を、単純化された形で伝えるために提供される。この発明の概要は、クレームされている主題の主要な特徴または本質的な特徴を特定することを意図するものではない。

図１は、分散計算リソースの割り振りのためのシステムのブロック図である。図２Ａは、分散計算リソースの割り振りのためのシステムの詳細ブロック図である。図２Ｂは、データ処理グラフの一例の図である。図３は、分散計算リソース割り振りアルゴリズムのフローチャートである。図４は、計算リソース割り振りアルゴリズムの第１ステップの完了後における図２のブロック図である。図５は、計算リソース割り振りアルゴリズムの第２ステップの完了後における図２のブロック図である。図６は、計算リソース割り振りアルゴリズムの第３ステップの間における図２のブロック図である。図７は、計算リソース割り振りアルゴリズムの第５ステップの間における図２のブロック図である。図８は、計算リソース割り振りアルゴリズムの第７ステップの第１の部分の間における図２のブロック図である。図９は、計算リソース割り振りアルゴリズムの第７ステップの第２の部分の間における図２のブロック図である。図１０は、計算リソース割り振りアルゴリズムの第７ステップの第３の部分の間における図２のブロック図である。図１１は、計算リソース割り振りアルゴリズムの第９ステップの１回目の反復の間における図２のブロック図である。図１２は、計算リソース割り振りアルゴリズムの第９ステップの２回目の反復の間における図２のブロック図である。図１３は、計算リソース割り振りアルゴリズムの第９ステップの３回目の反復の間における図２のブロック図である。図１４は、計算リソース割り振りアルゴリズムの第９ステップの４回目の反復の間における図２のブロック図である。図１５は、計算リソースを割り振ることができる、本明細書に記載されている番号付き条項を参照したプロセスフローを示す。

図１は、計算リソース割り振り技法を用いることができる、計算システム１００またはデータ処理システム１００の一例を示す。

システム１００は、種々の形式（例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイル、またはメインフレームによって用いられる固有の形式）のうちの任意のものでデータを各々記憶または提供し得る、記憶デバイス、またはオンラインデータストリームへの接続などの、データの１つ以上のソースを含み得るデータソース１０２を含む。実行環境１０４は、実行モジュール１１２、リソースマネージャ１２０、およびリソース要求モジュール１２２を含む。実行環境１０４は、例えば、ＵＮＩＸオペレーティングシステムのバージョンなどの、好適なオペレーティングシステムの制御を受ける１つ以上の汎用コンピュータ（中央処理装置、ＣＰＵを各々有する）上でホストされ得る。例えば、実行環境１０４は、複数の中央処理装置（ＣＰＵ）またはプロセッサコア、局所的なもの（例えば、対称型マルチプロセッシング（ＳＭＰ）コンピュータなどのマルチプロセッサシステム）、または局所的に分散したもの（例えば、クラスタとして結合された複数のプロセッサ、または超並列処理（ＭＰＰ）システム、あるいは遠隔的なもの、または遠隔的に分散したもの（例えば、ローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）を介して結合された複数のプロセッサ）のいずれか、あるいはそれらの任意の組み合わせを用いたコンピュータシステムの構成上でホストされた、複数ノード並列コンピューティング環境であり得る。

本出願全体を通じて使用するとき、１つ以上のコンピュータプログラム（１つ以上のデータ処理グラフなど）に割り振られる、用語「計算リソース」のいくつかの例は、計算システムのメモリ（一次メモリなど）の一部分へのアクセス、計算システム１００のデータ記憶（ディスク上に記憶されたファイルデータなど）へのアクセス、および計算システム１００の必要とされる量の処理パワーへのアクセス（ＣＰＵへのアクセスなど）のうちの１つ以上を含む。本出願全体を通じて、コンピュータプログラム（データ処理グラフなど）に割り振られる、用語「計算リソース」は、より具体的には、実行環境１０４によってアクセス可能なメモリ（一次メモリなど）の一部分へのアクセス、実行環境１０４によってアクセス可能なデータ記憶（データソース１０２もしくはデータ記憶１１６など）へのアクセス、および実行環境１０４の必要とされる量の処理パワーへのアクセス（実行環境１０４によってアクセス可能なＣＰＵもしくは仮想コアへのアクセスなど）のうちの１つ以上を含むことができる。

データ記憶システム１１６は、実行環境１０４および任意選択的な開発環境１１８がアクセス可能である。開発環境１１８は、本明細書に述べられているデータ処理グラフなどの、コンピュータプログラムを開発するためのシステムである。データ記憶システム１１６は、実行環境１０４に対してローカルにあることができ、例えば、実行環境１０４をホストするコンピュータに接続された記憶媒体（例えば、ハードドライブ）上に記憶されるか、または実行環境１０４に対してリモートにあることができ、例えば、（例えば、クラウド計算インフラストラクチャによって提供される）リモート接続を通じて、実行環境１０４をホストするコンピュータと通信するリモートシステム（例えば、メインフレーム）上でホストされる。

例えば、グラフベースの計算を開発するためのこのような環境が、本明細書において参照により組み込まれる、「ＭａｎａｇｉｎｇＰａｒａｍｅｔｅｒｓｆｏｒＧｒａｐｈ−ＢａｓｅｄＡｐｐｌｉｃａｔｉｏｎｓ」と題する米国特許出願公開第２００７／００１１６６８号明細書により詳細に記載されている。このようなグラフベースの計算を実行するためのシステムが、本明細書において参照により組み込まれる、「ＥＸＥＣＵＴＩＮＧＣＯＭＰＵＴＡＴＩＯＮＳＥＸＰＲＥＳＳＥＤＡＳＧＲＡＰＨＳ」と題する米国特許第５，９６６，０７２号明細書に記載されている。例えば、このシステムに従って作成された、データ処理グラフは、グラフコンポーネントによって表された個々のプロセス内へ情報を入れ、そこから出すための方法、プロセス間で情報を移動させるための方法、およびプロセスのための動作順序を定義するための方法を提供する。このシステムは、任意の利用可能な方法からプロセス間通信方法を選定するアルゴリズムを含み得る（例えば、グラフのリンクに係る通信経路は、ＴＣＰ／ＩＰまたはＵＮＩＸドメインソケットを用いるか、あるいはプロセス間でデータを受け渡すための共有メモリを用いることができる）。

実行モジュール１１２は、リソースマネージャ１２０によって割り振られた計算リソースを用いて、１つ以上のデータ処理グラフ１１４などの、１つ以上のコンピュータプログラム１１４に従ってデータソース１０２からのデータを処理し、データソース１０２内に再び記憶されるか、またはデータ記憶システム１１６内に記憶されるか、あるいは他の仕方で用いられ得る、出力データを生成する。データソース１０２を提供する記憶デバイスは、実行環境１０４に対してローカルにあることができ、例えば、実行環境１０４をホストするコンピュータに接続された記憶媒体（例えば、ハードドライブ１０８）上に記憶されるか、または実行環境１０４に対してリモートにあることができ、例えば、（例えば、クラウド計算インフラストラクチャによって提供される）リモート接続を通じて、実行環境１０４をホストするコンピュータと通信するリモートシステム（例えば、メインフレーム１１０）上でホストされる。実施例によっては、データソース１０２は、場合によってはヌル値を含む、（「属性」または「列」とも呼ばれる）それぞれのフィールドのための値を有するレコードとして編成され得るデータを含む１つ以上の（例えば異なる）形式のデータベースシステムを含む。

リソースマネージャ１２０は、実行環境１０４上における、１つ以上のデータ処理グラフ１１４などの、１つ以上のコンピュータプログラム１１４の実行をスケジュールし、コンピュータプログラムまたはデータ処理グラフ１１４への、計算システムの、またはより具体的には、実行環境の、計算リソースの割り振りを管理する。以下においてより詳細に説明されるように、数値データ処理コンポーネントを含むデータ処理グラフなどの、プログラム部分を含むコンピュータプログラムのために、リソース要求モジュール１２２はリソースマネージャ１２０と対話し、いずれのプログラム部分またはデータ処理コンポーネントも、別のプログラム部分コンポーネントの計算リソースが枯渇している間に、必要とするより多くの計算リソースを割り振られないよう、計算リソースをデータ処理コンポーネントなどのプログラム部分に割り振る。

１つ以上のデータ処理グラフ１１４などの、１つ以上のコンピュータプログラム１１４は、これらの異なる部分（例えば、データ処理グラフのデータ処理コンポーネントなどのプログラム部分）が、実行時における使用のために割り振られるべき計算リソースの特定の（例えば異なる）目標量に関連付けられるような種々の仕方で構成またはプログラムすることができる。目標量は、それぞれのプログラム部分によって、その１つ以上のインスタンスを全て適切に、または完全に実行するために、例えば、それぞれのプログラム部分に関連付けられた、またはそれによって処理されるべき所与の量の入力データを（失敗なく）完全に処理するため、ならびに／あるいは所与の入力データに対して、プログラム部分によって実施され、その入力データに関連付けられた、インスタンスに関連付けられた全てのデータ処理タスクを実行の失敗なく実行するために必要とされる計算リソースの最小必要量に基づいて決定され得る。計算リソースの最小必要量は、インスタンスのプログラム部分が実行されるべき時に、並列に消費されることが必要とされる、プログラム部分に関連付けられたＣＰＵ、仮想コア、および／または一次メモリの部分の最小数であり得る。本出願全体を通じて使用するとき、これらのコンピュータプログラム１１４は、実行時の間に、データソース１０２から受信されたデータなどのデータを処理するデータ処理プログラムであり得る。このようなデータ処理プログラムの一例は、頂点間の有向リンクまたはデータフロー接続（作業要素、すなわち、データのフローを表す）によって接続された頂点（データ処理コンポーネントまたはデータセットを表す）を含む有向グラフによって表すことができる、本出願全体を通じて述べられているとおりのデータ処理グラフ１１４（「データフローグラフ」と呼ぶこともできる）である。図２Ｂに、データ処理グラフ１１４の一例２２５が示されている。図２Ｂにおいて、データ処理コンポーネントはＣ１〜Ｃ５（２２６、２２８、２３０、２３２および２３４とも標識される）である。リンクまたはデータフロー接続は、図２Ｂにおいて、２２６ａ、２２８ａ、２２８ｂ、２３０ａおよび２３２ａと標識されている。本出願全体を通じて説明されるとおりのコンピュータプログラムのプログラム部分はまた、プログラム部分の間のデータのフローを提供するデータフロー接続によって接続することもできる。データ処理コンポーネントもしくはプログラム部分の数、およびリンクもしくはデータフロー接続の数は本出願において例示目的のためにのみ選定されており、各々、任意の他の数であることができる。これらのリンクまたはデータフロー接続に加えて、一部のデータ処理グラフは、データ処理コンポーネントの間のデータフローの決定および／または調整のための制御フロー接続も有し得る。本出願全体を通じて説明されるデータ処理グラフにおいて、データ処理コンポーネントはプログラム部分であることができ、それらのリンクまたはデータフロー接続に従って相互に関連し合う、または相互に依存し合うことができる。データ処理コンポーネントは、実行されるためにコンピューティングリソースを別個に許可され得る。コンピュータプログラムの他の例では、プログラム部分は、実行されるためにコンピューティングリソースを別個に許可されるコンピュータプログラム内のサブモジュールまたは他のデータ処理エンティティである。本出願全体を通じて説明するとき、データ処理コンポーネントなどのプログラム部分は、データ処理グラフなどの、それらが属するコンピュータプログラム全体が実行される能力が、個々のプログラム部分が実行される能力に依存する範囲で、「相互に関連し合う、または相互に依存し合う」と考えられる。一例では、プログラム部分のうちの１つが実行することができない場合には、それらが属するコンピュータプログラム全体が実行することができない。このような相互に関連し合う、または相互に依存し合うプログラム部分はまた、実行のために互いに依存し得る。例えば、１つのプログラム部分は別のプログラム部分からデータを受信し、そこへデータを提供し得る。また、データ処理コンポーネントなどのプログラム部分が計算システムのコンピューティングリソースを別個に許可されるが、それらは、一部共通するか、相互に関連し合うか、または様々な他の仕方で相互に依存し合ってもよい（例えば、限られた供給量のコンピューティングリソースを競合する）。本出願全体を通じて使用するとき、用語「プログラム部分」（または「データ処理コンポーネント」）は、１個のソフトウェアコード（「プログラミングコード」とも呼ばれる）であり得、コンピュータプログラム（またはデータフローグラフ）はそのプログラム部分（またはデータ処理コンポーネント）によって形成され得る。

図２Ａを参照すると、図１と関連して上述された計算システム１００／データ処理システム１００のより具体的な表現は、実行環境１０４、データソース１０２、および実行環境１０４の計算リソースを用いてデータソース１０２からのデータを処理するためのコンピュータプログラムもしくはデータ処理グラフ２２４を含む。

実行環境１０４は、リソース要求モジュール１２２、リソースマネージャ１２０、および実行モジュール１１２を含む。特徴の中でもとりわけ、実行モジュール１１２は、複数のホスト（例えば、サーバなどの計算クラスタ）にわたって分散し、および／または複数のホストに割り振られ得る計算リソースを含む。図２Ａでは、３つのホスト、第１のホストＨ１２３６、第２のホストＨ２２３８、および第３のホストＨ３２４０が存在する。各ホストは、総合すれば実行モジュール１１２の総計算リソースを含む有限の量または数の計算リソースを含む。リソースマネージャ１２０によって管理され、割り振られる計算リソースの例は、ホストのプロセッサの使用占有率（例えば、１つ以上のマルチコアプロセッサの物理コアに対応する仮想コアとして指定される）、ホストの揮発性メモリの部分（例えば、ホストの主メモリ空間の指定された量）、ホストの不揮発性メモリの部分（例えば、ホストのハードディスクドライブ記憶空間の量として指定される）、または通信チャネルの使用占有率（例えば、ホストのＥｔｈｅｒｎｅｔインターフェースの帯域幅の割合）のうちの任意のものを含み得る。計算リソースの単一のユニット２３７は、指定数のＣＰＵまたは仮想コア、ならびに指定量の主／一次メモリ、または指定数の（仮想）主／一次メモリ部分などの、複数の種類の計算リソースのうちの１つ以上を含み得る。ＣＰＵはプロセッサであり得る。

図２Ａでは、本明細書に記載される計算リソース割り振りアプローチの説明を簡単にするために、ホストの計算リソースの全部が、全て同じ細分性（すなわち、許可され得る最も小さいサイズ）を有するように示される、１つ以上の計算リソースユニット２３７（図２Ａにおけるホスト内の正方形として示される）によって形成されている。しかし、計算リソースは必ずしも、固定された等しい細分性を有するユニット２３７にセグメント化されるとは限らず、その代わりに、様々な細分性のユニットにセグメント化されるか、または他の代替的なアプローチを用いて分割することができることに留意されたい。さらに、本明細書に記載される計算リソース割り振りアプローチの説明を簡単にするために、図２Ａの実行モジュール１１２内のホストは全て、同じ数（すなわち、１６個）の計算リソースユニット２３７を有するように示されている。しかし、一般的に、異なるホストは、例えば、異なる数の計算リソースユニット２３７を有することによって、異なる量の計算リソースを有し得ることに留意されたい。

リソースマネージャ１２０は計算リソースの要求を受信し、実行モジュール１１２のホスト２３６、２３８、２４０内の利用可能な計算リソースの量に基づいて要求を許可または拒否する。このようなリソースマネージャ１２０の一例としては、コンピュータプログラム（またはプログラム部分）を実行するための計算リソースの要求を受信する能力を有し、十分な計算リソースが利用可能である場合には、計算リソースの何らかの数のユニットを有する「コンテナ」、例えば、プログラム部分のインスタンスごとに１つのコンテナをコンピュータプログラムによる使用のために許可する、「ＨａｄｏｏｐＹＡＲＮ」リソースマネージャが挙げられる。コンテナは、特定の量の計算リソースを包含するか、または特定の量の計算リソースを特定する任意の情報を包含するか、あるいはこれらの任意の組み合わせのための任意の好適なデータ構造として実現することができる。このとき、コンピュータプログラムは、許可されたコンテナ内の計算リソースを用いて実行し得る。実施例によっては、コンピュータプログラムは、計算リソースの複数のコンテナ（例えば、プログラムの一部分の並行インスタンス２３９を動作させるため、またはプログラムの複数の部分を動作させるための多数のコンテナ）をリソースマネージャ１２０から一度に要求することができる。リソースマネージャ１２０が、要求された複数のコンテナの全てをコンピュータプログラムに許可するために十分なリソースが利用可能である場合には、リソースマネージャ１２０はこれを行うことになる。さもなければ、利用可能なリソースに基づき、リソースマネージャ１２０は、要求されたコンテナのうちの一部のみ（すなわち、要求されたコンテナの総数未満の整数個のコンテナ）を許可し得るか、またはリソースマネージャ１２０は、要求されたコンテナを全く許可し得ない。実装形態によっては、所与のコンテナに関連付けられた計算リソースの全てが単一のホストから得られる。代替的に、他の実装形態では、所与のコンテナのリソースは複数のホストから得られ得る。

以下においてより詳細に説明されるように、リソース要求モジュール１２２は、データ処理グラフ２２４などの、コンピュータプログラムによって課された制約が満足されること、および／またはより釣り合いのとれた様態で満足されることを確実にする仕方でリソースマネージャ１２０と対話する。

データ処理グラフ２２４は、データソース１０２から受信されたデータを処理するためのコンピュータプログラムの一仕様または一例である。図２Ｂは、第１のデータ処理コンポーネントＣ１２２６、第２のデータ処理コンポーネントＣ２２２８、第３のデータ処理コンポーネントＣ３２３０、第４のデータ処理コンポーネントＣ４２３２、および第５のデータ処理コンポーネントＣ５２３４を含む多数の（例えば、相互に関連し合う、または相互に依存し合う）データ処理コンポーネントを含む、データ処理グラフ２２４のグラフベースの仕様の一例２２５を示す。

概して、本出願全体を通じて説明されるデータ処理グラフの各データ処理コンポーネントは１つ以上の制約に関連付けられ得る。このような制約は、データ処理コンポーネントのインスタンス２３９の並列化に関連する制約を指定する「レイアウト」であり得る。レイアウトにおいて指定される制約の１つは、静的（Ｓ）レイアウト型、固定深さ動的レイアウト（ＦＤＬ）型、および可変深さ動的レイアウト（ＶＤＬ）型を含む多数の値のうちの１つを取ることができる「レイアウト型」であり得る。異なるレイアウト型などの、１つ以上の制約は、データ処理コンポーネントの実行の間に並列に実行可能である、または実行されるべきデータ処理コンポーネントのコンポーネントインスタンスの目標数、および／またはそれらの実行場所を指定し得る。データ処理コンポーネントごとに、コンポーネントインスタンスの目標数は、データ処理コンポーネントによって処理されるべきデータ要素の関連付けられた数に基づいて決定され得る。

それはまた、レイアウトなどのこれらの制約が、目標数のコンポーネントインスタンスが実行されるべきである時に並列に消費されることが要求される計算リソースの目標量（例えば、仮想コア、または一次メモリの量）を直接決定することも意味する。換言すれば、これらのコンポーネントインスタンスの各々が計算リソースを消費することになり、これにより、特定のレイアウトを有するデータ処理コンポーネントのために必要とされる計算リソースの目標量は、そのコンポーネントのためのコンポーネントインスタンスの対応する目標数によって直接決定されるか、またはそれと相関する。本出願全体を通じて使用するとき、特定のデータ処理コンポーネントなどの特定のプログラム部分のための用語「計算リソースの目標量」は、プログラム部分のインスタンスの目標数と、プログラム部分のインスタンスの各々によって必要とされる計算リソースの量との積に等しくなり得る。

ごく一般的に言えば、本出願全体を通じて説明されるデータ処理コンポーネントのうちの１つが静的レイアウト型を有する場合には、このとき、このデータ処理コンポーネントは、データ処理グラフ２２４がうまく動作するよう（例えば、関連付けられたデータ処理タスクの全てを失敗なく実行するよう）実行モジュール１１２上で実行するために必要とされるコンポーネントインスタンス２３９の既定の固定目標数を有する。静的レイアウト型を有するデータ処理コンポーネントはまた、実行モジュール１１２の１つ以上のホスト２３６、２３８、２４０の既定のセット上でそのコンポーネントインスタンス２３９を実行することを必要とされる。

静的レイアウト型の潜在的利点は計算の局所性である。局所性とは、データ処理コンポーネントのための特定の計算リソース（例えば、インスタンスが実行することになるホストのコア）を他の計算リソース（例えば、インスタンスのためのデータが記憶されるホストのメモリ）と同じホスト上に位置付ける能力を指す。動的レイアウト型（ＦＤＬまたはＶＤＬ）は、インスタンスを、そのインスタンスによって操作されるべきデータを記憶するホストとは異なるホスト上で実行するように割り当てることができる。これは、柔軟性の増大をもたらし得るが、それは、局所性の低下をトレードオフすることによってのみもたらされる。しかし、局所性が特定の計算にとって重要でない場合には、このトレードオフは価値のあるものになり得る。

本出願全体を通じて説明されるデータ処理コンポーネントのうちの１つがＦＤＬ型を有する場合には、このとき、このデータ処理コンポーネントは、データ処理グラフ２２４がうまく動作するよう（例えば、関連付けられたデータ処理タスクの全てを失敗なく実行するよう）実行モジュール１１２上で実行するために必要とされるコンポーネントインスタンス２３９の既定の固定目標数を有する。ＦＤＬ型を有するデータ処理コンポーネントのコンポーネントインスタンスがどこで（すなわち、実行モジュール１１２のどのホスト２３６、２３８、２４０上で）実行するのかに関する制限はない。

本出願全体を通じて説明されるデータ処理コンポーネントのうちの１つがＶＤＬ型を有する場合には、このとき、このデータ処理コンポーネントは、コンポーネントインスタンス２３９の動的に決定される目標数（実行時に決定され得る）を有し、データ処理グラフ２２４がうまく動作するために（例えば、関連付けられたデータ処理タスクの全てを失敗なく実行するために）、実行モジュール１１２上における少なくとも１つのコンポーネントインスタンスの実行が必要とされる。ＶＤＬ型を有するデータ処理コンポーネントのコンポーネントインスタンスがどこで（すなわち、実行モジュール１１２のどのホスト２３６、２３８、２４０上で）実行するのかに関する制限はない。

動的レイアウト型（ＦＤＬまたはＶＤＬ）の潜在的利点は、たとえ、特定の（例えば、ローカルの）ホスト２３６、２３８、２４０上で利用可能な計算リソースが存在しない場合でも、クラスタ内のいずれかのホスト２３６、２３８、２４０上で利用可能な計算リソースが存在する限り、計算が開始可能であるという柔軟性である。別の潜在的利点は、１つ以上のホスト２３６、２３８、２４０の障害のために計算が失敗した場合には、ホスト２３６、２３８、２４０の異なるセット上で計算が再開可能であることである。

ＦＤＬ型を上回るＶＤＬ型の潜在的利点は、たとえ、所望どおりの大きさの量の計算リソースが存在しない場合でも、計算が依然として開始可能であることである。ＶＤＬ型を上回るＦＤＬ型の潜在的利点は、より高い並列度の要求が充足されるのを待つことによって生じるであろう起動時間遅延を抑制するために、並列度（すなわち、コンポーネントインスタンスの数）を固定する能力である。

図２Ａおよび図２Ｂの例示的なデータ処理グラフ２２４、２２５では、例示的な第１のコンポーネント２２６は静的レイアウト型を有し、（同じ、または異なる計算リソースユニット２３７内で実行される）２つのコンポーネントインスタンス２３９を実行モジュール１１２の第１のホスト２３６上で実行することを必要とされる。第２のコンポーネント２２８は模範的にＦＤＬ型を有し、コンポーネントインスタンスがどこで（すなわち、実行モジュール１１２のどのホスト２３６、２３８、２４０上で）動作させられるのかに関して制限なく、３つのコンポーネントインスタンス２３９を実行モジュール１１２上で動作させることを必要とされる。第３のコンポーネント２３０、第４のコンポーネント２３２、および第５のコンポーネント２３４は模範的に全てＶＤＬ型を有し、したがって、データ処理グラフが実行するために単一のコンポーネントインスタンスを実行モジュール１１２上で実行することを必要とされるのみであるが、十分な計算リソースが実行モジュール１１２上で利用可能である場合には、追加のコンポーネントインスタンスが実行され得る。第３のコンポーネント２３０、第４のコンポーネント２３２、および第５のコンポーネント２３４のコンポーネントインスタンスがどこで（すなわち、実行モジュール１１２のどのホスト２３６、２３８、２４０上で）実行するのかに関する制限はない。

データ処理グラフ２２４、２２５内のデータ処理コンポーネント２２６、２２８、２３０、２３２、２３４の各々は、データソース１０２内のデータセットからのデータ要素（例えば、ブロック、ファイル、またはレコード）などの、データソース１０２からのデータを処理するように構成されている。実施例によっては、ブロックは、１つ以上のレコードを含むファイル内のデータの部分である。図２Ａでは、第１のコンポーネント２２６は第１のデータセット２４２からの第１のデータ要素２５２を処理し、第２のコンポーネントＣ２２２８は第２のデータセット２４４からの第２のデータ要素２５４を処理し、第３のコンポーネントＣ３２３０は第３のデータセット２４６からの第３のデータ要素２５６を処理し、第４のコンポーネントＣ４２３２は第４のデータセット２４８からの第４のデータ要素２５８を処理し、第５のコンポーネントＣ５２３４は第５のデータセット２５０からの第５のデータ要素２６０を処理する。後述される一実施例では、システム１００の一部分（例えば、リソース要求モジュール１２２）が、各コンポーネントに関連付けられたデータセットを分析し、データ要素の数に基づき、異なるコンポーネントのためのインスタンスの目標数、ひいては計算リソースの目標量を決定する。しかし、他の実施例では、計算リソースの目標量は、関連付けられたデータセット内のデータの量に基づくのみでなく、その代わりに（またはさらに）、明示的もしくは暗黙的なユーザの要請、履歴的な、もしくは推定された性能データ、またはこれらの組み合わせなどの、他の因子にも依存し得る。各データ処理コンポーネント２２６、２２８、２３０、２３２、２３４が異なるデータセットに関連付けられるという要件はないことに留意されたい。例えば、複数のデータ処理コンポーネント２２６、２２８、２３０、２３２、２３４が全て、同じデータセットのうちの１つ以上からのデータを処理してもよい。

換言すれば、ならびに図１および図２Ａに関連して上述された計算システム１００を総括すれば、計算システム１００は、データの１つ以上のソースを含むデータソース１０２と、実行モジュール１１２、リソースマネージャ１２０、およびリソース要求モジュール１２２を含む実行環境１０４であって、実行環境１０４は１つ以上のコンピュータ上でホストされ、実行モジュール１１２は、リソースマネージャ１２０によって１つ以上のコンピュータプログラム１１４に割り振られた実行環境１０４の計算リソースを用いて、１つ以上のデータ処理グラフ２２４などの、１つ以上のコンピュータプログラム１１４に従ってデータソース１０２からのデータを処理し、出力データを生成するように構成されており、コンピュータプログラム１１４は、データソース１０２から複数のプログラム部分を通って流れるデータに対して遂行されるデータ処理タスクを実施し、出力データを生成する、データ処理グラフ２２４の複数の（例えば、相互に関連し合う、もしくは相互に依存し合う）データ処理コンポーネント２２６、２２８、２３０、２３２、２３４などの、複数の（例えば、相互に関連し合う、もしくは相互に依存し合う）プログラム部分を含む、実行環境１０４と、実行環境１０４がアクセス可能であるデータ記憶１１６であって、コンピュータプログラム１１４およびその複数のプログラム部分は、データ記憶１１６内に記憶されたプログラミングコードおよび／またはデータ構造によって指定される、データ記憶１１６と、を備え、複数のプログラム部分は、プログラム部分の間の、リンク２２６ａ、２２８ａ、２２８ｂ、２３０ａ、２３２ａなどの、データフローのための１つ以上のデータフロー接続によって接続され、データフロー接続はプログラミングコードおよび／またはデータ構造によって指定され、実行モジュール１１２は、記憶されたプログラミングコードおよび／またはデータ構造を読み込むように構成されており、リソースマネージャ１２０は、リソース要求モジュール１２２からの計算リソースの要求を受信し、実行環境１０４内で利用可能な計算リソースの量に基づき、受信された要求を許可または拒否するように構成されており、任意選択的に、リソースマネージャ１２０は、実行モジュール１１２による１つ以上のコンピュータプログラム１１４の実行をスケジュールし、監視するようにさらに構成されており、リソースマネージャ１２０は、要求され、許可された要求に関連付けられた、実行環境の計算リソースを複数のプログラム部分に割り振るようにさらに構成されており、リソース要求モジュール１２２およびリソースマネージャ１２０は、本出願に記載の方法のうちのいずれか１つが実行されるよう、例えば、複数のプログラム部分の各プログラム部分が、データソース１０２からのデータの一部分に対して実行の失敗なく実行され、出力データを生成する、プログラム部分のインスタンスを有するよう、複数のプログラム部分によって実装される全てのデータ処理タスクが、データソース１０２からのデータに対して実行の失敗なく実行され、出力データを生成されるよう、またはコンピュータプログラムによって処理されるべきデータソース１０２からの所与の量のデータが、コンピュータプログラムによって（例えば、実行の失敗なく）完全に処理され、出力データを生成されるよう、互いに対話するように構成されている。

本出願全体を通じて本明細書において使用するとき、データ処理コンポーネントの「コンポーネントインスタンス」、またはより一般的には、プログラム部分の「インスタンス」は、一次メモリの一部分内にあるなど、計算リソースを現在消費している、データ処理コンポーネントまたはプログラム部分の実行可能なコピーである。

１リソース割り振り
データ処理グラフ２２４内のコンポーネントに関連付けられたレイアウト制約を考慮すると、第１のデータ処理コンポーネント２２６の２つのコンポーネントインスタンスが実行モジュール１１２の第１のホスト２３６上で実行され、第２のデータ処理コンポーネント２２８の３つのコンポーネントインスタンスが実行モジュール１１２上で実行され、第３のデータ処理コンポーネント２３０、第４のデータ処理コンポーネント２３２、および第５のデータ処理コンポーネント２３４の各々の少なくとも１つのコンポーネントインスタンスが実行モジュール１１２上で実行された場合にのみ、例示的なデータ処理グラフ２２４はうまく動作するか、または少しでも動作することができる。データ処理グラフの動作の成功は、全てのコンポーネントインスタンスが、データソース１０２からのデータに対して実行の失敗なく実行され、出力データを生成することで特徴付けることができる。

リソース要求モジュール１２２が、データ処理グラフ２２４のデータ処理コンポーネントの総数のコンポーネントインスタンスによって必要とされる計算リソース、および実行モジュール１１２内で利用可能な計算リソースの知識を有する場合には、このとき、リソースマネージャ１２０を介してデータ処理グラフ２２４のための計算リソースを割り振るタスクは、パッキング最適化問題に対する解を用いて遂行することができるであろう。

しかし、一般的には、リソース要求モジュール１２２が、実行モジュール１１２内で利用可能な計算リソースの知識を有するとは限らない。その代わりに、リソース要求モジュール１２２はリソースマネージャ１２０から計算リソースを要求し、要求された計算リソースが許可されるかどうか分かるのを待つ。実行モジュール１１２内で利用可能な計算リソースの知識がないため、リソース要求モジュール１２２がデータ処理グラフ２２４の特定のＶＤＬ型データ処理コンポーネントのリソース要件を過剰に割り振り、そうすることで、任意の計算リソースがデータ処理グラフ２２４の他のＶＤＬ型データ処理コンポーネントに割り振られる前に、実行モジュール１１２内で利用可能な計算リソースを使い果たすか（すなわち、枯渇）、または過少に割り振られたデータ処理コンポーネントによるボトルネックを生み出すことによって、過剰に割り振られたデータ処理コンポーネントの計算リソースを無駄にすることになる（すなわち、釣り合いを欠いた実行）可能性がある。

１．１計算リソースの枯渇
例えば、計算リソースをデータ処理グラフ２２４のために割り振ることへの１つのアプローチでは、リソース要求モジュール１２２はまず、第１の静的レイアウト型コンポーネント２２６および第２のＦＤＬ型コンポーネント２２８のために必要とされるコンピューティングリソースを要求する。本例では、リソースマネージャ１２０は、第１のコンポーネント２２６および第２のコンポーネント２２８のために必要とされる計算リソースを割り振ることができる。

次に、リソース要求モジュール１２２は、（第３のコンポーネント２３０の必要とされる単一のインスタンスを実行モジュール１１２上で実行するのに足る計算リソースのみを要求するのではなく）第３のＶＤＬ型コンポーネント２３０の目標数のインスタンス（４つのインスタンス）を実行モジュール１１２上で実行するための計算リソースを要求する。リソースマネージャ１２０は、要求された計算リソースを第３のコンポーネント２３０の４つのインスタンスのために割り振ることができる。次に、リソース要求モジュール１２２は、第４のコンポーネント２３２の単一のインスタンスを実行するために必要とされる計算リソース要求する。本例では、リソースマネージャ１２０は、第４のコンポーネント２３２の単一のインスタンスを実行モジュール１１２上で実行するために必要とされる計算リソースを割り振るためのリソースが十分にないことを指示する。

上述の例では、目標計算リソースを第３のコンポーネント２３０のために過剰に割り振ることによって、リソース要求モジュール１２２は、データ処理グラフ２２４の第４のコンポーネント２３２および第５のコンポーネント２３４の任意の計算リソースを本質的に枯渇させている。その結果、第４のコンポーネント２３２および第５のコンポーネント２３４は、単一のコンポーネントインスタンスさえも実行モジュール１１２上で実行することができない。データ処理グラフ２２４は、うまく動作するために、計算システム１１２上におけるデータ処理グラフ２２４のＶＤＬ型コンポーネントの全ての少なくとも１つのインスタンスの実行を必要とするため、データ処理グラフはうまく動作することができない。それに対して、仮に第３のコンポーネント２３０が単一のインスタンスのための計算リソースのみを割り振られていれば、第４のコンポーネント２３２および第５のコンポーネント２３４の各々の単一のインスタンスのために十分なものが存在したであろう。この意味で、第３のコンポーネント２３０は計算リソースを過剰に割り振られていた。

１．２計算リソース要求アルゴリズム
図３を参照すると、リソース要求アルゴリズムが、リソース要求モジュール１２２によるなど、計算システム１００によって実装されており、以下において、コンピュータプログラムの一例としてデータ処理グラフのために、およびプログラム部分の例としてデータ処理コンポーネントのために説明される。アルゴリズムはデータ処理コンポーネントの上述の枯渇を回避し、計算リソースを釣り合いのとれた様態でＶＤＬ型コンポーネントに公平且つ適切に割り振る。アルゴリズムは、データ処理グラフ２２４のデータ処理コンポーネント３６２およびデータソース１０２からのデータセット３６４を入力として受け入れ、入力を処理し、計算リソースをＶＤＬ型コンポーネント２３０、２３２、２３４に公平且つ適切に割り振り、ＶＤＬ型コンポーネント２３０、２３２、２３４の計算リソースを枯渇させることを回避することを含む、データセット３６４からのデータの処理のために、計算リソースをデータ処理コンポーネント３６２に割り振る。第１ステップ３７０に先立つ１つ以上の前処理ステップがアルゴリズム内に任意選択的に含まれてもよく、（例えば、データ処理コンポーネントの各々に関連付けられたメタデータに基づき）データ処理グラフ２２４の受け入れられたデータ処理コンポーネント３６２内の任意の静的、ＦＤＬおよびＶＤＬデータ処理コンポーネントを特定することを含み得る。

第１ステップ３７０において、データ処理コンポーネント３６２の各々を分析し、データ処理コンポーネントのコンポーネントインスタンスを実行モジュール１１２上で実行するために必要とされる計算リソース３７２の量を決定する。すなわち、データ処理コンポーネント３６２の各々を分析し、データ処理コンポーネントの１つのコンポーネントインスタンス２３９の（全）実行のために、プログラミングコードによって必要とされる計算リソース３７２の量、および／またはデータ処理コンポーネントを規定するデータ構造を決定する。静的レイアウト型データ処理コンポーネントごと、およびＦＤＬ型データ処理コンポーネントごとに、データ処理コンポーネントの実行の間に実行されるべき、または実行可能な、コンポーネントインスタンスの目標数を決定することができ、これにより、これらのデータ処理コンポーネントの各々の実行のために必要とされる計算リソースの目標量が得られる。第２ステップ３６６において、ＶＤＬ型データ処理コンポーネント（例えば、図２Ａ、図２Ｂにおけるデータ処理コンポーネント２３０、２３２、２３４）ごとに、データ処理コンポーネントに関連付けられた、またはそれによって処理されるべき、データセットのデータの量またはデータ項目の数を用いて、データ処理コンポーネントに関連付けられた、またはそれによって必要とされる、コンポーネントインスタンス２３９、３６８（時としてと「プライ（ｐｌｙ）」呼ばれる）の目標数を決定し、データ処理コンポーネントの実行の間に実行されるべき、または実行可能であるコンポーネントインスタンスの目標数を決定することができ、これにより、これらのデータ処理コンポーネントの各々の実行のために必要とされる計算リソースの目標量が得られる。実施例によっては、インスタンス３６８の目標数は、コンポーネントに関連付けられたデータセットのデータ項目の数と同じである。

第３ステップ３７４において、データ処理コンポーネント３６２の中の各静的レイアウト型コンポーネント２２６の必要とされるコンポーネントインスタンスごとに、リソース要求モジュール１２２は、リソースマネージャ１２０からコンポーネントインスタンスのために必要とされるホストＨ１〜Ｈ３からの必要とされる計算リソースを含む「コンテナ」を要求する。要求が成功するか、または充足された場合には、リソースマネージャ１２０は、必要とされる計算リソースを含むコンテナをもって要求の各々に応答する。第４ステップ３７６において、第３ステップ３７４においてリソースマネージャ１２０に送信された要求のうちのいずれかが充足されない場合には（例えば、リソースマネージャ１２０が所定の期間以内に応答しない場合には）、データ処理グラフ２２４を実行するために実行モジュール１１２内で利用可能なリソースが十分に存在しないため、アルゴリズムは中止する。すなわち、要求のうちのいずれかが充足されない場合には、このとき、データ処理グラフは動作することができない。第３ステップ３７４においてリソースマネージャ１２０に送信された要求の全てが充足された場合には、アルゴリズムは第５ステップ３７８へ進む。

第５ステップ３７８において、データ処理コンポーネント３６２の中の各ＦＤＬ型コンポーネント２２８の必要とされるコンポーネントインスタンスごとに、リソース要求モジュール１２２は、リソースマネージャ１２０からコンポーネントインスタンスのために必要とされる計算リソースを含むコンテナを要求する。上記のように、ＦＤＬ型コンポーネントは、実行モジュール１１２のホストのうちの任意のものからの計算リソースを用いて実行することができる。第６ステップ３８０において、第５ステップ３７８においてリソースマネージャ１２０に送信された要求のうちのいずれかが充足されない場合には、データ処理グラフ２２４を実行するために実行モジュール１１２内で利用可能な計算リソースが十分に存在しないため、アルゴリズムは中止する。すなわち、要求のうちのいずれかが充足されない場合には、このとき、データ処理グラフは動作することができない。第５ステップ３７８においてリソースマネージャ１２０に送信された要求の全てが充足された場合には、アルゴリズムは第７ステップ３８２へ進む。

第７ステップ３８２において、データ処理コンポーネント３６２の中のＶＤＬ型コンポーネント２３０、２３２、２３４ごとに、リソース要求モジュール１２２は、リソースマネージャ１２０からコンポーネントの単一のコンポーネントインスタンスのために必要とされる計算リソースを含むコンテナを要求する。第８ステップ３８４において、第７ステップ３８２においてリソースマネージャ１２０に送信された要求のうちのいずれかが充足されない場合には、データ処理グラフ２２４を実行するために実行モジュール１１２内で利用可能な計算リソースが十分に存在しないため、アルゴリズムは中止する。第７ステップ３８２においてリソースマネージャ１２０に送信された要求の全てが充足された場合には、データ処理グラフ２２４が実行することができることを確実にするために十分な計算リソースが割り振られる。具体的には、第７ステップ３８２がうまく完了すると、アルゴリズムは、あらゆる静的レイアウト型コンポーネントおよびあらゆるＦＤＬ型コンポーネントのために必要とされる計算リソースが割り振られ、少なくともいくつかの計算リソースがＶＤＬ型コンポーネントの各々に割り振られることを確実にした。次に、アルゴリズムは第９ステップ３８６へ進む。

第９ステップ３８６において、データ処理コンポーネント３６２の中のＶＤＬ型コンポーネント２３０、２３２、２３４の全てをそれらの充足率に従ってランク付ける。ここで、用語「充足率」は、それぞれのコンポーネントに割り振られた計算リソースのそれぞれのコンポーネントの目標量の割合である。具体的には、充足率は、以前に要求された（および許可されたと仮定された）計算リソースの量「＃許可」を計算リソースのその関連目標量「＃目標」で除したものである。例えば、ＶＤＬ型コンポーネントが、それ自体では１０個のコンポーネントインスタンスを動作させるよう設定された目標を有し、２つのコンポーネントインスタンスが以前に要求された（および許可された）場合には、そのコンポーネントは２０パーセント充足されている、すなわち、２０パーセントの充足率を有する。本例では、特定のコンポーネントの各インスタンスは、（コンテナの数として指定された）同じ量の計算リソースを必要とすると想定されているが、他の例では、同じコンポーネントの異なるインスタンスは異なる量の計算リソースを必要とし得ることに留意されたい。このとき、許可されたコンテナの数が、実行時に実行することができるコンポーネントインスタンスの数を決定する。

ＶＤＬ型コンポーネントがそれらの充足率に従ってランク付けられると、最小充足ＶＤＬ型コンポーネント（コンポーネントＡと呼ばれる）および２番目の最小充足コンポーネント（コンポーネントＢと呼ばれる）が特定される。最小充足コンポーネントの特定における同順位については、以下のことを最小充足コンポーネントの各々のために遂行することができる。２番目の最小充足コンポーネントの特定における同順位は、その充足率のみが用いられることになるため、問題とならない。最小充足コンポーネントのために、リソース要求モジュール１２２は、許可された場合には、その「部分要求」の結果、最小充足コンポーネントが第２の最小充足コンポーネントよりも充足されるであろう、最小充足コンポーネントのための数Ｎ個のコンテナのために、１つ以上のコンテナを要求する。実施例によっては、Ｎは次式に従って決定される：

全てのコンポーネントが完全に充足されたために（すなわち、１の充足率）、同順位が生じた場合には、このとき、アルゴリズムは完了する。

第１０ステップ３８８において、第９ステップ３８６においてリソースマネージャ１２０によって要求されたコンテナのうちのいずれかが充足されない場合には、アルゴリズムは完了する。第９ステップ３８６においてリソースマネージャ１２０によって要求されたコンテナの全てが充足された場合には、アルゴリズムは第９ステップ３８６へループして戻る。データ処理コンポーネント３６２の全てが完全に充足される、すなわち、１００％の充足率を有するか、またはＶＤＬ型コンポーネントのうちのいずれかのためのコンテナの要求が充足されなくなるまで、第９ステップ３８６および第１０ステップ３８８は繰り返し動作する。

他の例示的な実装形態では、リソース要求アルゴリズムのステップのうちのいくつかを異なる順序で遂行することができるか、またはいくつかのステップを無くすことができる。例えば、ステップ３７４、３７８、および３８２の要求は、異なる順序で遂行するか、または単一の要求に組み合わせることができる。

例示的な実装形態によっては、上述のアルゴリズムは、要求のうちのいずれかがリソースマネージャ１２０に送信される前に、コンテナの要求の全てを定式化する。定式化されると、要求の全ては、例えば全て一度に、まとめて送信され、リソースマネージャ１２０によって、上述のアルゴリズムを用いて要求が送信されたであろう順序に従って順番に処理される。例えば、要求は、優先順位に関連付けられるか、または、優先順位を指定する優先順位タグ（例えば、第１次優先順位、第２次優先順位および第３次優先順位などを指定するメタデータ）を含み得、これにより、要求は、リソースマネージャ１２０によって、優先順位によって与えられた順序で許可のために評価されることになる。換言すれば、優先順位は、要求がリソースマネージャ１２０による許可のために評価されるべき順序を規定する、リソースマネージャ１２０によってアクセスされ、用いられるべき、評価制約を規定することができ、評価制約に従って、要求は、要求のうちの、より高い優先順位を有し、および／または以前に提出された１つ以上の要求が計算リソースマネージャによって全て許可された場合にのみ、リソースマネージャ１２０による許可のために評価されるようになる。例えば、リソースマネージャ１２０は、受信された全ての要求に含まれる優先順位タグに最初にアクセスし得る。次に、リソースマネージャ１２０は、優先順位タグによって与えられた優先順位に従ってこれらの要求の順序を特定し得る。次に、リソースマネージャ１２０は、特定された順序に従って１要求ずつ、現在考慮されている要求のために、より高い優先順位を有し、および／または以前に提出された要求（存在する場合）がリソースマネージャ１２０によって許可されたかどうかを判定し、そうである場合にのみ（さもなければ、現在考慮されている要求は計算リソースの許可のために評価さえされない）、計算リソースが、順序内の現在考慮されている要求に関連付けられたプログラム部分への割り振りのために依然として利用可能であるかどうかを評価する。このような計算リソースが依然として利用可能である場合には、このとき、この現在考慮されている要求は許可される。しかし、現在考慮されている要求に対して、順序内の現在考慮されている要求に関連付けられたプログラム部分への割り振りのために十分な計算リソースが利用可能でないと評価された場合には、このとき、現在考慮されている要求は許可されない（すなわち、拒否される）。各プログラム部分は、計算リソースマネージャモジュールによってそれぞれのプログラム部分に割り振られたか、または割り振られたとこれまで見なされる、それぞれのプログラム部分の、計算リソースの決定された目標量の度合いである、現在の充足率に関連付けられ得る。充足率は、追加の計算リソースが（例えば、リソースマネージャ１２０による関連要求の許可によって）それぞれのプログラム部分に割り振られたか、または割り振られたと見なされるたびに、更新され得る。

１．３実施例
図４〜図１４を参照すると、図３のアルゴリズムがデータ処理グラフ２２４の実行に備えて図１または図２のシステム１００に適用される。図４を参照すると、アルゴリズムの第１ステップ３７０において、リソース要求モジュール１２２はデータ処理グラフ２２４のデータ処理コンポーネントを分析し、データ処理コンポーネントの各々のための計算リソース要件を決定する。第１ステップ３７０の結果、リソース要求モジュール１２２は、第１のデータ処理コンポーネント２２６の各コンポーネントインスタンスは計算リソースの５つのユニット２３７を必要とし、第２のデータ処理コンポーネント２２８の各コンポーネントインスタンスは計算リソースの３つのユニット２３７を必要とし、第３のデータ処理コンポーネント２３０の各コンポーネントインスタンスは計算リソースの４つのユニットを必要とし、第４のデータ処理コンポーネント２３２の各コンポーネントインスタンスは計算リソースの５つのユニット２３７を必要とし、第５のデータ処理コンポーネント２３４の各コンポーネントインスタンスは計算リソースの２つのユニット２３７を必要とすると決定する。

図５を参照すると、アルゴリズムの第２ステップ３６６において、リソース要求モジュール１２２は、各ＶＤＬ型コンポーネントに関連付けられたデータセット２４６、２４８、２５０を分析し、コンポーネントのためのインスタンスの目標数を決定する。実施例によっては、コンポーネントに関連付けられたデータセット内に含まれるデータ項目の数がコンポーネントのためのインスタンスの目標数を決定する。図５では、第３のコンポーネント２３０に関連付けられた第３のデータセット２４６は４つのデータ項目２５６を含む。したがって、リソース要求モジュール１２２は、第３のコンポーネント２３０のためのコンポーネントインスタンスの目標数は４に等しいと決定する。第４のコンポーネント２３２に関連付けられた第４のデータセット２４８は２つのデータ項目２５８を含む。したがって、リソース要求モジュール１２２は、第４のコンポーネント２３２のためのコンポーネントインスタンスの目標数は２に等しいと決定する。第４のコンポーネント２３４に関連付けられた第５のデータセット２５０は１０個のデータ項目２６０を含む。したがって、リソース要求モジュール１２２は、第５のコンポーネント２３４のためのコンポーネントインスタンスの目標数は１０に等しいと決定する。

図６を参照すると、アルゴリズムの第３ステップ３７４において、リソース要求モジュール１２２はリソースマネージャ１２０と対話し、第１の静的レイアウト型コンポーネント２２６のための計算リソースを割り振る。これを行うために、リソース要求モジュール１２２は、５つの計算リソースユニット２３７のサイズを各々有する、第１のホスト２３６からの２つのコンテナ（すなわち、コンポーネントの必要とされるコンポーネントインスタンスごとに１つ）の要求６９０をリソースマネージャ１２０へ送信する。図６では、リソースマネージャ１２０は第１のホスト２３６上の１０個の計算リソースユニット２３７を割り振り、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求６９０が充足されたことを指示するメッセージ６９２をもって応答する。５つの計算リソースユニットを各々含む２つのコンテナが第１のコンポーネント２２６のために割り振られたことにより、第１のコンポーネント２２６は、データ処理グラフ２２４が実行するために必要とされるとおりに、１００％充足される。アルゴリズムの第４ステップ３７６は、要求６９０が充足されたと決定し、したがって、アルゴリズムをアルゴリズムの第５ステップ３７８へ進ませる。

図７を参照すると、アルゴリズムの第５ステップ３７８において、リソース要求モジュール１２２はリソースマネージャ１２０と対話し、第２のＦＤＬ型コンポーネント２２８のための計算リソースを割り振る。これを行うために、リソース要求モジュール１２２は、３つの計算リソースユニットのサイズを各々有する、ホスト２３６、２３８、２４０のうちの任意のものからの３つのコンテナ（すなわち、コンポーネントの必要とされるコンポーネントインスタンスごとに１つ）の要求７９０をリソースマネージャ１２０へ送信する。図７では、リソースマネージャ１２０は、第１のホスト２３６上の３つの計算リソースユニット２３７、第２のホスト２３８上の３つの計算リソースユニット、および第３のホスト２４０上の３つの計算リソースユニットを割り振る。次に、リソースマネージャ１２０は、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求７９０が充足されたことを指示するメッセージ７９２をもって応答する。３つの計算リソースユニット２３７を各々含む３つのコンテナが第２のコンポーネント２２８のために割り振られたことにより、第２のコンポーネント２２８は、データ処理グラフ２２４が実行するために必要とされるとおりに、１００％充足される。アルゴリズムの第６ステップ３８０は、要求７９０が充足されたと決定し、したがって、アルゴリズムをアルゴリズムの第７ステップ３８２へ進ませる。

図８〜図１０を参照すると、アルゴリズムの第７ステップ３８２において、リソース要求モジュール１２２はリソースマネージャ１２０と対話し、第３のＶＤＬ型コンポーネント２３０、第４のＶＤＬ型コンポーネント２３２、および第５のＶＤＬ型コンポーネント２３４の各々の単一のコンポーネントインスタンスのためのリソースを割り振る。

図８では、リソース要求モジュール１２２は、４つの計算リソースユニット２３７のサイズを有する単一のコンテナの要求８９０をリソースマネージャ１２０へ送信することによって、第３のＶＤＬ型コンポーネント２３０の単一のコンポーネントインスタンスのための計算リソースの割り振りを要求する。リソースマネージャ１２０は第３のホスト２４０上の４つの計算リソースユニット２３７を割り振り、次に、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求８９０が充足されたことを指示するメッセージ８９２をもって応答する。（４つのコンテナの目標数のうち）４つの計算リソースユニットを含む１つのコンテナが第３のコンポーネント２３０のために割り振られたことにより、第３のコンポーネント２３０は２５％充足される。

図９では、リソース要求モジュール１２２は、５つの計算リソースユニット２３７のサイズを有する単一のコンテナの要求９９０をリソースマネージャ１２０へ送信することによって、第４のＶＤＬ型コンポーネント２３２の単一のコンポーネントインスタンスのための計算リソースの割り振りを要求する。リソースマネージャ１２０は第２のホスト２３８上の５つの計算リソースユニット２３７を割り振り、次に、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求９９０が充足されたことを指示するメッセージ９９２をもって応答する。（２つのコンテナの目標数のうち）５つの計算リソースユニットを含む１つのコンテナが第４のコンポーネント２３２のために割り振られたことにより、第４のコンポーネント２３２は５０％充足される。

図１０では、リソース要求モジュール１２２は、２つの計算リソースユニット２３７のサイズを有する単一のコンテナの要求１０９０をリソースマネージャ１２０へ送信することによって、第５のＶＤＬ型コンポーネント２３４の単一のコンポーネントインスタンスのための計算リソースの割り振りを要求する。リソースマネージャ１２０は第２のホスト２３８上の２個の計算リソースユニット２２７を割り振り、次に、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求１０９０が充足されたことを指示するメッセージ１０９２をもって応答する。（１０個のコンテナの目標数のうち）２つの計算リソースユニットを含む１つのコンテナが第５のコンポーネント２３４のために割り振られたことにより、第５のコンポーネント２３４は１０％充足される。

アルゴリズムの第８ステップ３８４は、計算リソースがＶＤＬ型コンポーネント２３０、２３２、２３４の各々の単一のコンポーネントインスタンスのためにうまく割り振られたと決定し、したがって、アルゴリズムをアルゴリズムの第９ステップ３８６へ進ませる。

第７ステップおよび第８ステップ３８２、３８４が完了すると、各データ処理コンポーネントが、データ処理グラフ２２４が実行モジュール１０４上で実行することができるよう実行され得る少なくとも１つのコンポーネントインスタンスを有することを確実にするために十分な計算リソースが、データ処理グラフ２２４のデータ処理コンポーネントに割り振られる。その後、アルゴリズムの第９および第１０ステップ３８６、３８８を繰り返し動作させ、図１１〜図１４に示されるように、残りの計算リソースを第３、第４、および第５のコンポーネント２３０、２３２、２３４に公平且つ適切に分散させる。

図１１を参照すると、アルゴリズムの第９ステップ３８６において、ソース要求モジュール１２２は、第５のコンポーネント２３４が（１０％の充足率における）最小充足コンポーネントであり、第３のコンポーネント２３０が（２５％の充足率における）２番目の最小充足コンポーネントであると決定する。次に、リソース要求モジュール１２２は、許可された場合には、第５のコンポーネント２３４が第３のコンポーネント２３０よりも充足される結果をもたらすであろう、第５のコンポーネント２３４のインスタンスの数Ｎを次式のとおりとすると決定する：

次に、リソース要求モジュール１２２は、２つの計算リソースユニットのサイズを各々有する、ホストのうちの任意のものからの２つのコンテナの要求１１９０をリソースマネージャ１２０へ送信する。図１１では、リソースマネージャ１２０は、第２のホスト２３８上の２つの計算リソースユニット、および第３のホスト２４０上の２つの計算リソースユニットを割り振る。次に、リソースマネージャ１２０は、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求１１９０が充足されたことを指示するメッセージ１１９２をもって応答する。２つの計算リソースユニットを各々含む３つのコンテナが第５のコンポーネント２３４のために割り振られたことにより、第５のコンポーネント２３４は３０％充足される。第１０ステップ３８８は、第９ステップ３８６においてリソースマネージャ１２０によって要求されたコンテナの全てが充足されたと決定し、したがって、アルゴリズムは第９ステップ３８６へループして戻る。

図１２を参照すると、アルゴリズムの第９ステップ３８６の２回目の反復において、ソース要求モジュール１２２は、第３のコンポーネント２３０が（２５％の充足率における）最小充足コンポーネントであり、第５のコンポーネント２３４が（３０％の充足率における）２番目の最小充足コンポーネントであると決定する。次に、リソース要求モジュール１２２は、許可された場合には、第３のコンポーネント２３０が第５のコンポーネント２３４よりも充足される結果をもたらすであろう、第３のコンポーネント２３０のインスタンスの数Ｎを次式のとおりとすると決定する：

次に、リソース要求モジュール１２２は、４つの計算リソースユニットのサイズを有する、ホストのうちの任意のものからの１つのコンテナの要求１２９０をリソースマネージャ１２０へ送信する。図１２では、リソースマネージャ１２０は第２のホスト２３８上の４つの計算リソースユニットを割り振る。次に、リソースマネージャ１２０は、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求１２９０が充足されたことを指示するメッセージ１２９２をもって応答する。４つの計算リソースユニットを含む単一のコンテナが第３のコンポーネント２３０のために割り振られたことにより、第３のコンポーネント２３０は５０％充足される。第１０ステップ３８８は、第９ステップ３８６においてリソースマネージャ１２０によって要求されたコンテナの全てが充足されたと決定し、したがって、アルゴリズムは第９ステップ３８６へループして戻る。

図１３を参照すると、アルゴリズムの第９ステップ３８６の第３の反復において、ソース要求モジュール１２２は、第５のコンポーネント２３４が（３０％の充足率における）最小充足コンポーネントであり、第３のコンポーネント２３０（または第４のコンポーネント２３２）が（５０％の充足率における）２番目の最小充足コンポーネントであると決定する。次に、リソース要求モジュール１２２は、許可された場合には、第５のコンポーネント２３４が第３のコンポーネント２３０よりも充足される結果をもたらすであろう、第５のコンポーネント２３４のインスタンスの数Ｎを次式のとおりとすると決定する：

次に、リソース要求モジュール１２２は、各々のコンテナが２つの計算リソースユニットのサイズを有する、ホストのうちの任意のものからの３つのコンテナの要求１３９０をリソースマネージャ１２０へ送信する。図１３では、リソースマネージャ１２０は、第１のホスト２３６上の２つの計算リソースユニット、および第３のホスト２４０上の４つの計算リソースユニットを割り振る。次に、リソースマネージャ１２０は、リソースマネージャ１２０が、要求された計算リソースを割り振ることができ、したがって、要求１３９０が充足されたことを指示するメッセージ１３９２をもって応答する。２つの計算リソースユニットを各々含む３つのコンテナが第５のコンポーネント２３４のために割り振られたことにより、第５のコンポーネント２３４は６０％充足される。第１０ステップ３８８は、第９ステップ３８６においてリソースマネージャ１２０によって要求されたコンテナの全てが充足されたと決定し、したがって、アルゴリズムは第９ステップ３８６へループして戻る。

図１４を参照すると、アルゴリズムの第９ステップ３８６の４回目の反復において、ソース要求モジュール１２２は、第４のコンポーネント２３２が（５０％の充足率における）最小充足コンポーネントであり、第３のコンポーネント２３０が（５０％の充足率における）２番目の最小充足コンポーネントであると決定する。次に、リソース要求モジュール１２２は、許可された場合には、第４コンポーネント２３２が第３のコンポーネント２３０よりも充足される結果をもたらすであろう、第４のコンポーネント２３２のコンポーネントインスタンスの数Ｎを次式のとおりとすると決定する：

次に、リソース要求モジュール１２２は、５つの計算リソースユニット２３７のサイズを有する、ホスト２３６、２３８、２４０のうちの任意のものからの１つのコンテナの要求１４９０をリソースマネージャ１２０へ送信する。図１４では、リソースマネージャ１２０はホストのうちのいずれの上の利用可能な計算リソースユニットの間でも５つの計算リソースユニット２３７を割り振ることができず、したがって、リソースマネージャ１２０が、要求された計算リソースを割り振ることができなかったことを指示するメッセージ１４９２をもって応答する。第１０ステップ３８８は、第９ステップ３８６においてリソースマネージャ１２０によって要求されたコンテナの全てが充足されないと決定し、したがって、アルゴリズムは「終了し」、抜け出る。

実施例によっては、データ処理コンポーネントが異なる計算リソース要件を有し得るため、アルゴリズムは、リソース割り振りのための最初の要求失敗時に、抜け出ない、または完了しなくてもよく、その代わりに、データ処理コンポーネントのうちのいずれも追加の計算リソースを全く割り振ることができなくなるまで、他のＶＤＬ型コンポーネントのための追加のリソースを割り振ることを試みてもよいことに留意されたい。

実施例によっては、各データ処理コンポーネントは異なるレイアウトに関連付けられているが、他の実施例では、同じレイアウトを共有する複数の（またはさらに全ての）コンポーネントが存在してもよい。それらの後者の実施例では、複数のコンポーネントによって必要とされるリソースを合計し、共有するべき複数のコンポーネントのための得られた合計数のリソースを要求することによって、本明細書に記載されている同じ技法を用いることができる。

計算リソース割り振りのための様々な態様および実施形態が説明された。本発明はまた（代替的に）、図１５にも示される、後述の番号付き条項１〜２３によって記述され得る。

一般条項１によれば、記載されるのは、計算システム内で、複数のプログラム部分を有するコンピュータプログラムを実行するための計算リソースを割り振るための、コンピュータにより実施される方法（１０００）であって、本方法は、
複数のプログラム部分のプログラム部分ごとに、コンピュータプログラムが動作するべく計算システムによって実行されるために必要とされるプログラム部分の１つ以上のインスタンスの目標数を決定すること（１００１）と、
複数のプログラム部分のプログラム部分ごとに、プログラム部分を分析し、プログラム部分の必要とされる１つ以上のインスタンスを実行するために必要とされる計算リソースの目標量を決定すること（１００２）であって、複数のプログラム部分のうちの少なくとも１つのプログラム部分は第１の型のものであり、複数のプログラム部分のうちの異なる少なくとも１つのプログラム部分は、第１の型とは異なる第２の型のものである、決定すること（１００２）と、
複数のプログラム部分のプログラム部分ごとに、プログラム部分を、現在の、もしくは更新された充足率に関連付けること（１００３）、および／または維持することであって、充足率は、計算リソースマネージャモジュールによってそれぞれのプログラム部分に割り振られたか、または割り振られたとこれまで見なされる、それぞれのプログラム部分の、計算リソースの決定された目標量の度合いであり、
複数のプログラム部分のうちのプログラム部分は、その関連充足率が複数のプログラム部分の全てのプログラム部分にわたって関連充足率の最小値に等しい場合には、最小充足セットのメンバである、関連付けること（１００３）、および／または維持することと、
計算リソースの複数の要求を計算リソースマネージャモジュールへ提出すること（１００４）であって、複数の要求は、
第１の型のプログラム部分ごとに、第１の型のプログラム部分のために決定された完全な目標量の計算リソースを求める、関連付けられた第１次優先順位を有する、第１の要求、ならびに
第２の型のプログラム部分ごとに、第２の型のプログラム部分のために決定された完全な決定された目標量未満の計算リソースを求める、ただし、少なくとも、第２の型のプログラム部分の必要とされるインスタンスのうちの単一のものに関連付けられた量の計算リソースを求める、関連付けられた第２次優先順位を有する、第２の要求、ならびに
１つ以上の第３の要求であって、第３の要求の各々は、関連付けられた第３次優先順位を有し、最小充足セットのメンバである第２の型の１つのプログラム部分のために提出され、各第３の要求は以下の量の計算リソースを求めるものであり、その量とは、この量の計算リソースが第２の型の１つのプログラム部分に割り振られたか、または割り振られたと見なされた後には、最小充足セット内のメンバである複数のプログラム部分の各プログラム部分が、第３の要求において要求されたこの量の計算リソースが割り振られたか、または割り振られたと見なされる前における、最小充足セット内のメンバである１つ以上のプログラム部分についての充足率よりも大きく、且つ依然として１よりも小さい充足率を有することになるというものである、１つ以上の第３の要求、
を含む、提出すること（１００４）と、
利用可能な計算リソースに基づいて計算リソースマネージャモジュールによって許可された、複数の要求のうちのそれらの１つ以上の要求において要求されたとおりの複数のプログラム部分のうちのプログラム部分への計算リソースの割り振り、または見なされた割り振りの指示を受信すること（１００５）であって、第１次優先順位、第２次優先順位、および第３次優先順位は評価制約を規定し、この評価制約に従って、（ｉ）１つ以上の第１の要求、１つ以上の第２の要求、および１つ以上の第３の要求が、第２の要求の前に第１の要求、および第３の要求の前に第２の要求の順序で計算リソースマネージャモジュールによる許可のために評価され、（ｉｉ）第１、第２、および第３の要求は、複数の要求のうちの、より高い優先順位を有し、および／または以前に提出された１つ以上の要求が全て順番に計算リソースマネージャによって許可された場合にのみ、計算リソースマネージャモジュールによる許可のために評価されるようになる、受信すること（１００５）と、
を含む方法である。

条項２では、条項１に係る方法は、データソース内に記憶された複数のデータセットの各データセット内のデータ要素またはデータ項目の数を決定することをさらに含み、複数のデータセットの各データセットは複数のプログラム部分のうちのプログラム部分に関連付けられる。

条項３では、条項２に係る方法は、複数のプログラム部分のプログラム部分ごとに、データ要素またはデータ項目の関連付けられた決定された数に基づいて、コンピュータプログラムが複数のデータセットを入力データとして用いて動作するべく、計算システムによって実行されるために必要とされるプログラム部分の１つ以上のインスタンスの目標数を決定することをさらに含む。

第１の型の少なくとも１つのプログラム部分が計算リソースの固定目標量に関連付けられ、第２の型の少なくとも１つのプログラム部分が、計算リソースの可変目標量、または動的に決定される目標量に関連付けられる、条項１〜３のうちのいずれか１つに係る条項４。

第１の型の少なくとも１つのプログラム部分がインスタンスの固定目標数に関連付けられ、第２の型の少なくとも１つのプログラム部分が、インスタンスの可変目標数、または動的に決定される目標数に関連付けられる、条項１〜４のうちのいずれか１つに係る条項５。

動的決定がコンピュータプログラムの実行時における決定である、条項４または条項５に係る条項６。

複数の要求内の少なくともいくつかの要求が、互いに異なるサイズの計算リソースの量に対応する、条項１〜クローズ６のうちのいずれか１つに係る条項７。

１つ以上の第３の要求が、第３の要求が許可された後には、最小充足セット内の各プログラム部分が、最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率より依然として小さい充足率を有することになるような量以下である量の計算リソースを各々要求する、条項１〜条項７のうちのいずれか１つに係る条項８。

１つ以上の第３の要求が、第３の要求が許可された後には、最小充足セット内の各プログラム部分が、最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率と少なくとも同じ大きさである充足率を有することになるような量以上である量の計算リソースを各々要求する、条項１〜条項８のうちのいずれか１つに係る条項９。

１つ以上の第３の要求が、第３の要求が許可された後には、最小充足セット内の各プログラム部分が、最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率と少なくとも同じ大きさである充足率を有することになるような量以上である量の計算リソースを各々要求する、条項１〜条項９のうちのいずれか１つに係る条項１０。

本方法が、プログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量を指定する情報を記憶することをさらに含み、各プログラム部分が、そのプログラム部分が計算システム内で実行されることを可能にする、計算リソースマネージャによって許可された、許可された計算リソースを用いる、条項１〜条項１０のうちのいずれか１つに係る条項１１。

複数のプログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量を指定する情報を記憶することが、少なくとも１つのプログラム部分について、ユーザ入力に少なくとも部分的に基づいて、少なくとも１つのプログラム部分の、計算リソースの関連目標量を決定することを含む、条項１１に係る条項１２。

計算リソースが複数の計算ノードにわたって分散している、条項１〜条項１２のうちのいずれか１つに係る条項１３。

第１の型の１つ以上のプログラム部分のうちの少なくともいくつかが、それらの許可された計算リソースが複数の計算ノードのうちの特定の１つ以上の計算ノードから得られることを必要とする、条項１３に係る条項１４。

プログラム部分のうちの少なくともいくつかが、１つ以上のデータソースからのデータ項目を処理するように構成されており、本方法が、１つ以上のデータソースからのデータ項目に少なくとも部分的に基づいてプログラム部分の各々のための計算リソースの目標量を決定することをさらに含む、条項１〜１４のうちのいずれか１つに係る条項１５。

計算リソースの複数の要求が計算リソースマネージャモジュールへ全て一度に提出され、各要求が、関連付けられた第１次、第２次、または第３次優先順位を指定する優先順位タグを任意選択的に含み得る、条項１〜条項１５のうちのいずれか１つに係る条項１６。

計算リソースの複数の要求が、第２の要求の前に第１の要求、および第３の要求の前に第２の要求の順序で計算リソースマネージャモジュールへ提出される、条項１〜条項１６のうちのいずれか１つに係る条項１７。

データ要素またはデータ項目に少なくとも部分的に基づいてプログラム部分の各々のための計算リソースの目標量を決定することと、プログラム部分ごとに、プログラム部分の単一のインスタンスに関連付けられた計算リソースを、プログラム部分によって処理されるべきデータ項目またはデータ要素ごとのプログラム部分に関連付けられた計算リソースの目標量に加算することと、をさらに含む、条項２〜条項１７のうちのいずれか１つに係る条項１８。

第１または第２の要求を提出したことに応答して、第１または第２の要求のうちの１つ以上の要求が許可されなかった、または充足されなかったとの指示を受信し、応答に基づいてコンピュータプログラムの実行を中止することを含む、条項１〜条項１８のうちのいずれか１つに係る条項１９。

第１の型が、静的（Ｓ）レイアウト型または固定深さ動的レイアウト（ＦＤＬ）型であり、第２の型が可変深さ動的レイアウト（ＶＤＬ）型である、条項１〜１９のうちのいずれか１つに係る条項２０。

本方法が、複数の要求のうちの１つ以上の要求が計算リソース管理モジュールによって許可されなかったと決定することと、決定に応答して、許可されなかった１つ以上の要求に関連付けられた１つ以上のプログラム部分を指示する通知を出力することであって、任意選択的に、この通知は、許可されなかった１つ以上の要求に関連付けられた１つ以上のプログラム部分に関連付けられた現在の充足率の指示を含む、出力することと、をさらに含む、条項１〜２０のうちのいずれか１つに係る条項２１。

一般条項２２では、コンピュータ可読媒体は、計算リソースマネージャから、計算システム内で、複数のプログラム部分を有するコンピュータプログラムを実行するための計算リソースを要求するためのソフトウェアを記憶し、ソフトウェアは、コンピュータに条項１〜２１のうちのいずれかに係る方法を遂行させるための命令を含む。

一般条項２３では、計算リソースマネージャから、計算システム内で、複数のプログラム部分を有するコンピュータプログラムを実行するための計算リソースを要求するための計算システムであって、この計算システムは、ソフトウェア命令を記憶するコンピュータ可読媒体と、ソフトウェア命令を用いることによって条項１〜２１のうちのいずれかの方法を実行するように構成された少なくとも１つのプロセッサと、を含む計算システムが提供される。

２実装形態
上述された計算リソース割り振りアプローチは、例えば、好適なソフトウェア命令を実行するプログラム可能計算システムを用いて実施することができるか、あるいはそれは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの好適なハードウェアにおいて、または何らかのハイブリッド形態で実施することができる。例えば、プログラムされたアプローチでは、ソフトウェアは、少なくとも１つのプロセッサ、（揮発性および／または不揮発性メモリおよび／または記憶要素を含む）少なくとも１つのデータ記憶システム、（少なくとも１つの入力デバイスもしくはポートを用いて入力を受信するため、および少なくとも１つの出力デバイスもしくはポートを用いて出力を提供するための）少なくとも１つのユーザインターフェースを各々含む、（分散型、クライアント／サーバ型、またはグリッド型などの様々なアーキテクチャのものであり得る）１つ以上のプログラムされた、またはプログラム可能な計算システム上で実行する１つ以上のコンピュータプログラム内の手続きを含み得る。ソフトウェアは、例えば、データ処理グラフの設計、構成、および実行に関連するサービスを提供する、より大きなプログラムの１つ以上のモジュールを含み得る。プログラムのモジュール（例えば、データ処理グラフの要素）は、データリポジトリ内に記憶されたデータモデルに適合するデータ構造またはその他の編成データとして実装されることが可能である。

ソフトウェアは、揮発性もしくは不揮発性記憶媒体、または媒体の物理特性（例えば、表面ピットおよびランド、磁区、あるいは電荷）を用いる任意の他の非一時的媒体内に、期間（例えば、ダイナミックＲＡＭなどのダイナミックメモリデバイスのリフレッシュ期間の間の時間）にわたって組み込まれるなど、非一時的形態で記憶され得る。命令のロードに備えて、ソフトウェアは、ＣＤ−ＲＯＭ、または（例えば、汎用もしくは専用計算システムもしくはデバイスによって可読の）その他のコンピュータ可読媒体などの、有形の非一時的媒体上に提供され得るか、あるいはネットワークの通信媒体を通じて、ソフトウェアが実行される計算システムの有形の非一時的媒体へ（例えば、伝搬信号内に符号化されて）配信され得る。処理の一部または全ては、専用コンピュータ上で、あるいはコプロセッサまたはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）または専用の特定用途向け集積回路（ＡＳＩＣ）などの、専用ハードウェアを用いて遂行されてもよい。処理は、ソフトウェアによって指定された計算の異なる部分が異なるコンピューティング要素によって遂行される、分散した仕方で実施されてもよい。このようなコンピュータプログラムは各々、好ましくは、記憶デバイス媒体がコンピュータによって、本明細書において説明されている処理を実行するために読み出されると、コンピュータを構成し、動作させるために、汎用または専用プログラム可能コンピュータによってアクセス可能な記憶デバイスのコンピュータ可読記憶媒体（例えば、ソリッドステートメモリもしくは媒体、または磁気的もしくは光学的媒体）上に記憶されるか、またはそれにダウンロードされる。本発明のシステムはまた、コンピュータプログラムを用いて構成された、有形の非一時的媒体として実装されると考えられてもよく、このように構成された媒体は、コンピュータを、本明細書において説明されている処理ステップのうちの１つ以上を遂行するための特定の既定の仕方で動作させる。

本明細書に記載された任意選択的な特徴の各々は、任意選択的な特徴のうちの任意の他のものと組み合わせることができ、また、単独で、または他の任意選択的な特徴と組み合わせて、本出願に記載の番号付きの態様、条項、または請求項のうちの任意のものと組み合わせることもできる。

本発明の多数の実施形態が説明された。しかし、上述の説明は、本発明の範囲を限定することではなく、本発明を例示することが意図されていることを理解されたい。本発明の範囲は添付の請求項の範囲によって定義される。したがって、他の実施形態もまた、添付の請求項の範囲内に含まれる。例えば、様々な変更が、本発明の範囲から逸脱することなくなされ得る。追加的に、上述されたステップのいくつかは順序に依存しなくてもよく、それゆえ、説明されているものと異なる順序で遂行されることが可能である。

Claims

計算リソースマネージャから、複数のプログラム部分を有するコンピュータプログラムを計算システム内で実行するための計算リソースを要求するための方法であって、前記方法は、
前記プログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量についての情報を記憶することであって、各プログラム部分は、そのプログラム部分が前記計算システム内で実行されることを可能にする、前記計算リソースマネージャによって許可された、許可された計算リソースを用いる、記憶することと、
要求を計算することであって、前記要求は、要求の複数のセットとして前記計算リソースマネージャへ提出するための、前記コンピュータプログラムを前記計算システム内で実行するための計算リソースを求めるものであり、要求の各セットは、要求の初期セットを除いて、要求の前記複数のセットのうちの以前に提出された１つ以上のセットが、前記計算リソースマネージャによって前記複数のプログラム部分による使用のために許可された場合にのみ、前記計算リソースマネージャによって処理されることになる、計算することと、
を含み、前記計算することは、
要求の前記初期セットを形成すること、および
要求の前記初期セットの後に前記計算リソースマネージャによる処理のための要求の１つ以上の追加のセットを形成すること、
を含み、
要求の前記追加のセットのうちの要求の少なくとも１つのセットが、１つ以上のプログラム部分の最小充足セット内にある前記複数のプログラム部分のうちの少なくとも１つのプログラム部分のための部分要求を含み、
前記複数のプログラム部分の各プログラム部分が、各プログラム部分の、以前に要求された計算リソースの量を、各プログラム部分の、計算リソースの関連目標量で除した、それぞれの充足率に関連付けられ、
プログラム部分は、その関連充足率が前記複数のプログラム部分の全てにわたって前記関連充足率の最小値である場合には、前記最小充足セットのメンバであり、
前記部分要求は、前記部分要求が許可された後には、前記最小充足セット内の各プログラム部分が、前記部分要求が許可される前の前記最小充足セット内の前記１つ以上のプログラム部分の各々についての前記充足率より大きく、且つ依然として１より小さい充足率
を有することになるような量の計算リソースを要求する、
前記方法。
前記部分要求が、前記部分要求が許可された後には、前記最小充足セット内の各プログラム部分が、前記最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率より依然として小さい充足率を有することになるような量以下である量の計算リソースを要求する、請求項１に記載の方法。
前記部分要求が、前記部分要求が許可された後には、前記最小充足セット内の各プログラム部分が、前記最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率と少なくとも同じ大きさである充足率を有することになるような量以上である量の計算リソースを要求する、請求項１に記載の方法。
前記部分要求が、前記部分要求が許可された後には、前記最小充足セット内の各プログラム部分が、前記最小充足セットのメンバでない少なくとも１つのプログラム部分の充足率と少なくとも同じ大きさである充足率を有することになるような量以上である量の計算リソースを要求する、請求項１に記載の方法。
要求の前記初期セットがプログラム部分ごとの最小要求を含み、各最小要求は、前記プログラムの対応する部分を実行するために必要とされる最小量の計算リソースを要求する、請求項１〜４のいずれか一項に記載の方法。
前記プログラム部分のうちの少なくとも１つが計算リソースの固定目標量に関連付けられ、前記プログラム部分のうちの少なくとも１つが計算リソースの可変目標量に関連付けられ、計算リソースの前記固定目標量に関連付けられたプログラム部分ごとの前記最小要求が、計算リソースの完全な目標量に対応する全要求であり、計算リソースの前記可変目標量に関連付けられたプログラム部分ごとの前記最小要求が、計算リソースの前記完全な目標量未満に対応する部分要求である、請求項５に記載の方法。
計算リソースの可変目標量に関連付けられたプログラム部分ごとの前記最小要求が、計算リソースの単一のユニットに対応する部分要求であり、計算リソースの各可変目標量は、計算リソースの前記完全な目標量を等しいサイズの複数のユニットに分割する計算リソースの細分性を単位として規定される、請求項６に記載の方法。
要求の少なくとも１つのセット内の少なくともいくつかの要求が、互いに異なるサイズの計算リソースの量に対応する、請求項１〜７のいずれか一項に記載の方法。
前記複数のプログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量を指定する前記情報を記憶することが、少なくとも１つのプログラム部分について、ユーザ入力に少なくとも部分的に基づいて、前記少なくとも１つのプログラム部分の、計算リソースの関連目標量を決定することを含む、請求項１〜８のいずれか一項に記載の方法。
前記計算リソースが複数の計算ノードにわたって分散している、請求項１〜９のいずれか一項に記載の方法。
前記プログラム部分のうちの少なくともいくつかが、それらの許可された計算リソースが前記複数の計算ノードのうちの特定の１つ以上の計算ノードから得られることを必要とする、請求項１０に記載の方法。
要求の前記複数のセットの要求の各セットの各要求に関連付けられた計算リソースが、前記複数の計算ノードのうちの単一の計算ノードから得られなければならない、請求項１０に記載の方法。
前記プログラム部分のうちの少なくともいくつかが、１つ以上のデータソースからのデータ項目を処理するように構成されており、前記方法が、前記１つ以上のデータソースからの前記データ項目に少なくとも部分的に基づいて前記プログラム部分の各々のための計算リソースの前記目標量を決定することをさらに含む、請求項１〜１２のいずれか一項に記載の方法。
前記１つ以上のデータソースからの前記データ項目に少なくとも部分的に基づいて前記プログラム部分の各々のための計算リソースの前記目標量を決定することが、プログラム部分ごとに、前記プログラム部分の単一のインスタンスに関連付けられた計算リソースを、前記プログラム部分によって処理されるべきデータ項目ごとの前記プログラム部分に関連付けられた計算リソースの前記目標量に加算することを含む、請求項１３に記載の方法。
要求の前記複数のセットの要求の各セットの各要求が、前記複数のプログラム部分のうちの特定のプログラム部分の単一のインスタンスによって必要とされる計算リソースを要求する、請求項１〜１４のいずれか一項に記載の方法。
前記複数のプログラム部分のうちの第１のプログラム部分が、要求の前記複数のセットからの複数の要求に関連付けられる、請求項１〜１５のいずれか一項に記載の方法。
要求の前記初期セットに応答して、要求の前記初期セットのうちの１つ以上の要求が充足されなかったとの指示を受信し、前記応答に基づいて前記プログラムの実行を中止することをさらに含む、請求項１〜１６のいずれか一項に記載の方法。
計算リソースマネージャから、計算システム内で、複数のプログラム部分を有するコンピュータプログラムを実行するための計算リソースを要求するためのソフトウェアを記憶するコンピュータ可読媒体であって、前記ソフトウェアは、前記計算システムに請求項１〜１７のいずれか一項に記載の方法を遂行させるための命令を含む、コンピュータ可読媒体。
計算リソースマネージャから、複数のプログラム部分を有するプログラムを計算システム内で実行するための計算リソースを要求するための前記計算システムであって、前記計算システムは、
前記プログラム部分のうちのそれぞれのものに関連付けられた計算リソースの目標量を指定する情報を記憶するデータ記憶システムと、
請求項１〜１７のいずれか一項に記載の方法を遂行するように構成された少なくとも１つのプロセッサと、
を含む、計算システム。
計算リソースマネージャから、前記計算システム内で、複数のプログラム部分を有するコンピュータプログラムを実行するための計算リソースを要求するためのプログラムであって、前記プログラムは、前記計算システムに請求項１〜１７のいずれか一項に記載の方法を遂行させるための命令を含む、前記プログラム。