von: David Anderson, Leader Software Practice bei Confluent Flink SQL ist eine leistungsstarke Engine, die für die Verarbeitung von Echtzeit-Streaming-Daten mit der vertrauten SQL-Sprache und ihren zugrunde liegenden Beziehungskonzepten entwickelt wurde. Dies ist seit langem eine effektive Lösung für viele Anwendungsdomänen, insbesondere ETL-Pipelines und analytische Workloads, aber bis jetzt fehlte Flink SQL an Schlüsselfunktionen, die oft für Ereignis-basierte Anwendungen benötigt wurden. Mit den hier beschriebenen jüngsten Entwicklungen sind die relationalen APIs von Apache Flink – nämlich Flink SQL und die Table API – bis zu dem Punkt reif geworden, an dem die Nutzung ihrer leistungsstarken Abstraktionen und eingebauten Operatoren keine Kompromisse mehr für den Zugriff auf Flink's Low-Level-Stream-Prozessing-Primitiven erfordert. Alles, was hier gesagt wird, gilt gleichermaßen sowohl für Flink SQL als auch für die Tabellen-API. Beide sitzen oben auf der gleichen Laufzeit - die Konzepte und grundlegenden Fähigkeiten sind die gleichen - sie werden nur aus Java oder Python zugegriffen, anstatt SQL, wenn Sie die Tabellen-API verwenden. Verwenden von Fällen Diese relationalen APIs eignen sich besonders gut für zwei breite Kategorien von Anwendungen. Agentic AI Moderne KI-Anwendungen erfordern oft den Zugriff auf dynamische, Echtzeit-Informationen. Flink SQL erleichtert die Agentische KI, indem es einfach ist, Echtzeit-Ereignisströme mit Einblicken von Agenten, Modellen und Diensten zu kombinieren. Shift left In der Welt der Datenverarbeitung bezieht sich "Shifting left" auf die Durchführung von Datentransformationen und -anreicherungen so früh wie möglich im Datenfluss.Flink's relationale APIs übertreffen sich hier, indem sie Echtzeit-Transformationen und -anreicherungen mit anderen Datensätzen ermöglichen. Bekanntschaft kombiniert mit Neugier Flink SQL nimmt die gut durchdachten Konzepte und Semantik für Online Transaction Processing (OLTP) und Online Analytical Processing (OLAP) entwickelt und erweitert sie, um die Anforderungen von Echtzeit-Stream-Verarbeitungsanwendungen zu erfüllen. The relational algebra remains the same Die grundlegenden Prinzipien der relationalen Algebra, die den Grundstein von SQL bilden, sind in Flink SQL vollständig erhalten. Während traditionelle SQL-Tabellen statisch sind, führt Flink SQL das Konzept der dynamischen Tabellen ein, die logische Repräsentationen kontinuierlicher, grenzenloser Datenströme sind. Tables: Aggregationen (z.B. „COUNT“, „SUMM“, „AVG“) werden auf Streams angewendet und liefern Echtzeitübersicht der Daten. Aggregations: Flink SQL unterstützt verschiedene Join-Operationen, die die Kombination von Daten aus verschiedenen Streaming-Quellen ermöglichen. Diese können von traditionellen inneren und äußeren Joins bis hin zu spezialisierteren temporalen Joins reichen. Joins: Jede Flink SQL-Anweisung berechnet kontinuierlich das Ergebnis einer Abfrage auf Streams und ermöglicht sofortigen Zugriff auf häufig angeforderte Daten. Continuous queries (materialized views): New challenges and ideas for stream processing Auf der anderen Seite führt die Anwendung dieser relationalen Konzepte auf die dynamische Welt der Stromverarbeitung einige neue Überlegungen ein: Stream-Verarbeitungsvorgänge müssen häufig "Status" - Informationen über vergangene Ereignisse - beibehalten, um ihre Berechnungen durchzuführen. Zum Beispiel muss eine Aggregation das teilweise angesammelte Ergebnis verfolgen, und ein Join muss möglicherweise Aufzeichnungen von einem Stream buchen, während sie auf die Übereinstimmung von Aufzeichnungen von einem anderen warten. Entwickler, die Flink SQL (oder die Tabellen-API) verwenden, müssen das Statusmanagement sorgfältig in Betracht ziehen, da übermäßiger Zustand die Leistung und den Ressourcenverbrauch beeinflussen kann. Thinking about state: Wasserzeichen sind ein entscheidendes Konzept in Flink SQL, das hilft, mit diesen Unregelmäßigkeiten umzugehen, indem es eine Vorstellung von "Vollständigkeit" für Streams bietet. Wasserzeichen definieren eine Schwelle, nach der Flink davon ausgeht, dass keine weiteren Ereignisse mit einem früheren Zeitstempel ankommen werden, was konsistente Fensteraggregationen und rechtzeitige Ergebnisse ermöglicht. Watermarks: Flink SQL enthält eine Reihe von speziellen zeitlichen Versionen von staatlichen Operationen, wie z. B. Zeitfensteraggregationen und Fensterverbindungen, die sich auf Wasserzeichen verlassen, um zu wissen, wann ihre Ergebnisse bereit sind, ausgegeben zu werden (und wann der Zustand, den sie halten, freigegeben werden kann). jüngste Entwicklungen Die jüngsten Entwicklungen machen diese relationalen APIs überzeugender denn je. Flink SQL und die Tabellen-API sind durch die Verwendung von User-Defined Functions (UDFs) sehr erweiterbar. Diese ermöglichen es Java oder Python, benutzerdefinierte Logik zu implementieren, die nicht direkt in SQL ausgedrückt werden kann. sind ein neuer Geschmack von UDF, der gerade als Teil von Flink eingeführt wurde 2.1. Im Gegensatz zu herkömmlichen UDFs können PTFs ganze Tabellen (Streams) auf anspruchsvolle Weise verarbeiten, indem sie den verwalteten Zustand und die Timerdienste von Flink verwenden. Process Table Functions (PTFs) Streaming Joins in Flink SQL Join Operations veranschaulichen die Ähnlichkeiten und entscheidenden Unterschiede in den relationalen APIs von Flink im Vergleich zu herkömmlichen SQL-Datenbanken.Dieser Abschnitt verwendet einige praktische Beispiele, um zu erforschen, wie die oben dargestellten Konzepte auf reale Anwendungen angewendet werden können, die Joins verwenden. Betrachten Sie zum Beispiel ein Online-Geschäft zur Bearbeitung von Bestellungen und Zahlungen, bei dem jede Zahlung durch eine Fremdschlüssel-Referenz (die OrderId) zu einer Bestellung verknüpft ist. Eine einfache Lösung, die scheint zu funktionieren, ist 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
);
 Natürlich würden wir in einer echten Anwendung eine Menge mehr Informationen in die Ausgabe ziehen, wie z. B. die Kunden-ID, ihre Versandadresse und die IDs der bestellten Produkte. In der Rede der Flink-Community wird ein Join wie dieser als "regelmäßiger Join" bezeichnet (was bedeutet, dass wir nichts Besonderes getan haben, um Flink zu ermöglichen, es effizienter auszuführen). Und wenn es von Flink SQLs Streaming-Laufzeit ausgeführt wird, können regelmäßige Joins überraschend teuer sein. In der Tat, basierend auf unserem Wissen darüber, wie dieses Unternehmen sein Geschäft führt, könnten wir wissen, dass jede Bestellung höchstens eine entsprechende Zahlung haben wird, und so gibt es keine Notwendigkeit für Flink, eine Bestellung über den Punkt zu speichern, an dem ihre Zahlung verarbeitet wurde. Eine Sache, die wir tun könnten, um diesen Beitritt billiger zu machen, wäre anzunehmen, dass Zahlungen immer innerhalb von zwei Stunden nach der Bestellung erfolgen (zum Beispiel): 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
);
 Dies wird begrenzen, wie lange die Bestellungen im Flink-Laufzeit-Zustand gespeichert werden, aber es ist kein sehr befriedigender Ansatz. Auf der einen Seite würden wir lieber den Bestellstatus freigeben, sobald er mit einer Zahlung übereinstimmt, und auf der anderen Seite könnten einige Zahlungen für mehr als 2 Stunden verzögert werden. Leider kann die One-to-One-Berichterstattung, die wir idealerweise in diesem Fall tun möchten, nicht direkt mit Standard-SQL-Konzepten ausgedrückt werden. Hier ist ein vereinfachtes Beispiel dafür, wie dies aussehen könnte: // 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");
    }
  }
}
 Mit diesem PTF wird unsere Join-Abfrage CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 In der Praxis könnte dieses vereinfachte Beispiel erweitert werden, um etwas über die Möglichkeit zu tun, eine zunehmende Anzahl von unübersichtlichen Aufträgen (Aufträge, die niemals Zahlungen erhalten) zu akkumulieren. Weitere spannende Entwicklungen Native support for ML models FLIP-437 (in Flink 2.0 enthalten) fügte Unterstützung für maschinelle Lernmodelle als erstklassige Bürger in Flink SQL hinzu. Disaggregated state backend Die Flink-Community entwickelt einen cloudbasierten Ansatz für das staatliche Management, der es für Anwendungen letztendlich praktischer machen wird, enorme Mengen an Zustand zu verwenden. Dies wird niemals die Notwendigkeit beseitigen, über die Zustandsanforderungen Ihrer Streaming-Anwendungen nachzudenken, aber es wird erheblich verändern, wie Sie die einschlägigen Kompromisse betrachten sollten. Für mehr Details. Dokumentation Semi-structured types Semi-strukturierte Daten bieten eine größere Flexibilität, wie z. B. das Hinzufügen von Feldern im Laufe der Zeit, optionale Felder oder Felder, deren Typ von Zeile zu Zeile variieren kann. Derzeit müssen Benutzer von Flink-relationalen APIs zwischen ROWs mit strengen Schemata und statischen Typen wählen oder Daten als JSON-Stränge speichern. Es wird ein VARIANT-Typ hinzugefügt, um halbstrukturierte Daten zu unterstützen, die effizient gespeichert und verarbeitet werden können. Fliegen 521 Für ein tieferes Verständnis Um mehr über Flink SQL zu erfahren, Du wirst beginnen. Dieses Video auf kontinuierlichen Abfragen Die hat mehrere hervorragende Beispiele, wenn Sie tiefer in dieses Thema eintauchen möchten. Dokumentation über Prozesstabellenfunktionen Sean Falconer erklärt, warum . Die Zukunft der KI-Agenten ist Event-Driven Die Zukunft der KI-Agenten ist Event-Driven

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

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Was Sie über die neuesten Updates für die SQL- und Tabellen-API von Apache Flink wissen müssen

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our AI Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our AI Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps