Anbefalte fremgangsmåter for å få best mulig ytelse med Dataflyt gen2

Denne artikkelen inneholder anbefalte fremgangsmåter for optimalisering av ytelsen til Dataflyt gen2 i Fabric Data Factory. Ved å følge disse retningslinjene kan du forbedre effektiviteten og hastigheten til dataintegreringsprosessene.

Hva du vil lære

I denne artikkelen vil du oppdage:

• Viktige ytelsesoptimaliseringsområder: Forstå de tre kritiske komponentene (datakilde, dataflytmotor og datamål) som påvirker dataflytytelsen
• Kjerneoptimaliseringsteknikker: Slik drar du nytte av Fast Copy, spørringsdelegering og oppsamling for å maksimere effektiviteten
• Scenarier fra den virkelige verden: Vanlige ytelsesutfordringer og deres spesifikke løsninger
• Anbefalte fremgangsmåter: Praktisk veiledning for ulike dataintegreringsmønstre og brukstilfeller

Hva er de viktigste områdene å fokusere på for ytelsesoptimalisering?

Det finnes flere viktige områder å fokusere på for ytelsesoptimalisering innenfor dataflyten fra ende til slutt. Disse områdene inkluderer dataflyten, dataflytmotoren og datatransformasjonene. Hver av disse komponentene og banene mellom spiller en viktig rolle i den generelle ytelsen til dataflyten, og optimalisering av dem kan føre til betydelige forbedringer i utførelsestid og ressursutnyttelse.

Dataflytting

Databevegelse er et kritisk aspekt ved dataflytytelse. Det innebærer overføring av data mellom ulike komponenter, for eksempel datakilder, oppsamlingsområder og endelige mål. Effektiv databevegelse kan redusere kjøringstiden og ressursforbruket betydelig. I Dataflyt gen2 optimaliseres databevegelser gjennom teknikker som Fast Copy, som gjør det mulig å overføre data med høy gjennomstrømming uten overhead av transformasjoner som ikke brettes til kildesystemet. Finn ut mer om rask kopiering.

Datatransformering

Datatransformasjon er prosessen med å konvertere data fra én struktur til en annen, som ofte involverer operasjoner som filtrering, aggregering og sammenføyning. I Dataflyt gen2 er transformasjoner utformet for å være effektive og bruke spørringsdelegeringsfunksjoner når det er mulig. Spørringsdelegering gjør det mulig å sende transformasjoner ned til kildesystemet, noe som reduserer mengden data som overføres og behandles i Dataflyt gen2. Denne reduksjonen er spesielt viktig for store datasett, da det minimerer arbeidsbelastningen på dataflytmotoren og øker kjøringstiden. Hvis du vil lære mer om spørringsdelegering, kan du gå til Spørringsdelegering. Følg også andre anbefalte fremgangsmåter for spørringsoptimalisering, for eksempel filtrering tidlig og ofte, bruk av parameterisering for å begrense forhåndsvisning av data og unngå unødvendige transformasjoner i dataflyten. Hvis du vil lære mer om spørringsoptimalisering, kan du gå til Spørringsoptimalisering.

Sette opp data- og lagerdatabehandling

Oppsamlingsdata er en teknikk som brukes til å forbedre ytelsen ved å lagre mellomliggende resultater midlertidig i et oppsamlingsområde. Dataflyt gen2 kommer med en staging Lakehouse og en staging Warehouse, som kan brukes til å utføre transformasjoner mer effektivt. Ved å sette opp data kan du bruke databehandlingsressursene i disse oppsamlingsområdene til å dele opp komplekse dataflyter i håndterbare trinn, noe som reduserer den totale behandlingstiden. Denne oppdelingen er spesielt nyttig for store datasett eller komplekse transformasjoner som ellers ville tatt lang tid å utføre i ett enkelt steg. Du kan vurdere å sette opp plasseringer som et midlertidig lagringsområde som lar deg brette transformasjoner. Denne fremgangsmåten er spesielt nyttig når du arbeider med datakilder som ikke støtter spørringsdelegering eller når transformasjoner er for komplekse til å bli sendt ned til kildesystemet. Hvis du vil bruke oppsamling effektivt, kan du holde et øye med de sammenleggbare indikatorene i redigeringsprogrammet for dataflyten for å sikre at transformasjonene blir sendt ned til kilden. Hvis du legger merke til at en transformasjon ikke brettes, bør du vurdere å dele spørringen i to spørringer og bruke transformasjonen i den andre spørringen. Aktiver oppsamling på den første spørringen for å utføre transformasjonen i oppsamlings-Lakehouse- eller Warehouse-databehandlingen. Med denne fremgangsmåten kan du dra nytte av databehandlingsressursene som er tilgjengelige i oppsamlingsområdene, samtidig som du sikrer at dataflyten forblir effektiv og responsiv.

Når du har data som allerede er klarlagt i Lakehouse eller Warehouse, og du bruker flere transformasjoner som brettes fullstendig inn i følgende spørringer, vil dataflyten skrive utdataene til oppsamlingslageret. Dette kan være raskere enn å skrive til iscenesettelses-Lakehouse fordi datasettet kan skrives parallelt av DW og vil gjennomgå færre nettverkshopp med de tilsvarende serialiseringstrinnene.

Scenarioer og hvilke optimaliseringer du bør vurdere

Når du arbeider med Dataflyt gen2, er det viktig å forstå de ulike scenariene du kan støte på, og hvordan du optimaliserer ytelsen i hvert tilfelle. Følgende vurderinger gir praktisk veiledning om hvordan du bruker de beste fremgangsmåtene i virkelige situasjoner. Ved å skreddersy tilnærmingen din basert på de spesifikke egenskapene til dataene og transformasjonene, kan du oppnå optimal ytelse i arbeidsflytene for dataintegrering. Her er noen vanlige scenarioer du kan støte på når du arbeider med Dataflyt gen2, sammen med anbefalte handlinger for å optimalisere ytelsen. Vær oppmerksom på at ytelsesoptimalisering er en pågående prosess og svært spesifikk for scenarioet ditt. Du må kanskje justere tilnærmingen din basert på de spesifikke egenskapene til dine egne data og transformasjoner.

Vurdering 1: Forbedre dataflytting med Fast Copy

I dette scenarioet ser du at dataflytting mellom datakilden og oppsamlingsområdet eller til det endelige målet tar lengre tid enn forventet. Flere faktorer kan være involvert, for eksempel nettverksventetid, store datasettstørrelser eller ineffektive dataoverføringsmetoder.

I dette tilfellet bør du vurdere å evaluere dataflyttingsbanen og optimalisere den for bedre ytelse. Én fremgangsmåte er å bruke Fast Copy for dataoverføring med høy gjennomstrømming, noe som kan redusere kjøretiden betydelig. Fast Copy er utformet for å håndtere store mengder data effektivt, noe som minimerer kostnadene som er knyttet til tradisjonelle dataoverføringsmetoder. Vær imidlertid forsiktig: Hvis du legger til transformasjoner i samme spørring som en Hurtigkopi-operasjon, kan den deaktivere Fast Copy hvis transformasjonene ikke brettes til kildesystemet. I slike tilfeller bør du vurdere å skille spørringen i to trinn: én for Fast Copy-operasjonen og en annen for transformasjonene ved hjelp av databehandlingen Lakehouse eller Warehouse. Med denne fremgangsmåten kan du dra nytte av Fast Copy for databevegelse med høy gjennomstrømming mens du utfører de nødvendige transformasjonene i et eget trinn. Finn ut mer om rask kopiering.

Du kan aktivere Fast Copy i dataflytinnstillingene. Denne innstillingen er aktivert som standard, men du kan også kreve at hurtigkopi brukes for en bestemt spørring i dataflyten. Dette gjør du ved å velge alternativet Krev rask kopi i spørringsinnstillingene. Denne handlingen sikrer at Rask kopiering brukes for den valgte spørringen, og at den ignorerer terskelen for minste størrelse for Rask kopiering. Denne innstillingen er spesielt nyttig når du vil sikre at Hurtigkopiering brukes til bestemte spørringer, uavhengig av datastørrelsen eller andre betingelser. Hvis du trenger hurtigkopiering, må du kontrollere at datakilden er kompatibel med hurtigkopi, og at transformasjonene i spørringen kan sendes ned til kildesystemet. Hvis du trenger rask kopi på en spørring som ikke er kompatibel med hurtigkopiering, vil dataflyten mislykkes. Hvis du ikke trenger hurtigkopiering, kjører dataflyten fortsatt, men den kan falle tilbake til standard dataflyttingsmetode, som kanskje ikke er like effektiv som hurtigkopiering. Denne fleksibiliteten lar deg optimalisere dataflyten basert på de spesifikke kravene til dataintegreringsprosessene dine.

