Flink（エンハリメント）の複数のメタデータストリームと低レイテンシストリームの組み合わせ

Question

私はストリーミング分析シナリオでFlinkを評価しており、従来のETLセットアップの方法を満たす方法については十分な情報がありません今日のシステムです。

非常に一般的なシナリオは、我々がキーしていること、遅いスループットで、メタデータは、我々は、高スループットのデータ・ストリーム上での濃縮のために使用することをストリーム、の行で何か：

このFlinkに関する2つの質問を提起します：時間ウィンドウが重複するが、平等ではないストリームをゆっくりと更新しながら、速く動くストリームを豊かにするにはどうすればよいですか？（データが数分間生きる間、また、1つのデータストリームと9つの異なるエンリッチメントストリームなど、Flinkで複数（最大10）のストリームを効率的に結合するにはどうすればよいですか？

私は、ウィンドウズされていない外部ETLキャッシュ、たとえばRedis（現在使用しているもの）で自分のETLシナリオを実行できることを知っていますが、Flinkが提供する可能性を見てみたかったのです。

Answer 1

Flinkには、濃縮のために使用できるいくつかのメカニズムがあります。

すべてのストリームが対応するアイテムに参加するために使用できる共通のキーを共有していると仮定します。

最も簡単な方法は、おそらくRichFlatmapを使用し、open（）メソッド（docs about rich functions）で静的濃縮データを読み込むことです。これは、濃縮データが静的である場合、または濃縮データを更新するたびに濃縮作業を再開する意思がある場合にのみ適しています。

以下に説明する他の方法では、濃縮されたデータを管理されたキー状態（docs about working with state in Flinkを参照）として保存する必要があります。これにより、失敗した場合にFlinkが豊富なジョブを復元して再開できるようになります。

濃縮データに実際にストリームしたいと仮定すると、RichCoFlatmapが適切です。これは、2つの接続されたストリームをマージまたは結合するために使用できるステートフル演算子です。しかし、RichCoFlatmapでは、ストリーム要素のタイミングを考慮する能力がありません。たとえば、一方のストリームが他方のストリームよりも先に進んでいるか遅れているのかについて懸念があり、反復可能で決定論的な方法で濃縮を実行したい場合は、CoProcessFunctionを使用するのが適切な方法です。

Apache Flink training materialsに詳細な例とコードが記載されています。

参加するストリーム数が多い場合（たとえば10）、2入力の一連の2入力CoProcessFunction演算子をカスケードすることはできますが、それはある点ではかなり不愉快になります。代わりに、結合演算子を使用してすべてのメタデータストリームを結合します（これにはすべてのストリームが同じタイプでなければならないことに注意してください）。RichCoFlatmapまたはCoProcessFunctionは、このユニファイドエンリッチメントストリームをプライマリストリームに結合します。

更新：

FLINKの表とSQL APIは、ストリームの濃縮のためにも使用することができ、かつFLINK 1.4は、内側のストリーミングタイムウィンドウをジョイン追加することにより、このサポートを拡張します。 Table API joinsおよびSQL joinsを参照してください。たとえば、次の出荷が配置されるための4桁以内に発生した場合

SELECT * 
FROM Orders o, Shipments s 
WHERE o.id = s.orderId AND 
    o.ordertime BETWEEN s.shiptime - INTERVAL '4' HOUR AND s.shiptime 

この例では、それらの対応する出荷と注文を結合します。