特許 7560693 マルチパス分散データシャッフル

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-24

(45)【発行日】2024-10-02

(54)【発明の名称】マルチパス分散データシャッフル

(51)【国際特許分類】

   G06F 16/182 20190101AFI20240925BHJP

   H04L 67/2885 20220101ALI20240925BHJP

【ＦＩ】

G06F16/182

H04L67/2885

【請求項の数】 18

【外国語出願】

(21)【出願番号】P 2024064169

(22)【出願日】2024-04-11

(62)【分割の表示】P 2022522725の分割

【原出願日】2020-11-03

(65)【公開番号】P2024102090

(43)【公開日】2024-07-30

【審査請求日】2024-05-10

(31)【優先権主張番号】16/672,939

(32)【優先日】2019-11-04

(33)【優先権主張国・地域又は機関】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】バキリアン，モフセン

(72)【発明者】

【氏名】アマディ，ホセイン

【審査官】齊藤 貴孝

(56)【参考文献】

【文献】特表２０１９－５１７０６５（ＪＰ，Ａ）

【文献】特表２０１９－５０２９８９（ＪＰ，Ａ）

【文献】特表２０１４－５１５５２４（ＪＰ，Ａ）

【文献】米国特許第１０２２３４５０（ＵＳ，Ｂ１）

【文献】国際公開第２０１８／１４２８７４（ＷＯ，Ａ１）

【文献】米国特許第５７９０８０７（ＵＳ，Ａ）

【文献】米国特許出願公開第２０１８／００４６３９８（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

Ｈ０４Ｌ ６７／００－６７／７５

(57)【特許請求の範囲】

【請求項1】

分散ネットワークにおいてデータを再パーティション化する方法であって、
１つまたはそれ以上の第１のプロセッサが、複数の第１のソースから複数の第１のシンクへのデータセットの第１の部分の第１のシャッフルを実行することを備え、各第１のシンクは、前記複数の第１のソースのうちの１つまたはそれ以上の第１のソースからデータを収集し、前記方法はさらに、
前記１つまたはそれ以上の第１のプロセッサが、前記第１のシャッフル中に前記データセットの前記第１の部分のメタデータを追跡することと、
前記１つまたはそれ以上の第１のプロセッサとは別の１つまたはそれ以上の第２のプロセッサが、前記複数の第１のソースから複数の第２のシンクへの前記データセットの第２の部分の第２のシャッフルを実行することとを備え、各第２のシンクは、前記複数の第１のソースのうちの１つまたはそれ以上の第１のソースからデータを収集し、前記方法はさらに、
前記１つまたはそれ以上の第２のプロセッサが、前記第２のシャッフル中に前記データセットの前記第２の部分のメタデータを追跡することを備え、
前記第１および第２のシャッフルを実行することは、１つまたはそれ以上の第１のシンクおよび１つまたはそれ以上の第２のシンクが、前記複数の第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、前記データセットを再パーティション化するようにさせる、方法。

【請求項2】

前記複数の第１のシンクと前記複数の第２のシンクとの合計量は、前記複数の第１のソースの量よりも多い、請求項１に記載の方法。

【請求項3】

前記複数の第１のソースからＮ個のシンク群へのＮ個のシャッフルを実行することをさらに備え、Ｎは、２よりも大きな値を有する数であり、前記Ｎ個のシャッフルを実行することは、前記Ｎ個のシンク群の各々における１つまたはそれ以上のシンクが、前記複数の第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、前記データセットを再パーティション化するようにさせる、請求項１または２に記載の方法。

【請求項4】

前記第１のシャッフルおよび前記第２のシャッフルは、互いに並行して実行される、請求項１～３のいずれか１項に記載の方法。

【請求項5】

前記データセットの前記第１の部分のメタデータを追跡することは、前記データセットの前記第１の部分の第１のシャッフルログを維持することを備え、前記データセットの前記第２の部分のメタデータを追跡することは、前記データセットの前記第２の部分の第２のシャッフルログを維持することを備え、前記第１のシャッフルログおよび第２のシャッフルログは、互いに別々のものである、請求項１～４のいずれか１項に記載の方法。

【請求項6】

前記複数の第１のシンクの各々は、複数の第２のソースのうちの対応する１つであり、前記方法はさらに、
前記第１のシャッフルの完了を判断することと、
前記第１のシャッフルが完了したと判断すると前記データセットの前記第１の部分を含む１つまたはそれ以上の後続のシャッフルを開始することとを備える、請求項１～５のいずれか１項に記載の方法。

【請求項7】

前記１つまたはそれ以上の第１のプロセッサが、前記第２のシャッフルが完了したかどうかにかかわらず前記第１のシャッフルの完了に応答して、前記第１のシャッフルに関連付けられたシャッフルログをフラッシュすることをさらに備える、請求項６に記載の方法。

【請求項8】

前記複数の第２のソースのうちの２つまたはそれ以上の第２のソースから複数の第３のシンクのうちの２つまたはそれ以上の第３のシンクへの前記１つまたはそれ以上の後続のシャッフルのうちの少なくとも１つの後続のシャッフルのために、前記少なくとも１つの後続のシャッフルに含まれるデータの第３のシャッフルログを維持することをさらに備える、請求項６に記載の方法。

【請求項9】

前記少なくとも１つの後続のシャッフルは、前記データセットの前記第１の部分の少なくとも一部と、前記データセットの前記第２の部分の少なくとも一部とを含む、請求項８に記載の方法。

【請求項10】

前記少なくとも１つの後続のシャッフルは、バタフライシャッフルである、請求項９に記載の方法。

【請求項11】

前記第１のシャッフルの前に、前記複数の第１のシンクおよび前記複数の第３のシンクの各々を指定することを備え、前記複数の第３のシンクを指定することは、前記複数の第１のソースからのデータが前記第１のシャッフル中に前記複数の第３のシンクにおいて収集されないようにし、前記方法はさらに、
少なくとも１つの第１のシンクが前記第１のソースのうちの１つまたはそれ以上の第１のソースからの収集を完了したときであって、前記第１のシャッフルの完了前に、前記少なくとも１つの第１のシンクから収集を行うように１つまたはそれ以上の第３のシンクを指定することを備える、請求項８に記載の方法。

【請求項12】

前記データセットは、第１のハッシュ関数を使用して前記複数の第１のソースから前記複数の第１のシンクに渡され、前記第１のハッシュ関数に互いに関係づけられた第２のハッシュ関数を使用して前記複数の第２のソースから前記複数の第３のシンクに渡される、請求項１１に記載の方法。

【請求項13】

前記複数の第３のシンクの識別情報は連続的であり、各第３のシンクについて、前記方法は、前記第３のシンクの前記識別情報に基づいて、前記第３のシンクが収集を行う前記第２のソースの識別情報の範囲を計算することをさらに備える、請求項８に記載の方法。

【請求項14】

１つまたはそれ以上のプロセッサが、前記第１のシャッフルの第１のシャッフルログをフラッシュすることと、
前記第１のシャッフルログをフラッシュすることの完了前に、前記第１のシャッフルログから既にフラッシュされた前記データセットの前記第１の部分のセグメントについて前記後続のシャッフルを実行することとをさらに備える、請求項８に記載の方法。

【請求項15】

分散ネットワークにおいてデータを再パーティション化するためのシステムであって、
複数のプロセッサと、
前記複数のプロセッサと通信する１つまたはそれ以上のストレージデバイスとを備え、前記１つまたはそれ以上のストレージデバイスは、命令を含み、前記命令は、前記複数のプロセッサに、
複数の第１のソースから複数の第１のシンクへのデータセットの第１の部分の第１のシャッフルを実行させるように構成され、各第１のシンクは、前記複数の第１のソースのうちの１つまたはそれ以上の第１のソースからデータを収集し、前記命令はさらに、前記複数のプロセッサに、
前記第１のシャッフル中に前記データセットの前記第１の部分のメタデータを追跡させるように構成され、
前記複数の第１のソースから複数の第２のシンクへの前記データセットの第２の部分の第２のシャッフルを実行させるように構成され、各第２のシンクは、前記複数の第１のソースのうちの１つまたはそれ以上の第１のソースからデータを収集し、前記命令はさらに、前記複数のプロセッサに、
前記第２のシャッフル中に前記データセットの前記第２の部分のメタデータを追跡させるように構成され、
前記第１および第２のシャッフルは、１つまたはそれ以上の第１のシンクおよび１つまたはそれ以上の第２のシンクが、前記複数の第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、前記データセットを再パーティション化するようにさせる、システム。

【請求項16】

各第１のシンクおよび各第２のシンクは、前記複数の第１のソースのうちの２つまたはそれ以上の第１のソースからデータを収集し、前記複数の第１のシンクと前記複数の第２のシンクとの合計量は、前記複数の第１のソースの量よりも多い、請求項１５に記載のシステム。

【請求項17】

前記命令は、前記複数のプロセッサに、前記複数の第１のソースからＮ個のシンク群へのＮ個のシャッフルを実行させるように構成され、Ｎは、２よりも大きな値を有する数であり、前記Ｎ個のシャッフルを実行させることは、前記Ｎ個のシンク群の各々における１つまたはそれ以上のシンクが、前記複数の第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、前記データセットを再パーティション化するようにさせる、請求項１５または１６に記載のシステム。

【請求項18】

前記命令は、前記複数のプロセッサに、前記データセットの前記第１の部分の第１のシャッフルログおよび前記データセットの前記第２の部分の第２のシャッフルログの各々において前記データセットの前記第１の部分の前記メタデータを維持させるように構成され、前記第１のシャッフルログおよび第２のシャッフルログは、互いに独立して維持される、請求項１５～１７のいずれか１項に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１９年１１月４日に出願された米国特許出願番号第１６／６７２，９３９号の継続出願であり、米国特許出願番号第１６／６７２，９３９号の開示内容は、引用によって本明細書に援用される。

【背景技術】

【0002】

背景
本開示の技術は、一般に、多くのシンクを必要とするシャッフル演算の効率を向上させるためのシステムに関する。「シャッフル」では、複数のソースからのデータのブロックは、各ソースにおけるデータのブロックを複数のシンクに分散させる分散スキームを使用して、複数のシンクの間で再分散される。シャッフルが終わると、各シンクは、２つ以上のソースからのブロックを含み得る。

【0003】

従来、シャッフルデータは、そのソースによって編成されて、各シンクについてのその対応するソースにマッピングされていた。図１は、シャッフル演算の一例を示す機能ブロック図であり、ここでは、ソース１０に格納されたデータのブロックは、シンク３０にシャッフルされる。図１の例では、１４個のソースおよび１６個のシンクがある。各シンクは、４つの異なるソースからのデータにマッピングされて、このデータを受信する。たとえば、シンク３１および３２の各々は、シャッフルされたデータをソース１１，１２，１３および１４から受信するようにマッピングされる。さらに他の例では、シンク３３および３４の各々は、ソース１１および１２からソース１３、ソース１３からソース１５、およびソース１５からシンク３３および３４にマッピングされたシャッフルされたデータにマッピングされて、このシャッフルされたデータを受信する。図１のシャッフルではシンクとソースとの間に合計６４回のマッピングがあり、１６個のシンクの各々について４個のソースがある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来、シャッフル演算は、各ソースがそのデータを共通ログに付加することを必要とし得る。したがって、シャッフル演算は、追加のソースを収容するように容易に調整することができ、シャッフルを完了するための演算の回数は、ソースの数が増加するにつれて線形に増加し得る。しかし、シンクは、複数のソースからデータを受信し、そのためいくつかの異なるソースにマッピングされるので、各シンクは、データの受信元となるソースを全てスキャンしなければならない。したがって、シャッフル演算は、追加のシンクを収容するように調整することが容易ではない。なぜなら、シンクの数が増加するにつれて、シャッフルを完了するための演算の回数が二次式的に増加し得るからである。シャッフル演算で処理されるデータ量が増加するにつれて、データは限られた数のシンクに収まらなくなるため、データが再パーティション化されるシンクの数を増やすことが必要になる。

【課題を解決するための手段】

【0005】

簡単な概要
本開示の一局面は、分散ネットワークにおいてデータを再パーティション化する方法に向けられる。上記方法は、１つまたは複数のプロセッサが、複数の第１のソースから複数の第１のシンクへのデータセットの第１のパスを実行するステップを含み得て、各第１のシンクは、上記第１のソースのうちの１つまたは複数の第１のソースからデータを収集し、上記方法はさらに、上記１つまたは複数のプロセッサが、複数の第２のソースから複数
の第２のシンクへの上記データセットの第２のパスを実行するステップを含み得て、上記複数の第１のシンクの各々は、上記複数の第２のソースのうちの１つに対応し、各第２のシンクは、上記第２のソースのうちの１つまたは複数の第２のソースからデータを収集する。上記第１および第２のパスを実行するステップは、１つまたは複数の第２のシンクが、上記第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、上記データセットを再パーティション化するようにさせ得る。

【0006】

いくつかの例において、上記複数の第１のシンクの量は、上記複数の第１のソースの量よりも多いであろう。

【0007】

いくつかの例において、各第１のシンクは、上記第１のソースのうちの２つまたはそれ以上の第１のソースからデータを収集し得る。

【0008】

いくつかの例において、上記複数の第２のシンクの量は、上記複数の第２のソースの量よりも多いであろう。

【0009】

いくつかの例において、上記方法は、Ｎ個のパスを実行するステップをさらに含み得て、Ｎは、２よりも大きな値を有する数である。各々の所与のパスについて、複数のシンクは、複数のソースのうちの１つまたは複数のソースからデータを収集し得て、各ソースは、前のパスのシンクに対応する。上記Ｎ個のパスを実行するステップは、１つまたは複数の第Ｎのシンクが、上記第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、上記データセットを再パーティション化するようにさせ得る。

【0010】

いくつかの例において、上記Ｎ個のパスのうちの少なくとも１つのパスについて、上記パスの各シンクは、上記パスの上記ソースのうちの２つまたはそれ以上のソースからデータを収集し得て、上記パスの上記２つまたはそれ以上のソースの各々は、直前のパスの別のソースから生じたデータを含み得る。

【0011】

いくつかの例において、上記Ｎ個のパスのうちの少なくとも別のパスについて、上記パスの各シンクは、上記パスの上記ソースのうちの２つまたはそれ以上のソースからデータを収集し得て、上記パスの上記２つまたはそれ以上のソースの各々は、直前のパスの別のソースから生じたデータを含み得る。

【0012】

いくつかの例において、上記少なくとも１つのパスおよび上記少なくとも別のパスは、上記Ｎ個のパスのうちの連続するパスであり得る。

【0013】

いくつかの例において、上記複数の第１のシンクの各々は、上記複数の第２のソースのうちの対応する１つであり得る。上記方法はさらに、上記第１のパスの完了を判断するステップと、第１のパスが完了したと判断すると上記第２のパスを開始するステップとを含み得る。

【0014】

いくつかの例において、上記複数の第１のシンクの各々は、上記複数の第２のソースのうちの対応する１つであり得て、上記方法はさらに、上記第１のパスの前に、上記複数の第１のシンクおよび上記複数の第２のシンクの各々を指定するステップを含み得て、上記複数の第２のシンクを指定するステップは、上記複数の第１のソースからのデータが上記第１のパス中に上記複数の第２のシンクにおいて収集されないようにし、上記方法はさらに、少なくとも１つの第１のシンクが上記第１のソースのうちの１つまたは複数の第１のソースからの収集を完了したときであって、上記第１のパスの完了前に、上記少なくとも１つの第１のシンクから収集を行うように１つまたは複数の第２のシンクを指定するステ
ップを含み得る。

【0015】

いくつかの例において、上記データセットは、第１のハッシュ関数を使用して上記複数の第１のソースから上記複数の第１のシンクに渡され、上記第１のハッシュ関数に相関付けられ得る第２のハッシュ関数を使用して上記複数の第２のソースから上記複数の第２のシンクに渡され得る。

【0016】

いくつかの例において、上記複数の第２のシンクの識別情報は連続的であり得て、各第２のシンクについて、上記方法は、上記第２のシンクが収集を行う上記第２のソースの識別情報の範囲を、上記第２のシンクの上記識別情報に基づいて計算するステップを含み得る。

【0017】

いくつかの例において、上記方法は、１つまたは複数のプロセッサが、上記第１のパスのシャッフルログをフラッシュするステップと、上記フラッシュするステップの完了前に、上記第１のパスの上記シャッフルログからフラッシュされた上記データセットのセグメントについて上記第２のパスを実行するステップとをさらに含み得る。

【0018】

いくつかの例において、上記第２のパスを実行するステップは、複数のシャッフル演算を実行するステップを含み得る。上記第２のソースの第１の部分は、第１のデータログに含まれ得て、上記第２のソースの第２の部分は、上記第２のデータログに含まれ得る。

【0019】

いくつかの例において、上記複数のシャッフルの各々は、上記１つまたは複数のプロセッサによって並列に実行され得て、上記第１のデータログおよび上記第２のデータログの両方に含まれるデータは、上記第２のソースの上記第１および第２の部分から並列にフラッシュされ得る。

【0020】

本開示の別の局面は、分散ネットワークにおいてデータを再パーティション化するためのシステムに向けられ、１つまたは複数のプロセッサと、上記１つまたは複数のプロセッサと通信する１つまたは複数のストレージデバイスとを含む。上記１つまたは複数のストレージデバイスは、命令を含み得て、上記命令は、上記１つまたは複数のプロセッサに、複数の第１のソースから複数の第１のシンクへのデータセットの第１のパスを実行させるように構成され、各第１のシンクは、上記第１のソースのうちの１つまたは複数の第１のソースからデータを収集し、上記命令はさらに、上記１つまたは複数のプロセッサに、複数の第２のソースから複数の第２のシンクへの上記データセットの第２のパスを実行させるように構成され、上記複数の第１のシンクの各々は、上記複数の第２のソースのうちの１つに対応し、各第２のシンクは、上記第２のソースのうちの１つまたは複数の第２のソースからデータを収集する。上記第１および第２のパスは、１つまたは複数の第２のシンクが、上記第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、上記データセットを再パーティション化するようにさせ得る。

【0021】

いくつかの例において、各第１のシンクは、上記第１のソースのうちの２つまたはそれ以上の第１のソースからデータを収集し得て、上記複数の第２のシンクの量は、上記複数の第２のソースの量よりも多いであろう。

【0022】

いくつかの例において、上記命令は、上記１つまたは複数のプロセッサに、Ｎ個のパスを実行させるように構成され得て、Ｎは、２よりも大きな値を有する数である。各々の所与のパスについて、複数のシンクは、複数のソースのうちの１つまたは複数のソースからデータを収集し得て、各ソースは、前のパスのシンクに対応する。上記Ｎ個のパスを実行させることは、１つまたは複数の第Ｎのシンクが、上記第１のソースのうちの２つまたはそれ以上の第１のソースから生じたデータを収集するように、上記データセットを再パー
ティション化するようにさせ得る。

【0023】

いくつかの例において、上記Ｎ個のパスのうちの少なくとも１つのパスについて、上記パスの各シンクは、上記パスの上記ソースのうちの２つまたはそれ以上のソースからデータを収集し得て、上記パスの上記２つまたはそれ以上のソースの各々は、直前のパスの別のソースから生じたデータを含む。上記Ｎ個のパスのうちの少なくとも１つの他のパスについて、上記パスの各シンクは、上記他のパスの上記ソースのうちの２つまたはそれ以上のソースからデータを収集し得て、上記他のパスの上記２つまたはそれ以上のソースの各々は、直前のパスの別のソースから生じたデータを含み得る。上記少なくとも１つのパスおよび上記少なくとも１つの他のパスは、上記Ｎ個のパスのうちの連続するパスであり得る。

【図面の簡単な説明】

【0024】

【図1】例示的な従前のデータ分散スキームを示すブロック図である。

【図2A】本開示の局面に係る、分散データストア内の例示的なシステムのブロック図である。

【図2B】本開示の局面に係る、例示的なシステムおよびコンピューティングデバイスのブロック図である。

【図3】本開示の局面に係る、例示的なマルチパスシャッフルを示すフロー図である。

【図4】本開示の局面に係る、例示的なデータ分散スキームを示すブロック図である。

【図5】本開示の局面に係る、例示的なデータ分散スキームを示すブロック図である。

【図6】本開示の局面に係る、例示的なデータ分散スキームを示すブロック図である。

【図7】本開示の局面に係る、例示的なデータ分散スキームを示すブロック図である。

【図8】本開示の局面に係る、例示的なワークフローを示すブロック図である。

【図9】本開示の局面に係る、例示的なワークフローを示すブロック図である。

【発明を実施するための形態】

【0025】

詳細な説明
概要
シンクの数の増加にともなってシャッフル演算を調整するために、本開示は、シャッフル演算を複数のパスに分割する。このようにして、各シンクによって読み取られるソースの数を減少させ、それによって、各シンクについてシャッフル演算のオーバーヘッドの量を減少させる。マルチパスシャッフル演算は、さまざまな方法で実現することができ、各実現例は、異なる態様で効率を向上させることができる。

【0026】

いくつかの実現例において、マルチパスシャッフルの少なくとも１つのパスは、「シンク分割」であり得る。シンク分割では、各々の所与のソースからのデータは、複数のシンクの間で分散されるが、各シンクは、１つのソースのみからデータを読み取る。マルチパスシャッフルの１つのパスにおいてシンク分割を実行することにより、より少数のシンクを使用してマルチパスシャッフルの他のパスを実行できるようになり得る。

【0027】

たとえば、１００，０００個のソースから１００，０００個のシンクにデータを分散させることが望まれる場合、最初に、データは１，０００個のシンクに渡され得て、次いで、１，０００個のシンクの各シンクのデータは別々に１００個のシンクの間で分割され得て、その結果、分割後には合計１００，０００個のシンクが生じる。第１のパスにおいて
、１，０００個のシンクの各々は、ある一定数のソースからデータを読み取り得る。このパスはシャッフルであり、各シンクは複数のソースからデータを読み取るので、このパスにおけるシンクの数を１００分の１に減少させることにより、パスのオーバーヘッドは大幅に減少する。その後の分割では、各シンクは１つのソースのみから読み取ることになり、必要なオーバーヘッドが大幅に少なくなる。その結果、シンクによって読み取られるソースの数は、どちらのパスにおいても減少する。

【0028】

さらにまたは代替的に、分割は、マルチパスシャッフルの第１のパスとして実行されてもよい。シャッフルが多数のソースからのデータを含む場合には、早くからデータを分割することが好ましいであろう。たとえば、ソースが１，０００，０００個あって２，０００，０００個のシンクに分散される場合、１，０００，０００個のソースからのデータは、最初に各々２個のシンクに分割され得る。次いで、結果として生じる２，０００，０００個のシンクは、２，０００個のグループに分けられ得て、各グループは、１，０００個の異なるソースからデータを取得して、このデータを１，０００個のシンクにシャッフルする。第１のシャッフルのシンクは、グループ分けし直されて、次いで同様の態様でシャッフルされ得て、その結果、各々の元のソースは比較的完全に分散されることになる。この形態のグループ分けおよび再シャッフルは、本明細書では「バタフライシャッフル」と称される。従前の例と同様に、各パスにおけるオーバーヘッドは大幅に減少する。バタフライシャッフルの第１のパスのオーバーヘッドは、それが分割であることによってシンクが１つのソースのみから読み取るという理由で、減少する。その後のパスにおけるオーバーヘッドは、１，０００個のソースと１，０００個のシンクとの間の各々の個々のシャッフルが１，０００，０００個のソースと１，０００，０００個のシンクとの間のシャッフルよりも必要なオーバーヘッドが二次式的に少ないという理由で、減少する。別の言い方をすれば、各パスにおいて実行されるシャッフルの総回数は線形に増加するが、各シャッフルの処理は、１回の１，０００，０００から１，０００，０００へのシャッフルと比較して、二次式的に減少する。

【0029】

バタフライシャッフルの上記の例では、１つのパスから次のパスまでに実行される独立したシャッフルの回数は一定のままである。マルチパスシャッフルの他の例では、１つのパスから次のパスまでに実行されるシャッフルの回数は増加し得る。たとえば、１０，０００個のソースから２０，０００個のシンクにデータをシャッフルする最初のパスの後に、１０，０００個のソースから２０，０００個のシンクへの２つの独立したシャッフルを有する第２のパスが続くことがあり得る。第２のパスの結果は、データを４０，０００個のシンクの間で分散させるであろう。第２のパスの独立したシャッフルの各々は、シャッフルされるデータのブロックのためのメタデータの独自のログを有し得る。これは、シャッフル演算全体によって処理されるシンクの数を増やすことにとって好ましいであろう。なぜなら、各ログは、パス全体の全てのブロックではなく個々のシャッフルのブロックを読み取るシンクのみについてメタデータを含むからである。

【0030】

マルチパスシャッフルの使用は、シャッフル中にログからメタデータをフラッシュする必要がある場合にフラッシュ演算の効率を向上させることができる。これは、第１のシャッフルから既にフラッシュされたデータのみを分散させるようにマルチパスシャッフルの第２のパスを制御できるからである。さらに、場合によっては、複数のパスを使用してシャッフルを完了することにより、ログからメタデータをフラッシュする必要性を完全になくすことができる。なぜなら、所与のセグメントについてシンク宛先の総数を減少させることが、このセグメントのために格納されるメタデータの総量を減少させることにもなるからである。

【0031】

場合によっては、マルチパスシャッフルは、もっと後になるまで後続のパスのシンクのパーティション化を延期することによって単一のシャッフルとして実現され得る。たとえ
ば、第１のパスにおいてシンクのうちの１，０００個を使用して１００，０００個のソースから１００，０００個のシンクにデータをシャッフルする例では、残りの９９，０００個のシンクのパーティション化は延期され得る。これにより、１００，０００個のソースはそれらの９９，０００個のシンクに直接書き込むことができなくなる。ある例では、９９，０００個のシンクは、第１のパス全体が完了するまでブロックされ得る。別の例では、第１のパスが終了する前に次のパスが開始し得るが、次のパスのシンクのパーティション化スキームは、ソースがそれらに直接書き込むことができないように変更され得る。

【0032】

上記の実現例は、特にシンクが数万個を超える大きさに調整されると、シャッフル性能を向上させることができる。たとえば、テスト結果は、１００，０００個のソースから１００，０００個のシンクにおよそ２ＴｉＢ（テビバイト）のデータをシャッフルする速度は、１，０００個のシンクへの第１のパスおよび１００，０００個のシンクへの第２の分割パスを実行することによって２倍以上にできることを示した。この結果、シャッフルの実行に必要なリソース、コストおよび時間が大幅に減少する。

【0033】

例示的なシステム
図２Ａは、分散コンピューティング環境を含む例示的なシステムを示す図である。複数のデータセンタ１６０，１７０，１８０は、たとえばネットワーク１５０を介して通信可能に結合され得る。データセンタ１６０，１７０，１８０はさらに、ネットワーク１５０を介して１つまたは複数のクライアントデバイス（クライアント１１０など）と通信し得る。したがって、たとえば、クライアント１１０は、「クラウド」内で演算を実行し得る。いくつかの例において、データセンタ１６０，１７０，１８０はさらに、コントローラ１９０と通信し得る。

【0034】

各クライアント１１０は、人が使用することを意図したパーソナルコンピュータまたはモバイルデバイスであり得て、パーソナルコンピュータに通常見られる全ての内部コンポーネント（中央処理装置（ＣＰＵ）、ＣＤ－ＲＯＭ、ハードドライブ、ディスプレイデバイス（たとえば、スクリーンを有するモニタ、プロジェクタ、タッチスクリーン、小型ＬＣＤスクリーン、テレビ、またはプロセッサ１２０によって処理された情報を表示するように動作可能であり得る電気デバイスなどの別のデバイス）、スピーカ、モデムおよび／またはネットワークインターフェイスデバイス、ユーザ入力（マウス、キーボード、タッチスクリーンまたはマイクロフォン）、ならびに、これらの要素を互いに接続するために使用される全てのコンポーネントなど）を有する。さらに、本明細書に記載されているシステムおよび方法に係るコンピュータは、命令を処理して、人間および他のコンピュータ（汎用コンピュータ、ＰＤＡ、タブレット、携帯電話、スマートウォッチ、ローカルストレージ機能を持たないネットワークコンピュータ、テレビのためのセットトップボックス、および他のネットワーク接続されたデバイスを含む）との間でデータを伝送することができるデバイスを含み得る。

【0035】

クライアント１１０は、プロセッサ１２０と、メモリ１３０と、汎用コンピュータの中に一般的に存在する他のコンポーネントとを含み得る。メモリ１３０は、プロセッサ１２０によってアクセス可能な情報を格納することができ、この情報は、プロセッサ１２０によって実行され得る命令１３２を含む。メモリは、プロセッサ１２０によって検索、操作または格納され得るデータ１３４も含み得る。メモリ１３０は、プロセッサ１２０によってアクセス可能な情報を格納することができるタイプの非一時的なコンピュータ読取可能媒体（ハードドライブ、ソリッドステートドライブ、テープドライブ、光学式ストレージ、メモリカード、ＲＯＭ、ＲＡＭ、ＤＶＤ、ＣＤ－ＲＯＭ、書き込み可能および読み取り専用メモリなど）であり得る。プロセッサ１２０は、周知のプロセッサまたは他のあまり知られていないタイプのプロセッサであり得る。代替的に、プロセッサ１２０は、専用のコントローラ（ＡＳＩＣなど）であってもよい。

【0036】

命令１３２は、プロセッサ１２０によって直接実行される命令のセット（マシンコードなど）またはプロセッサ１２０によって間接的に実行される命令のセット（スクリプトなど）であり得る。この点に関して、「命令」、「ステップ」および「プログラム」という語は、本明細書では同義で使用することができる。命令１３２は、プロセッサ１２０による直接処理のためのオブジェクトコードフォーマットで、または他のタイプのコンピュータ言語（オンデマンドで解釈されるか、もしくは事前にコンパイルされるスクリプトもしくは独立したソースコードモジュールの集合体を含む）で格納され得る。

【0037】

データ１３４は、命令１３２に従ってプロセッサ１２０によって検索、格納または修正され得る。たとえば、システムおよび方法は、特定のデータ構造によって限定されるものではないが、データ１３４は、コンピュータレジスタに格納される場合もあれば、複数の異なるフィールドおよびレコードもしくはドキュメントを有する構造としてデータストアに格納される場合もあれば、またはバッファに格納される場合もある。また、データ１３４は、コンピュータ読取可能なフォーマット（二進値、ＡＳＣＩＩまたはユニコードなどであるが、これらに限定されるものではない）でフォーマットされ得る。さらに、データ１３４は、番号、説明文、プロプライエタリコード、ポインタ、他のネットワーク場所を含む他のメモリに格納されたデータへの参照、または関連データを計算する機能によって使用される情報のような関連情報を識別するのに十分な情報を含み得る。

【0038】

図２Ａは、プロセッサ１２０およびメモリ１３０を同一のブロック内にあるものとして機能的に示しているが、プロセッサ１２０およびメモリ１３０は、実際には、同一の物理的なハウジング内に格納される場合もあればそうでない場合もある複数のプロセッサおよびメモリを含み得る。たとえば、命令１３２およびデータ１３４のうちの一部は、リードオンリコンピュータチップ内の取り外し可能なＣＤ－ＲＯＭなどに格納され得る。命令およびデータの一部または全ては、プロセッサ１２０から物理的に離れた場所に格納されるが、依然としてプロセッサ１２０によってアクセス可能であり得る。同様に、プロセッサ１２０は、実際には、並列に動作する場合もあればそうでない場合もあるプロセッサの集合体を含み得る。

【0039】

データセンタ１６０～１８０は、互いにかなり離れて位置決めされ得る。たとえば、これらのデータセンタは、世界中のさまざまな国に位置決めされ得る。各データセンタ１６０，１７０，１８０は、１つまたは複数のコンピューティングデバイス（プロセッサ、サーバ、シャードなど）を含み得る。たとえば、図２Ａに示されるように、データセンタ１６０は、コンピューティングデバイス１６２，１６４を含み、データセンタ１７０は、コンピューティングデバイス１７２を含み、データセンタ１８０は、コンピューティングデバイス１８１～１８６を含む。いくつかの例に従って、これらのコンピューティングデバイスは、ホストマシン上で動作する１つまたは複数の仮想マシンを含み得る。たとえば、コンピューティングデバイス１６２は、オペレーティングシステムおよびアプリケーションを実行する複数の仮想マシン１６６，１６７をサポートするホストマシンであり得る。図２Ａには仮想マシン１６６，１６７が少しだけ示されているが、任意の数の仮想マシンが任意の数のホストコンピューティングデバイスによってサポートされてもよいということが理解されるべきである。さらに、図２Ａに示される構成は一例に過ぎず、例示的なデータセンタ１６０～１８０の各々におけるコンピューティングデバイスは、互いに同一である場合もあれば異なっている場合もあるさまざまな構造およびコンポーネントを有してもよい、ということが理解されるべきである。

【0040】

たとえば、第１のデータセンタの１つまたは複数のコンピューティングデバイスによっていくつかの演算が実行され、第２のデータセンタの１つまたは複数のコンピューティングデバイスによって他の演算が実行されるように、これらのコンピューティングデバイス
にわたってプログラムが実行され得る。いくつかの例では、さまざまなデータセンタにおけるコンピューティングデバイスは、異なる容量を有し得る。たとえば、異なるコンピューティングデバイスは、異なる処理速度、ワークロードなどを有し得る。これらのコンピューティングデバイスのうちの一部のみが示されているが、各データセンタ１６０，１７０，１８０は任意の数のコンピューティングデバイスを含んでもよく、第１のデータセンタにおけるコンピューティングデバイスの数は、第２のデータセンタにおけるコンピューティングデバイスの数とは異なっていてもよい、ということが理解されるべきである。さらに、各データセンタ１６０～１８０におけるコンピューティングデバイスの数は、時が経つにつれて（たとえば、ハードウェアが除去、交換、アップグレードまたは拡張されると）変動してもよい、ということが理解されるべきである。

【0041】

いくつかの例において、各データセンタ１６０～１８０は、いくつかのストレージデバイス（図示せず）（ハードドライブ、ランダムアクセスメモリ、ディスク、ディスクアレイ、テープドライブ、またはその他のタイプのストレージデバイスなど）も含み得る。データセンタ１６０～１８０は、いくつかのアーキテクチャおよび技術のうちのいずれかを実現し得て、これらのアーキテクチャおよび技術は、ダイレクト・アタッチト・ストレージ（ＤＡＳ）、ネットワーク・アタッチト・ストレージ（ＮＡＳ）、ストレージエリアネットワーク（ＳＡＮ）、ファイバチャネル（ＦＣ）、ファイバチャネル・オーバー・イーサネット（ＦＣｏＥ）、混合アーキテクチャネットワークなどを含むが、これらに限定されるものではない。これらのデータセンタは、ストレージデバイスに加えて、いくつかの他のデバイス（ケーブリング、ルータなど）を含み得る。さらに、いくつかの例では、データセンタ１６０～１８０は、仮想化環境であり得る。さらに、データセンタ１６０～１８０が少しだけ示されているが、多数のデータセンタがネットワーク１５０および／またはさらに他のネットワークを介して結合されてもよい。

【0042】

いくつかの例において、コントローラ１９０は、データセンタ１６０～１８０におけるコンピューティングデバイスと通信し得て、プログラムの実行を容易にし得る。たとえば、コントローラ１９０は、各コンピューティングデバイスの容量、ステータス、ワークロードまたは他の情報を追跡して、このような情報を使用してタスクを割り当て得る。コントローラ１９０は、上記のクライアント１１０と同様に、プロセッサ１９８と、データ１９４および命令１９６を含むメモリ１９２とを含み得る。コントローラ１９０は、格納されたデータをデータセンタ１６０～１８０におけるコンピューティングデバイスの間で再分散または再パーティション化するように構成され得る。

【0043】

クライアント１１０、データセンタ１６０～１８０およびコントローラ１９０は、ネットワーク１５０を介するなどして直接的および間接的に通信を行うことが可能であり得る。たとえば、インターネットソケットを使用して、クライアント１１０は、インターネットプロトコルスイートを介して、リモートサーバ上で動作するサービスに接続することができる。サーバは、情報を送受信するための開始接続を受け付け得るリスニングソケットをセットアップすることができる。ネットワーク１５０および介入ノードは、さまざまな構成およびプロトコルを含み得て、これらの構成およびプロトコルは、インターネット、ワールドワイドウェブ、イントラネット、仮想プライベートネットワーク、ワイドエリアネットワーク、ローカルネットワーク、１つまたは複数の企業に専有の通信プロトコルを使用したプライベートネットワーク、イーサネット（登録商標）、ＷｉＦｉ（たとえば、７０２．７１、７０２．７１ｂ、ｇ、ｎまたは他のこのような規格）、ＲＰＣ、ＨＴＴＰ、および上記のさまざまな組み合わせを含む。このような通信は、他のコンピュータ（モデム（たとえば、ダイアルアップ、ケーブルまたは光ファイバ）およびワイヤレスインターフェイスなど）との間でデータを伝送することができるデバイスによって容易にされ得る。

【0044】

クライアント１１０は、データセンタ１６０～１８０のコンピューティングデバイスに格納されたデータへのアクセスを要求し得る。このような要求は、コントローラ１９０および／またはデータセンタ１６０～１８０におけるコンピューティングデバイスのうちの１つまたは複数のコンピューティングデバイスによって処理され得る。いくつかの例において、要求に対する応答は、本明細書でさらに詳細に説明する演算を使用するなどしたデータの操作を含む、または必要とし得る。

【0045】

図２Ｂは、本開示に係る、シャッフル演算を実行するための１つまたは複数のコンピューティングデバイス２００を有する例示的なシステムを示すブロック図である。コンピューティングデバイス２００は、分散データ処理システムに含まれ得て、図２Ａに示されるようなデータセンタ１６０～１８０のうちの１つのコンピューティングデバイスまたはコントローラ１９０などである。コンピューティングデバイス２００は、データを再パーティション化することによって大量のデータに対して複雑なクエリ（「ＪＯＩＮ」および「ＧＲＯＵＰ ＢＹ」演算など）を実行するように構成され得る。このような演算は、クエリに応答して実行されてもよい。いくつかの例では、これらのクエリは、クライアントコンピューティングデバイスによって受信され得る。いくつかの例では、これらのクエリは、クライアントコンピューティングデバイスから受信された他の命令またはクエリを実行するために必要とされ得る。

【0046】

分散データ処理システムにおけるデータは、一時的に（分散インメモリファイルシステムもしくはディスクに、またはこれら２つの任意の組み合わせによって、など）格納され得る。データは、いくつかのデータソースＡ_１～Ａ_ＮからいくつかのデータシンクＢ_１～Ｂ_Ｎにシャッフルされ得る。これらのソースおよびシンクは、再パーティション化中にデータを追跡する目的で仮想アドレスを割り当てられ得る。いくつかの例において、データは、仮想マシン（図２Ａのデータセンタ１６０～１８０によってホストされる仮想マシン１６６～１６７など）に格納され得る。

【0047】

コンピューティングデバイス２００は、１つまたは複数のプロセッサ２１０、サーバ、シャード、セルなどを含み得る。各コンピューティングデバイスは、任意の数のプロセッサまたはコンピューティングデバイスを含んでもよく、コンピューティングデバイスにおけるこのようなデバイスの数は、時が経つにつれて（たとえば、ハードウェアが除去、交換、アップグレードまたは拡張されると）変動してもよい、ということが理解されるべきである。

【0048】

コンピューティングデバイス２００は、いくつかのストレージデバイスまたはメモリ２２０（ハードドライブ、ランダムアクセスメモリ、ディスク、ディスクアレイ、テープドライブ、またはその他のタイプのストレージデバイスなど）も含み得る。コンピューティングデバイス２００は、いくつかのアーキテクチャおよび技術のうちのいずれかを実現し得て、これらのアーキテクチャおよび技術は、ダイレクト・アタッチト・ストレージ（ＤＡＳ）、ネットワーク・アタッチト・ストレージ（ＮＡＳ）、ストレージエリアネットワーク（ＳＡＮ）、ファイバチャネル（ＦＣ）、ファイバチャネル・オーバー・イーサネット（ＦＣｏＥ）、混合アーキテクチャネットワークなどを含むが、これらに限定されるものではない。コンピューティングデバイス２００は、ストレージデバイスに加えて、コンピューティングデバイス間での入出力を可能にするための通信デバイス２５０などのいくつかの他のデバイス（ケーブリング、ルータなど）を含み得る。

【0049】

各コンピューティングデバイスのメモリ２２０は、１つまたは複数のプロセッサ２１０によってアクセス可能な情報を格納することができ、この情報は、コンピューティングデバイス２００において受信される、またはコンピューティングデバイス２００によって生成されるデータ２３０と、１つまたは複数のプロセッサ２１０によって実行可能な命令２
４０とを含む。

【0050】

データ２３０は、システムのソースＡ_１～Ａ_ＮとシンクＢ_１～Ｂ_Ｎとの間のシャッフル演算を追跡するシャッフルログ２３２を含み得る。シャッフルログ２３２は、シャッフル演算においてシャッフルされるデータセグメント２３４，２３６の詳細（各セグメントについてのセグメント長およびコミットステータスについての情報を含む個々のデータセグメント２３８のメタデータなど）を含み得る。概念上、シャッフルデータは、ソースとそれらのそれぞれの宛先シンクとの間のマッピングとしての表現であり得る。

【0051】

以下でさらに詳細に説明するように、シャッフル演算は、第１のパスから第Ｎのパスまでの複数のパスに分割され得る。したがって、データセグメント詳細は、図２Ｂの例示的なシャッフルログ２３２では、別々に格納されているように示されている。各パスについて詳細を別々に追跡することは、データセグメント詳細２３４，２３６およびメタデータ２３８のストレージの管理に役立ち得る。たとえば、第１のパスが完了してデータがその宛先シンクのログファイルに格納されると、たとえ後続のパスが進行中であっても、第１のパスの詳細２３４はメモリ２２０からフラッシュされ得る。他の例では、シャッフルログ２３２とシンクのデータログとの間には重複があってもよい。

【0052】

命令２４０は、データシャッフルの演算を制御するように構成されたシャッフル制御プログラム２４２を含み得る。命令２４０はさらに、シャッフルログ２３２のデータセグメント詳細２３４，２３６およびメタデータ２３８のストレージを管理するように構成されたシャッフルログフラッシュプログラム２４４を含み得る。格納されたデータおよびプログラムの上記の例については、以下でさらに詳細に説明する。

【0053】

例示的な方法
図３は、いくつかのソースからいくつかのシンクにデータをシャッフルする例示的なマルチパスシャッフルを示すフロー図３００である。このフロー図における動作は、シャッフルされたデータの格納場所（ソースＡ_１～Ａ_ＮおよびシンクＢ_１～Ｂ_Ｎなど）と通信するコンピューティングデバイス２００のプロセッサ（図２Ｂの１つまたは複数のプロセッサ２１０など）によって実行され得る。

【0054】

ブロック３１０において、データの第１のパスが実行され得る。第１のパスは、第１のソースのセットから第１のシンクのセットにデータを移動させることを含み得る。次いで、ブロック３２０において、データの第２のパスが実行され得る。第２のパスは、第１のシンクのセットに対応し得る第２のソースのセットから第２のシンクのセットにデータを移動させることを含み得る。

【0055】

たとえば、図４は、一連の２つのパスにおいてシャッフル演算を使用してデータがシャッフルされるデータ分散スキームおよびセットアップの一例を示す図である。シャッフル演算は、２つの別々のパス、すなわち第１のソース４００から第１のシンク４１０への第１のパスと、第１のシンク４１０に対応する第２のソース４２０から第２のシンク４３０への第２のパスと、に分割される。第１のパスにおいて、第１のシンク４１０の各々は、第１のソース４００のうちの３つの異なる第１のソース４００からデータのセグメントを受信する。たとえば、シンク４１１は、ソース４０１，４０２および４０３の各々からデータを受信する。別の例では、シンク４１８は、ソース４０１，４０２および４０６の各々からデータを受信する。シンクの各々は、データの受信元であるソースにマッピングされるので、図４のシャッフルの第１のパスでは第１のシンクと第１のソースとの間に合計２４回のマッピング、すなわち８個のシンクの各々について３回のマッピングがある。第２のパスにおいて、第２のシンク４３０の各々は、第２のシンク４１０に対応し得る第２のソース４２０のうちの１つからデータを受信する。たとえば、シンク４３１および４３
２の各々は、ソース４２１からデータを受信する。たとえば、シンク４４５および４４６の各々は、ソース４１８からデータを受信する。シンクの各々は、データの受信元であるソースにのみマッピングされるので、図４のシャッフルの第２のパスでは第２のシンクと第２のソースとの間に合計１６回のマッピング、すなわち１６個のシンクの各々について１回のマッピングしかない。合計して、ツーパスシャッフル中に追跡されるマッピングの総回数は４０回、すなわち第１のパスの２４回のマッピングおよび第２のパスの１６回のマッピングであり、これは、シングルパスとして実行された場合の同一のシャッフルの合計６４回のマッピングよりも少ない。

【0056】

シャッフル演算に関与するソースおよびシンクの数が増加するにつれて、複数のパスを実行する利点も増加する。たとえば、単一のパスにおいて１００，０００個のソースから１００，０００個のシンクにデータを分散させるために、各シンクは、多数のソース（たとえば、１０，０００個のソース）からデータを読み取らなければならない。これは、ソースとシンクとの間に合計１０，０００×１００，０００＝１０億回のマッピングを必要とするであろう。たとえ各シンクが１，０００個のソースから読み取るとしても、依然として１億回のマッピングを追跡する必要があるだろう。第２のパスを導入することにより、最初にデータをソースからシンクの小さな初期サブセット（１，０００個のシンクなど）に渡すことが可能になり、次いで、１，０００個のシンクの各々のデータは、別々に１００個のシンクの間で分割され得る。第１のパスにおいて、１，０００個のシンクの各々が１００，０００個のソースのうちの１０，０００個または１，０００個からデータを読み取る場合、マッピングの総回数は、それぞれ１，０００万回または１００万回になるだろう。第２のパスにおいて、１００，０００個のシンクの各々は、単一のソースにマッピングされて、合計１００，０００回のマッピングになるだろう。したがって、ツーパスシャッフルにおいて追跡されるマッピングの総回数は、１０，０００個の中間シンクを使用する場合には１，０１０万回のマッピングになり、または、１，０００個の中間シンクを使用する場合には１１０万回になるだろう。このマッピングの回数は、シングルパスシナリオの１０億回または１億回のマッピングよりも大幅に少ない。実験は、１，０００個の中間シンクを使用して約２ＴｉＢのデータをシャッフルするシャッフル演算が、中間シンクなしに実行される同一の演算の少なくとも２倍高速であり得ることを示唆している。

【0057】

図４の上記の例は、第２のパスが「シンク分割」と称される１つのこのようなツーパスシャッフルを示している。シンク分割において、各々の所与のソースからのデータは、複数のシンクの間で分散されるが、各シンクは、１つのソースのみからデータを読み取る。マルチパスシャッフルの１つのパスにおけるシンク分割により、より少数のシンクを使用してマルチパスシャッフルの他の前のパスを実行することが可能になり得る。上記の例示的なシナリオから分かるように、シャッフル演算の後続のパスとしてシンク分割を導入することにより、前のパスにおけるオーバーヘッドを大幅に減らすことができる。なぜなら、複数のソースにマッピングされて複数のソースからデータを読み取る必要がある中間シンクの数がはるかに少ないからである。また、シンク分割を導入することにより、最後のパスにおけるオーバーヘッドも大幅に減らすことができる。なぜなら、最後のシンクの各々は、１つのソースのみにマッピングされて１つのソースのみからデータを読み取るからである。

【0058】

上記の例において、１つのパスのシンクは、次のパスのソースに「対応する」ものとされている。この対応関係は、１つのパスのシンクが次のパスのソースと同一であるというものであり得て、これは、それらのアドレスが同一であることを意味する。代替的に、シンクのアドレスは、次のパスのソースのアドレスとは異なっていてもよいが、シンクのデータは全て、次のパスの対応するソースのアドレスに移動され得る。

【0059】

マルチパスシャッフルは、さらに他の演算（第３のパス、第４のパスなど）を含み得る
。図３の例示的なマルチパスシャッフルでは、パスは、第Ｎのパスに至るまで実行されるように示されている。特に、ブロック３３０において、データの第Ｎ－１のパスを実行し得る。第Ｎ－１のパスは、第Ｎ－２のシンクのセットに対応し得る第Ｎ－１のソースのセットから第Ｎ－１のシンクのセットにデータを移動させることを含み得る。さらに、ブロック３４０において、データの第Ｎの最後のパスを実行し得る。第Ｎのパスは、第Ｎ－１のシンクのセットに対応し得る第Ｎのソースのセットから第Ｎのシンクのセットにデータを移動させることを含み得る。

【0060】

Ｎの値は、シャッフルされるデータの量、シャッフル演算の目的、および実行されているシャッフル演算の特定のタイプによってさまざまであり得る。たとえば、図４の例に示されるシンク分割の場合、比較的少数のパス（２つのパスなど）を有することで事足りるであろう。他のタイプのシャッフル演算では、演算を３つまたはそれ以上のパスに分割することが有益であろう。

【0061】

図５は、「バタフライ」シャッフル分散スキームの一例を示す図である。バタフライでは、限られた数のソースが限られた数のシンクと対にされ、次いで、これらのソースからのデータは、対にされたシンクの間でシャッフルされる。したがって、各パスにおいて全てのデータがシャッフルされるが、別々のチャンクの状態でシャッフルされる。演算全体に複数のバタフライパスを導入することにより、各々の別々のチャンクからのシャッフルされたデータを、他の別々にシャッフルされたチャンクからのデータと対にすることが可能になる。

【0062】

図５の例において、シャッフル演算は、第１のソース５００から第１のシンク５１０への第１のパスと、第２のソース５２０（第１のシンク５１０に対応する）から第２のシンク５３０への第２のパスと、第３のソース５４０（第２のシンク５３０に対応する）から第３のシンク５５０への第３のパスとを含む。第１のパスにおいて、第１のシンク５１０の各々は、第１のソース５００のうちの１つからデータのセグメントを受信する。たとえば、シンク５１１は、ソース５０１からデータを受信し、シンク５１３は、ソース５０２からデータを受信し、シンク５１５は、ソース５０３からデータを受信し、シンク５１７は、ソース５０４からデータを受信する。各々の後続のパスにおいて、パスの各シンクは、前のパスにおける別のソースからセグメントを受信した２つのソースからデータのセグメントを受信する。たとえば、第２のパスにおいて、第２のシンク５３１は、前の第１のパスにおいて第１のソース５０１からデータを受信した第２のソース５２１および前の第１のパスにおいて第１のソース５０２からデータを受信した第２のソース５２２の各々からデータセグメントを受信する。シンク５３５は、前の第１のパスにおいて第１のソース５０３からデータを受信した第２のソース５２５および前の第１のパスにおいて第１のソース５０４からデータを受信した第２のソース５２６の各々からデータセグメントを受信する。さらに他の例では、第３のパスにおいて、第３のシンク５５１および５５２の各々は、前の第２のパスにおいて第２のソース５２１および５２２からデータを受信した第３のソース５４１ならびに前の第２のパスにおいて第２のソース５５２および５２６からデータを受信した第３のソース５４２の各々からデータセグメントを受信する。

【0063】

図５の例は、第１、第２および第３のパスのみを示しているが、パスが追加されても演算は継続し得るということを当業者は容易に理解するであろう。図５の例において、各パスは、わずか８個のソースおよび８個のシンクを有するものとして示されており、これは、各々の最後のシンク５５０が第１のソース５０１，５０２，５０３および５０４のそれぞれからのデータセグメントを含むのに十分である。ソースおよびシンクの数が増加するにつれて、より多くのパスをバタフライシャッフルに追加したり、各シャッフル演算の複雑さを増大させたりすることが必要になり得る。

【0064】

「バタフライ」シャッフルの使用は、データが多数のソースから分散される場合に特に有益である。たとえば、単一のパスにおいてデータを１，０００，０００個のソースから２，０００，０００個のシンクに分散させるために、各シンクは、多数のソースからデータを読み取らなければならない。たとえば、各シンクが１０，０００個のソースから読み取るとすると、シャッフルは、ソースとシンクとの間に合計１０，０００×２，０００，０００＝２００億回のマッピングを必要とするであろう。たとえ各シンクが１，０００個のソースから読み取るとしても、依然として２０億回のマッピングを追跡する必要があるだろう。図５の例のようにたとえ各シンクが８個のソースから読み取るとしても、この構成では依然として１，６００万回のマッピング（２００万個のシンクの各々について８回のマッピング）を追跡しなければならないであろう。マルチパスバタフライシャッフル演算内で最初の分割を第１のパスとして導入することにより、最初にデータを２，０００，０００個のシンクに渡すことが可能になり、ソースとシンクとの間のマッピングの回数が最小限、すなわち２，０００，０００回のマッピングまたは各シンクについて１つのソースになるだろう。次いで、各々の後続のパスにおいて、各シンクは、２つのソースにマッピングされ得て、その結果、第２のパスでは合計４，０００，０００回のマッピングになり、第３のパスではさらに４，０００，０００回のマッピングになり、いずれの後続のパスでも同様になる。合計で、図５に示される３つのパスでは、追跡されなければならないソースとシンクとの間のマッピングの総回数は、１，０００万回のマッピングになり、上記の例示的なシングルパスシナリオにおいてそれぞれ必要とされる１００億回または１０億回のマッピングよりも大幅に少なく、さらには１，６００万回のマッピングよりも少ない。したがって、シャッフル演算の各パスにおけるオーバーヘッドを大幅に減らすことができる。第１のパスのオーバーヘッドは、それが分割であるという理由で減少し、後続のパスにおけるオーバーヘッドは、各パスが１，０００，０００個のソースと１，０００，０００個のシンクとの間のシングルパスシャッフルよりも必要なオーバーヘッドが二次式的に少ないという理由で減少する。別の言い方をすれば、各パスにおいて実行されるシャッフルの総回数は線形に増加するが、シャッフルのための処理の総量は集合的に二次式的に減少する。

【0065】

図４に示されるシンク分割の上記の例では、各パスは、独立して実行される演算の代わりに、単一の演算を含むように示されている。他の例では、マルチパスシャッフル演算の単一の所与のパスにおいて実行される演算の回数は、２回以上であってもよい。たとえば、図５に示される個々のバタフライシャッフルは、互いに独立して実行され得て、その結果、第２および第３のパスの各々において演算が複数になる、ということを当業者は認識するであろう。

【0066】

さらに、図５におけるバタフライシャッフルの例では、独立したシャッフルの回数は、１つのパスから次のパスまで一定のままである。他の例では、各パスにおいて実行される独立した演算の回数は、パスによって変化してもよい。

【0067】

図６は、複数のシンク分割を含む「シャッフル分割」分散スキームの一例を示す図であり、ここでは、各パスにおいて実行される分割演算の回数が１つのパスから次のパスに向けて増加する。特に、図６の例では、第１のソース６００から第１のシンク６１０への第１のパスにおいて、２つのソース６０１および６０２のデータは、４つのシンク６１１，６１２，６１３および６１４の間でシャッフルされる。第１のシンク６１０に対応する第２のソース６２０から第２のシンク６３０への第２のパスにおいて、各ソースは２つのシンクに分割される。たとえば、ソース６２１のデータは、シンク６３１と６３２との間で分割され、ソース６２２のデータは、シンク６３３と６３４との間で分割され、ソース６２３のデータは、シンク６３５と６３６との間で分割され、ソース６２４のデータは、シンク６３７と６３８との間で分割される。第２のシンク６３０に対応する第３のソース６４０から第３のシンク６５０への第３のパスにおいて、各ソースは、再び２つのシンクに
分割される。たとえば、ソース６４１のデータは、シンク６５１と６５２との間で分割され、ソース６４２のデータは、シンク６５３と６５４との間で分割され、ソース６４３のデータは、シンク６５５と６５６との間で分割され、ソース６４４のデータは、シンク６５７と６５８との間で分割される。

【0068】

さらに、第２のパスのシャッフル演算は、２つの独立して実行される演算に二分または分割され、その結果、ソース６２１および６２２におけるデータの分割は第１の演算６８２において管理され、ソース６２３および６２４におけるデータの分割は第２の別個の演算６８４において管理される。同様に、第２のパスの各々の所与の独立した演算のシンクは、第３のパスの２つの別々の演算に二分される。たとえば、ソース６４１および６４２におけるデータの分割は第１の演算６９２において管理され、ソース６４３および６４４におけるデータの分割は第２の別個の演算６９４において管理される。同様に、第２のパスの演算６８４において分割されたデータは、次いで、第３のパスにおける２つの別々の分割演算６９６，６９８に二分される。

【0069】

図６の例では、分割演算の回数は、１つのパスから次のパスに向けて２倍に増加する。したがって、このシャッフル分割の「分割係数」は、２であると言われる。他の例では、独立した演算の回数は、２よりも大きな倍数（３倍、４倍、５倍、８倍、１０倍など）に増加してもよい。

【0070】

パスを複数の別々の演算として処理することによってソースとシンクとの間のマッピングの総回数を減らすことはできないが、別々の演算を使用することにより、同一のパスで複数のシャッフルログを使用できるようになる。これにより、各シャッフルログの全体サイズを小さなサイズに維持することができる。ソースおよびシンクの数が増加して、シャッフル演算中に追跡されるメタデータの量が増加すると、メタデータを別々のシャッフルログに分割することが有益であろう。たとえば、図６をさらに参照して、第２のソース６２０から第２のシンク６３０への第２のパスの演算を制御するプロセッサ（図２Ｂの例に示される１つまたは複数のプロセッサ２１０など）は、シーケンシャルにまたは同時に処理される演算６８２および６８４を制御し得るため、シャッフル演算の帯域幅およびタイミングに対する制御を向上させる。

【0071】

たとえば、１０，０００個のソースから２０，０００個のシンクにデータをシャッフルする最初のパスの後に、１０，０００個のソースから２０，０００個のシンクへの２つの独立したシャッフルを有する第２のパスが続くことがあり得る。第２のパスの結果は、データを４０，０００個のシンクの間で分散させるであろうが、第２のパスにおいて移動されたデータブロックのメタデータは、２つの別々のシャッフルログに二分され得る。これは、シャッフル演算がソースの数よりもはるかに多い数のシンクを含む場合に特に有用であろう。なぜなら、データは、シンクの数が増加する前の演算の初期のパスにおいて十分にシャッフルされ、次いで、別々のシャッフルログによって管理される独立した演算に従っていくつかのシンクに分割され得るからである。このように、各シャッフルログは、パスの他の独立した演算のブロックではなくそれ自体の演算のブロックを読み取るシンクのメタデータだけを含むであろう。

【0072】

さらに、演算が並列にまたは同時に処理される場合、および一方の演算が他方の演算の前に完了する場合、完了した演算のシャッフルログからのメタデータは、他の別個の演算も完了するのを待つことなくフラッシュされ得る。例示のために、１００，０００個の均一に分散されたシンクを含む単一の「シンク分割」演算のシャッフルログが５０ＧｉＢ（ギビバイト）を含む場合、フラッシャは、完了したシンク当たり平均して約０．５ＭｉＢ（メビバイト）のデータをフラッシュするであろう。しかし、同一のシャッフルログデータが１００個の別々の「シンク分割」演算（各演算は１，０００個のシンクを含む）の間
で分割される場合、フラッシャは、完了したシンク当たり平均して約５０ＭｉＢのデータをフラッシュするであろう。

【0073】

図７は、図５からのバタフライシャッフルおよび図６からのシャッフル分割の両方の概念を組み合わせた例示的なデータ分散スキームを示す図である。図７の例では、第１のソース７００のデータが第１のシンク７１０に書き込まれる第１のパス、第１のシンク７１０に対応する第２のソース７２０のデータが第２のシンク７３０に書き込まれる第２のパス、および第２のシンク７３０に対応する第３のソース７４０のデータが第３のシンク７５０に書き込まれる第３のパス。

【0074】

各パスにおいて、各シンクは、２つのソースからデータを受信し得る。さらに、各パスにおいて、シンクはグループに分割され得て、それによって、シンクの各グループは同一の２つのソースからデータを受信する。このように、シンクの各グループおよびそれらの対応する２つのソースについてのシャッフル演算は、シンクの所与のグループに書き込まれるデータのメタデータに限定される独自のシャッフルログを有する独立した演算として処理され得る。たとえば、第２のパスにおいて、第２のシンク７３５，７３６，７３７および７３８は全て、第２のソース７２３および７２４からデータを受信し得る。ソース７２３および７２４とシンク７３５，７３６，７３７および７３８との間のシャッフルは、シンク７３５，７３６，７３７および７３８に書き込まれるデータのメタデータだけを含む独自のシャッフルログにおいて独立して管理され得る。

【0075】

図７の例では、各パスから次のパスまでに実行される独立した演算の回数は、２倍に増加する。すなわち、第１のパスは２つの演算を含み、第２のパスは４つの演算を含み、第３のパスは８つの演算を含み得る（全て図示せず）。

【0076】

各第３のシンク７５０が第１のソース７００のそれぞれからデータを受信し得ることも図７の例から分かる。たとえば、各第３のシンク７５１は、第３のソース７４１のデータを含み得て、第３のソース７４１は、順に、第２のシンク７３５に対応する。第２のシンク７３５は、対応する第２のソース７２３および７２４の各々からのデータを含み得て、第２のソース７２３および７２４は、それぞれ、第１のシンク７１２および７１６に対応する。第１のシンク７１２は、第１のソース７０１および７０２の各々からのデータを含み得て、第１のシンク７１６は、第１のソース７０３および７０４の各々からのデータを含み得る。したがって、第３のシンク７５１および７５２におけるデータは、第１のソース７００の各々まで遡ることができる。

【0077】

別の言い方をすれば、図７の例は、独立した演算の回数が１つのパスから次のパスに向けて増加し得るという点において分割シャッフルのように考えることができ、前のパスの別のソースから得られるシンクのデータを後続のパスの単一の演算において組み合わせることができるという点においてバタフライシャッフルのように考えることができる。これにより、収集されたデータに適用されるクエリの結果を向上させるためにシャッフル演算に対して複雑さおよびロバスト性のさらに他の層を追加することが可能になる。

【0078】

図４、図５、図６および図７の上記の例は、データ、ソース、シンク、シャッフルまたはそれらの任意の組み合わせの量が増加するにつれて割り当て量を減少させるために実行され得るさまざまなタイプのパスおよびシャッフル演算を示している。１つまたは複数のプロセッサ（図２Ｂのプロセッサ２１０など）は、シャッフル演算の進捗状況を追跡して、追跡された進捗状況に基づいて実行すべきパスのタイプを動的に判断するようにプログラムされ得る。「ジョイン」または「グループシャッフル」のような、さまざまな演算に関連付けられたオートオペレータまたはプランアダプタは、マルチパスシャッフルを開始するか否か、および開始する場合にはどのタイプの演算を適用するかを動的に判断し得る
。たとえば、オートジョインプランアダプタは、データがまだジョインの両側に矛盾なく分散されていない場合に「シャッフル分割」を開始することと、データが既に矛盾なく分散されている場合に「シンク分割」を開始することとの間で判断し得る。

【0079】

いくつかの例において、シャッフル分割は、モニタリングされた値が予め定められた閾値を超えたとプロセッサが判断したことに応答して、１つまたは複数のプロセッサ（図２Ｂのプロセッサ２１０など）によって開始され得る。このモニタリングされた値は、所与のパスにおいて利用されるシンクの数であり得て、それによって、各演算におけるシンクの数が閾値未満になるまで、シンクは別々の演算に分割される。代替的にまたはさらに、このモニタリングされた値は、所与のパスにおけるソースとシンクとの間のマッピングの回数であり得て、それによって、各々の別々の演算におけるソースとシンクとの間のマッピングの回数が閾値未満になるまで、シンクは別々の演算に分割される。

