Skrivet av Tony Baer (dbInsight), bidragande skribent Tony Baer (dbInsight) Bidragande skribent
Ovum
Fullständig biografi Publicerad i Big on Data den 3 januari 2022 | Ämne: Big Data
När pandemin närmar sig sitt tvåårsjubileum har tillväxten av molnintroduktion fortsatt att accelerera. Även om den daterades i mars förra året, visar den senaste molnrapporten från Flexera en betydande acceleration av molnutgifterna för stora företag, med andelen som betalar ut över 1 miljon USD/månad – dubbelt jämfört med föregående år.
Som rapporterades av Larry Dignan förra sommaren, kan en motreaktion till molnmigrering börja brygga baserat på växande utgifter. Vi har hört anekdoter från teknikleverantörer som Vertica att några av deras största kunder faktiskt repatrierade arbetsbelastningar från molnet tillbaka till sina egna datacenter eller samlokaliseringsanläggningar.
Så vad händer i år? Vi delar upp vår utsikt för 2022 på två inlägg. Här kommer vi att fokusera på trender med molndataplattformar; imorgon delar vi med oss av våra tankar om vad som kommer att hända med datamesh under det kommande året.
När vi ser tillbaka på 2021
Förra året avslöjade några av de sista lokaliserade databaserna, som Vertica och Couchbase, sina egna molnhanterade tjänster. Detta återspeglar verkligheten att även om inte alla kunder kommer att distribuera i det offentliga molnet, är det nu ett obligatoriskt tillägg till portföljen att erbjuda ett som en tjänst-alternativ.
Trots ökningen av molnintroduktionen såg databasen och analysvärlden inga dramatiska introduktioner av produkter eller molntjänster. Istället såg den en avrundning av portföljer med tillägg av serverlösa alternativ för analys, och det gick mot pushdown-bearbetning i databasen eller lagringsnivån. Exklusive HPE, som avslöjade en betydande utbyggnad av sin GreenLake hybridmolnplattform i mitten av året, gällde detsamma i stort sett på hybridmolnfronten.
Då de flesta leverantörer hade placerat sina andelar i molnet var det senaste året om molnleverantörer som bygger broar för att göra det enklare att lyfta och flytta eller lyfta och transformera lokala databasinstallationer. För lyft och skift erbjöd Microsoft redan Azure SQL Database Managed Instance till SQL-serverkunder och lade till hanterad instans för Apache Cassandra under 2021.
Samtidigt introducerade AWS sitt svar på Managed Instance: ett nytt RDS Custom-alternativ för SQL Server- och Oracle-kunder som kräver speciella konfigurationer som annars inte skulle stödjas i RDS. Detta kan vara särskilt användbart för instanser som stöder, till exempel, äldre ERP-applikationer.
Vad händer om du vill fortsätta använda dina befintliga SQL-kunskaper på ett nytt mål? Förra året släppte AWS Babelfish, ett verktyg med öppen källkod som automatiskt kan konvertera de flesta SQL Server T-SQL-anrop till PostgreSQL:s pg/PLSQL-dialekt. Och så finns det Datometry för att bara virtualisera din databas.
Också i en anda av lyft och skift, såg vart och ett av de stora molnen förra året lägga till eller utöka databasmigreringstjänster utformade för att göra processen enklare. AWS och Azure hade redan tjänster som gav vägledda metoder för migrering från Oracle eller SQL Server till MySQL eller PostgreSQL. Samtidigt introducerade Google en databasmigreringstjänst som gör överföringen av lokal MySQL eller PostgreSQL till Cloud SQL till en nästan helt automatiserad process.
Även: Analytics och AI 2022: Innovation i covid-19-epok
Burdan ligger för närvarande på kunden
Streaming kommer börja konvergera med analyser och operativa databaser
Ett länge svårfångat mål för operativa system och analys är att förena data i rörelse (strömning) med data i vila (data som sitter i en databas eller datasjö).
Under det kommande året förväntar vi oss att se streaming och driftsystem komma närmare varandra. Fördelen skulle vara att förbättra operativt beslutsstöd genom att bädda in lite lättviktsanalys eller prediktiv förmåga. Det skulle finnas tydliga fördelar för användningsfall så olika som Customer 360 och Supply Chain Optimization; Underhåll, reparation och översyn (MRO); handel med kapitalmarknader; och smart nätbalansering. Det skulle också kunna tillhandahålla feedbackslingor i realtid för ML-modeller. I en värld där företagen digitaliseras förändras det från lyx till nödvändighet att ha den där förutsägande loopen för att stödja datadrivna operativa beslut.
Idén att föra samman streaming och data i vila är knappast ny; det stavades för flera år sedan som Kappa-arkitekturen, och det har förekommit isolerade implementeringar på big data-plattformar — den tidigare MapR:s “konvergerade plattform” (nu HPE Ezmeral Unified Analytics) kommer att tänka på.
Strömmande arbetsbelastningar körs traditionellt på deras egna dedikerade plattformar på grund av deras extrema resurskrav. Programstoppet att hålla streaming på sin egen ö av infrastruktur är resursstrid.
Strömmande applikationer – som att analysera realtidsflöden från kapitalmarknaden, upptäcka anomalier i dataflödet från fysiska maskiner, felsöka driften av nätverk eller övervaka kliniska data – har vanligtvis fungerat fristående. Och på grund av behovet av att upprätthålla ett lätt fotavtryck tenderar analyser och frågor att vara enklare än vad du skulle kunna köra i ett datalager eller en datasjö. Närmare bestämt involverar streaminganalys ofta filtrering, analys och, i allt högre grad, prediktiv trending.
När det sker en handoff till datalager eller datasjöar är data i de flesta fall begränsad till resultatuppsättningar. Du kan till exempel köra en SQL-fråga på Amazon Kinesis Data Analytics som identifierar extremvärden, bevara resultaten till Redshift och sedan utföra en fråga på den kombinerade datan för mer komplex analys. Men det är en operation i flera steg som involverar två tjänster, och den är inte strikt i realtid.
Vissligen, i minnesoperativa databaser som Redis, kan du stödja den nästan omedelbara beständigheten av strömmande data med enbart loggfiler dataformat, men det är inte samma sak som att lägga till en prediktiv återkopplingsslinga till operativa applikationer.
Under de senaste åren har vi sett några antydningar om att streaming är på väg att bli en del av operativa och analytiska datamoln. Confluent slog upp dörrarna när det släppte ksqldb på Confluent Cloud redan 2020. Förra året introducerade DataStax beta för Astra Streaming, med stöd av Apache Pulsar (inte Kafka); det är för närvarande en separat tjänst, men vi förväntar oss att den kommer att blandas in med Astra DB med tiden. I Spark-universumet kan Delta Lake fungera som en streamingkälla eller sänka för Spark Structured Streaming.
Spelväxlaren är molnbaserad arkitektur. Molnets elasticitet eliminerar problem med resursstridigheter, medan mikrotjänster ger mer motståndskraftiga alternativ till klassiska designmönster som involverar en central orkestrator eller statsmaskin. I sin tur gör Kubernetes (K8s) det möjligt för analytiska plattformar att stödja elasticitet utan att behöva uppfinna hjulet för att orkestrera beräkningsresurser på nytt. Konvergerade strömmande och operationella eller analytiska system kan köras på distribuerade kluster, som kan partitioneras och orkestreras för att utföra strömanalys i realtid, slå samman resultat och korrelera med komplexa operativa modeller.
Sådan konvergens kommer inte att ersätta dedikerade streamingtjänster, men det finns tydliga möjligheter för etablerade molnföretag: Amazon Kinesis Data Analytics parat med Redshift eller DynamoDB; Azure Stream Analytics med Cosmos DB eller Synapse Analytics; Google Cloud Dataflow med BigQuery eller Firestore kommer alla att tänka på.
Men det finns också möjligheter för datalagringar i realtid i minnet. Vi pratar med dig, Redis, för att inte tala om någon av dussintals tidsseriedatabaser som finns.
Också: Vad datahanteringsledare förutspår för sektorn 2022
Datadelning och -delning på samma sätt
Så här i efterhand ser det här ut som en no-brainer. Med molnlagring som de facto datasjön, bör främjande av bredare tillgång till data vara en win-win för alla: dataleverantörer får ut mer körsträcka (och potentiellt intäktsgenerering) av sina data; datakunder får tillgång till mer varierande datamängder; molnplattformsleverantörer kan sälja mer användning (lagring och beräkning); och molndatalager kan förvandla sig själva till datadestinationer.
Ur det perspektivet är det förvånande att det har tagit var och en av de stora molnleverantörerna nästan fem år att få tag i en idé som Snowflake kläcktes.
Snowflake och AWS har varit de mest aktiva i att främja datautbyte, även om båda närmade sig det från motsatta håll. Snowflake började med en datadelningsfunktion riktad över interna avdelningar och öppnade senare ett datautbyte för tredje part. AWS gick i omvänd ordning och öppnade ett datautbyte på AWS Marketplace för ett par år sedan, men det har bara lagt till möjligheter för intern delning av data för Redshift-kunder (vilket krävde att AWS utvecklade RA3-instansen som slutligen separerade Redshift-data i sin egen pool ) för det senaste året.
Snowflake har tagit det extra steget att öppna vertikala industrisektioner av sin marknadsplats, vilket gör det lättare för kunder att ansluta till rätt datamängder. Å andra sidan slog AWS Snowflake hårt för att kommersialisera sin datamarknad genom att använda den befintliga AWS Marketplace-mekanismen.
Google följde efter med Analytics Hub för att dela BigQuery-datauppsättningar, en möjlighet som de senare kommer att utöka till andra tillgångar som Looker Blocks och Connected Sheets. Microsoft Azure har också gett sig i kast.
Under nästa år förväntar vi oss att var och en av molnleverantörerna utvecklar sina interna och externa datautbyten och marknadsplatser, särskilt när det kommer till kommersialisering.
Databasplattformar vänder sig till ML för att driva sig själva< /strong>
Detta är baksidan av ML i databasen, som vi förutspådde skulle bli en kryssruta 2021 för molndatalager och datasjöar. Vad vi pratar om här är användningen av ML under täcket för att hjälpa till att köra eller optimera en databas.
Oracle avlossade det första skottet med den autonoma databasen; Oracle gick fullt ut med ML genom att designa en databas som bokstavligen kör sig själv. Det är bara möjligt med den bredd av databasautomatisering som till stor del är unik för Oracle-databasen. Men för Oracles rivaler har vi en mer blygsam syn: att tillämpa ML för att hjälpa, inte ersätta, DBA med att optimera specifika databasoperationer.
Som varje erfaren DBA kommer att vittna om, innebär att köra en databas massor av figurativa “rattar”. Exempel inkluderar fysisk dataplacering och lagringsnivå, sekvensen av kopplingar i en komplex fråga och identifiering av rätt index. I molnet kan det också omfatta att identifiera de mest optimala hårdvaruinstanserna. Vanligtvis sätts konfigurationer av formella regler eller baserat på DBA:s informella kunskap.
Att optimera en databas är väl lämpat för ML. Processerna är datarika, eftersom databaser genererar enorma mängder loggdata. Problemet är också väl begränsat, eftersom funktionerna är väldefinierade. Och det finns en betydande potential för kostnadsbesparingar, särskilt när det gäller att ta hänsyn till hur man bäst lägger upp data eller utformar en fråga. Cloud DBaaS-leverantörer är väl lämpade att använda ML för att optimera driften av sina databastjänster, eftersom de kontrollerar infrastrukturen och har rika pooler av anonymiserad driftdata som de kan bygga och ständigt förbättra modeller på.
Vi har dock blivit förvånade över att det har varit få som tagit del av Oracles utmaning. Nästan den enda formellt produktiserade användningen av ML (bortsett från Oracle) är med Azure SQL Database och SQL Managed Instance; Microsoft erbjuder automatisk justering av index och frågor. Det är ett klassiskt problem med avvägningar: den snabbare hämtningshastigheten med ett index kontra kostnaden och omkostnaden för skrivningar när du har för många index. Azures automatiska inställning kan automatiskt skapa index när den känner av hotspots för frågor; sänker index som inte används efter 90 dagar; och återställer tidigare versioner av frågeplaner om nyare visar sig vara långsammare.
Under det kommande året förväntar vi oss att se fler molntjänster för DBaaS introducera alternativ som inkluderar ML för att optimera databasen, vilket gör att företag uppmärksammar hur de kan spara pengar .
Upplysning: AWS, DataStax, Google Cloud, HPE, IBM och Oracle är dbInsight-klienter.
Utvalda
Varför jag bytte ut min iPhone 12 med Pixel 6 Covid-testningen: De bästa snabbtestsatserna hemma American Airlines har ett speciellt sätt att hantera arga kunder Plattformar med låg kod och ingen kod går bortom scenen med blanka verktyg Amazon | Digital transformation | Robotik | Internet of Things | Innovation | Företagsprogramvara