David Anderson, glavni softverski voditelj u Confluent-u Flink SQL je moćan motor dizajniran za obradu u realnom vremenu, streaming podataka koristeći poznati SQL jezik i njegove temeljne relacijske koncepte.To je dugo bio učinkovito rješenje za mnoge aplikacijske domene, posebno ETL pipelines i analitičke radne opterećenja, ali do sada Flink SQL je nedostajao ključne značajke često potrebne za aplikacije koje se temelje na događajima. S nedavnim razvojem opisanim ovdje, relacijski API-ji Apache Flink-a - naime, Flink SQL i Table API - sazreli su do točke u kojoj iskoristiti njihove moćne abstrakcije i ugrađene operatore više ne zahtijevaju kompromise na pristupu Flinkovim primitivima za obradu toka na niskoj razini. Sve što je ovdje rečeno jednako vrijedi i za Flink SQL i Tablicu API. Oba sjede na istom runtime - koncepti i temeljne mogućnosti su isti - oni su samo pristup iz Java ili Python, a ne SQL, ako se odlučite koristiti Tablicu API. Koristite slučajeve Ovi relacijski API-ji posebno su prikladni za dvije široke kategorije aplikacija. Agentic AI Moderne aplikacije AI često zahtijevaju pristup dinamičnim informacijama u realnom vremenu. Flink SQL olakšava agencijsku AI tako što olakšava kombiniranje tokova događaja u realnom vremenu s uvidom iz agenata, modela i usluga. Shift left U svijetu obrade podataka, "pomičući lijevo" odnosi se na obavljanje transformacija i obogaćivanja podataka što je ranije moguće u protoku podataka. Flinkova relacijska API-ja izvrsna su ovdje tako što omogućuju transformacije u realnom vremenu i obogaćivanje s drugim skupovima podataka. Poznanje u kombinaciji s novostima Tradicionalno, SQL se koristi i za operativne i analitičke slučajeve korištenja.Flink SQL uzima dobro promišljene koncepte i semantiku razvijene za Online Transaction Processing (OLTP) i Online Analytical Processing (OLAP), i proširuje ih kako bi zadovoljili zahtjeve aplikacija za obradu toka u realnom vremenu. The relational algebra remains the same Temeljni principi relacijske algebre, koji čine temelj SQL-a, potpuno su sačuvani u Flink SQL-u. Dok su tradicionalne SQL tablice statične, Flink SQL uvodi koncept dinamičkih tablica, koje su logičke reprezentacije kontinuiranih, neograničenih tokova podataka. Tables: Agregacije (npr., 'COUNT', 'SUM', 'AVG') primjenjuju se na tokove, pružajući sažetke podataka u realnom vremenu. Aggregations: Flink SQL podržava različite operacije spajanja, što omogućuje kombiniranje podataka iz različitih izvora pretraživanja. To može varirati od tradicionalnih unutarnjih i vanjskih spajanja do specijaliziranih vremenskih spajanja. Joins: Svaka Flink SQL izjava kontinuirano izračunava rezultat upita na tokovima, omogućujući trenutni pristup često zatraženim podacima. Continuous queries (materialized views): New challenges and ideas for stream processing S druge strane, primjena tih relacijskih koncepata na dinamični svijet obrade toka uvodi neke nove razmatranja: Postupci obrade toka često trebaju održavati "stanje" - informacije o prošlim događajima - kako bi izvršili svoja izračuna. Na primjer, agregat mora pratiti svoj djelomično akumulirani rezultat, a pridruživanje može morati buffirati zapise iz jednog toka dok čeka usklađivanje zapisa iz drugog. Programeri koji koriste Flink SQL (ili Tablicu API) moraju pažljivo razmotriti upravljanje stanjem, jer prekomjerno stanje može utjecati na performanse i potrošnju resursa. Thinking about state: U procesiranju toka, događaji mogu doći izvan reda ili s kašnjenjima. Vodeni žigovi su ključni koncept u Flink SQL-u koji pomaže u rješavanju tih nepravilnosti pružajući pojam "potpunosti" za tokove. Vodeni žigovi definiraju prag nakon kojeg Flink pretpostavlja da neće doći više događaja s ranijim vremenskim žigom, što omogućuje dosljedne agregirane prozore i pravovremene rezultate. Watermarks: Flink SQL uključuje niz posebnih vremenskih verzija državnih operacija, kao što su agregati s vremenskim prozorom i prozorski spojevi, koji se oslanjaju na vodene znake kako bi znali kada su njihovi rezultati spremni za emitiranje (i kada se stanje koje su držali može osloboditi). Nedavni razvoj Nedavni razvoj čini ove relacijske API-je uvjerljivijima nego ikad prije. Flink SQL i tablični API vrlo su proširivi korištenjem User-Defined Functions (UDF). Ovi omogućuju korištenje Java ili Pythona za provedbu prilagođene logike koja se ne može izreći izravno u SQL. UDF-ovi mogu izvesti složene izračune, iskoristiti knjižnice trećih strana, integrirati se s vanjskim sustavima ili implementirati transformacije specifične za domene. To je novi ukus UDF-a koji je upravo uveden kao dio Flink-a 2.1. Za razliku od tradicionalnih UDF-ova, PTF-ovi mogu na sofisticiran način obrađivati cijele tablice (streame) koristeći Flinkove usluge upravljanog stanja i vremenskog razdoblja. Process Table Functions (PTFs) Sljedeći Članak Streaming Joins in Flink SQL Operacije pridruživanja ilustriraju sličnosti i ključne razlike u Flinkovim relacijskim API-jima u usporedbi s tradicionalnim SQL bazama podataka. Ovaj odjeljak koristi neke praktične primjere kako bi istražio kako se gore predstavljeni koncepti mogu primijeniti na stvarne aplikacije koje koriste spojeve. Razmotrite, na primjer, online poslovanje koje obrađuje narudžbe i plaćanja, gdje je svako plaćanje povezano referencom stranog ključa (orderId) na jednu narudžbu. narudžbe i plaćanja su teme Apache Kafke, a želimo stvoriti novu Kafku temu za plaćene narudžbe koja će se koristiti za izvršenje narudžbe. Jednostavno rješenje koje se čini da bi trebalo raditi je 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
);
 Naravno, u stvarnoj aplikaciji izvučemo gomilu više informacija u izlaz, kao što su ID kupca, njihova adresa za isporuku i ID-ovi naručenih proizvoda. U govoru zajednice Flink, pridruživanje kao što je ovo naziva se "redovitim pridruživanjem" (što znači da nismo učinili ništa posebno kako bismo omogućili Flink-u da ga učinkovitije izvrši). Zapravo, na temelju našeg znanja o tome kako ova tvrtka vodi svoje poslovanje, mogli bismo znati da će svaka narudžba imati najviše jedno odgovarajuće plaćanje, pa stoga nije potrebno da Flink pohranjuje narudžbu nakon točke u kojoj je njegovo plaćanje obrađeno. Jedna stvar koju bismo mogli učiniti kako bi ovaj pristup bio jeftiniji bio bi pretpostaviti da će se plaćanja uvijek dogoditi unutar dva sata od narudžbe (na primjer): 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
);
 To će ograničiti koliko dugo se narudžbe pohranjuju u Flinkovom stanju trajanja, ali to nije vrlo zadovoljavajući pristup.S jedne strane, radije bismo oslobodili stanje narudžbe čim se podudara s plaćanjem, a s druge strane, neka plaćanja mogu biti odgođena za više od 2 sata. Drugim riječima, to je način da dobijemo odgovor na koji ne možemo vjerovati i potrošimo više nego što je potrebno da stignemo tamo. Nažalost, one-to-one obogaćivanje poruka koje bismo idealno željeli učiniti u ovom slučaju ne može se izravno izraziti pomoću standardnih SQL koncepata. Evo pojednostavljenog primjera kako bi to moglo izgledati: // 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");
    }
  }
}
 Uz ovaj PTF na mjestu, naš upit za pridruživanje postaje CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 U praksi, ovaj pojednostavljeni primjer mogao bi se proširiti kako bi se učinilo nešto o mogućnosti akumulacije sve većeg broja neusklađenih narudžbi (narudžbi koje nikada ne primaju plaćanja). Ostali uzbudljivi događaji Native support for ML models FLIP-437 (uključen u Flink 2.0) dodao je podršku za modele strojnog učenja kao građane prve klase u Flink SQL-u. Disaggregated state backend Zajednica Flink razvija više cloud-native pristup upravljanju državom, što će na kraju učiniti praktičnijim za aplikacije da koriste ogromne količine države. To nikada neće ukloniti potrebu da se razmišlja o uvjetima stanja vaših aplikacija za streaming, ali će značajno promijeniti način na koji biste trebali vidjeti kompromise uključeni. Za korisnike Flink SQL i Table API-ja, eksperimentiranje s ovim je jednostavno pitanje promjene konfiguracije vašeg vremena rada. Za više detalja. Dokumentacija Semi-structured types Polustrukturirani podaci nude veću fleksibilnost, kao što su dopuštanje dodavanja polja tijekom vremena, opcionalna polja ili polja čija se vrsta može razlikovati od reda do reda. Trenutno, korisnici Flinkovih relacijskih API-ja moraju odabrati između ROW-a sa strogim shemama i statičkim tipovima, ili pohranjivanja podataka kao JSON nizova. dodaje tip VARIANT kako bi podržao polustrukturirane podatke koji se mogu učinkovito pohraniti i obrađivati. Flip 521 Za dublje razumijevanje Da biste saznali više o Flink SQL, Ti ćeš početi. Ovaj video na kontinuiranim upitima Naš Ima nekoliko odličnih primjera, ako želite produbiti se dublje u ovu temu. Dokumentacija o procesnim stolnim funkcijama Sean Falconer objašnjava zašto . Budućnost agenata AI-a temelji se na događajima Budućnost agenata AI-a temelji se na događajima

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

Ovaj zvuk je proizveden na izvornom jeziku priče!

Što trebate znati o najnovijim ažuriranjima Apache Flinkovih SQL i Table API-ja

About Author

KOMENTARI

VIJESI OZNAKE

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps