上記のFlink の開始から放棄まで (12) - 企業での実際の戦闘でイベント駆動型シナリオの落とし穴を踏む (1) では、イベント駆動型シナリオに基づくチャネル トラフィック分析に対する Flink のリアルタイムのニーズと落とし穴を紹介しました。
この記事では、イベント駆動型のシナリオに基づいて説明を続け、応答の適時性、サービス品質要件スキームの設計、および遭遇した落とし穴を説明します (Flink のトピックに関するすべての記事は整理され、オンラインの Tencent ドキュメントに同期され、関連するその他の知識ポイントが含まれています)。この記事で使用できるドキュメントで表示し、バックグラウンドで [ドキュメント] に返信してリンクを取得します)。
需要の背景
対応の適時性とサービス品質の要件は、さまざまなビジネス シナリオに適用できます。実例として、いくつかの食品配送プラットフォームで支払い対象の商品を選択して注文し、加盟店の注文受付のリンクを入力します.この時点で、加盟店の注文受付の効率を分析し、この加盟店をランク付けしたいと考えています.顧客の評価データに基づいて、注文の効率化を待ち時間の計算に反映させたり、加盟店に到達するための早期警告メカニズムと組み合わせていくつかのルールを適用したりできます。
デザイン
ここでのリアルタイム計算の待機時間は、実際には前回の記事の実際のケースと同じですが、まだいくつかの違いがあります. 前回の記事では、インジケーター値を復元または初期化するために定期的に 1 回トリガーするだけで済みます. この需要では、注文から注文を受け取るまでのプロセス中に注文にイベントがないため、マーチャントが注文を受け入れるまで待機してトリガーするのではなく、リアルタイムで待機時間を計算することは困難です。計算. 待ち時間を取得します.
したがって、この要件では、循環ドライブ イベントをどのように生成するかが最大の難点です。ここで、エディターは、下の図に示すように、設計にキュー シャント
のアイデアを採用します:プロセスの詳細は次のとおりです:
1. データ ソース Kafka からデータを消費し、次にシャント;
2. 未決注文を3. 一時キューから処理対象の注文を取り出し、永続
ストレージから注文の最新ステータスを問い合わせる. 注文が処理済みの場合、注文は一時キューから破棄されます.一時キュー; 注文がまだ処理されていない場合, その後、処理の次のステップのために結果キューに入れます
4. 結果キューからまだ保留中の注文を取得し、永続ストレージ システムから最新のステータスを照会します.保留中の場合、一時的にキューに戻されます 処理のためにキューで待機中、注文が処理されている場合は破棄されます 5.
結果キューから計算する必要がある最後の注文が下流に出力されます。計算時間も十分です。
工学実習
上記のスキーム設計によると、キューと永続ストレージが関係しています。技術の選択に関しては、企業の実情に合わせて選択することができます。実装方法は、Flink SQL または Jar のいずれかです。
ここでエディターは一般的な解決策を選択します。つまり、キューは Kafka に基づいており、永続ストレージはディメンション テーブルの関連付けとして HBase を使用します。実装方法は、最初に参照用に SQL の疑似コードを使用します。
--输出队列
insert into real_dwd_order_info
select
t1.*
from
( --临时队列
select *,PROCTIME() as proctime
from real_tmp_order_info_from_kafka
)t1
left join real_dim_order_info_to_hbase FOR SYSTEM_TIME AS OF t1.proctime t2 --维度关联最新订单状态
on t1.order_id = t2.order_id
where t2.order_id is null or t2.order_status='待处理'
--回流到临时队列
insert into real_tmp_order_info_from_kafka
select
t1.*
from
( --输出队列
select *,PROCTIME() as proctime
from real_dwd_order_info
)t1
left join real_dim_order_info_to_hbase FOR SYSTEM_TIME AS OF t1.proctime t2 --维度关联最新订单状态
on t1.order_id = t2.order_id
where t2.order_id is null or t2.order_status='待处理'
下の図に示すように、上記のスキームは実現可能です。
ピットを踏んでピットを埋める
上記の解決策は実現できますが、次のようないくつかの欠点があります。
1. ディメンション テーブルは頻繁にクエリされ、最新の注文ステータスを取得する必要があるため、キャッシュ制御に一定のトレードオフが必要です。
2.一時キューと出力キューは周期的な状態にあり、必然的にストレージリソースの深刻な浪費につながり、下流の計算に影響を与えます.バックプレッシャーが発生する可能性があり、適時性に一定の影響があります. ここで、実際の状況に応じて通常のループで駆動できるかどうかを検討できます (構造を調整する必要があるだけです)
3. ループ駆動の逆流の特性により、下流のデータの変動がより明白になる場合があります (リトレースメント問題、質問 2 と同様)