シーケンス
ただ、ドキュメントやフォーラムを見て感じていくつかの時間のためのバッチおよびストリーミングによって行わFLINK作業は、デバッグや最適化には良い方法ではありません。実際に、私は慎重にちょうどコードでプログラマや、最もシンプルかつ直接的に見える、効果は非常に良いではない感じ、ドキュメントやフォーラムを勉強する方法はなかったです。
例えば、我々は、非技術的な人々はSQLプログラマの代わりに、直接実装アプリケーション、およびこれに基づいて、プラス画面上にいくつかのドラッグを使用してSQLを理解することができる上、理解していないベース、SQLエンジンにFLINK-SQLを構築しましたSQLアプリケーションを実装するドラッグを使用して、非技術者。同社の非常に大規模なデータソース、流通チャネルも非常に豊富で、我々は、SQLエンジンレーン、表シンク（データ配信）とUDFのテーブルソース（データソース）の広い範囲を実装しました（計算機）、ユーザは、トトは、大規模なデータ、計算モデル、並びに出版の、ライン上の操作を引っ張っ本当に簡単引っ張ることができます。
しかし、背景には、データは物事がしばしば起こるスキュー、それほど単純ではありません。例えば、大規模なデータソースとデータソースのデータ項目は、（例えば50％）で最もビッグデータ・ソースであれば、少し内部結合行うには非常にいくつかのキーを結合を使用、FLINKオプティマイザは、SQLを最適化するハッシュ結合に参加し、最終結果は、あなたが割り当てられTaskSlotsを達成何に関係なく、データの50％が特定のTaskSlotになってきたことを、このスロットまで遅い実行が資源を枯渇です。この場合には、好ましくは、スロット、フラグメンテーションによって並列に元の大規模なデータセットの全てに放送データの小さなセットです。ただし、SQL標準joinhintを指定する方法はありません、FLINKのSQLは、いくつかの変更がデバッグFLINKを通じて、この問題を解決するために行うことができる場所だけ見て、この機能をサポートしていません。私たちは、再びこのプログラムが可能かを確認するFLINKクライアント、FLINKオプティマイザから、実行時（ジョブ管理、タスクマネージャ）ソース、デバッグ中にブレークポイントを設定することで段階的にFLINK、データがそれを通って流れ、最後の章であります小さなデータセットが一緒に放送します。
読むために紙の一部を滑らかにするために、私はいくつかの章を通じてFLINKの概要を説明しましょう。