Geskryf deur: David Anderson, hoof sagteware praktyk leiers by Confluent Flink SQL is 'n kragtige enjin ontwerp vir die verwerking van real-time, streaming data met behulp van die bekende SQL taal en sy onderliggende relasionele konsepte.Dit is lank 'n effektiewe oplossing vir baie toepassingsdomeine, veral ETL pipelines en analitiese werkloads, maar tot dusver het Flink SQL ontbreek belangrike funksies wat dikwels vereis word vir gebeurtenis-gedrewe programme. Met die onlangse ontwikkelings wat hier beskryf word, het Apache Flink se relasionele API's - naamlik, Flink SQL en die Tabel-API - tot die punt aangetref waar die benutting van hul kragtige abstraksies en ingebouwde operateurs nie meer vereis om kompromieer te maak met die toegang tot Flink se lae vlak verwerking primitiewe. Alles wat hier gesê word, is ewe van toepassing op beide Flink SQL en die Tabel API. Beide sit op dieselfde runtime - die konsepte en basiese vermoëns is dieselfde - hulle word net van Java of Python toeganklik, eerder as SQL, as jy kies om die Tabel API te gebruik. Gebruik die gevalle Hierdie relasionele API's is veral goed geskik vir twee breë kategorieë van toepassings. Agentic AI Moderne AI-toepassings vereis dikwels toegang tot dinamiese, real-time inligting. Flink SQL fasiliteer agentlike AI deur dit maklik te maak om real-time gebeurtenisstrome te kombineer met insigte van agente, modelle en dienste. Shift left In die wêreld van dataverwerking verwys "verander links" na die uitvoering van data transformasies en verrykings so vroeg as moontlik in die data vloei. Flink se relatiewe API's uitsteek hier deur real-time transformasies te toelaat, en verryk met ander datasette. Bekendheid gekombineer met nuwigheid Tradisionele, SQL is gebruik vir beide operasionele en analitiese gebruik gevalle. Flink SQL neem die goed-gedankte konsepte en semantiek ontwikkel vir Online Transaction Processing (OLTP) en Online Analytical Processing (OLAP), en brei dit uit om te voldoen aan die vereistes van real-time stroom verwerking toepassings. The relational algebra remains the same Die fundamentele beginsels van relasionele algebra, wat die basis van SQL vorm, word ten volle bewaar in Flink SQL. Terwyl tradisionele SQL-tabelle statiese is, stel Flink SQL die konsep van dinamiese tabelle in, wat logiese verteenwoordigings van voortdurende, onbeperkte datastrome is. Tables: Aggregasies (bv. 'COUNT', 'SUM', 'AVG') word toegepas op strome, wat real-time ooreenkomste van data verskaf. Aggregations: Flink SQL ondersteun verskeie joint-operasies, wat die kombinasie van data van verskillende streaming bronne toelaat. Dit kan wissel van tradisionele interne en eksterne joins tot meer gespesialiseerde tydsjoins. Joins: Elke Flink SQL-verklaring bereken voortdurend die resultaat van 'n query op streams, wat onmiddellike toegang tot dikwels versoekte data toelaat.Dit is basies dieselfde operasie wat tradisionele databasisse doen wanneer hulle incrementele gemateraliseerde weergave onderhou. Continuous queries (materialized views): New challenges and ideas for stream processing Aan die ander kant, die toepassing van hierdie relasionele konsepte op die dinamiese wêreld van stroomverwerking stel 'n paar nuwe oorwegings in: Stream verwerkingsoperasies moet dikwels "staat" behou - inligting oor verlede gebeure - om hul berekenings uit te voer. Byvoorbeeld, 'n aggregering moet die gevolgtrekking van sy gedeeltelik geaccumuleerde resultaat hou, en 'n aansluiting moet rekords van een stroom buffer terwyl hulle wag vir ooreenstemmende rekords van 'n ander. Ontwikkelaars wat Flink SQL (of die Tabel API) gebruik, moet versigtig oorweeg state management, aangesien oormatige toestand prestasie en hulpbronneverbruik kan beïnvloed. Thinking about state: In stroomverwerking kan gebeurtenisse uit die orde of met vertragings kom. Watermarke is 'n belangrike konsep in Flink SQL wat help om hierdie onregelmatighede te hanteer deur 'n idee van "volledigheid" vir strome te verskaf. Watermarke definieer 'n drempel waarna Flink aanneem dat geen meer gebeurtenisse met 'n vroeër tydstempel sal aankom, wat konsekwente vensteraggregaassies en tydige resultate toelaat. Watermarks: Flink SQL bevat 'n aantal spesiale tydelike weergawes van stateful-operasies, soos tyd-venstersagregasies, en windowed joins, wat vertrou op watermerke om te weet wanneer hul resultate gereed is om uitgegee te word (en wanneer die staat wat hulle gehou het, kan vrygelaat word). Onlangse ontwikkelings Onlangse ontwikkelings maak hierdie relatiewe API's meer oortuigend as ooit. Flink SQL en die Tabel API is hoogs uitbreidbaar deur die gebruik van User-Defined Functions (UDFs). Hierdie toelaat dat Java of Python gebruik kan word om aangepaste logika te implementeer wat nie direk in SQL uitgedruk kan word nie. is 'n nuwe smaak van UDF wat net ingesluit is as deel van Flink 2.1. In teenstelling met tradisionele UDF's, kan PTF's hele tabelle (stroom) op 'n gesofistikeerde manier verwerk, met behulp van Flink se bestuurde toestand en timer dienste. Process Table Functions (PTFs) Streaming Joins in Flink SQL Join operations illustreer die ooreenkomste en belangrike verskille in Flink se relatiewe API's in vergelyking met tradisionele SQL databasis. Hierdie afdeling gebruik 'n paar praktiese voorbeelde om te ondersoek hoe die konsepte wat hierbo aangebied word, toegepas kan word op werklike programme wat joins gebruik. Dink byvoorbeeld aan 'n aanlynbedryf wat bestellings en betalings verwerk, waar elke betaling deur 'n buitelandse sleutelverwysing (die orderId) aan een bestelling gekoppel word. bestellings en betalings is Apache Kafka-onderwerpe, en ons wil 'n nuwe Kafka-thema skep vir betaalde bestellings wat vir bestellingvervulling gebruik sal word. 'N eenvoudige oplossing wat lyk asof dit moet werk, is 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
);
 Natuurlik, in 'n werklike aansoek sou ons 'n klomp meer inligting in die uitvoer trek, soos die kliënt-ID, hul verzendadres en die ID's van die produkte wat bestel word. In die spreekwoord van die Flink gemeenskap, 'n aansluiting soos hierdie een word 'n "reguliere aansluiting" genoem (wat beteken dat ons niks spesiaals gedoen het om Flink te toelaat om dit meer doeltreffend uit te voer nie). En wanneer uitgevoer word deur Flink SQL se streaming runtime, kan gereelde aansluiting verrassend duur wees. Natuurlik, in werklikheid, ons weet dit sal nie so wees nie.In werklikheid, gebaseer op ons kennis van hoe hierdie maatskappy sy besigheid bestuur, kan ons weet dat elke bestelling ten hoogste een ooreenstemmende betaling sal hê, en dus is daar geen behoefte vir Flink om 'n bestelling te stoor ná die punt waar sy betaling verwerk is nie. Een ding wat ons kon doen om hierdie aansluiting minder duur te maak, sou wees om te veronderstel dat betalings altyd binne twee uur van die bestelling plaasvind (byvoorbeeld): 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
);
 Dit sal beperk hoe lank die bestellings in Flink se loop tydstoestand gehou word, maar dit is nie 'n baie bevredigende benadering nie. Aan die een kant, ons sal eerder die status van 'n bestelling vrymaak sodra dit met 'n betaling gekoppel word, en aan die ander kant, sommige betalings kan vir meer as 2 uur vertraag word. Met ander woorde, dit is 'n manier om 'n antwoord te kry wat ons nie kan vertrou nie, en meer as nodig te spandeer om daar te kom. Ongelukkig kan die een-tot-een boodskap verryking wat ons ideaal in hierdie geval wil doen, nie direk uitgedruk word deur standaard SQL konsepte te gebruik nie. Hier is 'n vereenvoudigde voorbeeld van hoe dit kan lyk: // 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");
    }
  }
}
 Met hierdie PTF in plek, ons aansluit query word CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 In die praktyk kan hierdie vereenvoudigde voorbeeld uitgebrei word om iets te doen oor die moontlikheid van die ophoping van 'n toenemende aantal ongeëvenaarde bestellings (bestellings wat nooit betalings ontvang nie). Ander opwindende ontwikkelings Native support for ML models FLIP-437 (insluit in Flink 2.0) het ondersteuning vir masjienleringsmodelle as eersteklas burgers in Flink SQL bygevoeg. Disaggregated state backend Die Flink-gemeenskap ontwikkel 'n meer wolk-gebaseerde benadering tot staatsbestuur, wat dit uiteindelik meer prakties sal maak vir programme om groot hoeveelhede state te gebruik. Dit sal nooit die behoefte elimineer om te dink oor die staatvereistes van jou streaming-programme nie, maar dit sal aansienlik verander hoe jy die betrokke kompromisse moet sien. Vir gebruikers van Flink se SQL- en Tabel-API's, is dit eenvoudig 'n kwessie van die verandering van jou runtime-konfigurasie. Vir meer besonderhede. Dokumenteer Semi-structured types Semi-gestruktureerde data bied meer fleksibiliteit, soos die toevoeging van velde met verloop van tyd, optionele velde, of velde waarvan die tipe van rigting tot rigting kan verskil. Op die oomblik moet gebruikers van Flink se relatiewe API's kies tussen ROW's met streng skema's en statiese tipes, of die stoor van data as JSON-strings. word 'n VARIANT-type bygevoeg om semi-gestruktureerde data te ondersteun wat doeltreffend gestoor en verwerk kan word. Geskryf 521 Vir dieper begrip Om meer te leer oor Flink SQL, Jy sal begin. Hierdie video op voortdurende vrae die Daar is 'n paar uitstekende voorbeelde, as jy meer diep in hierdie onderwerp wil duik. Dokumentasie oor prosestafelfunksie Sean Falconer maak die saak waarom . Die toekoms van AI-agente is gebeurtenisgedrewe Die toekoms van AI-agente is gebeurtenisgedrewe

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

Hierdie oudio word in die oorspronklike taal van die storie vervaardig!

Wat jy moet weet oor die nuutste updates vir Apache Flink se SQL- en Tabel-API's

About Author

KOMMENTAAR

HANG TAGS

HIERDIE ARTIKEL IS AANGEBIED IN

Related Stories

"What If ... I didn't Do It?"

Meet the Writer: HackerNoon Contributor Daniil Sitdikov, Software Engineer

The Opt Out Writing Contest: Final Round Results Announcement 🎉

$30M Raised in 30 Minutes and the Controversies to Follow: The Story Behind Dexter’s GM.ai Project

"What If ... I didn't Do It?"

Meet the Writer: HackerNoon Contributor Daniil Sitdikov, Software Engineer

The Opt Out Writing Contest: Final Round Results Announcement 🎉

$30M Raised in 30 Minutes and the Controversies to Follow: The Story Behind Dexter’s GM.ai Project

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps