エラスティックMapReduce。 分散実装

「スーパーコンピューター」という言葉に言及して最初に見た映画はターミネーターでした。 しかし、奇妙なことに、私の（まだ）未形成の精神は、スカイネットを世界の悪とは見なさず、世界初のAIの攻撃的な振る舞いが単体テストの不十分なカバレッジに起因すると考えました。



当時、私はZX Spectrum（128 KbはAIに似たものを実行するには明らかに十分ではありませんでした）と多くの（10年ほどと思います）自由時間を持っていました。 後者の事実のおかげで、仮想化の時代を安全に待ちました。 少なくとも10K VPSを削除し、それらの間に通信チャネルを確立してAIの作成を開始できます。 しかし、私はプログラミングに従事したかったのですが、グリッドシステムの管理/構成には参加したくなかったので、コンピューティングリソースがサービスとして提供されるようになるまで合理的に待ち始めました。



クラウドサービスが登場したとき、私の喜びは終わりではありませんでした。 しかし、喜びは長続きしませんでした：別々のコンピューティングインスタンス間の直接通信は、自分で書く必要がある素晴らしいコードであることが明らかになりました（つまり、ほとんどの場合機能しません）。 このことについて数年後、私たち（全員）はHadoopを待ちました。最初はオンプレミス 、その後はオンデマンドのエラスティックです。 でも、結局のところ、すべてがそれほど弾力的ではない 好きなように。 しかし、これはまったく別の話です...それについて、物語のコミックトーンをわずかに変更したことについて、お話しします。

Hadoopエラスティック問題の分散導入

クラウドテクノロジーとApache Hadoopプラットフォームの共生は、長年にわたってビッグデータ分析に関連する興味深いソリューションのソースとして考えられてきました。



そして、それが「クリーン」ではなく「共生」である主なポイントは、もちろん、ハードウェアの資格（管理者）と初期金融投資の両方の面で、MPPアプリケーションの開発者（だけでなく）のエントリーレベルの低下です。アプリケーションが実行される部分。



2番目のポイントは、クラウドプロバイダーがマスター/スレーブアーキテクチャによって課されるHadoop *制限の一部を回避できることです（マスターは常に単一障害点であり、これを使用して何かを行う必要があります）、そして（Microsoftでは、並行して開発されたDryadプロジェクトに関連して） 、特別な希望がありました）、強力なデータウェアハウス結合（ HDFS ）および分散コンピューティング実行コンポーネント（ Hadoop MapReduce ）でさえも。



Hadoopクラスターの所有コストを削減するという最初のポイントに関連する希望は正当化されました：リリースモードへの近さの程度に違いがある最大の3つのクラウドプロバイダーは、価格に「 サービスとしてのHadoopクラスター 」（条件付き用語）を提供し始めましたスタートアップや研究チームにとって非常に高揚します。



Hadoopプラットフォームの制限を回避することに関連する希望はまったく実現しませんでした。



IaaSプラットフォームと同様に、アマゾンウェブサービスはサービスとしてサービスを提供しようとしませんでした（ただし、ここには例外があります-Amazon S3、Amazon DynamoDB）。 2009年に、Amazonは開発者にAmazon Elastic MapReduceをサービスとしてではなくインフラストラクチャとして提供しました。



2010年半ばのAmazonに続いて、GoogleはGoogle App Engineクラウドプラットフォームの一部として、 App Engine MapReduceソフトウェアインターフェースのパイロットバージョンを発表しました。



App Engine MapReduce APIは、開発者に「Hadoop MapReduce」のようなインターフェイスを提供しました。これは、既にマップ/ reduceパラダイムで動作しているサービスへのインターフェイスです。 しかし、これは、データウェアハウスとコンピューティングコンポーネントの強力な接続性の制限を取り除くものではありませんでした。 さらに、Google自体が制限を追加しました-マップフェーズ**のみを再定義する可能性があり、その割り当てでGAEプラットフォーム自体がApp Engine MapReduce APIにさらに2、3の制限を課しました。



2011年に、Microsoftに変わりました。 2011年10月、MicrosoftはHadoop on Azureサービスの開始を発表しました。 現在、CTPバージョンです。 私はこのサービスを試すことができませんでした。招待状がなかったためです（怠け者がいたため）。 しかし、Hadoopの克服された制限に関する記事が不足しているため、この場合、Hadoop自体を解決するためにHadoopプラットフォームの「問題」が残っていたことは明らかです。



「クラウドプラットフォーム+ Hadoop」に基づいた上記のソリューションの制限により、 Cloud MapReduceプロジェクトによって解決されるさまざまな問題を理解できます。これについては、この記事の残りの部分で説明します。

1. Cloud MapReduce。 基本的な概念

Cloud MapReduce （CMR）は、（トップの）Amazon Web Servicesクラウドサービスに基づくマップ/削減ソフトウェアパラダイムを実装するオープンソースプロジェクトです。



