Data 2022 outlook, del et: Bliver dataskyer nemmere? Vil streaming forsvinde fra sin egen ø?

0
173

Tony Baer (dbInsight)Skrevet af Tony Baer (dbInsight), medvirkende skribent Tony Baer (dbInsight) Tony Baer (dbInsight) bidragende skribent

Ovum

Fuld biografi Udgivet i Big on Data den 3. januar 2022 | Emne: Big Data

Med pandemien nærmer sig sit to-års jubilæum, er væksten i cloud-adoptionen fortsat med at accelerere. Selvom den er dateret i marts sidste år, viser den seneste tilstand af cloud-rapporten fra Flexera en betydelig acceleration i cloud-udgifter for store virksomheder, hvor andelen udbetaler over 1 million USD/måned – det dobbelte i forhold til det foregående år.

Som rapporteret af Larry Dignan sidste sommer, kan et modreaktion til skymigrering begynde at brygge baseret på voksende udgifter. Vi har hørt anekdoter fra teknologiudbydere som Vertica om, at nogle af deres største kunder faktisk repatrierede arbejdsbyrder fra skyen tilbage til deres eget datacenter eller colocation faciliteter.

Så hvad er der på tryk i år? Vi deler vores 2022-udsigt over to stillinger. Her vil vi fokusere på trends med cloud-dataplatforme; i morgen deler vi vores tanker om, hvad der vil ske med data mesh i det kommende år.

Når vi ser tilbage på 2021

Sidste år afslørede nogle af de sidste lokale databaseholdouts, såsom Vertica og Couchbase, deres egne cloud-administrerede tjenester. Dette afspejler den virkelighed, at selvom ikke alle kunder kommer til at implementere i den offentlige sky, er det nu en nødvendig tilføjelse til porteføljen at tilbyde en as-a-service mulighed.

På trods af væksten i cloud-adoption, så database- og analyseverdenen ikke dramatiske introduktioner af produkter eller cloud-tjenester. I stedet så den en afrunding af porteføljer med tilføjelsen af ​​serverløse muligheder for analyse, og den bevægede sig mod pushdown-behandling i databasen eller lagerniveauet. Bortset fra HPE, som afslørede en betydelig udvidelse af sin GreenLake hybrid cloud-platform midt på året, var det samme stort set tilfældet på hybrid cloud-fronten.

Da de fleste udbydere havde plantet deres andel i skyen, var det sidste år om cloud-udbydere, der bygger broer for at gøre det nemmere at løfte og flytte eller løfte og transformere on-premise databaseimplementeringer. Til løft og skift tilbød Microsoft allerede Azure SQL Database Managed Instance til SQL-serverkunder, og det tilføjede administreret instans til Apache Cassandra i 2021.

I mellemtiden introducerede AWS sit svar på Managed Instance: en ny RDS Custom-mulighed til SQL Server- og Oracle-kunder, der kræver specielle konfigurationer, som ellers ikke ville blive understøttet i RDS. Dette kan især være nyttigt i tilfælde, der understøtter for eksempel ældre ERP-applikationer.

Hvad hvis du vil fortsætte med at bruge dine eksisterende SQL-færdigheder på et nyt mål? Sidste år udgav AWS Babelfish, et open source-værktøj, der automatisk kan konvertere de fleste SQL Server T-SQL-kald til PostgreSQL's pg/PLSQL-dialekt. Og så er der Datometry for at bare virtualisere din database.

Også i en ånd af løft og skift, så hver af de store skyer sidste år tilføje eller udvide databasemigreringstjenester designet til at gøre processen enklere. AWS og Azure havde allerede tjenester, der gav guidede tilgange til migrering fra Oracle eller SQL Server til MySQL eller PostgreSQL. I mellemtiden introducerede Google en databasemigreringstjeneste, der gør overførslen af ​​lokalt MySQL eller PostgreSQL til Cloud SQL til en næsten fuldautomatisk proces.

Også: Analytics og AI i 2022: Innovation i COVID-19-æraen

Byrden er i øjeblikket på kunden

Streaming vil begynde at konvergere med analytics og operationelle databaser

Et længe uhåndgribeligt mål for operationelle systemer og analyser er at forene data i bevægelse (streaming) med data i hvile (data sidder i en database eller datasø).

I det kommende år forventer vi at se streaming og driftssystemer komme tættere på hinanden. Fordelen ville være at forbedre operationel beslutningsstøtte ved at indlejre nogle letvægtsanalyse- eller forudsigelsesevner. Der ville være klare fordele for brugssager så forskellige som Customer 360 og Supply Chain Optimization; Vedligeholdelse, reparation og eftersyn (MRO); handel med kapitalmarkeder; og smart grid balancering. Det kunne også give feedback-loops i realtid til ML-modeller. I en verden, hvor forretning er ved at blive digitaliseret, er det at have den forudsigende sløjfe til at understøtte datadrevne operationelle beslutninger ved at ændre sig fra luksus til nødvendighed.

Ideen om at bringe streaming og data i ro sammen er næppe ny; det blev beskrevet for år siden som Kappa-arkitekturen, og der har været isolerede implementeringer på big data-platforme — den tidligere MapR's “konvergerede platform” (nu HPE Ezmeral Unified Analytics) kommer til at tænke på.

Streaming-arbejdsbelastninger kører traditionelt på deres egne dedikerede platforme på grund af deres ekstreme ressourcekrav. Showstopperen til at holde streaming på sin egen ø af infrastruktur er ressourcestrid.

Streaming-applikationer – såsom at analysere real-time kapitalmarkedsfeeds, opdage uregelmæssigheder i datastrømmen fra fysiske maskiner, fejlfinding af driften af ​​netværk eller overvågning af kliniske data – har typisk fungeret selvstændigt. Og på grund af behovet for at opretholde et let fodaftryk, har analyser og forespørgsler en tendens til at være enklere end hvad du kunne køre i et datavarehus eller en datasø. Specifikt involverer streaminganalyse ofte filtrering, parsing og i stigende grad forudsigende tendenser.

Når der er en overdragelse til datavarehuse eller datasøer, er dataene i de fleste tilfælde begrænset til resultatsæt. For eksempel kan du køre en SQL-forespørgsel på Amazon Kinesis Data Analytics, der identificerer outliers, fortsætter resultaterne til Redshift og derefter udføre en forespørgsel på de kombinerede data for mere komplekse analyser. Men det er en flertrinsoperation, der involverer to tjenester, og den er ikke strengt taget i realtid.

Ganske vist kan du, i hukommelsen operationelle databaser som Redis, understøtte den næsten øjeblikkelige vedholdenhed af streaming af data med kun tilføjelseslog. dataformater, men det er ikke det samme som at tilføje en forudsigelig feedback-loop til operationelle applikationer.

I løbet af de sidste par år har vi set nogle hints om, at streaming er ved at blive en del af operationelle og analytiske dataskyer. Confluent åbnede dørene, da det udgav ksqldb på Confluent Cloud tilbage i 2020. Sidste år introducerede DataStax betaen til Astra Streaming, understøttet af Apache Pulsar (ikke Kafka); det er i øjeblikket en separat tjeneste, men vi forventer, at den vil blive blandet sammen med Astra DB over tid. I Spark-universet kan Delta Lake fungere som en streamingkilde eller synke til Spark Structured Streaming.

Game changer er cloud-native arkitektur. Skyens elasticitet eliminerer problemer med ressourcestridigheder, mens mikrotjenester giver mere modstandsdygtige alternativer til klassiske designmønstre, der involverer en central orkestrator eller statsmaskine. Til gengæld gør Kubernetes (K8s) det muligt for analytiske platforme at understøtte elasticitet uden at skulle genopfinde hjulet til at orkestrere computerressourcer. Konvergerede streaming- og operationelle eller analytiske systemer kan køre på distribuerede klynger, som kan opdeles og orkestreres til at udføre streaming i realtid, flette resultater og korrelere med komplekse driftsmodeller.

En sådan konvergens vil ikke erstatte dedikerede streamingtjenester, men der er klare muligheder for cloud-virksomheder: Amazon Kinesis Data Analytics parret med Redshift eller DynamoDB; Azure Stream Analytics med Cosmos DB eller Synapse Analytics; Google Cloud Dataflow med BigQuery eller Firestore kommer alle til at tænke på.

Men der er også muligheder for datalagre i realtid i hukommelsen. Vi taler til dig, Redis, for ikke at nævne nogen af ​​de snesevis af tidsseriedatabaser derude.

Også: Hvad datastyringsledere forventer for sektoren i 2022

Datadeling og -deling på samme måde

Set i bakspejlet ser dette ud som en no-brainer. Med cloud storage som de facto datasøen, bør fremme af bredere adgang til data være en win-win for alle: Dataudbydere får flere kilometer (og potentielt indtægtsgenerering) ud af deres data; datakunder får adgang til mere forskelligartede datasæt; udbydere af cloud-platforme kan sælge mere udnyttelse (opbevaring og computer); og cloud-datavarehuse kan transformere sig selv til datadestinationer.

Set fra det perspektiv er det overraskende, at det har taget hver af de store cloud-udbydere næsten fem år at fange en idé, som Snowflake udklækkede.

Snowflake og AWS har været de mest aktive i at fremme dataudvekslinger, selvom de begge nærmede sig det fra modsatte retninger. Snowflake begyndte med en datadelingsfunktion rettet på tværs af interne afdelinger og åbnede senere en dataudveksling for tredjeparter. AWS gik i omvendt rækkefølge og åbnede en dataudveksling på AWS Marketplace for et par år tilbage, men det har kun tilføjet muligheder for intern deling af data for Redshift-kunder (det krævede, at AWS udviklede RA3-instansen, der til sidst adskilte Redshift-data i sin egen pulje ) for det seneste år.

Snowflake har taget det ekstra skridt at åbne vertikale industrisektioner af sin markedsplads, hvilket gør det nemmere for kunderne at oprette forbindelse til de rigtige datasæt. På den anden side slog AWS Snowflake til spidsen for at kommercialisere sin datamarkedsplads ved at bruge den eksisterende AWS Marketplace-mekanisme.

Google fulgte trop med Analytics Hub for at dele BigQuery-datasæt, en funktion, som de efterfølgende vil udvide til andre aktiver såsom Looker Blocks og Connected Sheets. Microsoft Azure er også gået ind i sagen.

I løbet af det næste år forventer vi, at hver af cloud-udbyderne konkretiserer deres interne og eksterne dataudvekslinger og markedspladser, især når det kommer til kommercialisering.

Databaseplatforme henvender sig til ML for at drive sig selv< /strong>

Dette er bagsiden af ​​ML i databasen, som vi forudsagde ville blive et afkrydsningsfelt i 2021 for cloud-datavarehuse og datasøer. Det, vi taler om her, er brugen af ​​ML under coveret til at hjælpe med at køre eller optimere en database.

Oracle affyrede det første skud med den autonome database; Oracle gik fuldt ud med ML ved at designe en database, der bogstaveligt talt kører sig selv. Det er kun muligt med bredden af ​​databaseautomatisering, der stort set er unik for Oracle-databasen. Men for Oracles rivaler har vi et mere beskedent synspunkt: at anvende ML til at hjælpe, ikke erstatte, DBA med at optimere specifikke databaseoperationer.

Som enhver erfaren DBA vil bevidne, involverer driften af ​​en database masser af figurative “knapper”. Eksempler omfatter fysisk dataplacering og lagertrinering, rækkefølgen af ​​joinforbindelser i en kompleks forespørgsel og identifikation af de rigtige indekser. I skyen kunne det også omfatte at identificere de mest optimale hardwareforekomster. Typisk er konfigurationer fastsat af formelle regler eller baseret på DBA's uformelle viden.

Optimering af en database er velegnet til ML. Processerne er datarige, da databaser genererer enorme skare af logdata. Problemet er også velafgrænset, da funktionerne er veldefinerede. Og der er et betydeligt potentiale for omkostningsbesparelser, især når det kommer til at tage højde for, hvordan man bedst lægger data ud eller designer en forespørgsel. Cloud DBaaS-udbydere er godt placeret til at anvende ML til at optimere driften af ​​deres databasetjenester, da de kontrollerer infrastrukturen og har rige puljer af anonymiserede driftsdata, som de kan bygge og løbende forbedre modeller på.

Vi har dog været overraskede over, at der har været få deltagere til Oracles udfordring. Næsten den eneste formelt produktiserede brug af ML (bortset fra Oracle) er med Azure SQL Database og SQL Managed Instance; Microsoft tilbyder autotuning af indekser og forespørgsler. Det er et klassisk problem med afvejninger: den hurtigere genfindingshastighed med et indeks i forhold til omkostningerne og overhead ved skrivninger, når du har for mange indekser. Azures automatiserede tuning kan automatisk oprette indekser, når den registrerer forespørgselshotspots; falder indekser, der forbliver ubrugte efter 90 dage; og genindsætter tidligere versioner af forespørgselsplaner, hvis nyere viser sig at være langsommere.

I løbet af det kommende år forventer vi at se flere cloud-DBaaS-tjenester introducere muligheder, der inkorporerer ML for at optimere databasen, hvilket fremmer virksomhederne, hvordan de kan spare penge .

Oplysninger: AWS, DataStax, Google Cloud, HPE, IBM og Oracle er dbInsight-klienter.

Fremhævede

Hvorfor jeg udskiftede min iPhone 12 med Pixel 6 Covid-testen: De bedste hurtige testsæt derhjemme American Airlines har en særlig måde at håndtere vrede kunder på Platforme med lav kode og ingen kode bevæger sig ud over scenen med skinnende værktøj Amazon | Digital transformation | Robotik | Internet of Things | Innovation | Enterprise Software