Data 2022 Outlook del I: Vil dataskyer bli enklere og strømming forsvinne fra sin egen øy?

Med pandemien nærmer seg toårsjubileet, er det liten tvil om at veksten av skyadopsjon har fortsatt å akselerere. Selv om den er datert i mars i fjor, viste den siste tilstanden til skyrapporten fra Flexera betydelig akselerasjon i skyutgifter for store bedrifter, med andelen som utbetalte over 1 million dollar per måned doblet i forhold til året før.

Som rapportert av Larry Dignan i fjor sommer, kan et tilbakeslag til skymigrasjon begynne å komme basert på forestillingen om at mye billig til slutt blir dyrt. Vi har hørt anekdoter fra teknologileverandører som Vertica om at noen av deres største kunder faktisk repatrierte arbeidsbelastninger fra skyen tilbake til deres eget datasenter eller samlokaliseringsfasiliteter.

Ser tilbake på 2021

I fjor avslørte noen av de siste lokale databaseholdoutene, som Vertica og Couchbase, sine egne skyadministrerte tjenester: det reflekterte virkeligheten som, selv om ikke alle kunder kommer til å distribuere i den offentlige skyen, tilbyr en as-a -tjenestealternativet er nå et nødvendig tillegg til porteføljen.

Til tross for veksten i skyadopsjon, så databasen og analyseverdenen ikke mange dramatiske introduksjoner av produkter eller skytjenester; i stedet så vi en avrunding av porteføljer, med tillegg av serverløse alternativer for analyse, og et økende trekk mot pushdown-behandling i databasen eller lagringsnivået. Med unntak av HPE, som avduket en betydelig utvidelse av GreenLake hybridskyplattformen sin midt i året, gjaldt det samme stort sett på hybridskyfronten.

Da de fleste tilbydere hadde plantet sine eierandeler i skyen, var det siste året om skyleverandører som bygger broer for å gjøre det enklere å løfte og flytte eller løfte og transformere lokale databasedistribusjoner. For løft og skift tilbød Microsoft allerede Azure SQL Database Managed Instance til SQL-serverkunder, og i fjor la til administrert forekomst for Apache Cassandra.

I mellomtiden introduserte AWS sitt svar på Managed Instance: et nytt RDS Custom-alternativ for SQL Server- og Oracle-kunder som har spesielle konfigurasjoner som ellers ikke ville blitt støttet i RDS. Dette kan være spesielt nyttig for tilfeller som støtter for eksempel eldre ERP-applikasjoner. Og hva om du vil fortsette å bruke dine eksisterende SQL-ferdigheter på et nytt mål? I fjor ga AWS ut Babelfish, et åpen kildekodeverktøy som automatisk kan konvertere de fleste SQL Server T-SQL-anrop til PostgreSQLs pg/PLSQL-dialekt. Og så er det Datometry, som sier, bare virtualiser databasen din.

Også i en ånd av løft og skift, så hver av de store skyene i fjor legge til eller utvide databasemigreringstjenester designet for å gjøre prosessen enklere. AWS og Azure har allerede tjenester som gir veilede tilnærminger til migrering fra Oracle eller SQL Server til MySQL eller PostgreSQL. I fjor introduserte Google en databasemigreringstjeneste som er omtrent som for eksempel: å gjøre overføring av lokal MySQL eller PostgreSQL til Cloud SQL til en nesten helautomatisert prosess.

Så hva er på trykk for 2022? Vi deler utsiktene for året fremover på to poster. Her skal vi trene øye på trender med skydataplattformer, og i morgen deler vi tankene våre om hva som vil skje når søkelyset skinner på datanett i det kommende året.

Skyen kan starte blir enklere

Skyleverandører kommer ikke plutselig til å slutte å utvide porteføljene sine ved å legge til nye produkter og tjenester. Men vi forventer at de i løpet av det kommende året vil begynne å være mer oppmerksomme på å identifisere synergier på tvers av sine porteføljer som de kan levere nye blandede løsninger fra. Sjåføren? Å tilby løsninger som blander noen av tjenestene deres, bør fjerne i det minste noe av byrden med integreringsevner fra skuldrene til skykunder.

Bakteppet for alt dette er at skyen skulle forenkle, ikke bare IT-budsjettering, men også driften. I dataverdenen, når kunder tar i bruk administrerte DBaaS-tjenester som Amazon Aurora, Azure SQL Database, Google Cloud Spanner, IBM Db2 Warehouse Cloud eller Oracle Autonomous Database, er beregnings- og lagringsforekomster vanligvis forhåndsbestemt og DBaaS-leverandøren håndterer programvaren. Serverless tar på sin side forenklingen opp enda et hakk ved å unngå behovet for kundene til å kapasitetsplanlegge distribusjonene sine.

Problemet blir da, får vi for mye av det gode?

< p>AWS alene har godt over 250 tjenester, hvorav du for eksempel har 11 forskjellige containertjenester, 16 databaser og over 30 maskinlæringstjenester (ML). Det er ikke mye forskjellig med Google Cloud eller Azure heller. Google Cloud tilbyr et dusin analytiske tjenester, 10 containertjenester og minst et dusin eller flere AI- og ML-tjenester; mens Azure tilbyr nesten et dusin DevOps-tjenester, 10 hybrid- og multiskytjenester og nesten et dusin IoT-tjenester. Med tungen på vektskålen ble vi privat lettet da AWS ikke introduserte en 17. database på den siste re:Invent-konferansen.

Breden av administrerte tilbud i skyen gjenspeiler en voksende modenhet: skyleverandører utvider rekkevidden til deres plattform-, database- og programvare-som-en-tjeneste-tilbud, og dekker et bredere utvalg av bedriftsdatabehov.

Så, hva skjer når du ønsker å integrere et BI-verktøy med en database eller legge til en chatbot for kundeopplevelse, videogjenkjenningssystem eller en eller annen mulighet for hendelsesvarsling for en produksjons-, forsyningskjede- eller vedlikeholdsprosess? Eller containerisere og distribuere det som mikrotjenester? Med et så stort utvalg av valg har byrden ligget på kunden for å integrere eller sette dem sammen.

Det neste trinnet for skyleverandører er å utnytte mangfoldet i porteføljene deres, identifisere synergiene og begynne å samle løsninger som i det minste løfter en del av integrasjonsbyrden fra kundens skuldre. Vi ser noen tidlige omrøringer. For eksempel har AWS og Google Cloud gjort fremskritt for å forene sine ML-utviklingstjenester. Som vi vil legge merke til nedenfor, ser vi en viss fremgang i analysestakken der skydatavarehustjenester begynner å enten forvandles til ende-til-ende-løsninger, eller presse ned mer prosessering inn i databasen. Og vi ser integrering av konversasjons-AI (a.k.a., chatbots) i preskriptive tilbud som Google Contact Center AI.

Ønskelisten vår inkluderer å bygge inn noe datastoff, katalogisering og forent spørring i analytiske verktøy, både for sluttbrukere og dataforskere, slik at de ikke trenger å integrere en verktøykjede for å få en sammenhengende oversikt over data. Det er utmerket mulighet til å bygge inn ML-funksjoner som lærer og optimaliserer til en sluttbrukers eller organisasjons spørremønstre basert på SLA og kostnadskrav. Vi ønsker også å se foreskrivende løsninger som knytter ulike AI-tjenester til forretningsapplikasjoner, for eksempel videogjenkjenning for produksjon av kvalitetsapplikasjoner. Som vi bemerker nedenfor, forventer vi å se strømming integrert tettere med datavarehus/datainnsjøer og operasjonelle databasetjenester.

Vi forventer at skyleverandører i 2022 vil øke innsatsen for å utnytte synergiene som skjuler seg i tydelig i porteføljene deres – et initiativ som også i stor grad bør involvere horisontale og vertikale løsningspartnere.

Strøming vil begynne å konvergere med analyser og operasjonelle databaser

Et lenge unnvikende mål for operasjonelle systemer og analyser er å forene data i bevegelse (streaming) med data en hvile (data som sitter i en database eller datainnsjø).

I det kommende året forventer vi å se streaming og driftssystemer komme nærmere hverandre. Fordelen ville være å forbedre operativ beslutningsstøtte ved å bygge inn litt lettvektsanalyse eller prediktiv evne. Det vil være klare fordeler for brukstilfeller så forskjellige som Customer 360 og Supply Chain Optimization; Vedlikehold, reparasjon og overhaling (MRO); kapitalmarkedshandel; og smart nettbalansering. Det kan også gjøre analyse mer oppdatert og gi sanntids tilbakemeldingsløkker for ML-modeller. I en verden hvor virksomheten blir digitalisert, endres det å ha den prediktive sløyfen for å støtte datadrevne driftsbeslutninger fra luksus til nødvendighet.

Ideen om å bringe strømming og data i ro sammen er neppe ny; det ble skrevet ut for mange år siden som Kappa-arkitekturen, og det har vært isolerte implementeringer på big data-plattformer – den tidligere MapRs “konvergerte plattform” (nå HPE Ezmeral Unified Analytics) kommer til tankene.

Strømmearbeidsmengder kjørte tradisjonelt på deres egne dedikerte plattformer på grunn av deres ekstreme ressurskrav. Showstopperen for å holde strømming på sin egen øy av infrastruktur har lenge vært ressursstrid.

Strømmeapplikasjoner, som å analysere kapitalmarkedsstrømmer i sanntid, oppdage anomalier i dataflyten fra fysiske maskiner, feilsøke driften av nettverk eller overvåke kliniske data, har vanligvis fungert frittstående. Og på grunn av behovet for å opprettholde et lett fotavtrykk, hadde analyser og spørringer en tendens til å være mye enklere enn det du kunne kjøre i et datavarehus eller datainnsjø. Nærmere bestemt involverer streaminganalyse ofte filtrering, analysering og i økende grad prediktiv trending.

Når det var en overlevering til datavarehus eller datainnsjøer, ville dataene i de fleste tilfeller være begrenset til resultatsett. Du kan for eksempel kjøre en SQL-spørring på Amazon Kinesis Data Analytics som identifiserer uteliggere, vedvare resultatene til Redshift, og deretter utføre en spørring på de kombinerte dataene for mer komplekse analyser. Men det er en flertrinnsoperasjon, som involverer to tjenester, som strengt tatt ikke er sanntid.

Riktignok støtter driftsdatabaser i minnet som Redis nesten umiddelbar varighet av strømmedata med loggdataformater som bare kan legges til, men det er ikke det samme som å legge til en prediktiv tilbakemeldingssløyfe til operative applikasjoner.

I løpet av de siste par årene har vi sett noen hint om at strømming er i ferd med å bli en del av operasjonelle og analytiske dataskyer. Confluent åpnet dørene da den ga ut ksqldb på Confluent Cloud tilbake i 2020, mens DataStax i fjor introduserte betaen for Astra Streaming, støttet på Apache Pulsar (ikke Kafka); det er for øyeblikket en egen tjeneste, men vi forventer over tid at den vil bli blandet inn med Astra DB. I Spark-universet kan Delta Lake fungere som en strømmekilde eller synke for Spark Structured Streaming.

Spillveksleren er skybasert arkitektur. Elastisiteten til skyen eliminerer problemer med ressursstrid, mens mikrotjenester gir mer robuste alternativer til klassiske designmønstre som involverer en sentral orkestrator eller statsmaskin. I sin tur gjør Kubernetes (K8s) det mulig for analytiske plattformer å støtte elastisitet uten å måtte finne opp hjulet for å orkestrere dataressurser på nytt. Konvergerte strømme- og operasjonelle eller analytiske systemer kan kjøres på distribuerte klynger som kan partisjoneres og orkestreres for å utføre strømanalyse i sanntid, slå sammen resultater og korrelere med komplekse driftsmodeller.

Slik konvergens vil ikke erstatte dedikerte strømmetjenester, men det er klare muligheter for etablerte nettskyer: Amazon Kinesis Data Analytics sammenkoblet med Redshift eller DynamoDB; Azure Stream Analytics med Cosmos DB eller Synapse Analytics; Google Cloud Dataflow med BigQuery eller Firestore kommer til tankene. Men det er også muligheter for datalagre i sanntid i minnet. Vi snakker til deg, Redis, for ikke å snakke om noen av dusinvis av tidsseriedatabaser der ute.

Del og del data på samme måte

I ettertid ser dette ut som en no-brainer. Med skylagring som de facto datainnsjøen, bør fremme av bredere tilgang til data være en vinn-vinn for alle: dataleverandører får mer kjørelengde (og potensielt inntektsgenerering) ut av dataene sine; datakunder får tilgang til flere forskjellige datasett; leverandører av skyplattformer kan selge mer utnyttelse (f.eks. lagring og databehandling); mens skydatavarehus forvandler seg til datadestinasjoner. Fra det perspektivet er det overraskende at det har tatt hver av de store nettskyleverandørene nesten fem år å fange opp en idé som Snowflake klekket ut.

Snowflake, etterfulgt av AWS, har vært de mest aktive i å fremme datautveksling, selv om begge nærmet seg det fra motsatte retninger. Snowflake begynte med en datadelingsmulighet rettet på tvers av interne avdelinger og åpnet senere en datautveksling for tredjeparter; AWS gikk i omvendt rekkefølge, og åpnet en datautveksling på AWS Marketplace for et par år tilbake, men bare i løpet av det siste året har det lagt til muligheter for intern deling av data for Redshift-kunder (som krevde at AWS utviklet RA3-forekomsten som til slutt skilte Redshift-data inn i sin eget basseng). Snowflake har tatt det ekstra trinnet med å åpne vertikale industriseksjoner av markedsplassen, noe som gjør det enklere for kunder å koble seg til de riktige datasettene; på den annen side slo AWS Snowflake til bunns i kommersialiseringen av datamarkedsplassen sin ved å bruke den eksisterende AWS Marketplace-mekanismen.

Google fulgte etter i år med Analytics Hub for å dele BigQuery-datasett, en funksjon som de vil deretter utvides til andre eiendeler som Looker Blocks og Connected Sheets. Microsoft Azure har også kommet på banen.

I løpet av det neste året forventer vi at hver av nettskyleverandørene skal utvikle sine interne og eksterne datautvekslinger og markedsplasser, spesielt når det gjelder kommersialisering.

Databaseplattformer henvender seg til ML for å kjøre seg selv

Dette er baksiden av ML i databasen, som vi i fjor spådde ville bli et avmerkingsbokselement for skydatavarehus og datainnsjøer. Det vi snakker om her er bruken av ML under dekslene for å hjelpe til med å kjøre eller optimalisere en database.

Oracle avfyrte det første skuddet med Autonomous Database. Oracle gikk fullt ut med ML ved å designe en database som bokstavelig talt kjører seg selv. Det er bare mulig med bredden av databaseautomatisering som stort sett er unik for Oracle-databasen. Men for Oracles rivaler har vi et mer beskjedent syn: å bruke ML for å hjelpe, ikke erstatte DBA for å optimalisere spesifikke databaseoperasjoner.

Som enhver erfaren DBA vil vitne om, innebærer det å kjøre en database mange figurative «knotter». Eksempler inkluderer fysisk dataplassering og lagringsnivå, sekvensen av sammenføyninger i en kompleks spørring og identifisering av de riktige indeksene. I skyen kan det også omfatte identifisering av de mest optimale maskinvareforekomstene. Vanligvis er konfigurasjoner satt av formelle regler eller basert på DBAs uformelle kunnskap.

Optimalisering av en database er godt egnet for ML. Prosessene er datarike, ettersom databaser genererer enorme mengder loggdata. Problemet er også godt begrenset, siden funksjonene er veldefinerte. Og det er et betydelig potensial for kostnadsbesparelser, spesielt når det gjelder å vurdere hvordan man best kan legge ut data eller designe en spørring. Cloud DBaaS-leverandører er godt posisjonert til å bruke ML for å optimere driften av databasetjenestene deres ettersom de kontrollerer infrastrukturen og har rike puljer av anonymiserte driftsdata som de kan bygge og kontinuerlig forbedre modeller på.

Så vi har blitt overrasket over at det så langt har vært få som har mottatt Oracles utfordring. Omtrent den eneste formelt produktiserte bruken av ML (bortsett fra Oracle) er med Azure SQL Database og SQL Managed Instance. Microsoft tilbyr autotuning av indekser og spørringer. Det er et klassisk problem med avveininger: den raskere gjenfinningshastigheten med en indeks vs. kostnadene og overhead av skrivinger når du har for mange indekser. Azures automatiserte tuning kan automatisk lage indekser når den registrerer søk-hot spots; faller indekser som går ubrukt etter 90 dager; og gjeninnfør tidligere versjoner av spørreplaner hvis nyere viser seg tregere.

Andre har eksperimentert med teknikker som forsterkende læring i ulik grad av suksess. UC Berkeleys RISELab har eksperimentert med forsterkende læring for å øke ytelsen i forhold til Sparks eksisterende Catalyst-søkeoptimerer. Som nevnt ovenfor, har skyadministrerte databasetjenesteleverandører enorme mengder data for å trene ML-modeller. For kostnads- eller ytelsesbevisste kunder kan ML gi taktiske konkurransefortrinn som, i motsetning til den autonome databasen, ikke vil få deres potensielle marked av DBAer til å oppfatte jobbene deres som truet.

I løpet av det kommende året, vi forventer å se flere sky-DBaaS-tjenester introdusere alternativer som inkluderer ML for å optimalisere databasen, og fremme for bedrifter hvordan de kan spare penger.

Offentliggjøring: AWS, DataStax, Google Cloud, HPE, IBM og Oracle er dbInsight-klienter.

Big Data

Googles toppsøk i 2021: Squid Spill, COVID-19-vaksine, Bernie Sanders sine votter Otonomo: Fremtiden kjører på mobilitetsdata Kan denne maskinlæringsmodellen halvere skykostnadene dine? Hvordan teknologi og data får Walmart til å skinne i forsyningskjedeproblemer Amazon | Digital transformasjon | Robotikk | Internet of Things | Innovasjon | Enterprise Software