Vad är på gång?

Lär dig mer om funktioner och beteendeändringar i kommande Azure Databricks versioner.

Power BI anslutningar övergår till ADBC

Power BI planerar att överföra alla Power BI anslutningar till Arrow Database Connectivity (ADBC) i juli 2026. För att undvika störningar rekommenderar Databricks att du byter utvecklings- och mellanlagringssemantikmodeller till ADBC nu och verifierar dina arbetsbelastningar.

ADBC-drivrutinen för Power BI på Azure Databricks har varit i offentlig förhandsversion sedan oktober 2025. Sedan februari 2026 använder alla nya anslutningar i Power BI Desktop och služba Power BI ADBC som standard. Befintliga anslutningar fortsätter att använda ODBC om du inte uppdaterar dem manuellt.

Se Konfigurera ADBC- eller ODBC-drivrutin för Power BI.

Användarauktorisering för Databricks-appar kommer snart att vara tillgänglig för arbetsytor med säkerhetsprofilen för efterlevnad aktiverad

I början av juni 2026 aktiveras användarauktorisering för Databricks-appar automatiskt för arbetsytor med säkerhetsprofilen för efterlevnad aktiverad. Med användarauktorisering kan appar agera med appanvändarens identitet, så att appar kan komma åt resurser för användarens räkning samtidigt som användarens befintliga behörigheter tillämpas.

Se Användarauktorisering.

Behörigheter för arbetsyteobjekt ärvs snart från alla kontogrupper

I en kommande version ärvs behörigheter för arbetsyteobjekt från alla kontogrupper, inte bara grupper som är direkt tilldelade till arbetsytan. Huvudansvariga ärver behörigheter på arbetsyteobjekt som jobb, anteckningsböcker, mappar, sökfrågor och instrumentpaneler från alla kontogrupper som de är medlemmar i, oavsett om dessa grupper är tilldelade arbetsytan. Användarna måste fortfarande tilldelas till arbetsytan för att kunna använda dessa behörigheter.

Den här ändringen aktiverar också inaktiva ("föräldralösa") behörighetstilldelningar. Det här är behörigheter som finns kvar i en grupp när den har tagits bort från ett arbetsområde. Inga nya behörigheter läggs till, men befintliga överblivna bidrag blir aktiva, vilket potentiellt ger arbetsytemedlemmar oväntad åtkomst. Om en "Contractors"-grupp till exempel har tagits bort från en arbetsyta men fortfarande har redigeringsåtkomst till en mapp, får alla medlemmar i "Leverantörer" åtkomst till den mappen.

Databricks rekommenderar att du granskar dina arbetsytebehörigheter. Använd följande notebook-fil för att identifiera inaktiva behörighetsbidrag på dina arbetsytor:

Analysanteckningsbok för överblivna behörigheter

Hämta anteckningsbok

Begränsade personliga åtkomsttoken med definierade behörigheter kommer snart att vara tillgängliga som standard för arbetsytor med aktiverad säkerhetsprofil för regelefterlevnad.

Begränsade personliga åtkomsttokens kommer finnas tillgängliga som standard för arbetsmiljöer med säkerhetsprofilen för efterlevnad aktiverad från slutet av maj 2026.

Begränsade personliga åtkomsttoken begränsar en PAT:s behörighet till specifika API-åtgärder genom att tilldela en eller flera API-omfång, i stället för att ge den fullständiga arbetsyteåtkomsten för den skapade identiteten.

Se Autentisera med Azure Databricks personliga åtkomsttoken (legacy).

Systemgrupper för arbetsytor kommer snart att ha fasta behörighetsbeviljanden

I en kommande version har arbetsytesystemgrupper (users och admins) fasta berättiganden som inte kan ändras. När den här ändringen börjar gälla:

• Gruppen users har inga rättigheter.
• Gruppen admins har alla behörigheter för arbetsytan.
• Befintliga rättigheter i users gruppen migreras automatiskt till en klonad grupp, så att aktuella användare behåller sin åtkomst.

Det här är en genombrytande ändring för kunder som använder automatisering (Terraform, arbetsyta SCIM API:er eller skript) för att hantera rättigheter i systemgrupper. Dessa arbetsflöden måste uppdateras för att rikta sig mot vanliga grupper i stället.

En inställning för att samtycka kommer snart. Mer information finns i Ändra standardåtkomst för arbetsytor till konsumentåtkomst.

ai_parse_document kommer snart att vara tillgänglig som standard för arbetsytor med efterlevnadssäkerhetsprofilen aktiverad