Vurdering 2: Forbedre utførelsestiden for komplekse transformasjoner ved hjelp av oppsamling

I dette scenarioet har du en dataflyt med flere komplekse transformasjoner, for eksempel sammenføyninger, aggregasjoner og filtrering. Kjøringstiden er lengre enn ønsket, og du vil optimalisere ytelsen til disse transformasjonene.

I dette tilfellet bør du vurdere å dele opp dataflyten i mindre, mer håndterbare trinn. I stedet for å utføre alle transformasjoner i én enkelt spørring, kan du sette opp dataene i et oppsamlingssted i Lakehouse eller Warehouse og deretter bruke transformasjonene i etterfølgende spørringer. Med denne fremgangsmåten kan du bruke databehandlingsressursene i oppsamlingsområdet for komplekse transformasjoner, noe som reduserer den totale kjøringstiden. I tillegg må du sørge for at transformasjonene er utformet for å brettes til kildesystemet når det er mulig, da dette kan forbedre ytelsen betydelig ved å redusere mengden data som overføres og behandles i Dataflyt Gen2. Hvis du legger merke til at enkelte transformasjoner ikke brettes, bør du vurdere å dele dem opp i separate spørringer og bruke dem etter at du har satt opp dataene.

Legg merke til hvordan delegeringsindikatorene i redigeringsprogrammet for dataflyt i bildet nedenfor kan hjelpe deg med å identifisere hvilke transformasjoner som sendes ned til kildesystemet.

Hvis du vil implementere oppsamling effektivt, kan du dele dataflyten i to spørringer. Du gjør dette ved å høyreklikke på det første trinnet som ikke brettes til kildesystemet og velge alternativet Trekk ut forrige . Denne handlingen oppretter en ny spørring som faser dataene i oppsamlings-Lakehouse- eller Warehouse-databehandlingen, slik at du kan utføre transformasjonen i et eget trinn. Denne fremgangsmåten hjelper deg med å dra nytte av databehandlingsressursene som er tilgjengelige i oppsamlingsområdene, samtidig som du sikrer at dataflyten forblir effektiv og responsiv.

Angi deretter et navn for den nye spørringen, og velg OK.

Nå som den nye spørringen er opprettet, kan du kontrollere om oppsamling er aktivert for den første spørringen. Hvis oppsamling ikke er aktivert, kan du aktivere den ved å velge alternativet Aktiver oppsamling i spørringsinnstillingene. Med denne handlingen kan du utføre transformasjoner i databehandlingen lakehouse eller warehouse, som optimaliserer ytelsen til dataflyten. Det er valgfritt å sette opp den andre spørringen, men den kan forbedre ytelsen ytterligere ved å la deg utføre flere transformasjoner i oppsamlingsområdet før du skriver den endelige utdataene til målet.

Hvis du nå ser på delegeringsindikatorene i redigeringsprogrammet for dataflyt, sendes transformasjonene i den første spørringen ned til kildesystemet. Den andre spørringen gjenspeiler kanskje ikke de samme foldingsindikatorene, da den bare er under kjøretid klar over oppsamlingsområdet og transformasjonene som kan skyves ned til oppsamlingsområdet.

Hvis du vil lære mer om hvordan du optimaliserer dataflyttransformasjonene og sikrer at de sendes ned til kildesystemet, kan du gå til Spørringsdelegering.

Vurdering 3: Optimaliser staging-til-Lakehouse-databevegelse for en Lakehouse-destinasjon

I dette tilfellet bruker du en Lakehouse-destinasjon for dataflyten din, og aktiverer staging for å kjøre transformasjoner før du skriver den endelige utdataen. Sørg for at steget som flytter trinnvise data til Lakehouse ikke legger til unødvendig overhead på den totale oppdateringstiden.

Et innsjøhus er et fullt støttet, høyytelses mål for dette mønsteret. Dataoverføringen fra staging-lageret til Lakehouse-destinasjonen er optimalisert, slik at du ikke lenger trenger å bytte destinasjon til et lager for å oppnå god ytelse. Den anbefalte tilnærmingen er ELT-mønsteret: bruk Fast Copy for å lande dataene raskt, kjør transformasjonene dine på de trinnvise dataene ved å bruke Fabric-staging-beregningen, og skriv den endelige utdataen til Lakehouse. For store datasett er Fast Copy fortsatt den anbefalte måten å flytte dataene effektivt på.

For å få mest mulig ut av dette mønsteret i dag, del Fast Copy og transformasjonsarbeidet i to spørringer: én spørring som utfører Fast Copy-databevegelsen, og en annen spørring som anvender transformasjonene på de trinnvise dataene før den skriver til Lakehouse-destinasjonen. Å kombinere en Fast Copy-operasjon med ikke-folding-transformasjoner i samme spørring deaktiverer Fast Copy, så det viktigste å være oppmerksom på er å holde dem i separate spørringer. Hvis transformasjonene dine folder seg helt mot kilden, kan du også skrive direkte til Lakehouse med stagingen deaktivert.

Når du stagenererer data og skriver til en Lakehouse-destinasjon, slå på alternativet Optimalisert kopier til Lakehouse (Forhåndsvisning) på Scale-fanen for å rute de trinnede dataene til Lakehouse gjennom den raskere kopieringsveien, noe som reduserer overheaden ved steging-til-Lakehouse-hoppet. For mer informasjon, se Staged data-alternativer for Dataflow Gen2.

Vurdering 4: Store forhåndsvisninger av data i utformingstidspunktet

I dette scenarioet arbeider du med en dataflyt med store datasett, og utformingstidsopplevelsen går tregt på grunn av størrelsen på forhåndsvisningene av dataene. Denne prosessen kan gjøre det vanskelig å redigere og teste dataflyten effektivt.

I dette tilfellet bør du vurdere å bruke skjemavisning eller parametrisering for å begrense størrelsen på forhåndsvisninger av data. Ved å bruke filtre basert på parametere, for eksempel et datointervall eller bestemte ID-er, kan du redusere mengden data som vises i utformingstidsmiljøet. Denne fremgangsmåten bidrar til å holde utformingsmiljøet responsivt og effektivt, slik at du kan fokusere på redigering og testing av dataflyten uten å bli hindret av store forhåndsvisninger av data. I tillegg kan du justere parameterne under kjøretid for å hente hele datasettet ved behov.

Hvis du for eksempel arbeider med et stort transaksjonsdatasett, kan du opprette en parameter som filtrerer dataene basert på et bestemt datointervall. På denne måten ser du bare et delsett av dataene som er relevante for det gjeldende arbeidet, i løpet av utformingstiden. Når du er klar til å kjøre dataflyten, kan du justere parameteren for å inkludere det fullstendige datasettet, slik at dataintegreringsprosessene forblir effektive og responsive. Følgende eksempel viser hvordan du konfigurerer en parameter i Dataflyt gen2:

1. Velg alternativet Administrer parametere i redigeringsprogrammet for dataflyt.

2. Velg Legg til parameter-knappen for å legge til en ny parameter.

   

3. Fyll ut parameterdetaljene, for eksempel navn, type og verdi. Du kan for eksempel opprette en parameter kalt DesignDateFilter av typen DateTime med en standardverdi som begrenser forhåndsvisningen av data til et bestemt datointervall.

   

4. Bruk parameteren i dataflytspørringene ved å bruke den i filterbetingelsene. Du kan for eksempel filtrere dataene basert på DesignDateFilter-parameteren for å begrense forhåndsvisningen av data til et bestemt datointervall. I dette tilfellet filtrerer vi dataene slik at de bare inkluderer poster der «Date»-kolonnen er større enn DesignDateFilter-parameteren .

   

5. Nå kan du bruke DesignDateFilter-parameteren i dataflytspørringene for å begrense forhåndsvisningen av data under utformingstidspunktet. Når du er klar til å kjøre dataflyten, kan du justere parameterverdien for å inkludere det fullstendige datasettet, slik at dataintegreringsprosessene forblir effektive og responsive.

   

Et annet alternativ er å bruke skjemavisningen, som lar deg se strukturen til dataene dine uten å laste inn hele datasettet. Denne visningen gir en oversikt på høyt nivå over datatypene og kolonnene i datasettet, slik at du kan utforme og teste dataflyten uten å bli påvirket av forhåndsvisninger av store data. Hvis du vil bytte til skjemavisning, velger du alternativet Skjemavisning i redigeringsprogrammet for dataflyt.

Vurdering 5: Egenskaper for dataflyt gen2 runtime sammenlignet med Dataflyt gen1

I dette scenarioet ser du at ytelsen til Dataflyt gen2 er tregere enn dataflyt gen1, spesielt når det gjelder kjøringstid og ressursbruk. Denne ytelsesforskjellen kan skyldes flere faktorer, inkludert forskjellene i optimaliseringsteknikker og utdataformater som brukes i Dataflyt gen2.

Dataflyt gen2 avgir data i Delta Parquet-format når du bruker oppsamlings- eller Lakehouse-destinasjoner, som er forskjellig fra CSV-utdataene til Dataflow Gen1. Selv om Delta Parquet kan resultere i lengre ETL-kjøretider sammenlignet med CSV, muliggjør det kraftige nedstrømsfunksjoner som Direct Lake, Lakehouses og Warehouses, slik at disse tjenestene kan bruke data effektivt uten ekstra behandling eller kostnad. Denne forskjellen i lagringsmetoden betyr at selv om den første kjøringstiden kan være lengre, kan den generelle ytelsen og effektiviteten til nedstrømsprosesser forbedres betydelig og kan føre til bedre langsiktig ytelse for arbeidsflytene for dataintegrering. Finn ut mer om Delta Parquet-format.

Vurdering 6: Optimalisere oppdateringstiden for store transaksjonsdatasett ved hjelp av trinnvis oppdatering

I dette scenarioet arbeider du med et stort transaksjonsdatasett som oppdateres ofte, og du vil optimalisere oppdateringstiden for dataflyten. Denne optimaliseringen kan være utfordrende på grunn av datavolumet og behovet for å behandle bare de nye eller endrede postene.

I dette tilfellet bør du vurdere å bruke trinnvis oppdatering eller mønsteret for trinnvis innsamling av data. Trinnvis oppdatering lar deg behandle bare de nye eller endrede dataene siden forrige oppdatering, noe som reduserer mengden data som behandles og øker hastigheten på den totale kjøringstiden. Denne fremgangsmåten er spesielt nyttig for scenarioer der data oppdateres ofte, for eksempel i transaksjonssystemer. Ved å implementere trinnvis oppdatering kan du optimalisere ytelsen til dataflyten og sikre at dataintegreringsprosessene forblir effektive og responsive. Finn ut mer om trinnvis oppdatering eller lær om mønsteret for trinnvis innsamling av data.

Vurdering 7: Jeg bruker en gateway til å koble til den lokale datakilden, og jeg vil optimalisere ytelsen til dataflyten

I dette scenarioet bruker du en gateway til å koble til den lokale datakilden, og du vil optimalisere ytelsen til dataflyten. Gatewayer kan introdusere ekstra ventetid og indirekte kostnader, noe som kan påvirke den generelle ytelsen til dataflyten.

I dette tilfellet bør du vurdere å dele opp dataflyten i to separate dataflyter: én for dataflyt fra den lokale datakilden til et datamål (for eksempel et Lakehouse eller Warehouse) og en annen for transformasjoner og endelig utdata. Med denne fremgangsmåten kan du optimalisere dataflyttingen trinnvis ved å bruke Fast Copy for dataoverføring med høy gjennomstrømning, samtidig som du holder transformasjonstrinnet fokusert på å behandle dataene effektivt og redusere den totale kjøringstiden. Ved å skille dataflyttings- og transformasjonstrinnene kan du redusere virkningen av ventetid og kapasitetsbegrensninger for gatewayen. Årsaken til dette er at gatewayen kjører hele dataflyten, og hvis dataflyten er kompleks eller har mange transformasjoner, kan det føre til langsommere ytelse når gatewayen behandler alle transformasjonene på datamaskinen som er vert for gatewayen. Ved å dele opp dataflyten kan du sikre at gatewayen bare er ansvarlig for databevegelsestrinnet, noe som kan forbedre ytelsen betydelig og redusere kjøringstiden.

Vurdering 8: Jeg bruker dataflytkoblingene til å bruke data fra dataflyten og ønsker å optimalisere prosessene for dataintegrering

I dette scenarioet bruker du dataflytkoblinger til å bruke data fra dataflyten, og du vil optimalisere dataintegreringsprosessene. Dataflytkoblinger kan gi en praktisk måte å få tilgang til og bruke data på.

I dette tilfellet bør du vurdere å bruke datamål i stedet for dataflytkoblinger for å bruke data fra dataflyten. Datadestinasjoner, for eksempel Lakehouses og Warehouses, er utformet for effektiv lagring og bruk av data, slik at du kan bruke funksjonene deres for nedstrømsforbruk. En stor fordel med å bruke datamål er at de ofte tjener mer generiske måter å koble til data på, for eksempel SQL-endepunktet eller bruke Direct Lake-funksjonene, noe som kan forbedre ytelsen betydelig og redusere ressursforbruket.

Vurdering 9: Aktiver Modern Evaluator for forbedret spørringsytelse

I dette scenariet ønsker du å forbedre den totale ytelsen til dataflyten din, spesielt for komplekse transformasjoner eller når du jobber med koblinger som ikke støtter spørringsfolding.

I dette tilfellet bør du vurdere å aktivere Modern Query Evaluation Engine (Modern Evaluator) for Dataflow Gen2 med CI/CD. Modern Evaluator er en ny spørringsmotor som kjører på .NET Core 8, og som kan forbedre ytelsen til dataflytkjøringer betydelig. Det anbefales alltid å aktivere denne funksjonen for støttede scenarier, da den gir flere viktige fordeler:

• Raskere kjøring av dataflyt: Den moderne motoren kan redusere spørringsevalueringstiden betydelig. Mange dataflyter kjører merkbart raskere, slik at du kan oppdatere data oftere eller møte stramme oppdateringsvinduer.
• Mer effektiv behandling: Motoren er optimalisert for effektivitet, ved hjelp av forbedrede algoritmer og en moderne kjøretid. Dette betyr at den kan håndtere komplekse transformasjoner med mindre overhead, noe som bidrar til å opprettholde ytelsen etter hvert som datavolumet vokser.
• Skalerbarhet og pålitelighet: Ved å øke hastigheten på utførelsen og redusere flaskehalser, hjelper Modern Evaluator dataflyter med å skalere til større volumer med større stabilitet. Du kan forvente mer konsistente oppdateringstider og færre timeout-problemer på store dataflyter.

Den moderne evaluatoren er spesielt nyttig når:

• Du jobber med ikke-foldbare eller delvis sammenleggbare kontakter
• Du bruker filtre, kolonneutledninger eller datarensingsoperasjoner
• Du har med store datamengder eller komplekse transformasjoner å gjøre
• Dataflytene dine kjøres flere ganger om dagen, og du må spare tid

For å muliggjøre den moderne evaluatoren:

1. Åpne dataflyten din i Power Query-editoren.
2. Velg Alternativer fra menyen.
3. Gå til fanen Skala .
4. Slå på alternativet for moderne spørringsvurderingsmotor .
5. Lagre og kjør dataflowen din.

Modern Evaluator støtter en voksende liste av kontakter. For fullstendig liste over støttede kontakter og nåværende funksjonsstatus, se Modern Evaluator for Dataflow Gen2 med CI/CD. Hvis dataflyten din bruker koblinger som ikke finnes i støttelisten, fortsetter disse spørringene å kjøre med standardmotoren.

For å lære mer om Modern Evaluator, se Modern Evaluator for Dataflow Gen2 med CI/CD.

Conclusion

Ved å følge disse anbefalte fremgangsmåtene og vurdere de spesifikke egenskapene til dataene og transformasjonene, kan du optimalisere ytelsen til Dataflyt Gen2 i Fabric Data Factory. Enten du arbeider med store datasett, komplekse transformasjoner eller spesifikke dataintegreringsmønstre, gir disse retningslinjene handlingsrettet innsikt for å forbedre effektiviteten og hastigheten til dataintegreringsprosessene. Husk at ytelsesoptimalisering er en pågående prosess, og du må kanskje justere tilnærmingen din basert på de stadig voksende behovene til arbeidsflytene for dataintegrering. Ved å kontinuerlig overvåke og optimalisere dataflytene, kan du sikre at de forblir effektive og lydhøre for forretningskravene dine.