第10章 バッチ処理
前の章
前の章である第9章 一貫性と合意の問題はこちらです。
3 つの異なるシステム
結果整合性は、複数のノード間でデータをレプリケートする際に遅延が発生する可能性があっても、データは最終的にはすべてのノードに到達します。
ただし、これは弱い保証になります。レプリカがいつ収束されるかについては言及されておらず、単に収束します。
オンラインシステム
サービスは、クライアントからのリクエストまたは指示が到着するのを待ちます。メッセージを受信すると、サービスはできるだけ早くそれを処理し、応答を送り返します。
通常、応答時間はサービスのパフォーマンスの主な尺度であり、可用性が非常に重要であることがよくあります。
バッチ処理システム
大量の入力データを受け取り、それを処理するジョブを実行して出力データを生成します。ジョブは基本的に数分から数日の時間がかかることが多いです。
バッチジョブは定期的に (たとえば、1 日に 1 回) 実行されるようにスケジュールされることがよくあります。
ストリーム処理システム (準リアルタイム システム)
ストリーム処理は、オンライン処理とオフライン/バッチ処理の中間に位置します(そのため、準リアルタイム処理またはニアライン処理と呼ばれることもあります)。バッチ処理システムと同様に、ストリーム プロセッサは (リクエストに応答するのではなく) 入力を消費して出力を生成します。
ただし、ストリームジョブは発生直後のイベントを操作しますが、バッチ ジョブは固定の入力データセットを操作します。この違いにより、ストリーム処理システムは同等のバッチ システムよりも待ち時間が短くなります。
MapReduce と分散ファイルシステム
数千台のマシンに分散される可能性があります。単一の MapReduce ジョブは単一の Unix プロセスに相当します。つまり、1 つ以上の入力を受け取り、1 つ以上の出力を生成します。
Hadoop の Map-Reduce 実装では、そのファイルシステムは HDFS (Hadoop Distributed File System) と呼ばれ、Google ファイル システム (GFS) のオープンソースの再実装です。
HDFS は、共有ディスクのアプローチとは対照的に、シェアードナッシングの原則に基づいています。共有ディスク ストレージは集中ストレージ アプライアンスによって実装され、多くの場合、カスタム ハードウェアやファイバーチャネルなどの特別なネットワーク インフラストラクチャが使用されます。
MapReduce ジョブの実行
MapReduce は、HDFS などの分散ファイル システムで大規模なデータセットを処理するコードを作成できるプログラミング フレームワークです。 MapReduce でのデータ処理のパターンは、次の例と非常によく似ています。
一連の入力ファイルを読み取り、レコードに分割します。
mapper関数を呼び出して、各入力レコードからキーと値を抽出します。
すべてのキーと値のペアをキーで並べ替えます。
reducer関数を呼び出して、並べ替えられたキーと値のペアを反復処理します。同じキーが複数ある場合は、並べ替えによりリスト内でそれらが隣接するため、メモリ内に多くの状態を保持することなく、これらの値を簡単に組み合わせることができます。
mapperとは、入力レコードごとに 1 回呼び出され、それは入力レコードからキーと値を抽出します。入力ごとに、任意の数のキーと値のペアを生成できます (何も生成しない場合も含みます)。ある入力レコードから次の入力レコードまで状態を保持しないため、各レコードは独立して処理されます。
reducerは、出力レコード (同じURLの出現数など) を生成できます。MapReduce フレームワークは、マッパーによって生成されたキーと値のペアを取得し、同じキーに属するすべての値を収集し、その値のコレクションに対するイテレーターを使用してreducerを呼び出します。
障害に備えた設計
MapReduce と MPP データベースを比較すると、障害の処理とメモリとディスクの使用という設計アプローチのさらに 2 つの違いが際立ちます。バッチ プロセスは、失敗してもすぐにユーザーに影響を与えず、いつでも再実行できるため、オンライン システムよりも障害の影響を受けにくくなります。
クエリの実行中にノードがクラッシュすると、ほとんどの MPP データベースはクエリ全体を中止し、ユーザーがクエリを再送信するか、自動的にクエリを再度実行します。
通常、クエリの実行時間は数秒、長くても数分であるため、再試行のコストがそれほど高くないため、この方法でエラーを処理することは許容できます。
また、MPP データベースは、ディスクからの読み取りコストを回避するために、できるだけ多くのデータをメモリ内に保持します (ハッシュ結合を使用するなど)。
一方、MapReduce は、個々のタスクの粒度で作業を再試行することで、ジョブ全体に影響を与えることなく、マップまたはタスクの削減の失敗を許容できます。
また、部分的にはフォールトトレランスのため、部分的にはデータセットが大きすぎてメモリに収まらないという前提で、データをディスクに書き込みもします。 MapReduce アプローチは、大規模なジョブに適しています。
MapReduceの先に
データの量、データの構造、データに対して実行される処理の種類によっては、計算を表現するのに他のツールの方が適している場合があります。
中間状態の実体化
分散ファイル システム内の既知の場所にデータをパブリッシュすると、疎結合が可能になるため、ジョブは誰が入力を生成し、誰が出力を消費しているかを知る必要がなくなります。
データフロー エンジン
map reduceのこれら（中間状態の実体化など）の問題は、データフローエンジン(Spark, Tez, Flink, etc on Hadoop)で対処されており、高速に処理を実行することができます。これらのシステムは、いくつかの処理段階を通るデータフローを明示的にモデル化するため、データフロー エンジンとして知られています。
まとめ
以上、分散システムの問題について解説しました。
この章は少し難しい内容が多く、また、アカデミックな内容も一部含まれているので理解するのに時間がかかる可能性があります。
もし、内容が入ってこなければ、一旦次の章を読むことをオススメします。
分散システムの問題について特に重要な点を解説しました。ただし、非常に量が多いため解説していない部分が多々あります。詳細は本書を手にとってみて下さい。
いいなと思ったら応援しよう！