ai_parse_document kommer att vara tillgängligt som standard för arbetsytor med efterlevnadssäkerhetsprofilen aktiverad och HIPAA-, HITRUST-, C5- och TISAX-kontroller som valts i mitten av maj 2026.

Använd ai_parse_document för att parsa strukturerat innehåll från ostrukturerade dokument, inklusive PDF-filer, bilder, Word dokument och PowerPoint filer.

Se ai_parse_document funktion.

Kommande beteendeförändring: VOID kolumner som ingår i Delta-tabellläsningar

I mitten av juni 2026 kommer Delta Lake att ha fullt stöd för VOID kolumner. VOID Tidigare hoppades kolumnerna tyst över av sökvägsbaserade DataFrame-läsningar (till exempel spark.read.format("delta").load(path)) och frågor om tidsresor. Efter den här ändringen inkluderar dessa frågor kolumner i VOID utdata.

Frågor som är beroende av kolumnantal eller position, till exempel INSERT INTO ... SELECT *, kan misslyckas eller ge felaktiga resultat efter den här ändringen. Granska alla frågor som läser från Delta Lake-tabeller med VOID kolumner för att säkerställa att de hanterar de ytterligare kolumnerna korrekt.

Se VOID typ.

Kommande bakåtkompatibla ändringar: standardbeteende vid borttagning av en Unity Catalog-pipeline

I en kommande version ändras standardbeteendet när du tar bort en Unity Catalog-pipeline. För närvarande tar borttagning av en pipeline också bort alla associerade materialiserade vyer, strömmande tabeller och vyer. Efter den här ändringen kommer associerade tabeller att behållas, men de blir inaktiva när pipelinen har tagits bort. API:et ändras också så att det behåller tabeller som standard, men att ställa in cascade fältet till true åsidosätter detta och behåller det aktuella beteendet.

Fältet cascade är tillgängligt nu. Om du vill behålla det aktuella beteendet för att ta bort alla tabeller när du tar bort en pipeline uppdaterar du koden så att den anger cascade=true.

Se Ta bort en pipeline och Ta bort en pipeline.

Git-baserad distribuering för Databricks-appar kommer snart att finnas tillgänglig för arbetsytor med efterlevnadsprofilen för säkerhet aktiverad

I början av maj 2026 aktiveras Git-baserad distribution för Databricks-appar automatiskt för arbetsytor med efterlevnadssäkerhetsprofilen aktiverad. Distribuera appar direkt från en Git-lagringsplats för att effektivisera ditt CI/CD-arbetsflöde.

Se Installera en Databricks-applikation.

Ny SQL-redigerare – standardaktivering och äldre SQL-redigerare – tillbakadragning

Den nya SQL-redigeraren har varit allmänt tillgänglig sedan oktober 2025. Som en del av övergången till den nya redigeraren planeras följande ändringar:

• Från och med slutet av maj 2026: Den nya SQL-redigeraren aktiveras som standard för alla arbetsytor. Möjligheten att inaktivera funktionen på arbetsytenivå är inte längre tillgänglig. Enskilda användare kommer fortfarande att kunna växla sina frågor till den äldre SQL-redigeraren efter att den här perioden har börjat.
• Från och med slutet av juli 2026: Den äldre SQL-redigeraren dras tillbaka. Alla användare kommer att använda den nya SQL-redigeraren och den enskilda opt-outen kommer inte längre att vara tillgänglig.

Mer information om den nya SQL-redigeraren finns i Skriva frågor och utforska data i den nya SQL-redigeraren. Om du har frågor om den här övergången kontaktar du ditt kontoteam.

Ändra sorteringsordningen för listdashboards-API:er

Den 4 maj 2026 ändrar en ny version av API:et listinstrumentpaneler sorteringsordningen för resultaten. Instrumentpaneler returneras i omvänd kronologisk ordning efter senaste ändringsdatum, med de senast ändrade instrumentpanelerna först, i stället för alfabetiskt efter titel.

Detta är en brytande ändring för användare som paginerar resultat med hjälp av next_page_token. Token som genereras av en tidigare version av API:et är inte giltiga med den nya versionen. Om du använder en token från en tidigare version returnerar API:et ett fel:

Invalid page_token: this token was generated by a previous/different API version. Please retry without page_token.

Om du vill fortsätta sidnumrering efter den här ändringen startar du en ny begäran utan .next_page_token

Lakebase kommer att aktiveras som standard för arbetsytor med efterlevnadsäkerhetsprofilen

Den 30 april 2026 eller senare aktiveras Lakebase som standard för arbetsytor med efterlevnadssäkerhetsprofilen när efterlevnadsstandarden är inställd på HIPAA, C5, TISAX eller Ingen.

