Automatiser prognosene dine for tidsserier i Snowflake ved å bruke Amazon Forecast

Dette innlegget er et felles samarbeid med Andries Engelbrecht og James Sun fra Snowflake, Inc.

Cloud computing-revolusjonen har gjort det mulig for bedrifter å fange opp og beholde bedrifts- og organisasjonsdata uten kapasitetsplanlegging eller begrensninger for datalagring. Nå, med mangfoldige og store reserver av longitudinelle data, er bedrifter i økende grad i stand til å finne nye og virkningsfulle måter å bruke sine digitale eiendeler til å ta bedre og informerte beslutninger når de tar kortsiktige og langsiktige planleggingsbeslutninger. Tidsserieprognoser er en unik og essensiell vitenskap som lar bedrifter ta kirurgiske planleggingsbeslutninger for å balansere kundeservicenivåer mot ofte konkurrerende mål om optimal lønnsomhet.

Hos AWS jobber vi noen ganger med kunder som har valgt vår teknologipartner Snowflake å levere en skydataplattformopplevelse. Å ha en plattform som kan huske år og år med historiske data er kraftig – men hvordan kan du bruke disse dataene til å se fremover og bruke gårsdagens bevis til å planlegge morgendagen? Tenk deg ikke bare å ha det som har skjedd tilgjengelig i Snowflake – din enkeltversjon av sannheten – men også et tilstøtende sett med ikke-silobaserte data som tilbyr en sannsynlig prognose for dager, uker eller måneder inn i fremtiden.

I en samarbeidende forsyningskjede kan deling av informasjon mellom partnere forbedre ytelsen, øke konkurranseevnen og redusere bortkastede ressurser. Deling av fremtidige prognoser kan forenkles med Snowflake Datadeling, som lar deg sømløst samarbeide med forretningspartnerne dine på en sikker måte og identifisere forretningsinnsikt. Hvis mange partnere deler sine prognoser, kan det bidra til å kontrollere bullwhip-effekten i den tilkoblede forsyningskjeden. Du kan effektivt bruke Snowflake Marketplace for å tjene penger på prediktiv analyse fra datasett produsert i Amazon Prognose.

I dette innlegget diskuterer vi hvordan du implementerer en automatisert løsning for tidsserieprognoser ved å bruke Snowflake og Forecast.

Essensielle AWS-tjenester som muliggjør denne løsningen

Forecast gir flere toppmoderne tidsseriealgoritmer og administrerer allokeringen av nok distribuert datakapasitet til å møte behovene til nesten enhver arbeidsbelastning. Med Forecast får du ikke én modell; du får styrken til mange modeller som er videre optimalisert til en unikt vektet modell for hver tidsserie i settet. Kort sagt, tjenesten leverer all vitenskap, datahåndtering og ressursadministrasjon i et enkelt API-kall.

AWS trinnfunksjoner gir en prosessorkestreringsmekanisme som styrer den generelle arbeidsflyten. Tjenesten innkapsler API-anrop med Amazonas Athena, AWS Lambda, og Forecast for å lage en automatisert løsning som høster data fra Snowflake, bruker Forecast til å konvertere historiske data til fremtidige spådommer, og deretter oppretter dataene inne i Snowflake.

Athena-fødererte spørringer kan kobles til flere bedriftsdatakilder, inkludert Amazon DynamoDB, Amazon RedShift, Amazon OpenSearch-tjeneste, MySQL, PostgreSQL, Redis og andre populære tredjeparts databutikker, for eksempel Snowflake. Datakoblinger kjører som Lambda-funksjoner – du kan bruke denne kildekoden for å hjelpe til med å starte Amazon Athena Lambda Snowflake Connector og koble med AWS PrivateLink eller gjennom en NAT-gateway.

Løsningsoversikt

En av tingene vi ofte gjør hos AWS er ​​å jobbe med å hjelpe kundene med å realisere målene sine, samtidig som de fjerner byrden av de udifferensierte tunge løftene. Med dette i bakhodet foreslår vi følgende løsning for å hjelpe AWS- og Snowflake-kunder med å utføre følgende trinn:

1. Eksporter data fra Snowflake. Du kan bruke fleksible metadata til å laste ned de nødvendige historiske dataene drevet av en klar arbeidsflyt.
2. Importer data til Forecast. Uansett brukstilfelle, bransje eller skala, er import av forberedte datainndata enkelt og automatisert.
3. Tren en toppmoderne tidsseriemodell. Du kan automatisere tidsserieprognoser uten å administrere den underliggende datavitenskapen eller maskinvareklargjøringen.
4. Generer slutninger mot den trente modellen. Prognoseproduserte utdata er enkle å konsumere til ethvert formål. De er tilgjengelige som enkle CSV- eller Parkett-filer Amazon enkel lagringstjeneste (Amazon S3).
5. Bruk historie og fremtidsspådommer side om side direkte i Snowflake.

