Dela via

Konfigurera automatisk inläsning för produktionsarbetsbelastningar

  • Artikel

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

Databricks rekommenderar att du använder Auto Loader i Delta Live Tables för inkrementell datainmatning. Delta Live Tables 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:

Övervaka automatisk inläsning

Köra frågor mot filer som identifieras av autoinläsaren

Kommentar

Funktionen cloud_files_state är tillgänglig i Databricks Runtime 11.3 LTS och senare.

Auto Loader tillhandahåller ett SQL-API för att inspektera tillståndet för en dataström. Med hjälp av cloud_files_state funktionen kan du hitta metadata om filer som har identifierats av en automatisk inläsningsström. Fråga bara från cloud_files_stateoch ange den kontrollpunktsplats som är associerad med en automatisk inläsningsströ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 gränssnitt för strömningsfrågaslyssnare.

Automatisk inläsning rapporterar mått till lyssnaren för strömningsfråga i varje batch. Du kan visa hur många filer som finns i kvarvarande uppgifter och hur stora kvarvarande uppgifter som finns 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 Databricks-jobb för att schemalägga automatisk inläsning som batchjobb med i Trigger.AvailableNow 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 komma i form av LIST-åtgärder på dina lagringskonton i kataloglistningsläge och API-begäranden på prenumerationstjänsten och kötjänsten i filmeddelandeläge. För att minska kostnaderna för filidentifiering rekommenderar Databricks:

  • Tillhandahålla en ProcessingTime utlösare när automatisk inläsning körs kontinuerligt i kataloglistningsläge
  • Att skapa filuppladdningar till ditt lagringskonto i lexikal ordning för att utnyttja inkrementell lista (inaktuell) när det är möjligt
  • Använda filmeddelanden när inkrementell lista 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 hastighetsbegränsning

Kommentar

Finns i Databricks Runtime 10.4 LTS och senare.

Automatisk inläsning kan schemaläggas att köras i Databricks-jobb som ett batchjobb med hjälp Trigger.AvailableNowav . 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

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.

Kvarhållning av hä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. Databricks rekommenderar starkt att du använder cloudFiles.maxFileAge alternativet för alla dataströmmar med hög volym eller lång livslängd. Det här alternativet upphör att gälla händelser från kontrollpunktsplatsen, vilket påskyndar autoinläsningens starttid. Starttiden kan växa till minuter per autoinläsningskörning, vilket medför onödiga kostnader när du har en övre gräns för den maximala åldern för filer som ska lagras i källkatalogen. Det minsta värde som du kan ange för cloudFiles.maxFileAge är "14 days". Borttagningar i RocksDB visas som tombstone-poster. Därför bör du förvänta dig att lagringsanvändningen ökar tillfälligt när händelserna upphör att gälla innan den börjar plana ut.

Varning

cloudFiles.maxFileAge tillhandahålls som en mekanism för kostnadskontroll för datauppsättningar med stora volymer. Om du justerar cloudFiles.maxFileAge för aggressivt kan det orsaka problem med datakvaliteten, till exempel duplicerad inmatning eller filer som saknas. Därför rekommenderar Databricks en konservativ inställning för cloudFiles.maxFileAge, till exempel 90 dagar, vilket liknar vad jämförbara datainmatningslösningar rekommenderar.

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 följer några saker att tänka på när du väljer :cloudFiles.maxFileAge

  • Om strömmen startas om efter en lång tid ignoreras filaviseringshändelser som hämtas från kön som är äldre än cloudFiles.maxFileAge de som ignoreras. 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ösa vanliga återfyllnad med hjälp av cloudFiles.backfillInterval

Automatisk inläsning kan utlösa asynkrona återfyllnad vid ett visst intervall, till exempel en dag för att fylla på en gång om dagen eller en vecka för att fylla på igen en gång i veckan. System för filhändelsemeddelanden garanterar inte 100 % leverans av alla filer som har laddats upp och tillhandahåller inte strikta serviceavtal för svarstiden för filhändelserna. Databricks rekommenderar att du utlöser regelbundna återfyllnad med automatisk inläsning med hjälp cloudFiles.backfillInterval av alternativet för att garantera att alla filer identifieras inom ett visst serviceavtal om data är fullständiga. Att utlösa vanliga återfyllnad orsakar inte dubbletter.