【0080】

上記の例は、各パスが別々の演算として扱われるマルチパスシャッフルの例を示している。他の例では、オーバーヘッドが減少してメタデータログが小さくなるという利点を維持しながら、単一のシャッフル演算としてパスを組み合わせてもよい。さらに、上記の例は、各パスのシンクを互いに別々のものとして扱う。他の例では、各パスのシンクの間に重複があってもよい。たとえば、各パスが前のパスよりも多くのシンクに書き込む例示的なシャッフル演算において、１つのパスのシンクは、次のパスのシンクのサブセットであり得て、次のパスのシンクは、後続のパスのシンクのサブセットであり得る、などである。

【0081】

たとえば、データが１００，０００個のソースから１００，０００個のシンクにシャッフルされる場合、および１，０００個のシンクが第１のパスにおいて使用される場合、第１のパスの１，０００個のシンクは、第２のパスにおいて使用される１００，０００個のシンクのうちの１，０００個のシンクであり得る。このような場合、パーティション化スキームを利用して、第１のソースが、第１のシンクではない残りの９９，０００個のシンクのいずれかに書き込まないようにすることができる。このようなパーティション化スキームの１つの効果は、上記の例の複数のシャッフル演算を、予め指定されたソースの１つのセットから予め指定されたシンクの１つのセットへの基本的には単一のシャッフル演算に変形させたというものである。

【0082】

図８および図９は、このような単一のシャッフル演算のパスをパーティション化するために使用され得る例示的なパーティション化スキームを示す図である。図８および図９の例は、第１および第２のパスに限定されているが、本明細書に記載されているスキームは、３つ以上のパスを有するシャッフル演算において繰り返されることができるということが理解されるべきである。

【0083】

図８の例は、第２のパス８２０が開始する前に第１のパス８１０が完了する「延期パーティション化」スキームを示している。第１のパス８１０は、１つまたは複数のプロセッサ（図２Ｂの１つまたは複数のプロセッサ２１０など）が、第１のソースのセットを指定すること（８１２）と、第１のシンクのセットを指定すること（８１４）と、第２のシンクのセットをブロックすること（８１６）とを含み得る。１つまたは複数のプロセッサからの命令に従ってデータが第１のソースのセットから第１のシンクのセットに書き込まれている間（８１８）、第２のシンクのセットは、シャッフルされたデータのいずれも受信することをブロックされたままであり得る。これは、第１のパスにおける全てのシャッフルされたデータが第２のシンクではなく第１のシンクにのみ書き込まれることを保証することができる。第１のパス８１０が完全に完了すると、１つまたは複数のプロセッサは、第２のパス８２０の演算を開始し得て、それによって、第２のシンクのセットをブロック解除し得る（８２２）。その後、第２のソース（第１のシンクに対応し得る）からのデー
タを第２のシンクのセットに書き込み得る（８２４）。全てのデータが第２のシンクのセットに書き込まれると、第２のパスは完了する。

【0084】

図９の代替例は、先行する第１のパス９１０が完了する前に第２のパス９２０が開始し得る「パイプライン方式延期パーティション化」スキームを示している。第１のパス９１０は、１つまたは複数のプロセッサが、第１のソースのセットを指定すること（８１２）と、第１のシンクのセットを指定すること（８１４）と、パイプライン方式を使用して第２のシンクのセットを指定すること（８１６）とを含み得る。このパイプライン方式は、パーティション化スキームを使用し得て、それによって、第１のソースはいずれも、延期パーティション化を有する第１のシンクが書き込むシンクには書き込まない。第１のシンクのいずれか１つへの書き込みが完了すると、たとえ他の第１のシンクへの書き込みがまだ終了していなくても、第２のパス９２０が開始し得る。第２のパス９２０において、終了した第１のシンクに対応する第２のソースは、パーティション化スキームに従ってデータを第２のシンクに書き込み得る（９２２）。各第１のシンクへの書き込み演算が完了すると、別の対応する第２のソースのための書き込み演算が開始し得て、これは、第２のパス９２０全体が完了するまで継続し得る。

【0085】

いくつかの例では、マルチパスシャッフルの第２のパスの開始は、データが第１のシャッフルのシャッフルログから既にフラッシュされていることを条件とすることができる。このような条件付けは、マルチパスシャッフルのシャッフルログが不必要なスペースをとらないことを保証することができ、フラッシュ演算の効率を向上させることができる。他の例では、複数のパスを使用してシャッフル演算を完了させることは、それ自体が、シャッフルログ全体からメタデータをフラッシュする必要性をなくすことができる。なぜなら、（マルチパスシャッフルで実現されるように）任意の所与のセグメントについてのシンク宛先の総数を減少させることにより、各セグメントについて格納する必要があるメタデータの総量も減少するからである。

【0086】

いくつかの例において、マルチパスシャッフル演算のパスは、パイプライン方式であり得る。これは、１つまたは複数のプロセッサの割り当て使用量を増加させ得るが、性能を向上させるという利点がある。このような例では、パイプライン方式においてバックログを回避するために、時間的により早いパスにおいて行われるシャッフルには、より高い優先順位が与えられ得る（十分な割り当て量が与えられるなど）。１つまたは複数のプロセッサは、パイプライン方式のシャッフルおよびパスの間で適切に割り当て量を分散させるために、スケジューラプログラムから命令を受信し得る。

【0087】

いくつかの例において、マルチパスシャッフル演算のパーティション化スキームは、１つのパスにおいてデータを全ての利用可能なシンクに再パーティション化し、次いで、後続のパスにおいてこのデータを利用可能なシンクのサブセットに圧縮し得る。このようなパーティション化スキームは、後続のパスにおけるシンクの読み取りを最適化することができる。特に、使用されるシンクアドレスが連続的である場合、およびシャッフルログが利用可能なシンクのサブセットを非重複アドレス範囲にマッピングする場合、後続のパスのシンクのためのルックアップ演算は、所与のアドレス範囲と同程度に単純であろう。その結果、ソースとシンクとの間のマッピングは、スペースをとらない。なぜなら、シンクが読み取ることを指定されるソースは、シンク自体のアドレスに基づいて決定することができ、シンクとソースアドレスとの間の別個のマッピングを格納する必要がないからである。

【0088】

上記の例において、各パスは、データをソースからそれらのそれぞれの宛先シンクに向けるためにハッシュパーティション化関数を使用し得る。各パスにおいて使用されるハッシュパーティション化関数は、前のパスのハッシュ関数に相関付けられ得る。同様に、別
々のシャッフル演算が単一のパスにおいて別々に実行されて前のパスの共通のシャッフル演算から分割される「シャッフル分割」の場合、別々のシャッフル演算の各々は、前のパスのハッシュ関数に相関付けられたそれぞれのハッシュ関数を使用し得る。

【0089】

上記の例は、通常、約１０ＴｉＢよりも大きな量のデータ（数十ＴｉＢのデータなど）上で複雑なクエリを実行しようとする際に生じる問題を解決する。このようなデータ量は、一般に、１０，０００個以上のシンクの使用を必要とするため、従来のシングルパスシャッフル演算ではスケーリング問題を生じさせる。本明細書に記載されているマルチパスシャッフル演算の利点は、より少ない量のデータにも適用できることである、ということを当業者は認識するであろう。すなわち、たとえ従来のシングルパスシャッフル演算を使用してそれらのより少ない量のデータを処理できるとしても、本明細書に記載されているマルチパスシャッフル演算は、効率を向上させて、演算の全体コストおよびオーバーヘッドを減少させることができる。実際、いくつかの実験は、１ＴｉＢほどの少ない入力データ量での全体的なスピードアップは、１０ＴｉＢほどの大きな入力データ量でのスピードアップよりも大きいことを示唆してきた。

【0090】

特定の実施形態を参照して本明細書における技術を説明してきたが、これらの実施形態は、本技術の原理および適用例の例示に過ぎないということが理解されるべきである。したがって、添付の特許請求の範囲によって規定される本技術の精神および範囲から逸脱することなく、これらの例示的な実施形態に対して多数の変更がなされてもよく、他の構成が考案されてもよい、ということが理解されるべきである。

【0091】

上記の代替例の大半は、互いに相容れないわけではなく、さまざまな組み合わせで実現されて固有の利点を実現することができる。特許請求の範囲によって規定される主題から逸脱することなく上記の特徴のこれらのおよび他のバリエーションおよび組み合わせを利用することができるので、実施形態の上記の説明は、特許請求の範囲によって規定される主題を限定するものではなく例示するものであると解釈されるべきである。一例として、上記の動作は、上記の厳密な順序で実行されなくてもよい。それどころか、さまざまなステップは、逆にされるなどの異なる順序で、または同時に処理されてもよい。また、特に指示のない限り、ステップは省略されてもよい。また、本明細書に記載されている例の提供および「など」、「含む」などと表現される節は、特許請求の範囲の主題を具体例に限定するものとして解釈されるべきではなく、むしろ、これらの例は、多くの可能な実施形態のうちの１つだけを例示するよう意図されている。さらに、異なる図面中の同一の参照番号は、同一または同様の要素を特定し得る。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】