Att bygga en omöjligt svår analysplattform

Event stream analytics låter företag använda strömmande händelsedata som inträffat under de senaste sekunderna, minuterna eller timmarna för att få insikter och fatta beslut. Det har blivit viktigt eftersom företag vill förstå vad som händer nu och varför, inklusive att analysera komplexa händelsemönster och flöden. Med den här nya typen av analys kan du snabbt reagera på problem och möjligheter i stunden - men ur ett tekniskt perspektiv är det mycket svårt att göra rätt.

Världens Googles och Facebooks har byggt spretiga hemmagjorda system för att driva sina affärssystem med analys av händelseströmmar. Dessa system, som bemannas av programvaruteam med hundratals ingenjörer, är utom räckhåll för de flesta företag.

Vi har byggt Warehouse-native analytics så att alla företag kan bygga upp en analysstack i världsklass. Allt de behöver är en molnbutik som AWS S3, en strömbearbetningsplattform som Apache Kafka och Warehouse-Native Analytics. Jag är Priyendra Deshwal, CTO och medgrundare av Warehouse-Native Analytics. Att bygga den här plattformen har varit mitt livs äventyr, och idag vill jag ge dig en titt bakom kulisserna på den hemliga sås som får Warehouse-Native Analytics att fungera.

De tekniska utmaningarna

Händelseströmsanalys skiljer sig mycket från traditionell analys och kräver en unik uppsättning funktioner. Låt oss ta en titt på dessa krav och hur de skapar utmaningar som vi har arbetat hårt för att lösa på Warehouse-Native Analytics.

• Inmatning avdata: Event stream analytics handlar om att veta vad som händer nu jämfört med tidigare. Därför måste plattformen stödja konstant inmatning av händelsedata med hög genomströmning och låg latens. Warehouse-native Analytics är utformat för att ta in miljontals händelser per sekund med en latens på under en sekund.
• Varningar påunder ensekund: Konsumtionsmodellen för en plattform för analys av händelseströmmar skiljer sig mycket från traditionell analys. Traditionell analys bygger på att användarna hämtar data från systemet, medan operativa användningsfall (som övervakning) kräver en push-modell. En varning måste utlösas inom några sekunder efter att en negativ händelse inträffat. Live dashboards måste alltid visa det senaste tillståndet i systemet. Warehouse-Native Analytics har inbyggt stöd för kontinuerliga, inkrementella och strömmande SQL-frågor för att hantera dessa användningsfall.
• Interaktiva SQL-frågor: Även om den primära interaktionen med ett händelseströmsystem är push-baserad, kommer användarna fortfarande att behöva interagera med systemet med hjälp av pull-modellen. När en varning utlöses är det till exempel viktigt att användarna kan följa upp med ad hoc-diagnostiska undersökningar av data. För att ge verklig insyn i verksamheten måste plattformen göra det enkelt att sammanföra statiska referensdata med strömmande händelsedata. Warehouse-native Analytics har en toppmodern query execution engine som möjliggör interaktiva SQL-frågor över stora datavolymer, med både data i rörelse och data i vila.
• Optimering av tidsserier: De allra flesta operativa data består av tidsstämplade händelseströmmar, vilket kräver särskild hantering av tidssemantik - för att ta hänsyn till datafullständighet, sen ankomst av data, aggregerade fönster och joins med mera. Warehouse-native Analytics är byggt för att hantera denna komplexitet och stödja effektiv lagring och hämtning av dataset med tidsserier.
• Avancerad analys av händelseflöden: Sann analys av händelseflöden ger användarna möjlighet att utveckla en djup förståelse för händelsesekvenser och vägar för händelsetillstånd. Analys av händelseströmmar (trattar, Sankey-diagram etc.) innebär ofta att man studerar sekvenser av händelser och vägar som tas av händelsetillstånd. Dessa analyser är dock svåra att uttrycka med SQL eller att beräkna med traditionella system. Warehouse-Native Analytics har inbyggt stöd för avancerad händelseflödesanalys.
• Dataset i petabyte-skala upp: I takt med att företag har börjat använda telemetri i många olika branscher har dataset i petabyte-skala blivit vanliga och alla plattformar måste skala upp till dessa storlekar. Warehouse-Native Analytics är utformat för att skala upp till behoven hos de största företagen i världen.

Det finns traditionella BI-plattformar, övervakningsverktyg, produktanalyssystem och en drifta av andra specialiserade alternativ för att hantera ett, eller ibland flera, av dessa krav. Warehouse-Native Analytics är dock den första plattformen med alla funktioner som behövs för analys av händelseströmmar på ett och samma ställe.

Warehouse-Native Analytics viktigaste tekniska innovationer

Warehouse-Native Analytics erbjuds som en vertikalt integrerad molntjänst för att möta dessa krav. Den är byggd på tre viktiga innovationer:

• Konvergerad analytisk bearbetning (CAP): Warehouse-Native Analytics måste stödja en mängd olika analytiska arbetsbelastningar. Vår CAP-dataplattform åstadkommer en sann konvergering av streaming och batchfrågebehandling, med integrerad, optimerad lagring. Den är utformad för strömmande ingång, effektiva inkrementella beräkningar, beräkningar av händelseflöden, tidsresor och kontinuerliga SQL-frågor - i extrem skala.
• Relationella händelseströmmar: Med relationella händelseströmmar möjliggör Warehouse-native analytics komplex händelseflödesanalys ovanpå den välbekanta och kraftfulla relationsmodellen. Du behöver inte använda specialiserade produktanalysverktyg för vissa frågor och relationsdatabaser för andra.
• NetScript: Vi ville göra det enklare att ställa komplexa analytiska frågor som förenar data i vila och data i rörelse. Därför utvecklade vi ett nytt analysspråk, NetScript, som kan komponeras till SQL men som ger en högre abstraktionsnivå, komponerbarhet och återanvändbarhet. För företagsanvändare behövs ingen kod - vi erbjuder ett bibliotek med generiska och användningsspecifika mallar för produktanalys.

Du kan tänka på CAP som beräkningslagret, relationella händelseströmmar som modelleringslagret för affärsenheter och NetScript som hur du enkelt uttrycker komplexa analytiska frågor. Nu ska vi gå närmare in på var och en av dessa innovationer och förklara hur de hjälper oss att lösa viktiga problem med att implementera analys av händelseströmmar i dag.

Konvergerad analytisk bearbetning

Converged analytical processing, eller CAP, är en konvergerad batch- och streamingmotor som körs ovanpå ett mycket optimerat, integrerat lagringslager. Med CAP kan du göra sökningar i alla data på ett och samma ställe med fullt stöd för "join" över data i rörelse och data i vila. CAP är kraftfullt och flexibelt och ger en ryggrad med låg latens och hög genomströmning för allt från realtidsövervakning till avancerad händelseflödesanalys.

CAP har utformats för att tillgodose behovet av att hantera batch- och streamingberäkningar och lagring i en och samma produkt. Datalager har traditionellt hanterat batchberäkningar och lagring, men inte streamingberäkningar (kontinuerliga och inkrementella). Plattformar som Apache Spark och Apache Flink har gjort batch- och streamingberäkningar (men inte lagring). Warehouse-native analytics gör alla tre.

Problemet som det löser

Om du tittar in i ett datakunnigt företag idag hittar du ett virrvarr av datalager, datasjöar, meddelandebussar, strömprocessorer, tidsseriedatabaser, OLAP-motorer i realtid, minnesdatabaser med låg latens, händelseflödesanalys och mycket mer.

Det finns två problem med den här arkitekturen:

1. Hög ägandekostnad: För varje system behöver du ett högutbildat team som hanterar det, och komplexiteten växer exponentiellt när fler system läggs till och relationerna mellan dem också måste hanteras. Du kanske betalar för en leverantör eller betalar med ingenjörstimmarna för att implementera en open source-lösning, men oavsett vilket innebär varje ytterligare system en extra kostnad.
2. Åtskildadata: I en komplex datastack med många analyssystem är alla dataset naturligtvis inte synliga för alla system, och möjligheten att delta i dataset tenderar att vara svag. Detta skapar åtskilda dataset och gör det svårt att få insikter som sträcker sig över flera dataset. Om till exempel data om klick på webbplatsen finns i ett verktyg för händelseanalys och data om kundrelationer finns i ett datalager, kan du inte analysera produktanvändningen utifrån kundens totala utgifter. Med andra ord låter den här arkitekturen faktiskt inte en Product Manager svara på en så grundläggande fråga som "Hur använder mina värdefulla kunder min produkt?"

Så här fungerar det

De viktigaste delarna av CAP-motorn och lagringslagret är:

• Optimering avfrågor: Frågor analyseras och optimeras till en fysisk frågeplan. Den fysiska planen består av en graf med operatörer som är schemalagda för att köras på noder i ett warehouse-native analytics-kluster. Dessa operatörer sammanställs till fragment av högoptimerad maskinkod, vilket gör att frågor kan skanna hundratals miljoner rader per sekund per kärna.
• Enhetlig batch och streaming: Frågeexekveringsmotorn har en streaming-first-arkitektur där Apache Arrow-kodade datapaket flödar genom en operatörsgraf. Dessa operatörer släpper data till nedströmsoperatörer efter att ha mottagit speciella kontrollpaket som innehåller vattenstämpeluppdateringar i händelsetid. Exekveringslagret kan stödja både batch- och streamingberäkningar genom att helt enkelt styra frekvensen för vattenstämpeluppdateringar.
• Anpassat lagringsskikt: Vi använder en kolumnär lagringsarkitektur i tre nivåer där nyinkomna data skrivs direkt till minnet för att möjliggöra en genomströmning på miljontals händelser per sekund med en latenstid på under en sekund. Det här är ett mycket bra sätt att använda de knappa minnesresurserna, eftersom de flesta operativa arbetsbelastningar gynnar ny data och drar stor nytta av att den datan redan finns i minnet. Äldre, mindre nyligen använda data delegeras till lokal NVMe-lagring och blob-/objektlagring i molnet.
• Deklarativa avvägningar mellan kostnad och prestanda: Vi har byggt in "rattar" i systemet som gör det möjligt för användare att styra de relativa cacheprioriteringarna för olika dataset, bygga aggregerade index över dataset, underhålla ytterligare kopior av dataset med olika partitionerings- och klustringsnycklar med mera. Vår vision är att användarna ska kunna uppnå vilken önskvärd punkt som helst på avvägningskurvan mellan kostnad och prestanda.

Relationella händelseströmmar

Genom att modellera affärsdata som vad vi kallar relationella händelseströmmar möjliggör Warehouse-native analytics komplexa händelseflödesanalyser över data som lagras i sin ursprungliga relationella form. Du behöver inte längre välja mellan att undersöka trattar, segmentering av händelser eller kohorter och att köra "vanliga" SQL-frågor på dina händelseströmmar.

Problemet som det löser

Det är mycket svårt för traditionella analyssystem att representera händelsedata. De befintliga metoderna faller inom två kategorier:

• Representera händelsedata i en tillplattad form. Specialiserade system för händelseflödesanalys, t.ex. produktanalysverktyg, kräver att du tvingar in dina affärsdata i rigida, fördefinierade modeller. Som ett resultat förlorar du rikedomen i data. Dessa verktyg saknar också fullständigt SQL-stöd, vilket innebär att de bara kan användas för en mycket liten del av de analytiska användningsområdena.

• Representera händelsedata i sin ursprungliga relationsform. I den här formen har de flesta system svårt att göra händelseflödesanalyser. Beräkningar på händelseströmmar är inte lätta att uttrycka i SQL.

Med relationella händelseströmmar överbryggar Warehouse-native Analytics dessa två metoder för att uppnå det bästa av två världar. Händelsedata representeras i sin ursprungliga relationella form, men den underliggande CAP-arkitekturen kan stödja avancerad händelseflödesanalys direkt på denna relationella form.

Så här fungerar det

Relationella händelseströmmar drivs av flera funktioner som ingår:

• Lagringsoptimeringar: Händelsedata komprimeras i kolumner och sorteras ungefärligt efter tid. Detta ger effektivt stöd för avancerad händelseflödesanalys eftersom händelserna måste behandlas i tidsstämpelsorterad ordning.
• SQL-utökningsbarhet för händelseflödesanalys: MATCH_RECOGNIZE lades till i SQL-standarden för att möjliggöra komplex händelseflödesanalys inom SQL. Warehouse-Native Analytics MATCH_RECOGNIZE-implementering använder JIT-kodgenerering och utnyttjar sin kunskap om den underliggande lagringslayouten för att bearbeta hundratals miljoner händelser per sekund och kärna.
• Förbättrad uttrycksmöjlighet: Beräkningar för händelseflödesanalys är mycket besvärliga att uttrycka i SQL. Warehouse-Native Analytics applikationslager (UI-mallar + NetScript) gör det möjligt att enkelt uttrycka dessa analyser. All komplexitet med att utforma rätt SQL-fråga, tekniska detaljer i samband med korrekt användning av MATCH_RECOGNIZE etc. hanteras av applikationslagret.

NetScript

NetScript är ett programmeringsspråk som gör det möjligt för användare att uttrycka komplexa analytiska beräkningar på ett enkelt och naturligt sätt. NetScript-program manipulerar inte data - de manipulerar snarare SQL-frågor och ger möjlighet att tillämpa vanliga analytiska operationer på dessa frågor: tillämpa filter, aggregera efter någon dimension, sammanfoga mellanresultat efter någon delad dimension, etc.

Varje interaktion i Warehouse-Native Analytics UI drivs av NetScript under huven. Även om vi har funnit att det är intuitivt och kraftfullt, vill vi notera att NetScript är helt valfritt för användarna - du kan fråga plattformen med SQL eller använda vårt stora bibliotek med mallar utan kod.

Problemet som det löser

Vi uppfann NetScript eftersom SQL har tre stora nackdelar när det gäller att representera analytiska beräkningar:

1. SQL är mångordigt: Om du har arbetat med analytisk SQL i verkligheten är du väl medveten om att SQL-frågorna för dessa beräkningar kan vara ganska utförliga, ofta flera sidor långa.
2. SQL är repetitivt: I en typisk företagsmiljö använder ett stort antal frågor ett mycket litet antal join-relationer. Dessa join-villkor upprepas i slutändan i varje fråga.
3. SQL är inte komponerbar: Vilket är det mest naturliga sättet att definiera totalintäktsmåttet i SQL? Ett rimligt svar är: select sum(revenue) from Txns. Detta relativt triviala exempel belyser en viktig brist i SQL. Helst skulle vi vilja definiera det här måttet på ett centralt ställe så att alla våra rapporter kan använda det utan att duplicera logiken. Det är dock inte klart hur vi ska återanvända detta mått. Det är mycket sällan vi vill ha en rapport med totala intäkter för alla produkter eller alla geografiska områden. Faktiska rapporter skulle filtrera denna beräkning efter olika kriterier och dela upp det slutliga antalet efter olika dimensionella attribut (vilket kan leda till kopplingar till andra dimensionella tabeller). Det finns inget enkelt sätt att härleda denna slutliga SQL-fråga från den ursprungliga SQL-frågan som fungerade som definition av måttet för totala intäkter. SQL-vyer ger en viss primitiv komponerbarhet - men de är långt ifrån tillräckliga för att möjliggöra den typ av användningsfall som NetScript är utformat för.

Så här fungerar det

Ett NetScript-program består av frågeuttryck. NetScript-kompilatorn tar frågeuttrycket som indata och använder det underliggande schemat (tabeller, kolumner och relationer) för att konvertera uttrycket till en SQL-fråga som skickas till beräkningslagret.

En NetScript-åtgärd, t.ex. ett filter, filtrerar inte bara data som kommer ut från en operator. Den förstår snarare semantiken i indata och gör djupgående ingrepp i SQL-frågan för att stödja semantiken i det filter som används. Denna kirurgi kan driva filtret genom aggregerade, introducera joins för att få in kolumner som refereras till av filtervillkoret, och så vidare.

Vi påstår inte att NetScript kan ersätta SQL - det kompileras ju till SQL! Men vi tror att NetScript-modellen ligger närmare hur användare (och analytiska applikationer) representerar beräkningar, vilket gör att du kan skriva program på en högre abstraktionsnivå.

Ljuset i slutet av analystunneln

En lösning för analys av händelseströmmar har varit på gång i många decennier. Nu är timingen äntligen rätt. Ur teknikens synvinkel är det två faktorer som gör det möjligt för operativ intelligens att växa fram idag:

1. Flödesbearbetning: Plattformar för flödesbearbetning som Kafka är nu standard i de flesta företag. Det finns också en ökande förståelse för nyanserna i strömbearbetning, t.ex. semantik med exakt samma data, data som kommer i oordning eller sent, vattenstämplar, transaktionsgarantier osv. Som ett resultat av detta konsumeras allt mer data på ett strömmande sätt, vilket öppnar upp för potentialen för strömmande analys av dessa data.
2. Datasjöar i molnet: Möjligheten att instrumentera och samla in händelsedata i realtid måste åtföljas av effektiva sätt att lagra och hantera dessa data. Det är här moderna datasjöar kommer in i bilden. Cloud blob/object stores som AWS S3 tillhandahåller effektiva och kostnadseffektiva sätt att lagra, säkra och hantera en ständigt ökande, massiv volym av händelsedata. I takt med att allt fler företag flyttar till molnet och bygger upp dessa moderna datasjöar blir all rådata på lägsta detaljnivå tillgänglig för analys.

Den tredje delen som saknas är en plattform som gör det möjligt, och faktiskt enkelt, att ställa komplexa analytiska frågor över en konvergerande mängd av dina strömmande data och batchdata.

Det är här Warehouse-Native Analytics kommer in för att komplettera det vi kallar den moderna dataintelligensstacken.