Konfigurera Auto Loader för produktionsarbetsbelastningar

Databricks rekommenderar att du följer metodtipsen för direktuppspelning för att köra automatisk inläsning i produktion.

Databricks rekommenderar att använda Auto Loader i Lakeflow deklarativa pipelines för successiv datainmatning. Deklarativa pipelines för Lakeflow utökar funktionerna i Apache Spark Structured Streaming och gör att du bara kan skriva några rader deklarativ Python eller SQL för att distribuera en datapipeline av produktionskvalitet med:

• Beräkningsinfrastruktur för automatisk skalning för kostnadsbesparingar
• Datakvalitetskontroller med förväntningar
• Automatisk schemautvecklingshantering
• Övervakning via mått i händelseloggen

Övervaka Auto Loader

Fråga filer som upptäckts av Auto Loader

Auto Loader tillhandahåller ett SQL-API för att inspektera tillståndet för en dataström. Med cloud_files_state-funktionen kan du hitta metadata om filer som har identifierats av en Auto Loader-ström. Ange bara frågan från cloud_files_state och ange kontrollpunktens plats som är associerad med en Auto Loader-ström.

SELECT * FROM cloud_files_state('path/to/checkpoint');

Lyssna på stream-uppdateringar

För att ytterligare övervaka automatiska inläsningsströmmar rekommenderar Databricks att du använder Apache Sparks Streaming Query Listener-gränssnitt.

Auto Loader rapporterar mått till lyssnaren för strömmande frågor i varje batch. Du kan se hur många filer som finns i eftersläpningen och hur stor eftersläpningen är i måtten numFilesOutstanding och numBytesOutstanding under fliken Rådata på instrumentpanelen för strömningsfrågans förlopp.

{
  "sources": [
    {
      "description": "CloudFilesSource[/path/to/source]",
      "metrics": {
        "numFilesOutstanding": "238",
        "numBytesOutstanding": "163939124006"
      }
    }
  ]
}

I Databricks Runtime 10.4 LTS och senare, när du använder filmeddelandeläget, innehåller måtten även det ungefärliga antalet filhändelser som finns i molnkön som approximateQueueSize för AWS och Azure.

Kostnadsöverväganden

När du kör Auto Loader är din huvudsakliga kostnadskälla kostnaden för beräkningsresurser och filidentifiering.

För att minska beräkningskostnaderna rekommenderar Databricks att du använder Lakeflow-jobb för att schemalägga Auto Loader som batchjobb i stället för att köra det kontinuerligt, så länge du inte har krav på låg svarstid. Se Konfigurera utlösarintervall för strukturerad direktuppspelning.

Kostnader för filidentifiering kan uppstå i form av LIST åtgärder på dina lagringskonton i katalogbläddringsläge och API-begäranden på prenumerationstjänsten och kötjänsten i filnotifieringsläge. För att minska kostnaderna för filidentifiering rekommenderar Databricks:

• Tillhandahålla en ProcessingTime utlösare när Auto Loader körs kontinuerligt i kataloglistningsläge
• Att utforma filuppladdningar till ditt lagringskonto i lexikografisk ordning för att utnyttja inkrementell uppräkning (inaktuell) när det är möjligt
• Utnyttja filnotiser när inkrementell listning inte är möjlig
• Använda resurstaggar för att tagga resurser som skapats av Auto Loader för att spåra dina kostnader

Använda Trigger.AvailableNow och gräns för hastighet

Automatisk inläsning kan schemaläggas att köras i Lakeflow-jobb som ett batchjobb med hjälp av Trigger.AvailableNow. Utlösaren AvailableNow instruerar autoinläsaren att bearbeta alla filer som kom innan frågans starttid. Nya filer som laddas upp när strömmen har startat ignoreras till nästa utlösare.

Med Trigger.AvailableNowsker filidentifiering asynkront med databehandling och data kan bearbetas över flera mikrobatcher med hastighetsbegränsning. Automatisk inläsning bearbetar som standard högst 1 000 filer varje mikrobatch. Du kan konfigurera cloudFiles.maxFilesPerTrigger och cloudFiles.maxBytesPerTrigger konfigurera hur många filer eller hur många byte som ska bearbetas i en mikrobatch. Filgränsen är en hård gräns, men bytegränsen är en mjuk gräns, vilket innebär att fler byte kan bearbetas än den angivna maxBytesPerTrigger. När båda alternativen tillhandahålls tillsammans bearbetar Auto Loader så många filer som behövs för att nå en av gränserna.

Kontrollpunktsplats

Kontrollpunktsplatsen används för att lagra status- och förloppsinformation för dataströmmen. Databricks rekommenderar att du ställer in kontrollpunktsplatsen på en plats utan en livscykelprincip för molnobjekt. Om filer på kontrollpunktsplatsen rensas enligt principen är dataströmstillståndet skadat. Om detta händer måste du starta om strömmen från grunden.

Spårning av filhändelser

Automatisk inläsare håller reda på identifierade filer på kontrollpunktsplatsen med hjälp av RocksDB för att tillhandahålla inmatningsgarantier exakt en gång. För dataströmmar med hög volym eller lång livslängd rekommenderar Databricks att du uppgraderar till Databricks Runtime 15.4 LTS eller senare. I dessa versioner väntar inte Auto Loader på att hela RocksDB-tillståndet ska laddas ned innan strömmen startar, vilket kan påskynda starttiden för dataströmmen. Om du vill förhindra att filtillstånden växer utan gränser kan du också överväga att använda cloudFiles.maxFileAge alternativet för att förfalla filhändelser som är äldre än en viss ålder. Det minsta värde som du kan ange för cloudFiles.maxFileAge är "14 days". Borttagningar i RocksDB visas som gravstensposter. Därför kan lagringsanvändningen öka tillfälligt när händelserna upphör att gälla innan den börjar plana ut.

Om du försöker justera cloudFiles.maxFileAge alternativet kan det leda till att obearbetade filer ignoreras av Auto Loader eller att redan bearbetade filer upphör att gälla och sedan bearbetas på nytt, vilket orsakar duplicerade data. Här är några saker att tänka på när du väljer encloudFiles.maxFileAge:

• Om din ström startas om efter en lång tid, ignoreras filaviseringshändelser som hämtas från kön och är äldre än cloudFiles.maxFileAge. På samma sätt, om du använder kataloglistan, filer som kan ha dykt upp under den nedtid som är äldre än cloudFiles.maxFileAge ignoreras.
• Om du använder kataloglistningsläget och använder cloudFiles.maxFileAge, till exempel inställt på "1 month", stoppar du strömmen och startar om strömmen med cloudFiles.maxFileAge inställt på "2 months", filer som är äldre än 1 månad, men senare än 2 månader bearbetas på nytt.

Om du anger det här alternativet första gången du startar dataströmmen matar du inte in data som är äldre än cloudFiles.maxFileAge. Om du vill mata in gamla data bör du därför inte ange det här alternativet när du startar dataströmmen för första gången. Du bör dock ange det här alternativet vid efterföljande körningar.

Utlös regelbundna återfyllnader med hjälp av cloudFiles.backfillInterval

I sällsynta fall kan filer missas eller bli sena när de enbart beror på meddelandesystem, till exempel när kvarhållningsgränser för meddelandemeddelanden nås. Om du har strikta krav på datakompletthet och SLA kan du överväga att ange cloudFiles.backfillInterval för att utlösa asynkrona efterfyllningar vid ett angivet intervall. Ange till exempel en dag för dagliga återfyllnad eller en vecka för veckovisa återfyllnad. Att utlösa vanliga återfyllnad orsakar inte dubbletter.

När du använder filhändelser kör du dataströmmen minst en gång var sjunde dag

Cachen för filhändelser innehåller endast metadata för filer som ändrats under de senaste 7 dagarna. Därför kan den bara stödja inkrementella läsningar om du kör automatisk inläsning minst en gång var sjunde dag. Om du inte kör autoinläsaren minst så här ofta utför den en fullständig kataloglista för att uppdatera cachen och kontrollpunkten.