著者: David Anderson, Principal Software Practice Lead at Confluent Flink SQL は、既知の SQL 言語とそのベースのリレーショナルコンセプトを使用してリアルタイムでストリーミングデータを処理するのに設計された強力なエンジンです. これは、長い間、多くのアプリケーションドメイン、特に ETL パイプラインと分析ワークロードのための効果的なソリューションであり、しかし、これまで Flink SQL は、イベントドライブアプリケーションに必要な重要な機能を欠けていました。 ここで説明された最近の開発により、Apache FlinkのリレーシャルAPI(すなわち、Flink SQLおよびTable API)は、それらの強力な抽象と組み込まれたオペレーターを利用することにより、Flinkの低レベルのストリーム処理原始にアクセスすることに妥協する必要がなくなった。 ここで述べたすべては、Flink SQLとTable APIの両方に同様に適用されます. Both sit on top of the same runtime - the concepts and fundamental capabilities are the same - they are only accessed from Java or Python, rather than SQL, if you choose to use the Table API. 両方、同じランタイムの上に座っている - コンセプトと基本的な機能は同じです - あなたがTable APIを使用することを選択した場合、SQLではなくJavaやPythonからアクセスできます。 使用ケース これらのリレーショナル API は、特に 2 つの幅広いカテゴリのアプリケーションに適しています。 Agentic AI 現代のAIアプリケーションは、しばしばダイナミックでリアルタイムの情報へのアクセスを必要とします。Flink SQLは、リアルタイムのイベントストリームとエージェント、モデル、およびサービスからの洞察を組み合わせることを容易にすることにより、エージェントAIを容易にします。 Shift left データ処理の世界では、「shifting left」とは、データフローでできるだけ早くデータの変換と豊かさを実行することを意味します。FlinkのリレーショナルAPIは、リアルタイムの変換と他のデータセットの豊かさを可能にすることにより、ここで優れています。 ニュアンスと組み合わせた知恵 Flink SQL は、オンライントランザクション処理 (OLTP) とオンライン分析処理 (OLAP) のために開発されたよく考えられた概念とセマンティクスを採用し、リアルタイムストリーム処理アプリケーションの要件を満たすためにそれらを拡張します。 The relational algebra remains the same SQLの基盤を構成する関係アルジェベラの基本原則は、Flink SQLで完全に保存されています。 従来の SQL テーブルは静的である一方で、Flinks SQL はダイナミック テーブルの概念を導入します。 Tables: アグレグレーション(例えば「COUNT」、「SUM」、「AVG」)は、ストリームに適用され、データのリアルタイムの概要を提供します。 Aggregations: Flink SQL は、さまざまな Join オペレーションをサポートし、異なるストリーミング ソースからのデータを組み合わせることができます。これらは、従来の内部および外部の Joins から、より専門的なタイム  Joins にまで行うことができます。 Joins: 各 Flink SQL ステートメントは、ストリーム上のクエリの結果を継続的に計算し、頻繁にリクエストされるデータへの即時アクセスを可能にします。 Continuous queries (materialized views): New challenges and ideas for stream processing 一方、これらの関係概念をストリーム処理のダイナミックな世界に適用すると、いくつかの新しい考慮事項が導入されます。 例えば、統合は部分的に蓄積された結果を追跡する必要があり、結合は別のストリームからのレコードをバッファリングするのを待ちながら、1つのストリームからのレコードをバッファリングする必要があるかもしれません。 Thinking about state: ストリーム処理では、イベントは順序が異なる場合や遅延が伴う場合があります。 ウォーターマークは、ストリームの「完全性」の概念を提供することによって、これらの不規則性に対処するのに役立つFlinks SQLの重要なコンセプトです。 ウォーターマークは、Flinksがより早いタイムスタンプを持つイベントの到着を前提とし、一貫したウィンドウアグレギュレーションとタイムリーな結果を可能にすると仮定する限界を定義します。 Watermarks: Flink SQL には、タイムウィンドウの集計やウィンドウの結合など、いくつかの特殊なタイムバージョンが含まれており、その結果がいつ発信される準備ができているかを知るために、ウォーターマークに依存している(そして、保持していた状態がいつ解放されるか)。 最近の発展 最近の開発は、これらのリレーショナル API をこれまで以上に魅力的にしています。 Flink SQL と Table API は、User-Defined Functions (UDFs) を使用して高度に拡張可能で、Java または Python を使用して、SQL で直接表現できないカスタム ロジックを実装できます。 従来の UDF とは異なり、PTF は、Flink の管理状態およびタイマーサービスを使用して、完全なテーブル (ストリーム) を高度な方法で処理できます。 Process Table Functions (PTFs) ストリーミング Joins in Flink SQL Join Operations では、Flinks のリレーショナル API が従来の SQL データベースと比較して類似性や重要な違いを示しています。このセクションでは、上記の概念が joins を使用する実際のアプリケーションにどのように適用されるかについて実践的な例を使用しています。 たとえば、オンラインビジネスで注文と支払いを処理する場合、各支払いは外国のキー参照(orderId)によって1つの注文と関連付けられています。 効果があるように見える簡単な解決策は、 CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
);
 もちろん、実際のアプリケーションでは、顧客ID、配送アドレス、注文されている製品のIDなどのより多くの情報を出力しますが、この例をシンプルにし、大きな画面に焦点を当てましょう。 Flink コミュニティの発言では、このような Join は「定期的な Join」と呼ばれています(つまり Flink がそれをより効率的に実行できるように特別なことをしたわけではありません)。そして Flink SQL のストリーミング ランタイムによって実行された場合、定期的な Join は驚くほど高価です。 実際、この会社がそのビジネスをどのように運営しているかについての知識に基づいて、私たちは、各注文に最多1件の一致した支払いがあることを知ることができ、したがって、Flinkがその支払いが処理された時点を超えて注文を保存する必要はありません。 この加入を低コストにするために我々は、支払いが常に注文から2時間以内に発生すると仮定することができる(例えば): CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
  WHERE
    p.paymentTime BETWEEN o.orderTime AND o.orderTime + INTERVAL '2' HOUR
);
 これは、注文がFlinkのランタイム状態でどのくらい保存されているかを制限しますが、これは非常に満足できるアプローチではありません。一方で、支払いに匹敵すると、注文の状態を自由にしますが、他方で、いくつかの支払いは2時間以上遅れる可能性があります。 残念ながら、私たちがこの場合に理想的にやりたいという一対一のメッセージの豊かさは、標準のSQLコンセプトを使用して直接表現することはできません。 以下は、これがどう見えるかを簡素化した例です。 // Function that buffers one object from each side
// of the join to produce exactly one result.
public static class OrderPaymentJoin
  extends ProcessTableFunction<JoinResult> {

  public void eval(
    Context ctx,
    @StateHint(name = "result") JoinResult result,
    @ArgumentHint(SET_SEMANTIC_TABLE) Order order,
    @ArgumentHint(SET_SEMANTIC_TABLE) Payment payment
  ) {

    if (order != null) {
      if (result.orderId != null) {
        // Skip duplicates.
        return;
      } else {
        // Save the order and wait 
        // for the matching payment.
        result.orderId = order.id;
      }
    }

    if (payment != null) {
      if (result.paymentId != null) {
        // Skip duplicates.
        return;
      } else {
        // The order will precede the payment, but
        // we cannot guarantee the order will be
        // processed first. Save the payment
        // and wait for the matching order.
        result.paymentId = payment.id;
      }
    }
  
    if (result.orderId != null && 
        result.paymentId != null) {
      // Send out the final join result
      // and clear the state.
      collect(result);
      ctx.clearState("result");
    }
  }
}
 この PTF が存在すると、私たちの Join クエリは CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 実際には、この簡素化された例は、比較されていない注文(決して支払いを受けない注文)の数が増加する可能性について何かをするために拡張される可能性があります。 その他のエキサイティングな展開 Native support for ML models FLIP-437 (Flink 2.0 に含まれている) は、Flink SQL でファーストクラス市民としての機械学習モデルのサポートを追加しました。 Disaggregated state backend Flink コミュニティは、よりクラウドネイティブなステータス管理アプローチを開発しており、最終的には、アプリケーションが膨大な量のステータスを使用することをより実践的に行うことになります。これは、ストリーミングアプリケーションのステータス要件について考える必要性を決して排除することはありませんが、あなたが関連するトランザクションをどのように見るべきかを大幅に変更します。 もっと詳細へ 文書化 Semi-structured types Semi-structured data offers greater flexibility, such as allowing for fields to be added over time, optional fields, or fields whose type may vary from row to row. Currently, users of Flink's relational APIs must choose between ROWs with strict schemes and static types, or storing data as JSON strings. However, working with JSON has significant performance limitations.現在、FlinksのリレーショナルAPIのユーザーは、厳格なスケジュールと静的タイプのROWの間を選択する必要があります。 効率的に保存および処理できる半構造化データをサポートするために VARIANT タイプを追加しています。 フリップ521 より深い理解のために Flink SQLについてもっと知るには、 あなたを始めるでしょう。 この動画はContinuous Queriesです。 THE いくつかの素晴らしい例があります、もしあなたがこのテーマに深く浸りたい場合は。 プロセステーブル機能に関するドキュメント ショーン・ファルコーナーがなぜ . AIエージェントの未来はイベント駆動 AIエージェントの未来はイベント駆動

This story contains new, firsthand information uncovered by the writer.

このオーディオは、ストーリーの元の言語で制作されています。

Apache Flink の SQL および Table API の最新のアップデートについて知る必要があること

About Author

コメント

ラベル

この記事は

Related Stories

ワークフローを10倍に向上させる方法: 必須アプリ17選

ユニークなエコシステムを支えるビットコインUTXOのモデル

フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

ワークフローを10倍に向上させる方法: 必須アプリ17選

ユニークなエコシステムを支えるビットコインUTXOのモデル

フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps