データ集約型アプリケーションの設計 (Japanese Edition), 2nd Edition

第12章 ストリーム 処理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

機能する複雑なシステムは、必ず機能する単純なシステムから進化したものだと発見される。 逆の命題もまた真実のようだ：ゼロから設計された複雑なシステムは決して機能せず、 機能させることもできない。

ジョン・ガル『システムアンティクス』（1975年）

第11章ではバッチ処理について論じた。これは一連のファイルを入力として読み取り、 新たな出力ファイル群を生成するテクニックである。出力は派生データの一形態であり、 必要に応じてバッチ処理を再実行することで再構築可能なデータセットだ。この単純ながら強力な概念が、 検索インデックスや推薦システム、分析など様々な用途に活用できることを確認した。

しかし、第11章全体を通して大きな前提が一つあった。 すなわち、入力は境界を持つ——既知で有限のサイズである——ため、 バッチプロセスは入力の読み取りが完了した時点を把握できるという前提だ。 例えば、MapReduceの中核となるソート操作は、出力生成を開始する前に全入力を読み終えなければならない。最後の入力レコードが最小キーを持つ可能性があり、それが出力レコードの最初にならなければならないからだ。したがって、出力を早期に開始する選択肢はない。

現実には、多くのデータは時間をかけて徐々に到着するため、境界を持たない。ユーザは昨日も今日もデータを生成し、明日もさらに生成し続ける。事業が終了しない限りこのプロセスは終わらないため、データセットは意味のある意味で「完結」することはない[1]。 したがって、バッチ処理システムはデータを人為的に固定期間のチャンクに分割せざるを得ない。例えば、 毎日終了時に1日分のデータをプロセスする、あるいは毎時間終了時に1時間分のデータをプロセスするといった方法だ。

日次バッチ処理の問題点は、入力の変化が1日遅れて出力に反映されることで、多くのせっかちなユーザには遅すぎる。遅延を減らすには、処理頻度を上げる方法がある——例えば毎秒終了時に1秒分のデータを処理する、あるいは固定時間スライスを完全に放棄し、発生したイベントを逐次処理する連続処理だ。これがストリーム処理の考え方である。

一般的にストリームとは、時間とともに増分的に利用可能になるデータを指す。この概念は多くの場面で現れる：Unixの標準入力 ・標準出力、プログラミング言語（遅延リスト）[2]、ファイルシステムAPI（JavaのFileInputStreamなど）、TCP接続、インターネット経由で配信される音声・動画などである。

本章では、データ管理メカニズムとしてのイベントストリームを扱う。これは前章で見たバッチデータに対応する、境界がなく増分処理されるデータ形態である。まずストリームの表現方法、保存方法、ネットワーク経由での伝送方法を議論し、次にストリームとデータベースの関係を考察する。 最後に「ストリーム処理」では、これらのストリームを継続的に処理する手法とツール、そしてそれらを用いてアプリケーションを構築する方法を考察する。

イベントストリームの伝送

のバッチ処理環境では、ジョブの入力と出力はファイル（分散ファイルシステム上のものかもしれない）である。 これに対応するストリーミング処理はどのようなものか？

入力がファイル（バイト列）の場合、最初の処理ステップは通常、それをレコード列に解析することだ。ストリーム処理のコンテキストでは、レコードはより一般的に ...