ストリーミング・システム

第5章. 正確な一回性と副作用

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

ここで、プログラミング・モデルやAPIの議論から、それらを実装するシステムの議論に移る。 モデルとAPIは、ユーザが何を計算したいかを記述することを可能にする。実際に計算を正確に実行するには、システムが必要である-通常は分散システムである。

この章では、実装システムがどのようにBeam Modelを正しく実装し、正確な結果を出すかに焦点を当てる。 ストリーミング・システムでは、しばしば "actly-once processing "について語られる。これは何を意味するのか、そしてどのように実装されるのかを説明する。

動機づけとなる例として、この章では、Google Cloud Dataflowがレコードのジャストワンス処理を効率的に保証するために使用するテクニックに焦点を当てる。章の終わりには、他の一般的なストリーミング・システムで使われている、正確に一度だけ処理することを保証するテクニックも紹介する。

なぜ正確な1回が重要なのか

多くのユーザにとって、データ処理パイプラインにおけるレコードの取りこぼしやデータ損失のリスクは許容できないものであることは言うまでもない。それでも、歴史的に多くの一般化ストリーミングシステムは、レコード処理について何の保証もしていなかった。しかし、レコードが重複する可能性がある（その結果、集計が不正確になる）。実際には、このようなat-least-onceシステムの多くは、メモリ内で集計を実行するため、マシンがクラッシュした場合でも集計が失われる可能性があった。このようなシステムは、遅延が少なく、投機的な結果を得るために使用されたが、一般的にこれらの結果の信憑性については何も保証できなかった。

第1章が指摘するように、これは、Lambdaアーキテクチャと呼ばれる戦略につながった。ストリーミング・システムを実行して、高速だが不正確な結果を得る。しばらくして（多くの場合、終業後に）、バッチシステムが正しい答えを得るために実行される。これは、データ・ストリームが再生可能な場合にのみ機能する。しかし、この戦略は十分なデータ・ソースに当てはまり、実行可能であることが証明された。それにもかかわらず、これを試した多くの人が、Lambdaアーキテクチャで多くの問題を経験した：

不正確さ

ユーザは障害の影響を過小評価する傾向がある。 レコードのごく一部が失われたり重複したりすると（多くの場合、自分が行った実験に基づいて）想定し、ある悪い日にレコードの10％（あるいはそれ以上！）が失われたり重複したりするとショックを受けることが多い。ある意味で、このようなシステムは「半分」の保証しか提供しない。

矛盾

終日計算に使われるバッチシステムは、ストリーミングシステムとはデータのセマンティクスが異なることが多い。 2つのパイプラインで同等の結果を出すことは、初期化で考えていたよりも難しいことが判明した。

複雑さ

定義上、Lambdaでは2つの異なるコードベースを書いて保守する必要がある。また、それぞれ障害モードが異なる2つの複雑な分散システムを実行し、維持しなければならない。最も単純なパイプライン以外では、これはすぐに圧倒的なものになる。

予測不可能性

多くのユースケースにおいて、エンドユーザは、ストリーミング（）の結果を目にすることになるが、その結果は、日次の結果とは不確定なものであり、ランダムに変化する可能性がある。このような場合、ユーザはストリーミング・データを信用しなくなり、代わりに日次のバッチ結果を待つようになるため、そもそも遅延の少ない結果を得る価値が失われる。 ...