CMRは、クラウドオペレーティングシステムの概念に基づいています。 従来のOSから類推すると、クラウドOSの場合：

• コンピューティングリソースはCPUではなく、Amazon EC2 / Windows Azureワーカー/ Google Compute Engineで表されます。
  
  
• データストレージは、ハードディスク（SD、フラッシュドライブなど）ではなく、Amazon S3 / Windows Azure Blob / Google Cloud Storageサービスで表されます。
  
  
• ステートストア （OCの再起動後に失われない）は、レジストリ（または同様の機能を持つローカル構造）ではなく、Amazon SimpleDB / Windows Azureテーブル/ Google BigQueryサービスによって表されます。
  
  
• プロセス間通信メカニズムは 、Amazon SQS / Windows Azureキュー/ Google App EngineタスクキューAPIサービスを使用して実装されます。
  
  

Cloud MapReduceアーキテクチャでクラウドOSの原則を確立した開発者は、印象的な結果を得ました。 彼らのブログで、彼らは自分のプラットフォームをHadoopプラットフォームと比較することから以下の事実を引用している：

• 単一障害点がない;
  
  
• MapReduceジョブを実行する前に、ストレージサービス（Amazon S3など）からHDFSにデータをコピーする必要はありません
  
  
• 場合によっては60倍以上の加速。
  
  
• このプロジェクトはJavaで3,000行のコードしか必要としませんが、Hadoopは280Kのコードを「配置」しました。
  
  

さらに、Apache Hadoopとは異なり、Cloud MapReduceはマスター/スレーブアーキテクチャに基づいて設計されていません。 ピアライクなアーキテクチャの明白な利点（単一障害点がない）に加えて、CMR開発者は実装の利点にMapReduceをHadoop、構成、バックアップ、障害からの回復よりも簡単にします。



スケーラビリティの向上もCMRの長所です。新しいコンピューティングインスタンスがクラスターに追加されると、それらはマップ/削減タスクに「ホット」に接続されます。 また、CMRは同種のクラスターを持つことを推奨しません（つまり、同じ計算能力を持つマシンから）。 異種マシンのクラスターでは、最速のマシンが低速のマシンよりも多くのタスクを実行します。



増分拡張性には、Hadoopプラットフォームが実際には欠けていたと付け加えます。 ただし、クラスターの均質性に関する要件の欠如（推奨事項）は、クラウド環境にはほとんど関係ありません。

2. Cloud MapReduce。 建築

Cloud MapReduceアーキテクチャは、次の論理層に分割されます。

• データストレージレイヤー（ ストレージレイヤー ）;
• レイヤー処理およびコンピューティング（ Computing Layer ）;
• 対話の層（ メッセージング ）。

これらのレイヤーの関係、情報フロー、およびAWSで提示されるサービスを下の図に示します。



以下では、上記の各レイヤーの機能をより詳細に分析します。

2.1。 ノード間の相互作用

Map WorkersノードとReduce Workersノード間の相互作用はキューに入れられます。 Cloud MapReduceのキューは、Amazon SQSによって提供されます。



次のタイプのキューがCMRに存在します。

• 入力/マップキュー -マップタスクのキュー。
  
  
• 複数の削減キュー -マップ関数実行の中間結果のキュー。
  
  
• マスターキュー削減 -ジョブキューを削減します。
  
  
• 出力キュー -出力キュー。
  
  

Amazon SQS / Azure Queuesのメッセージには、「非表示タイムアウト」メカニズムがあります。 メカニズムのロジックは次のとおりです。メッセージはキューから取得され、その後しばらくメッセージがキューに表示されなくなります。 メッセージが正常に処理されると、最後のキューが削除されます。そうでない場合は、非表示タイムアウトが期限切れになると、メッセージがキューに再表示されます。



キューサービスによって提供される「非表示タイムアウト」メカニズムのおかげで、Map and Reduce Workerの障害に対する非常に簡単なサポートが実装され、クラスターの全体的なフォールトトレランスが向上します。

2.2。 データ保存

データウェアハウスはアプリケーション入力を保存し、Amazon S3によって提供されます。



Amazon S3は、ファイル（ファイルシステムに一般的）ではなくリソース（RESTサービスに一般的）としてデータにアクセスが提供されるという事実により、データストレージレイヤーのよりクリーンな抽象化も提供します。 クラウドストレージにデータを保存するアプローチには、管理性が低いというマイナス面があることに注意してください。



Amazon S3は、マップ段階で分析されたデータを保存します。 入力キューにはペア<k、v>が含まれます。ここで、kは一般的な場合、マップタスクの識別子であり、vはS3のファイルへのリンクであり、オプションでファイル内のパーツへのポインターです。