Se Lakebase Compliance.

Ändringar för att öppna deltadelningsmottagaretoken

Deltadelning för öppna mottagare övergår till ett nytt mottagarspecifikt URL-format. Övergångsdatumet har uppdaterats och är nu den 1 juli 2026. Nya token som skapats den 1 juli 2026 eller senare använder automatiskt det nya URL-formatet. Den här ändringen förbättrar nätverkssäkerheten och låter mottagarna konfigurera mottagarspecifika nätverksprinciper och brandväggsregler.

För Azure Kina kommer övergången att tillkännages senare.

De nya URL:erna innehåller mottagar-ID:t i domänen:

https://<recipient-id>.delta-sharing.westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

Som referens innehåller URL:er som skapats före den här ändringen inte mottagar-ID:t.

https://westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

De gamla URL:erna fortsätter att fungera under en viss tid. Den specifika varaktigheten beror på mottagartypen och datumet då token skapades. Dataleverantörer bör övergå till det nya URL-formatet innan det gamla URL-formatet blir ogiltigt.

OIDC-federationsdelning:

Dataleverantörer måste kontrollera att mottagarna använder det nya URL-formatet före den 1 juli 2027. Från och med den 1 juli 2026 kan leverantörer hitta den nya URL:en i deltadelningsgränssnittet. Efter den 1 juli 2027 är det gamla URL-formatet inte giltigt.

Delning av ägartoken:

Dataklassificering kommer snart att vara tillgängligt som standard för vissa arbetsytor med säkerhetsprofilen för efterlevnad aktiverad

I mitten av mars 2026 är dataklassificering tillgänglig som standard för arbetsytor med säkerhetsprofilen för efterlevnad aktiverad och HIPAA-kontroller valda.

EventBridge-stöd kommer snart att finnas tillgängligt för filhändelser genom tillhandahållna köer.

I slutet av februari 2026 kommer EventBridge-stöd att vara tillgängligt för filhändelser i köer för S3-platser. För närvarande kan filhändelser endast konfigureras med hjälp av SNS eller genom att dirigera lagringshändelser direkt till SQS.

Se Använda en angiven kö för S3.

Ny segmenteringslogik för jobbtidstabeller

Från och med den 19 januari 2026 använder jobbens tidslinjetabeller en ny klocktimmesjusterad segmenteringslogik. Tidssnitt linjeras nu med standard timmar (17:00–18:00, 18:00–19:00 och så vidare) i stället för entimmesintervall baserade på körningens starttid. Nya rader använder den nya segmenteringslogik, medan befintliga rader förblir oförändrade.

Se Logik för klocktimmesjusterad segmentering.

Navigeringsuppdateringar för Katalogutforskaren

Katalogutforskaren får snart navigeringsförbättringar för att effektivisera arbetsflöden och hjälpa dig att identifiera och hantera datatillgångar mer effektivt.

Förenklad navigering:

Fliken duplicerande kataloger tas bort för att minska redundansen och fokusera på en enda katalognavigeringsyta. DBFS och Åtgärder för att skicka feedback flyttas till kebabmenyn för en renare layout.

Nytt föreslaget avsnitt:

En ny föreslagen flik på katalogutforskarens landningssida visar ofta använda objekt, exempelobjekt för förstagångsanvändare och användarfavoriter. Detta hjälper dig att snabbt åter engagera dig i viktiga tillgångar eller upptäcka användbara utgångspunkter.

Konsoliderade startpunkter:

Relaterade funktioner grupperas under tydligare kategorier för att minska det visuella bruset och förbättra sökbarheten:

• Styrning – startpunkt för reglerade taggar, metaarkivadministration och dataklassificering
• Anslut – Startpunkter för externa platser, externa data, autentiseringsuppgifter och anslutningar
• Dela – Startpunkter för Delta Sharing och sekretessrum

Dessa grupper ersätter spridda underflikar och skapar en mer intuitiv och skalbar informationsarkitektur.

Lakehouse Federation-delningstjänster och standardlagring

Deltadelning på Lakehouse Federation finns i Beta, vilket gör att dataleverantörer för Delta Sharing kan dela utländska kataloger och tabeller. Som standard måste data tillfälligt materialiseras och lagras på standardlagringen (privat förhandsversion). För närvarande måste användarna manuellt aktivera deltadelning för standardlagring – utökad åtkomst i kontokonsolen för att använda Lakehouse Federation-delning.

När Delta-delning för standardlagring – utökad åtkomst är aktiverat som standard för alla Azure Databricks användare, blir DeltaDelning på Lakehouse Federation automatiskt tillgängligt i regioner där standardlagring stöds.

Se Standardlagring i Databricks och Lägg till externa scheman eller tabeller i en resurs.

Ladda om avisering i arbetsytor

I en kommande version kommer ett meddelande att visas om att ladda om din arbetsyteflik om fliken har varit öppen under en längre tid utan att uppdateras. Detta hjälper dig att se till att du alltid använder den senaste versionen av Databricks med de senaste funktionerna och korrigeringarna.

Deltadelning för tabeller på standardlagring aktiveras snart som standard (Beta)

Den här standardlagringsuppdateringen för deltadelning har utökade delningsfunktioner, vilket gör det möjligt för leverantörer att dela tabeller som standardlagring till alla deltadelningsmottagare (öppna eller Azure Databricks), inklusive mottagare som använder klassisk beräkning. Den här funktionen är för närvarande i Beta och kräver att leverantörer manuellt aktiverar deltadelning för standardlagring – utökad åtkomst i kontokonsolen. Snart aktiveras detta som standard för alla användare.

Se Begränsningar.

Uppdateringar av offentliga IP-adresser för kontrollplan för utgående trafik

Azure Databricks uppdaterar outbound control plane offentliga IP-adresser och Azure-tjänsttaggar för att förbättra säkerhet och zontillgänglighet. Dessa ändringar är en del av en kontrollplansuppdatering som började lanseras den 20 maj 2025.

Om din organisation använder resursbrandväggar för att styra inkommande åtkomst:

• Om brandväggsreglerna refererar till taggen Azure Databricks service krävs ingen åtgärd.
• Om du tillåter specifika offentliga IP-adresser för kontrollplanet måste du lägga till alla ip-adresser för utgående kontrollplan senast den 26 september 2025.

De tidigare IP-adresserna för kontrollplanet för utgående trafik stöds fortfarande.

Beteendeförändring för alternativet automatisk inläsning av inkrementell kataloglista

I en kommande version av Databricks Runtime kommer värdet för det inaktuella Auto Loader-alternativet cloudFiles.useIncrementalListing att som standard sättas till false. Att ställa in det här värdet till false får Auto Loader att utföra en fullständig kataloglistning varje gång den körs. För närvarande är standardvärdet för alternativet cloudFiles.useIncrementalListingauto, vilket instruerar Auto Loader att göra ett bästa försök att identifiera om en inkrementell lista kan användas med en katalog.

Om du vill fortsätta använda funktionen för inkrementell lista anger du alternativet cloudFiles.useIncrementalListing till auto. När du anger det här värdet till autogör Auto Loader ett bra försök att göra en fullständig lista en gång var sjunde inkrementell lista, vilket matchar beteendet för det här alternativet före den här ändringen.

Mer information om kataloglistan för automatisk inläsning finns i Konfigurera automatiska inläsningsströmmar i kataloglistningsläge.

Beteendeförändringar när datauppsättningsdefinitioner tas bort från Lakeflow Spark Deklarativa Pipelines

Nästa version av Lakeflow Spark Deklarativa Pipelines kommer att ändra beteendet när en materialiserad vy eller en strömmande tabell tas bort från en pipeline. Med den här ändringen tas den borttagna materialiserade vyn eller strömningstabellen inte bort automatiskt när nästa pipelineuppdatering körs. I stället kan du använda kommandot DROP MATERIALIZED VIEW för att ta bort en materialiserad vy eller kommandot DROP TABLE för att ta bort en strömmande tabell. När ett objekt har släppts återställs inte objektet automatiskt när du kör en pipelineuppdatering. Ett nytt objekt skapas om en materialiserad vy eller en strömmande tabell med samma definition läggs till i pipelinen igen. Du kan dock återställa ett objekt med hjälp av kommandot UNDROP.

Fältet sourceIpAddress i granskningsloggar innehåller inte längre ett portnummer

På grund av en bugg innehåller vissa granskningsloggar för auktorisering och autentisering ett portnummer utöver IP-adressen i sourceIPAddress fältet (till exempel "sourceIPAddress":"10.2.91.100:0"). Portnumret, som loggas som 0, ger inget verkligt värde och är inkonsekvent med resten av Databricks-granskningsloggarna. För att förbättra konsekvensen av granskningsloggar planerar Databricks att ändra formatet på IP-adressen vid dessa granskningshändelser. Den här ändringen kommer gradvis att lanseras från och med början av augusti 2024.

Om granskningsloggen innehåller en sourceIpAddress av 0.0.0.0kan Databricks sluta logga den.