Apache Flinkによるストリーム処理

第8章. 外部システムからの読み取りと外部システムへの書き込み

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

データ 、ファイルシステム、オブジェクトストア、リレーショナルデータベースシステム、キーバリューストア、検索インデックス、イベントログ、メッセージキューなど、さまざまなシステムに格納することができる。各クラスのシステムは、特定のアクセスパターンを想定して設計されており、特定の目的を果たすことに長けている。その結果、今日のデータインフラは多くの異なるストレージシステムで構成されていることが多い。新しいコンポーネントをミックスに加える前に、論理的な質問として、"スタック内の他のコンポーネントとどの程度うまく機能するか？"を問うべきである。

Apache Flinkのようなデータ処理システムを追加するには、慎重な検討が必要だ。なぜなら、Flinkは独自のストレージレイヤーを持たず、データの取り込みと永続化を外部ストレージシステムに依存しているからだ。したがって、Flinkのようなデータ処理システムにとって重要なのは、外部システムからデータを読み込んだり、外部システムにデータを書き込んだりするためのコネクタや、カスタムコネクタを実装するためのAPIを備えたライブラリを提供することである。しかし、外部データストアにデータを読み書きできるだけでは、障害発生時に意味のある一貫性保証を提供したいストリーム・プロセッサにとっては十分ではない。

この章では、ソースコネクタとシンクコネクタが Flink ストリーミングアプリケーションの一貫性保証にどのような影響を与えるかを説明し、データの読み取りと書き込みのための Flink の最も一般的なコネクタを紹介する。カスタムのソースコネクタとシンクコネクタを実装する方法と、外部データストアに非同期で読み取りまたは書き込み要求を送信する関数を実装する方法を学ぶ。

アプリケーションの一貫性保証

チェックポイント、セーブポイント、ステート・リカバリ" で、 を学んだ。Flink のチェックポイントとリカバリのメカニズムは、アプリケーションの状態の一貫したチェックポイントを定期的に取る。障害が発生した場合、アプリケーションの状態は完了した最新のチェックポイントから復元され、処理は続行される。しかし、アプリケーションの状態を一貫性のある点にリセットできるだけでは、アプリケーションの処理保証を満足させるには不十分である。その代わりに、アプリケーションのソース・コネクタとシンク・コネクタは、Flinkのチェックポイントとリカバリ・メカニズムと統合され、意味のある保証を与えることができるように、特定のプロパティを提供する必要がある。

、アプリケーションに1回きりの状態一貫性を提供する、¹アプリケーションの各ソース・コネクタは、その読み取り位置を以前にチェックポイントした位置にセットできる必要がある。チェックポイントを行う際、ソース演算子はその読み取り位置を永続化し、リカバリ時にこれらの位置を復元する。読み取り位置のチェックポイントをサポートするソース・コネクタの例としては、読み取りオフセッ トをファイルのバイト・ストリームに格納するファイル・ベースのソースや、読み取りオフセットを消費するトピッ ク・パーティションに格納する Kafka ソースがある。読み取り位置をストアおよびリセットできないソース・コネクタからアプリケーション がデータを取り込むと、障害が発生した場合にデータ損失が発生し、at-most-once ...