1. ステータスとは
ステートレス計算の例:たとえば、初めて加算演算子を入力すると、2+3=5今後複数回データを入力した2+3ときに同じ結果が得られます5。結論としては、同じ入力は回数に関係なく同じ結果が得られます。
ステートフル コンピューティングの例:訪問の統計:Nginxアクセス ログにはリクエストごとに 1 つのログがあることは誰もが知っています。これに基づいて訪問をカウントできます。以下に示すように、/api/a最初urlの訪問では返される結果は ですcount1が、2 回目の訪問では返される結果は になります2。Flink以前に一度処理されたことがあるのはなぜですかhello world? ここで問題が発生します。前にカウントする必要があるデータを保存するstateために呼び出されます。インターフェイスの呼び出しにより、除算用のペアが作成されます。これは、次の前提条件です。使用。結論としては、同じ入力でも異なる結果が得られ、これは回数に関係します。これはステートフルなデータです。keyed statekeybykeyed streamkeykeyed state
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/bfe5bd6d492442988b1093be08422513.png)
この種のステータス データはどのようなシナリオで大量に使用されるのでしょうか? いくつか例を挙げてみましょう:
[1]重複を削除する必要がある場合、たとえば、100この
【2】ウィンドウ計算、未トリガーデータが入力されました。たとえば、統計は 1 分に 1 回カウントされますが、1-2その結果が関連しているため、1.5この時点のデータは2ステートフル データとなります。【3】機械学習/深層学習、学習済みモデルとパラメータ。これは機械学習の学生にとって深い印象です。たとえば、初めて を入力すると、マシンはフィードバックを返し、次回はこのフィードバックに基づいてさらなる学習と処理を行います。前のステップの結果は、私へのステートフルな入力になります。【4】過去のデータにアクセスするには、昨日と比較する必要があります。昨日のデータは今日の状態でもあります。じっくり味わって味わってください。21.5
hello
なぜ状態管理が必要なのでしょうか? メモリを使用するのは良いことではないでしょうか? まず、チャーン操作には独自の基準があり、単にチャーン処理と言えるものではありません。まず、24時間365日稼働しており信頼性が高いですが、メモリが少ないといずれ容量を使い果たしてしまいます。第二に、データが失われていない場合、データは重くなりませんが、一度だけ計算された場合、メモリのバックアップと復元が必要になり、常にデータのごく一部の損失が伴います。最後に、データは遅延なくリアルタイムに生成されますが、メモリが足りない場合は水平展開を遅らせる必要があります。
理想的な状態管理は以下で説明するものであり、Flink私たちはそれを実現しています。
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/74dfefe7bc7a4a529ae517cc496f7521.png)
2. ステータスの種類
管理された状態と生の状態
| 管理された状態 | 生の状態 | |
|---|---|---|
| ステータス管理方法 | Flink ランタイム管理 - 自動ストレージ、自動リカバリ - 最適化されたメモリ管理 | ユーザーが自分で管理します (Flink は State に保存したデータ構造を知りません) - 自分でインスタンス化する必要があります |
| ステータスデータ構造 | 既知のデータ構造 - 値、リスト、マップなど | バイトデータ—byte[] |
| 推奨される使用シナリオ | ほとんどの場合に使用できます | Operator をカスタマイズするときに使用できます (管理状態が十分でない場合に使用) |
Managed Stated は、次の Keyed StatedものとOperator State
[1] Keyed Stated:keyBy生成にのみ使用できるKeyedStream演算子に分かれています。それぞれがkey1 つに対応しState、1 つのOperatorインスタンスが複数の を処理しKey、対応する複数の にアクセスしますState。同じものはKey同じインスタンスで処理されます。keyByプロセス全体に操作がなければ無駄でありKeyedStream、Keyed Stated適用することしかできませんKeyedStream 。
同時変更: Stateインスタンス間での移行時Key。たとえば、インスタンス内で との前をA処理し、その後 インスタンス を拡張すると、インスタンスは処理するだけで済み、処理のためにインスタンスに渡されます。設置状況が分離されており、分散していることが分かります。KeyAKeyBBAKeyAKeyBB
RuntimeContext を通じてアクセスされる場合、説明はOperator1 つですRich Functionが、それ以外の場合は取得できませんRuntimeContext。
サポートされているデータ構造: ValueState、ListState、ReducingState、AggregatingState、MapState
【2】演算子の状態:すべての演算子に使用できます。sourceたとえば、 でよく使用されますFlinkKafkaConsumer。1 つのOperatorインスタンス は 1 つの インスタンス に対応するStateため、Operator複数の インスタンス は 1 つの インスタンス で処理されkey、クラスターとして理解できます。
同時変更: Operator Stateいいえkey、同時変更が発生した場合は再割り当てが必要です。均等配分と全額を取得するための結合という 2 つの組み込みソリューションがあります。
アクセス方法:実装CheckpointedFunctionまたはListCheckpointedインターフェイス。
サポートされているデータ構造: ListState
3. Keyed Stateの使用例
キー付き状態とは:にはkeyed state2 つの特性があります: [1] KeyedStream の関数と操作(例: )
にのみ適用できます; [2]パーティション化/分割されており、各キーは にのみ属することができます。特定のキー付き状態. ;パーティショニングの概念を理解するには、セマンティクスを確認する必要があります。下の図の左側に 3 つの同時実行性があり、右側にも 3 つの同時実行性があることがわかります。左の言葉が入ってきたら、それに応じて分配されます。たとえば、この単語は常に右下に移動し、同時に上に移動します。Keyed UDFwindow statekeyed statekeybykeybyhello wordhellohashtask
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/0fa22dc275054473a2fd61f68d86b68f.png)
オペレーター状態とは
[1] とも呼ばれnon-keyed state、それぞれはoperator state1 つのインスタンスのみにバインドされますoperator。
【2】一般的な例operator stateは、source state現在のコードを記録してsourceから、使用されているコードoffsetの一部を確認することです。operator stateword count
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/0fc4b3a77d3a48f3a5329aba2aa31615.png)
ここでfromElements呼び出されるクラスはFromElementsFunctionの型を使用しlist stateますoperator state。次のタイプKeyed State間の依存関係はすべて のstateサブクラスです。それらのアクセス方法とデータ構造には特定の違いがあります。
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/c45fa1db62c94783b638e6cd690b7dd7.png)
| ステータスのデータ型 | アクセスインターフェース | 述べる | |
|---|---|---|---|
| 値の状態 | 単一の値 | [更新(T)変更/T値取得] | たとえば、WordCount は word をキーとして使用し、state は単一の値です。この単一項目は文字列やオブジェクトなどにすることも可能です。アクセスする方法は 2 つだけです。 |
| 地図の状態 | 地図 | put(UK キー, UV 値) putAll(Map<UK,UV> マップ) Remove(UK キー) boolean contains(UK キー) UV get(UK キー) Iterable<Map.Entry> エントリ() Iterable<Map.Entry> iterator() 反復可能なキー() 反復可能な値() | 特定のオブジェクトを操作できるキー |
| リスト状態 | リスト | add/ addAll(List) update(List) Iterable get() | |
| 還元状態 | 単一の値 | add/ addAll(List) update(List) T get() | List と同じ親クラスであり、この追加により、Reducing 結果にデータが直接更新されます。たとえば、1 分間の結果をカウントする場合、最初にデータがリストに追加され、1 分後にすべてのデータがカウントされます。削減すると、結果ごとに 1 つの結果がカウントされます。利点はメモリを節約できることです。 |
| 集約状態 | 単一の値 | add(IN)/OUT get() | Listと同じ親クラスですが、Reducingとの違いは入力と出力の型が同じであることです。集約は異なる場合があります。たとえば、タイの値を計算したい場合、Reducing では計算結果が返され、Aggregating では合計と数値が返されます。 |
ValueStateケースを与える
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
//获取数据流
DataStream<Event> events = env.addSource(source);
DataStream<Alert> alerts = events
// 生成 keyedStata 通过 sourceAddress
.keyBy(Event::sourceAddress)
// StateMachineMapper 状态机
.flatMap(new StateMachineMapper());
//我么看下状态机怎么写 实现 RichFlatMapFunction
@SuppressWarnings("serial")
static class StateMachineMapper extends RichFlatMapFunction<Event, Alert> {
private ValueState<LeaderLatch.State> currentState;
@Override
public void open(Configuration conf) {
// 获取一个 valueState
currentState = getRuntimeContext().getState(
new ValueStateDescriptor<>("state", State.class));
}
//来一条数据处理一条
@Override
public void flatMap(Event evt, Collector<Alert> out) throws Exception {
// 获取 value
State state = currentState.value();
if (state == null) {
state = State.Initial;//State 是本地的变量
}
// 把事件对状态的影响加上去，得到一个状态
State nextState = state.transition(evt.type());
//判断状态是否合法
if (nextState == State.InvalidTransition) {
//扔出去
out.collect(new Alert(evt.sourceAddress(), state, evt.type()));
}
//是否不能继续转化了，例如取消的订单
else if (nextState.isTerminal()) {
// 从 state 中清楚掉
currentState.clear();
}
else {
// 修改状态
currentState.update(nextState);
}
}
}
4. CheckPoint と状態の関係
Checkpointこれは、トリガーからすべての下流ノードの完了までのグローバル操作ですsource。次の図は、正しい直観的な感覚を与えることができます。赤いボックス内で、合計で 2回トリガーされ、すべてが正常に完了したことCheckpointがわかります。そのようなことはありません。569KCheckpointfail
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/1e57eba878a644c6815cb4ecf30be85c.png)
**状態は実際には、チェックポイントによって作成されたメイン永続バックアップのメイン データです。**下の図の特定のデータ統計を見てください。これはサイズstateでもあります。9kb
![[クリックしてドラッグして移動します]](https://img-blog.csdnimg.cn/direct/018fd963f44344cea42b1b8302898da5.png)
5. ステータスの保存と復元方法
Checkpoint定期的に分散スナップショットを作成して、プログラムの状態をバックアップします。失敗した場合は、ジョブ全体をTask最後に成功したCheckpoint状態にロールバックし、保存された時点から処理を続行します。
必要な条件:データ ソースが再送信をサポートしている (再送信しない場合、失われたメッセージは実際に失われます)
一貫性セマンティクス:少なくとも 1 回 (p同じ、単一スレッド、複数スレッドの場合、一部の演算子は一度計算され、一部の演算子は一度計算されていない可能性があるため、注意する必要があります)。
// 获取运行环境
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
//状态数据
//两个checkpoint 触发间隔设置1S，越频繁追的数据就越少，io消耗也越大
env.enableCheckpointing(1000);
//EXACTLY_ONCE语义说明 Checkpoint是要对替的，这样消息不会重复，也不会对丢。
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
//两个checkpoint 最少等待500ms 例如第一个checkpoint做了700ms按理300ms后就要做下一个checkpoint。但是它们之间的等待时间300ms<500ms 此时，就会延长200ms减少checkpoint过于频繁，影响业务。
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
//checkpoint多久超时，如果这个checkpoint在1分钟内还没做完，那就失败了
env.getCheckpointConfig().setCheckpointTimeout(60000);
//同时最多有多少个checkpoint进行
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
//当重新分配并发度，拆分task时，是否保存checkpoint。如果不保存就需要使用savepoint来保存数据，放到外部的介质中。
env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION);
チェックポイントとセーブポイント
| チェックポイント | セーブポイント | |
|---|---|---|
| トリガー管理方法 | Flink によって自動的にトリガーおよび管理されます | ユーザーによって手動でトリガーおよび管理されます |
| 主目的 | ネットワークジッターによるタイムアウト例外など、タスク例外が発生した場合に迅速に回復します。 | コードの変更や同時実行性の調整などのジョブを停止して再開できるように、計画的なバックアップを実行します。 |
| 特徴 | 軽量、障害から自動的にサービスされ、ジョブの停止後にデフォルトでクリアされる | 耐久性があり、標準形式で保存されるため、コードまたは構成の変更によりセーブポイントのリカバリを手動でトリガーできます。 |
オプションの状態保存方法:
[1] MemoryStateBackend: 構築方法:
MemoryStateBackend(int maxStateSize, boolean asynchronousSnapshots)
保存方法: State :TaskManagerメモリ。Checkpoint：JobManagerメモリ。
容量制限:State maxStateSizeデフォルトは 1 つです5M。maxStateSize <= akka.framesizeデフォルト10M。合計サイズがJobManagerメモリを超えることはありません。
推奨される使用シナリオ:ETL/JobManagerローカル テスト、ほぼステートレスなジョブ (ハングしにくい状況や影響がほとんどない状況など) 。運用シナリオでの使用はお勧めしません。
【2】FsStateBackend：構築方法：
FsStateBackend(URL checkpointDataUri, boolean asynchronousSnapshots)
保存方法: State :TaskManagerメモリ。Checkpoint: 外部ファイル システム (ローカルまたはHDFS)。
容量制限:単一TaskManagerデバイスの合計容量はState、そのメモリを超えません。合計サイズは、構成されたファイル システムの容量を超えません (定期的にクリーンアップされます)。
推奨される使用シナリオ:分単位のウィンドウ集計など、通常の使用状況のジョブjoin。開始する必要があるジョブHA。実稼働環境でも使用できます。
【3】RocksDBStateBackend：構築方法：
RocksDBStateBackend(URL checkpointDataUri, boolean enableIncrementalCheckpointing)
保存方法: State :TaskManagerデータベースKV(メモリ + ディスクの実使用量)。Checkpoint: 外部ファイル システム (ローカルまたはHDFS)。
容量制限:単一TaskManagerデバイスの合計容量は、単一デバイスの最大値であるStateメモリ + ディスクを超えません。合計サイズは、構成されたファイル システムの容量を超えません。推奨される使用シナリオ:日レベルのウィンドウ集計など、非常に大きなステータスを持つジョブ。開始する必要があるジョブ。比較的高いステータスの読み取りおよび書き込みパフォーマンスを必要とするジョブ。実稼働環境でも使用できます。key2G
HA