Kafka får SQL med KSQL

Streaming er varmt. Efterspørgslen efter databehandling i realtid er stigende, og streamingleverandører breder sig og konkurrerer. Apache Kafka er en nøglekomponent i mange datapipeline-arkitekturer, mest på grund af dens evne til at indtage streamingdata fra en række forskellige kilder i realtid.

Confluent, den kommercielle enhed bag Kafka, har ambitionen om at udnytte denne position til at blive den foretrukne platform for real-time applikationsudvikling i virksomheden.

På vej til at implementere denne vision, Kafka har udvidet sin rækkevidde til at omfatte mere end dataindtagelse - især behandling.

I denne proces vokser overlapningen med andre platforme, og Confluent ser ud til at være indstillet på at tilføje funktioner, der gør Kafka i stand til at skille sig ud. Det verdens største Kafka-topmøde, der finder sted i San Francisco i dag markerer fremkomsten af ​​en sådan funktion: Kafka SQL, eller KSQL, er en SQL-implementering, der gør det muligt for Kafka-brugere at behandle deres streamingdata ved hjælp af SQL frem for Java eller Python API'er.

Neha Narkhede, Confluent medstifter og CTO, er den, der delte nyheden med verden i sin keynote. Ud over annonceringen diskuterede Narkhede KSQL med ZDNet.

En kort historie om streaming af SQL

SQL over streaming data er anderledes end SQL over data gemt i tabeller i traditionelle relationelle databaser. Streaming af data er ubegrænset, hvilket betyder, at forespørgsler kører og producerer resultater kontinuerligt. Hvis der er behov for at producere afgrænsede resultater, er der behov for specielle konstruktioner såsom tidsvinduer.

Dette betyder, at SQL for streaming data per definition vil være anderledes, men begrundelsen er, at ved at tilbyde en SQL-grænseflade vil baren for at bruge streaming data være markant reduceret: det er nemmere at lære et par ekstra begreber og konstruktioner, mens du bruger et velkendt sprog og værktøjer end at skulle lære og bruge nye API'er programmatisk.

Dette blev indset tidligt, og der har været implementeringer af SQL over streaming af data. Sælgere som f.eks Oracle og StreamBase (erhvervet af TIBCO) har arbejdet på dette i et stykke tid nu, og der er mange andre muligheder: open source-projekter såsom Apache Gnist, Flink, Storm, Samza, Spids, og RørledningDB eller proprietære løsninger som f.eks SQLStream, Striim, og Kinetica.

Kafka er bestemt ikke den første til at tilbyde SQL over streaming, så hvad er så specielt ved dette? Narkhede siger, at "KSQL er den eneste streaming SQL-motor, der er fuldstændig interaktiv og en begivenhed-ad-gangen streaming SQL-motor.

Der er et par andre, men de er enten mikro-batch eller kræver, at brugeren skifter mellem Java/Python-kode og SQL for at skrive sofistikerede strømbehandlingsoperationer. Med KSQL kan du skrive enhver form for strømbehandlingsoperation ved hjælp af en fuldstændig interaktiv SQL-grænseflade."

KSQL versus API'er

Narkhede bemærker dog, at KSQL er bygget oven på selve Kafkas Streams API, og derfor arver dets elastiske skalerbarhed, avancerede tilstandsstyring og fejltolerance:

"KSQL-serveren indlejrer Kafka Streams og tilføjer oven i en distribueret SQL-motor (inklusive noget fancy ting som automatisk bytekodegenerering til forespørgselsydeevne) og en REST API til forespørgsler og styring.

KSQL-serverprocessen udfører forespørgsler. Et sæt KSQL-processer kører som en klynge. Du kan dynamisk tilføje mere behandlingskapacitet ved at starte flere forekomster af KSQL-serveren. Disse tilfælde er fejltolerante: hvis den ene fejler, vil de andre overtage dets arbejde.

KSQL er også tæt integreret med Apache Kafka og dets meddelelsesleveringsgarantier. Dette inkluderer Apache Kafkas stærkeste garanti, præcis én gang. Brug af KSQL konfigureret til levering præcis én gang betyder, at du har problemfri streambehandling uden tab af data eller duplikering. Disse garantier gør det nemt at bygge pålidelige realtidsapplikationer uden at skrive kode."

Forvirret? Man skal måske tilbage til Kafkas tidligere introducerede interaktive forespørgsler at give mening i dette. Hvad Confluent synes at sige her er, at KSQL kommer som det næste skridt i udviklingen af ​​interaktiv forespørgsler, der lover at frigøre udviklere fra behovet for overhovedet at bruge en API for at kunne forespørge på deres streams.

KSQL – hvad er det godt for?

Det lyder som et stærkt salgsargument, kombineret med Kafkas styrker som påpeget af Narkhede. Men hvad skal du vide for at kunne bruge KSQL, og hvad kan du helt præcist gøre med det?

Narkhede siger, at KSQL-syntaksen tager ANSI SQL som et velkendt udgangspunkt og beriger det med specialiserede nøgleord til at manipulere streamingdata. En sådan berigelse er tilføjelsen af ​​STREAM som en førsteklasses konstruktion ud over TABELLEN:

"Begge disse konstruktioner repræsenterer ting, der løbende opdateres; en strøm repræsenterer en ubegrænset sekvens af strukturerede fakta, og en TABEL repræsenterer en kontinuerligt opdateret samling af evolverbare fakta.

Da Kafka er bygget på den kraftfulde idé om en uforanderlig, holdbar log, er der ingen understøttelse for, hvad der traditionelt ville blive betragtet som "opdaterings"-funktionalitet. Vi planlægger dog at tilføje support til INSERT'er i fremtiden."

Narkhede tilføjer, at preview-versionen understøtter en bred vifte af strømbehandlingsoperationer, fra kontinuerlige vinduessammenlægninger til stream-tabel-sammenføjninger og meget mere. Så hvad kan du gøre med interaktiv SQL over streaming af data?

Vil KSQL-forespørgsler fungere som en slags trigger, som ved affyring vil muliggøre yderligere handling? Vil det være muligt at gemme de nøgleværdi-par, som en Kafka-meddelelses underliggende struktur består af i et eksternt lager og behandle dem?

Alt ovenstående er muligt med KSQL, siger Narkhede: "KSQL-forespørgselsresultater kan dirigeres til nye emner eller eksterne datalagre ved hjælp af Kafka Connect. Dette gør KSQL særligt velegnet til Streaming ETL, hvor du skal forbehandle data, før du eksporterer dem til et downstream-system, det være sig Hadoop, Elastic, Cassandra eller et hvilket som helst andet datasystem."

Og hvad med skema og ikke-relationelle data? Kafka har dig dækket ifølge Narkhede:

"Beskeder i Kafka-emner indeholder ofte ikke-relationelle data. Af denne grund leverer KSQL mekanismer til at læse en række serialiserede formater, herunder JSON- og AVRO-kodede data, og definere skemaer mod felterne, der findes i dem.

I den første forhåndsvisningsversion administreres og bruges skemaoplysningerne af KSQL ved hjælp af dets interne katalog. Vi planlægger at integrere det med Confluents Schema Registry såvel. Ud over det kan det blive mere udbredt i fremtiden."

Det større billede

Pressemeddelelsen får det til at se ud som om udviklere er målgruppen for KSQL, men det er det ikke nødvendigvis. I teorien kunne analytikere eller ops eller enhver, der kender deres SQL og har brug for data indtaget gennem Kafka – og det er mange mennesker – drage fordel af KSQL.

Man kunne forestille sig at producere eller forbruge KSQL-forespørgsler ved at bruge alt fra en teksteditor til verdens Tableaus.

Narkhede siger, at målgruppen for KSQL er enhver udvikler, der kender SQL og ønsker at behandle realtidsstreams i Kafka. Selvom hun siger, at de fleste Tableau-lignende værktøjer ikke kan forbruge de uendelige resultater af kontinuerlige forespørgsler på nuværende tidspunkt, tilføjer hun også, at KSQL nemt kan integreres med Grafana til overvågning og alarmering i realtid:

"I vores KSQL demo, viser vi udviklere en nem måde at definere metrics om deres Kafka-emner og eksportere det ved hjælp af Kafka Connect til Grafana. Vi samarbejder også med Arcadia data på dette, og de frigiver native visuelle analyser på real-time, streaming data. Integrationen med KSQL giver alle brugere avancerede visualiseringer til streaming af databrugssager, specifikt omkring advarsler og tidsbaseret dataudforskning (og drill downs)."

Når vi diskuterer KSQL's plads i det større billede, gør Narkhede det dog klart, at dette handler om mere end at gøre livet lettere for udviklere:

"KSQL er et stort skridt fremad mod vores vision om en streaming-første dataarkitektur med Kafka. På en eller anden måde udvider det rækkevidden af ​​Kafka betydeligt i en organisation ved at gøre sofistikeret strømbehandling tilgængelig, ud over udviklere, for alle, der kan skrive SQL.

Kafka og KSQL låser op for en række funktioner, som enten ikke var mulige at udføre i realtid eller var besværlige. Kafka-loggen er kernelagringsabstraktionen til streaming af data, hvilket gør det muligt at de samme data, som gik ind i dit offline datavarehus, nu er tilgængelige for streaming.

Alt andet er en streaming materialiseret visning over loggen, det være sig forskellige databaser, søgeindekser eller andre dataserveringssystemer i virksomheden. Al databerigelse og ETL, der er nødvendig for at skabe disse afledte visninger, kan nu udføres på en streaming måde ved hjælp af KSQL.

Overvågning, sikkerhed, afvigelser og trusselsdetektion, analyser og reaktion på fejl kan udføres i realtid i forhold til, når det er for sent. Alt dette er tilgængeligt for næsten alle at bruge gennem en enkel og velkendt SQL-grænseflade til alle dine Kafka-data: KSQL.

Og hvis du vil bruge både in-motion og hviledata, med Kafka Connect API, er det nemt at inkludere data fra andre kildesystemer ind i Kafka-emner og foren derefter disse med data fra andre emner ved hjælp af KSQL."

Dette er i overensstemmelse med Confluents vision om at få Kafka til at blive den foretrukne platform til udvikling af realtidsapplikationer. I denne vision bliver loggen tyngdepunktet for data, forespørgsler sker i farten ved indgående streaming data, og eksterne lagre bruges som koldt datalager, der i nogle tilfælde kan være helt omgået.

Selvom Kafka ikke er den eneste, der omfavner denne vision, gør dens positionering som indgangspunktet for datapipelines det til et attraktivt valg at bygge videre på. Confluent ser dette, og at spille på denne styrke med KSQL kan vise sig at være et afgørende skridt i kampen om dominans af streamingplatformen.

Tidligere og relateret dækning

Semantisk datasø-arkitektur i sundhedsvæsenet og videre

Datasøer kan være et stort aktiv, men de har brug for en række elementer for at fungere korrekt. Vi tager et kig på, hvordan det fungerer for Montefiore Health System og diskuterer betydningen af ​​semantik og grafdatabaser i datasø-arkitekturen.

Overladning af dit billede: Maskinlæring til fotografiapplikationer

Avancerede muligheder for billedhentning og -behandling er relativt nye og drevet i vid udstrækning af fremskridt inden for maskinlæringsteknologi. Vi præsenterer en kort historie om dette rum og deler historien om, hvordan Shutterstock har taget denne teknologi til sig, og hvad den gør for dem.