Å bygge en umulig vanskelig analyseplattform

Med hendelsesstrømanalyse kan virksomheter bruke strømmende hendelsesdata som har skjedd i løpet av de siste sekundene, minuttene eller timene, til å få innsikt og ta beslutninger . Denne nye typen analyse gjør det mulig å reagere raskt på problemer og muligheter i øyeblikket - men fra et teknisk perspektiv er det svært vanskelig å få det til.

Verdens Googles og Facebooks har bygget opp store, egenutviklede systemer for å drive virksomhetene sine med hendelsesstrømanalyser. Disse systemene, som bemannes av programvareteam med hundrevis av ingeniører, er utenfor rekkevidde for de fleste bedrifter.

Vi har utviklet Warehouse-Native Analytics slik at enhver bedrift kan bygge opp en analysestack i verdensklasse. Alt de trenger er en skylagringsplass som AWS S3, en strømprosesseringsplattform som Apache Kafka og Warehouse-Native Analytics. Jeg er Priyendra Deshwal, CTO og medstifter av Warehouse-Native Analytics. Å bygge denne plattformen har vært mitt livs eventyr, og i dag vil jeg gi deg en titt bak kulissene på den hemmelige sausen som får Warehouse-Native Analytics til å fungere.

De tekniske utfordringene

Hendelsesstrømanalyse er svært forskjellig fra tradisjonell analyse og krever et unikt sett med muligheter. La oss ta en titt på disse kravene, og hvordan de skaper utfordringer som vi i Warehouse-Native Analytics har jobbet hardt for å løse.

• Datainnhenting: Hendelsesstrømanalyse handler om å vite hva som skjer nå og hva som har skjedd tidligere. Derfor må plattformen støtte konstant inntak av hendelsesdata med høy gjennomstrømning og lav latenstid. Warehouse-Native Analytics er utviklet for å ta inn millioner av hendelser i sekundet med en latenstid på under et sekund.
• Varsler påunder etsekund: Forbruksmodellen til en hendelsesstrømanalyseplattform er svært forskjellig fra tradisjonell analyse. Tradisjonell analyse baserer seg på at brukerne henter data fra systemet, mens operasjonelle brukstilfeller (som overvåking) krever en push-modell. Et varsel må utløses i løpet av sekunder etter at en uønsket hendelse har inntruffet. Live-dashbord må alltid vise den nyeste tilstanden i systemet. Warehouse-Native Analytics har innebygd støtte for kontinuerlige, inkrementelle, strømmende SQL-spørringer for å håndtere disse brukstilfellene.
• Interaktive SQL-spørringer: Selv om den primære interaksjonen med et hendelsesstrømsystem er push-basert, må brukerne likevel samhandle med systemet ved hjelp av pull-modellen. Når et varsel utløses, er det for eksempel viktig at brukerne kan følge opp med ad hoc-diagnostiske undersøkelser av dataene. For å gi ekte innsyn i virksomheten må plattformen gjøre det enkelt å koble sammen statiske referansedata med strømmende hendelsesdata. Warehouse-Native Analytics har en avansert spørringsmotor som gjør det mulig å utføre interaktive SQL-spørringer over store datamengder, på tvers av data i bevegelse og data i ro.
• Optimalisering av tidsserier: De aller fleste driftsdata består av tidsstemplede hendelsesstrømmer, noe som krever spesiell håndtering av tidssemantikken - for å ta hensyn til dataenes fullstendighet, sen ankomst av data, aggregeringer og sammenføyninger i vinduer med mer. Warehouse-Native Analytics er utviklet for å håndtere denne kompleksiteten og støtte effektiv lagring og gjenfinning av tidsseriedatasett.
• Avansert hendelsesstrømanalyse: Ekte hendelsesstrømanalyse gir brukerne mulighet til å utvikle en dyp forståelse av hendelsessekvenser og baner av hendelsestilstander. Analyser av hendelsesstrømmer (trakter, Sankey-diagrammer osv.) innebærer ofte at man studerer sekvenser av hendelser og baner som hendelsestilstander tar. Disse analysene er imidlertid vanskelige å uttrykke ved hjelp av SQL eller å beregne ved hjelp av tradisjonelle systemer. Warehouse-Native Analytics har innebygd støtte for avansert hendelsesflytanalyse.
• Datasett i petabyte-skala: Etter hvert som bedrifter har tatt i bruk telemetri i en lang rekke bransjer, har datasett i petabyte-skala blitt vanlig, og enhver plattform må kunne skaleres til slike størrelser. Warehouse-Native Analytics er utviklet for å skalere til behovene til de største bedriftene i verden.

Det finnes tradisjonelle BI-plattformer, overvåkingsverktøy, produktanalysesystemer og en rekke andre spesialiserte alternativer for å dekke ett, eller noen ganger flere, av disse kravene. Warehouse-Native Analytics er imidlertid den første plattformen som har alle funksjonene som trengs for hendelsesstrømanalyse, samlet på ett sted.

De viktigste tekniske nyvinningene i Warehouse-Native Analytics

Warehouse-Native Analytics tilbys som en vertikalt integrert skytjeneste for å imøtekomme disse kravene. Den er bygget på toppen av tre viktige innovasjoner:

• Konvergert analytisk prosessering (CAP): Warehouse-Native Analytics må støtte et bredt utvalg av analytiske arbeidsbelastninger. CAP-dataplattformen vår sørger for en ekte konvergens mellom strømme- og batchprosessering av spørringer, med integrert, optimalisert lagring. Den er utviklet for strømmeinntak, effektive inkrementelle beregninger, hendelsesflytberegninger, tidsreiser og kontinuerlige SQL-spørringer - i ekstrem skala.
• Relasjonelle hendelsesstrømmer: Med relasjonelle hendelsesstrømmer muliggjør Warehouse-Native Analytics komplekse hendelsesstrømanalyser på toppen av den velkjente og kraftige relasjonsmodellen. Du slipper å bruke spesialiserte produktanalyseverktøy for visse spørsmål og relasjonsdatabaser for andre.
• NetScript: Vi ønsket å gjøre det enklere å stille komplekse analysespørsmål som kombinerer data i ro og data i bevegelse. Derfor utviklet vi et nytt analysespråk kalt NetScript, som kan kompileres til SQL, men som gir et høyere abstraksjonsnivå, komponerbarhet og gjenbrukbarhet. Forretningsbrukere trenger ikke å kode - vi tilbyr et bibliotek med generiske og brukstilfellespesifikke maler for produktanalyse.

Du kan tenke på CAP som beregningslaget, relasjonelle hendelsesstrømmer som laget for modellering av forretningsenheter, og NetScript som måten du enkelt uttrykker komplekse analytiske spørsmål på. I det følgende skal vi gå nærmere inn på hver av disse nyvinningene og forklare hvordan de hjelper oss med å løse viktige problemer ved implementering av hendelsesstrømanalyser i dag.

Konvergert analytisk prosessering

Converged analytical processing, eller CAP, er en konvergert batch- og strømmemotor som kjører på toppen av et svært optimalisert, integrert lagringslag. Med CAP kan du søke i alle dataene dine på ett sted, med full støtte for sammenkoblinger på tvers av data i bevegelse og data i ro. CAP er en kraftig og fleksibel løsning med lav latenstid og høy gjennomstrømning som gjør det mulig å utføre alt fra sanntidsovervåking til avansert hendelsesanalyse.

CAP ble utviklet for å dekke behovet for å håndtere batch- og streamingberegning og -lagring i ett og samme produkt. Datavarehus har tradisjonelt sett håndtert batchberegning og -lagring, men ikke strømmeberegning (kontinuerlig og inkrementell). Plattformer som Apache Spark og Apache Flink har håndtert batch- og streamingberegning (men ikke lagring). Warehouse-Native Analytics gjør alle tre.

Problemet det løser

Hvis du ser inn i en datakyndig bedrift i dag, vil du finne et virvar av datavarehus, datasjøer, meldingsbusser, strømmeprosessorer, tidsseriedatabaser, OLAP-motorer i sanntid, in-memory-databaser med lav latenstid, hendelsesstrømanalyser og mer.

Det er to problemer med denne arkitekturen:

1. Høye eierkostnader: For hvert system trenger du et høyt kvalifisert team til å administrere det, og kompleksiteten vokser eksponentielt etter hvert som flere systemer legges til og relasjonene mellom dem også må håndteres. Du betaler kanskje for en leverandør, eller du betaler med ingeniørtimer for å implementere en løsning med åpen kildekode, men uansett er hvert ekstra system en ekstra kostnad.
2. Data i siloer: I en kompleks datastack med mange analysesystemer er ikke alle datasett synlige for alle systemer, og muligheten til å koble sammen datasett er ofte dårlig. Dette skaper datasiloer og hindrer oppdagelsen av innsikt på tvers av datasett. Hvis dataene om klikk på nettstedet ditt for eksempel ligger i et verktøy for hendelsesanalyse, og dataene om kunderelasjonene dine ligger i et datavarehus, kan du ikke analysere produktbruken ut fra kundenes totale forbruk. Med andre ord gir ikke denne arkitekturen en produktsjef mulighet til å svare på et så grunnleggende spørsmål som "Hvordan bruker kundene med høy verdi produktet mitt?"

Slik fungerer det

De viktigste delene av CAP-motoren og lagringslaget er

• Optimalisering avforespørsler: Forespørsler analyseres og optimaliseres til en fysisk spørringsplan. Den fysiske planen består av en graf med operatorer som er planlagt kjørt på noder i en Warehouse-Native Analytics-klynge. Disse operatørene kompileres til svært optimaliserte maskinkodefragmenter, slik at spørringer kan skanne hundrevis av millioner av rader per sekund per kjerne.
• Enhetlig batch og strømming: Motoren for spørringskjøring har en strømme-først-arkitektur der Apache Arrow-kodede datapakker flyter gjennom en operatørgraf. Disse operatørene frigir data til nedstrømsoperatører når de mottar spesielle kontrollpakker som inneholder oppdateringer av hendelsestidsvannmerker. Utførelseslaget kan støtte både batch- og strømmeberegninger ved å kontrollere hyppigheten av vannmerkeoppdateringer.
• Tilpasset lagringslag: Vi bruker en tredelt kolonnelagringsarkitektur der nyankomne data skrives direkte til minnet, slik at vi kan ta inn millioner av hendelser i sekundet med en latenstid på under et sekund. Dette er en svært god utnyttelse av knappe minneressurser, fordi de fleste operasjonelle arbeidsbelastninger foretrekker ferske data og drar stor nytte av at disse dataene allerede finnes i minnet. Eldre, mindre nylig brukte data delegeres til lokal NVMe-lagring og blob-/objektlagring i skyen.
• Deklarative avveininger mellom kostnad og ytelse: Vi har bygget inn "knotter" i systemet som gjør det mulig for brukerne å kontrollere de relative cache-prioriteringene for ulike datasett, bygge forhåndsaggregerte indekser over datasett, vedlikeholde flere kopier av datasett ved hjelp av ulike partisjonerings- og klyngenøkler, med mer. Vår visjon er at brukerne skal kunne oppnå et hvilket som helst ønsket punkt på kurven for kostnadseffektivitet og ytelse.

Relasjonelle hendelsesstrømmer

Ved å modellere forretningsdata som det vi kaller relasjonelle hendelsesstrømmer, gjør Warehouse-Native Analytics det mulig å utføre komplekse hendelsesstrømanalyser på data som er lagret i sin opprinnelige relasjonelle form. Du trenger ikke lenger å velge mellom å undersøke trakter, hendelsessegmentering eller kohorter og å kjøre "vanlige" SQL-spørringer på hendelsesstrømmene dine.

Problemet det løser

Det er svært vanskelig for tradisjonelle analysesystemer å representere hendelsesdata. De eksisterende tilnærmingene faller inn i to kategorier:

• Representere hendelsesdata i en flat form. Spesialiserte systemer for hendelsesstrømanalyse, som produktanalyseverktøy, krever at du tvinger forretningsdataene dine inn i rigide, forhåndsdefinerte modeller. Dermed mister du datarikdommen. Disse verktøyene mangler også full SQL-støtte, slik at de bare dekker et svært smalt utsnitt av analytiske bruksområder.

• Representere hendelsesdata i sin opprinnelige relasjonelle form. I denne formen sliter de fleste systemer med å utføre hendelsesstrømanalyser. Beregninger på hendelsesstrømmer er ikke enkle å uttrykke i SQL.

Med relasjonelle hendelsesstrømmer bygger Warehouse-Native Analytics bro mellom disse to tilnærmingene for å oppnå det beste fra begge verdener. Hendelsesdata representeres i sin opprinnelige relasjonelle form, men den underliggende CAP-arkitekturen kan støtte avansert hendelsesstrømanalyse direkte på denne relasjonelle formen.

Slik fungerer det

Relasjonelle hendelsesstrømmer drives av flere nøkkelfunksjoner:

• Optimalisering av lagring: Hendelsesdata komprimeres i kolonner og sorteres tilnærmet etter tid. Dette gir effektiv støtte for avansert hendelsesstrømanalyse fordi hendelsene må behandles i tidsstempelsortert rekkefølge.
• SQL-utvidelser for hendelsesflytanalyse: MATCH_RECOGNIZE ble lagt til i SQL-standarden for å muliggjøre komplekse hendelsesflytanalyser i SQL. Warehouse-Native Analytics' MATCH_RECOGNIZE-implementering bruker JIT-kodegenerering og utnytter kunnskapen om den underliggende lagringslayouten til å behandle hundrevis av millioner av hendelser per sekund per kjerne.
• Forbedret uttrykksmuligheter: Beregninger for hendelsesflytanalyse er svært tungvint å uttrykke i SQL. Warehouse-Native Analytics' applikasjonslag (UI-maler + NetScript) gjør det mulig å uttrykke disse analysene på en enkel måte. All kompleksiteten ved å formulere den riktige SQL-spørringen, tekniske detaljer knyttet til riktig bruk av MATCH_RECOGNIZE osv. håndteres av applikasjonslaget.

NetScript

NetScript er et programmeringsspråk som lar brukerne uttrykke komplekse analytiske beregninger på en enkel og naturlig måte. NetScript-programmer manipulerer ikke data - de manipulerer i stedet SQL-spørringer, og gir mulighet til å bruke vanlige analytiske operasjoner over disse spørringene: bruke filtre, aggregere etter en eller annen dimensjon, koble sammen mellomresultater på en delt dimensjon osv.

Hver eneste interaksjon i Warehouse-Native Analytics-brukergrensesnittet drives av NetScript under panseret. Selv om vi har funnet det intuitivt og kraftfullt, vil vi gjerne bemerke at NetScript er helt valgfritt for brukerne - du kan spørre plattformen med SQL, eller bruke vårt store bibliotek med maler uten kode.

Problemet det løser

Vi oppfant NetScript fordi SQL har tre store ulemper når det gjelder å representere analytiske beregninger:

1. SQL er omstendelig: Hvis du har jobbet med analytisk SQL i den virkelige verden, er du klar over at SQL-spørringene for disse beregningene kan bli ganske omfattende, ofte flere sider lange.
2. SQL er repetitivt: I en typisk bedrift bruker et stort antall spørringer et svært lite antall sammenkoblingsrelasjoner. Disse sammenkoblingsbetingelsene blir gjentatt i hver eneste spørring.
3. SQL er ikke komponerbar: Hva er den mest naturlige måten å definere totalomsetningsmålet på i SQL? Et rimelig svar er: select sum(revenue) from Txns. Dette relativt trivielle eksempelet belyser en viktig mangel ved SQL. Ideelt sett vil vi gjerne definere denne beregningen på et sentralt sted, slik at alle rapportene våre kan bruke den uten å duplisere logikken. Det er imidlertid ikke klart hvordan vi skal gjenbruke denne beregningen. Det er svært sjelden vi ønsker en rapport med total omsetning på tvers av alle produkter eller alle geografiske områder. I faktiske rapporter vil denne beregningen bli filtrert etter ulike kriterier, og det endelige tallet vil bli delt opp etter ulike dimensjonsattributter (noe som kan føre til sammenkoblinger med andre dimensjonstabeller). Det finnes ingen enkel måte å utlede denne endelige SQL-spørringen fra den opprinnelige SQL-spørringen som fungerte som definisjon av den totale inntektsmålemetoden. SQL-visninger gir en viss primitiv komposisjonsevne - men de er langt fra nok til å muliggjøre den typen brukstilfeller som NetScript er designet for.

Slik fungerer det

Et NetScript-program består av spørringsuttrykk. NetScript-kompilatoren tar spørringsuttrykket som input og bruker det underliggende skjemaet (tabeller, kolonner og relasjoner) til å konvertere uttrykket til en SQL-spørring som sendes til beregningslaget.

En NetScript-operasjon, for eksempel et filter, filtrerer ikke bare dataene som kommer ut av en operator. Den forstår snarere semantikken i inndataene og gjør dyptgripende operasjoner i SQL-spørringen for å støtte semantikken i filteret som brukes. Denne operasjonen kan føre til at filteret går gjennom aggregater, introduserer sammenføyninger for å få med kolonner som det refereres til i filterbetingelsen, og så videre.

Vi påstår ikke at NetScript kan erstatte SQL - det kan tross alt kompileres til SQL! Men vi mener at NetScript-modellen ligger nærmere hvordan brukere (og analytiske applikasjoner) representerer beregninger, slik at du kan skrive programmer på et høyere abstraksjonsnivå.

Lyset i enden av analysetunnelen

En løsning for hendelsesstrømanalyse har vært under utvikling i mange tiår. Nå er timingen endelig riktig. Fra et teknologisk ståsted er det to faktorer som muliggjør fremveksten av operasjonell intelligens i dag:

1. Strømprosessering: Strømprosesseringsplattformer som Kafka er nå standard i de fleste bedrifter. Det er også en økende forståelse for nyansene ved strømprosessering, for eksempel semantikk med "exactly-once", data som kommer i feil rekkefølge og sent, vannmerker, transaksjonsgarantier osv. Resultatet er at stadig mer data konsumeres i strømmet form, noe som åpner opp for strømmeanalyser av disse dataene.
2. Datasjøer i skyen: Muligheten til å instrumentere og samle inn hendelsesdata i sanntid må ledsages av effektive måter å lagre og administrere disse dataene på. Det er her moderne datasjøer kommer inn i bildet. Blob-/objektlagre i skyen, som AWS S3, tilbyr effektive og kostnadseffektive måter å lagre, sikre og administrere et stadig økende og massivt volum av hendelsesdata på. Etter hvert som flere og flere bedrifter flytter til skyen og bygger disse moderne datasjøene, blir alle rådata på laveste detaljnivå tilgjengelige for analyse.

Den tredje brikken som mangler, er en plattform som gjør det mulig, og faktisk enkelt, å stille komplekse analytiske spørsmål på tvers av strømme- og batchdata.

Det er her Warehouse-Native Analytics kommer inn for å fullføre det vi kaller den moderne datainformasjonsstakken.