Følgende diagram illustrerer hvordan du implementerer en automatisert arbeidsflyt som gjør at Snowflake-kunder kan dra nytte av svært nøyaktige tidsserieprediksjoner støttet av Forecast, en AWS-administrert tjeneste. Designet som tilbys her, overskrider brukstilfeller og industri, trekker først ut historiske data fra Snowflake. Deretter sender arbeidsflyten de forberedte dataene for tidsserieberegning. Til slutt er prognoser for fremtidige perioder tilgjengelige i Snowflake, og skaper en sømløs brukeropplevelse for felles AWS- og Snowflake-kunder.

Selv om denne arkitekturen bare fremhever de viktigste tekniske detaljene, er løsningen enkel å sette sammen, noen ganger innen 1–2 virkedager. Vi gir deg fungerende eksempelkode for å fjerne de udifferensierte tunge løftene ved å lage løsningen alene og uten forsprang. Etter at du har oppdaget hvordan du implementerer dette mønsteret for én arbeidsbelastning, kan du gjenta prognoseprosessen for alle data som lagres i Snowflake. I avsnittene som følger skisserer vi de viktigste trinnene som gjør deg i stand til å bygge en automatisert pipeline.

Trekk ut historiske data fra Snowflake

I dette første trinnet bruker du SQL til å definere hvilke data du vil ha prognosert og la en Athena Federated Query koble seg til Snowflake, kjøre din tilpassede SQL og opprettholde den resulterende rekorden satt på Amazon S3. Prognose krever at historiske treningsdata er tilgjengelige på Amazon S3 før inntak; derfor fungerer Amazon S3 som en mellomlagringsbuffer mellom Snowflake og Forecast. Vi har Athena i dette designet for å aktivere Snowflake og andre heterogene datakilder. Hvis du foretrekker det, er en annen tilnærming å bruke Snowflake COPY-kommandoen og lagringsintegrasjon for å skrive spørringsresultater til Amazon S3.

Uavhengig av transportmekanismen som brukes, skisserer vi nå hva slags data prognosen trenger og hvordan data defineres, utarbeides og trekkes ut. I avsnittet som følger beskriver vi hvordan du importerer data til Forecast.

Følgende skjermbilde viser hvordan et sett med data kan se ut i det opprinnelige Snowflake-skjemaet.

Selv om dette skjermbildet viser hvordan dataene ser ut i sin naturlige tilstand, krever Forecast at data formes til tre forskjellige datasett:

• Måltidsserie – Dette er et nødvendig datasett som inneholder målvariabelen og brukes til å trene og forutsi en fremtidig verdi. Alene fungerer dette datasettet som en univariat tidsseriemodell.
• Relaterte tidsserier – Dette er et valgfritt datasett som inneholder tidsvariabler som skal ha en relasjon til målvariabelen. Eksempler inkluderer variabel prissetting, markedsføringstiltak, hyperlokal begivenhetstrafikk, økonomiske utsiktsdata – alt du føler kan bidra til å forklare variasjonen i måltidsserien og gi en bedre prognose. Det relaterte tidsseriedatasettet gjør din univariate modell til en multivariat for å bidra til å forbedre nøyaktigheten.
• Elementmetadata – Dette er et valgfritt datasett som inneholder kategoriske data om det prognostiserte elementet. Varemetadata bidrar ofte til å øke ytelsen for nylig lanserte produkter, som vi kaller en kald start.

Med omfanget av hvert av prognosedatasettene definert, kan du skrive spørringer i Snowflake som henter de riktige datafeltene fra de nødvendige kildetabellene med de riktige filtrene for å få ønsket delsett av data. Følgende er tre eksempler på SQL-spørringer som brukes til å generere hvert datasett som Forecast trenger for et spesifikt matbehovsplanleggingsscenario.

Vi starter med måltidsseriespørringen:

select LOCATION_ID, ITEM_ID, 
DATE_DEMAND as TIMESTAMP, QTY_DEMAND as TARGET_VALUE 
from DEMO.FOOD_DEMAND

Den valgfrie relaterte tidsseriespørringen trekker kovariater som pris og kampanjetilbud:

select LOCATION_ID,ITEM_ID, DATE_DEMAND as TIMESTAMP,
CHECKOUT_PRICE, BASE_PRICE,
EMAILER_FOR_PROMOTION, HOMEPAGE_FEATURED
from DEMO.FOOD_DEMAND

Varemetadataspørringen henter distinkte kategoriske verdier som hjelper til med å gi dimensjoner og ytterligere definere prognoseelementet:

select DISTINCT ITEM_ID, FOOD_CATEGORY, FOOD_CUISINE
from DEMO.FOOD_DEMAND

Med kildespørringene definert, kan vi koble til Snowflake gjennom en Athena Federated Query for å sende inn spørringene og fortsette de resulterende datasettene for prognosebruk. For mer informasjon, se Spør snøfnugg med Athena Federated Query og bli med data i Amazon S3 -datasjøen din.

De Athena Snowflake Connector GitHub repo hjelper med å installere Snowflake-kontakten. De Prognose MLOps GitHub repo hjelper til med å orkestrere alle makrotrinn som er definert i dette innlegget, og gjør dem repeterbare uten å skrive kode.

Importer data til Forecast

Etter at vi har fullført forrige trinn, er et måltidsseriedatasett i Amazon S3 og klart for import til Forecast. I tillegg kan de valgfrie relaterte tidsserie- og elementmetadata-datasettene også være forberedt og klare for inntak. Med det gitte Prognose MLOps-løsning, alt du trenger å gjøre her er å starte Step Functions-tilstandsmaskinen som er ansvarlig for å importere data – ingen kode er nødvendig. Forecast lanserer en klynge for hvert av datasettene du har oppgitt, og gjør dataene klare for tjenesten til bruk for ML-modellbygging og modellslutning.

Lag en tidsserie ML-modell med nøyaktighetsstatistikk

Etter at data er importert, lages svært nøyaktige tidsseriemodeller ganske enkelt ved å kalle et API. Dette trinnet er innkapslet inne i en Step Functions-tilstandsmaskin som starter Forecast API for å starte modelltrening. Etter at prediktormodellen er trent, eksporterer statsmaskinen modellstatistikken og spådommene under tilbaketestvinduet til Amazon S3. Backtest-eksporter kan søkes etter av Snowflake som en ekstern fase, som vist i følgende skjermbilde. Hvis du foretrekker det, kan du lagre dataene i en intern fase. Poenget er å bruke backtest-beregningene for å evaluere ytelsesspredningen til tidsserier i datasettet ditt.

Lag fremtidige spådommer

Med modellen trent fra forrige trinn, kaller en spesialbygd Step Functions-tilstandsmaskin Forecast API for å lage fremtidsdaterte prognoser. Prognose sørger for en klynge for å utføre slutningen og trekker de importerte måltidsseriene, relaterte tidsseriene og elementmetadatasettet gjennom en navngitt prediktormodell opprettet i forrige trinn. Etter at spådommene er generert, skriver tilstandsmaskinen dem til Amazon S3, hvor de igjen kan søkes på plass som en Snowflake ekstern scene eller flyttes inn i Snowflake som en intern scene.

Bruk fremtidsdaterte prediksjonsdata direkte i Snowflake

AWS har ikke bygget en helautomatisert løsning for dette trinnet; men med løsningen i dette innlegget ble data allerede produsert av Forecast i de to foregående trinnene. Du kan behandle utdataene som handlingsrettede hendelser eller bygge business intelligence-dashboards på dataene. Du kan også bruke dataene til å lage fremtidige produksjonsplaner og innkjøpsordrer, estimere fremtidige inntekter, bygge bemanningsressursplaner og mer. Hvert brukstilfelle er forskjellig, men poenget med dette trinnet er å levere spådommene til de riktige forbrukssystemene i organisasjonen din eller utover.

Følgende kodebit viser hvordan du forespør Amazon S3-data direkte fra Snowflake:

CREATE or REPLACE FILE FORMAT mycsvformat
type = 'CSV'
field_delimiter = ','
empty_field_as_null = TRUE
ESCAPE_UNENCLOSED_FIELD = None
skip_header = 1;

CREATE or REPLACE STORAGE INTEGRATION amazon_forecast_integration
TYPE = EXTERNAL_STAGE
STORAGE_PROVIDER = S3
STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::nnnnnnnnnn:role/snowflake-forecast-poc-role'
ENABLED = true
STORAGE_ALLOWED_LOCATIONS = (
's3://bucket/folder/forecast',
's3://bucket/folder/backtest-export/accuracy-metrics-values',
's3://bucket/folder/backtest-export/forecasted-values';

CREATE or REPLACE STAGE backtest_accuracy_metrics
storage_integration = amazon_forecast_integration
url = 's3://bucket/folder/backtest-export/accuracy-metrics-values'
file_format = mycsvformat;

CREATE or REPLACE EXTERNAL TABLE FOOD_DEMAND_BACKTEST_ACCURACY_METRICS (
ITEM_ID varchar AS (value:c1::varchar),
LOCATION_ID varchar AS (value:c2::varchar),
backtest_window varchar AS (value:c3::varchar),
backtestwindow_start_time varchar AS (value:c4::varchar),
backtestwindow_end_time varchar AS (value:c5::varchar),
wQL_10 varchar AS (value:c6::varchar),
wQL_30 varchar AS (value:c7::varchar),
wQL_50 varchar AS (value:c8::varchar),
wQL_70 varchar AS (value:c9::varchar),
wQL_90 varchar AS (value:c10::varchar),
AVG_wQL varchar AS (value:c11::varchar),
RMSE varchar AS (value:c12::varchar),
WAPE varchar AS (value:c13::varchar),
MAPE varchar AS (value:c14::varchar),
MASE varchar AS (value:c15::varchar)
)
with location = @backtest_accuracy_metrics
FILE_FORMAT = (TYPE = CSV FIELD_DELIMITER = ',' SKIP_HEADER = 1);

For mer informasjon om å sette opp tillatelser, se Alternativ 1: Konfigurere en Snowflake Storage Integration for å få tilgang til Amazon S3. I tillegg kan du bruke AWS servicekatalog å konfigurere Amazon S3-lagringsintegrasjon; mer informasjon er tilgjengelig på GitHub repo.

Start en tidsplanbasert eller hendelsesbasert arbeidsflyt

Etter at du har installert en løsning for din spesifikke arbeidsmengde, er det siste trinnet å automatisere prosessen etter en tidsplan som gir mening for dine unike krav, for eksempel daglig eller ukentlig. Det viktigste er å bestemme hvordan du skal starte prosessen. En metode er å bruke Snowflake til å starte Step Functions-tilstandsmaskinen og deretter orkestrere trinnene i serie. En annen tilnærming er å lenke statsmaskiner sammen og starte den totale kjøringen gjennom en Amazon EventBridge regel, som du kan konfigurere til å kjøre fra en hendelse eller planlagt oppgave – for eksempel klokken 9:00 GMT-8 hver søndag kveld.

konklusjonen

Med mest erfaring; den mest pålitelige, skalerbare og sikre skyen; og det mest omfattende settet med tjenester og løsninger, AWS er ​​det beste stedet å låse opp verdi fra dataene dine og gjøre dem om til innsikt. I dette innlegget viste vi deg hvordan du lager en automatisert arbeidsflyt for tidsserieprognoser. Bedre prognoser kan føre til høyere kundeserviceresultater, mindre avfall, mindre ledig beholdning og mer kontanter på balansen.

Hvis du er klar til å automatisere og forbedre prognoser, er vi her for å hjelpe deg på reisen. Kontakt AWS- eller Snowflake-kontoteamet ditt for å komme i gang i dag og be om et prognoseverksted for å se hva slags verdi du kan låse opp fra dataene dine.

Om forfatterne

Bosco Albuquerque er Sr. Partner Solutions Architect hos AWS og har over 20 års erfaring med å jobbe med database- og analyseprodukter fra bedriftsdatabaseleverandører og skyleverandører. Han har hjulpet teknologiselskaper med å designe og implementere dataanalyseløsninger og -produkter.

Frank Dalezotte er Sr. Solutions Architect hos AWS og brenner for å jobbe med uavhengige programvareleverandører for å designe og bygge skalerbare applikasjoner på AWS. Han har erfaring med å lage programvare, implementere byggepipelines og distribuere disse løsningene i skyen.

Andries Engelbrecht er Principal Partner Solutions Architect hos Snowflake og jobber med strategiske partnere. Han er aktivt engasjert med strategiske partnere som AWS som støtter produkt- og tjenesteintegrasjoner samt utvikling av felles løsninger med partnere. Andries har over 20 års erfaring innen data og analyse.

Charles Laughlin er en hovedarkitekt for AI/ML spesialistløsninger og jobber på Time Series ML-teamet hos AWS. Han hjelper til med å forme Amazon Forecast-tjenestens veikart og samarbeider daglig med ulike AWS-kunder for å hjelpe til med å transformere virksomhetene deres ved å bruke banebrytende AWS-teknologier og tankelederskap. Charles har en MS i Supply Chain Management og har tilbrakt det siste tiåret i industrien for forbrukerpakkede varer.

James Sun er Senior Partner Solutions Architect hos Snowflake. James har over 20 års erfaring innen lagring og dataanalyse. Før Snowflake hadde han flere ledende tekniske stillinger hos AWS og MapR. James har en doktorgrad fra Stanford University.