このアプローチは、Amazon Elastic MapReduceサービスでMapReduceタスクを起動する最初の段階でAmazon S3からHDFSにデータをコピーすることによる不便/問題（誰にとっても）を取り除きます。



開発者は、出力をAmazon S3に直接保存することもできることにも言及しました。

入力データと出力データをS3に保存します

ドキュメンテーションから明らかなように、リデュースフェーズのすべての結果はペア<k '、v'>としてリデュースキューに保存されます。

2.3。 計算ノード

計算ノードはユーザー定義のマップを実行し、ジョブを削減します。 計算ノードはEC2インスタンスによって表され、2つのタイプに分けられます： Map WorkersとReduce Workersです。 マップワーカーではマップ関数が実行され、リデュースワーカーではリデュース関数が実行されます。



同じEC2インスタンスに対して、Map WorkerとReduce Workerの両方の役割を一貫して実行できます。



map操作とreduce操作のワークフローを以下に示します。



マッパーワークフロー：

1. Map Queueキューリンクからマップタスクのデータへの取得。
   
   
2. Amazon S3からデータを抽出します。
   
   
3. ユーザー定義のマップ関数の実行。
   
   
4. 複数の削減キューのセットから、（明示的に再定義されていない限り）k 'ハッシュに基づいて定義されたキューに実行結果<k'、v '>を追加します。
   
   
5. マップキューからマップジョブを削除します。
   
   

レデューサーワークフロー：

1. 畳み込み関数を適用する必要があるマスター削減キューから削減キューへのリンクを取得します。
   
   
2. <k '、v'>-複数の削減キューのキューのセットの対応するキューからペアを取得します。
   
   
3. ユーザー定義のreduce関数を実行し、出力ペア<k ''、v ''>を出力キューに追加します。
   
   
4. マスター削減キューから削減ジョブを削除します。
   
   

2.4。 お客様

クライアント （ Job Client ）-map / reduce-tasksの実装を制御するソフトウェアクライアント。



CMRのドキュメントからクライアントに関する最も明確でないこと。 しかし、Mapのワークフローについて知っていて、Workersを減らし、そのようなシステムを構築する原則を考えると、Job Clientのワークフローについて、科学的に近い仮定をいくつか立てさせてください。



ジョブクライアントのワークフローは、次の段階に分かれています。

1. 入力データをAmazon S3サービスに保存します。
   
   
2. データ分割ごとにマップタスクを作成し、作成したタスクをマップキューキューに追加します。
   
   
3. 複数のキューの作成Multiple Reduce Queues;
   
   
4. マスター削減キューを作成し、作成した削減ジョブキューを各パーティションキューに追加します。
   
   
5. 出力キューの作成。
   
   
6. ジョブリクエストを作成し、作成したリクエストをSimpleDBに追加します。
   
   
7. マップワーカーのEC2インスタンスを起動し、ワーカーを削減します。
   
   
8. マップワーカーの調査とワーカーの削減により、タスクの完了ステータスを取得します。
   
   
9. すべてのタスクの最後に、出力キューから結果をロードします。
   
   

2.5。 補助操作

map- / reduce-tasksの実行ステータスを保存/更新する操作は、非リレーショナルデータベースに基づいて実装されます。 AWSの非リレーショナルデータベースは、Amazon SimpleDB（2007年以降）およびAmazon DynamoDB（2012年以降）で表されます。

なぜなら CMRアーキテクチャはコンピューティングクラスターに含まれるすべてのノードが同等であることを意味するため、分散型の非リレーショナルデータウェアハウスを提供するAmazon SimpleDBサービスがノード調整の中心です。

結論と脚注

Haskellの本を読むときにこの紛れもなく素晴らしい言語のプログラマになるつもりはないのと同様に、Cloud MapReduceを今日または明日***に切り替えることはお勧めしません。



Cloud MapReduceには、それを使用するビジネス上のリスク（小さなチーム、まれな更新、Hadoopのようなエコシステムの欠如）を大きくする欠陥があり、見通しはあいまいです。 しかし、Cloud MapReduceプロジェクトアーキテクチャの関数型プログラミングから収集されたアイデアは、ITプロフェッショナルの間で既に確立されているHadoop指向のデータインテンシブコンピューティングのプレゼンテーションをさらに分散的に見せるものです。



* Apache Hadoop 2.0のアルファ版は考慮されていません。これは、説明されているアーキテクチャ上の制限が「奪われている」（より正確には、リリースバージョンが「奪われようとしている」）ものです。

**リコールされた（または夢を見たかもしれない）Google I / O 2011カンファレンスで、App Engineプラットフォームの既存の制限であるMike Aizatskyを緩和することに加えて（歪みさえしません）、Googleエンジニアはマップアルゴリズムの他の段階を再定義する可能性を提供するために取り組んでいます/ App Engine MapReduce APIで削減します。

***反対を求めないこと。