Wat kunt u verwachten?

Meer informatie over functies en gedragswijzigingen in toekomstige Azure Databricks releases.

Power BI verbindingen worden overgestapt op ADBC

Power BI plant in juli 2026 om al haar verbindingen naar Arrow Database Connectivity (ADBC) over te stappen. Om onderbrekingen te voorkomen, raadt Databricks aan om uw ontwikkel- en faseringsmodellen nu over te schakelen naar ADBC en uw workloads te valideren.

Het ADBC-stuurprogramma voor Power BI op Azure Databricks is sinds oktober 2025 in openbare preview. Sinds februari 2026 gebruiken alle nieuwe verbindingen in Power BI Desktop en de Power BI-service standaard ADBC. Bestaande verbindingen blijven ODBC gebruiken, tenzij u ze handmatig bijwerkt.

Zie ADBC- of ODBC-stuurprogramma configureren voor Power BI.

Gebruikersautorisatie voor Databricks-apps is binnenkort beschikbaar voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld

Begin juni 2026 wordt gebruikersautorisatie voor Databricks-apps automatisch ingeschakeld voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld. Met gebruikersautorisatie kunnen apps handelen met de identiteit van de app-gebruiker, zodat apps namens de gebruiker toegang hebben tot resources terwijl de bestaande machtigingen van de gebruiker worden afgedwongen.

Zie Gebruikersautorisatie.

Machtigingen voor werkruimteobjecten worden binnenkort overgenomen van alle accountgroepen

In een toekomstige release worden machtigingen voor werkruimteobjecten overgenomen van alle accountgroepen, niet alleen groepen die rechtstreeks aan de werkruimte zijn toegewezen. Principals nemen machtigingen over voor werkruimteobjecten, zoals taken, notitieblokken, mappen, query's en dashboards, van alle accountgroepen waarvan ze lid zijn, ongeacht of deze groepen aan de werkruimte zijn toegewezen. Gebruikers moeten nog steeds worden toegewezen aan de werkruimte om deze machtigingen te kunnen gebruiken.

Deze wijziging activeert ook inactieve toestemmingsverleningen ('achtergelaten') autorisaties. Dit zijn toestemmingsrechten die bij een groep blijven bestaan nadat deze uit een werkruimte zijn verwijderd. Er worden geen nieuwe machtigingen toegevoegd, maar bestaande verweesde autorisaties worden actief, waardoor werkruimteleden mogelijk onverwachte toegang krijgen. Als bijvoorbeeld een groep 'Contractanten' is verwijderd uit een werkruimte, maar nog steeds bewerkingstoegang heeft tot een map, krijgt elk werkruimtelid in 'Contractanten' toegang tot die map.

Databricks raadt u aan om uw werkruimtemachtigingen te controleren. Gebruik het volgende notebook om inactieve machtigingen in uw werkruimten te identificeren:

Notitieblok voor analyse van verweesde machtigingen

Notebook krijgen

Toegesneden persoonlijke toegangstokens zullen binnenkort standaard beschikbaar zijn voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld.

Persoonlijke toegangstokens binnen het bereik zijn standaard beschikbaar voor werkruimten waarvoor het nalevingsbeveiligingsprofiel eind mei 2026 is ingeschakeld.

Gescopeerde persoonlijke toegangstokens beperken de toestemming van een PAT voor specifieke API-bewerkingen door een of meer API-scopes toe te wijzen in plaats van de volledige toegang van de identiteitswerkruimte te verlenen.

Zie Verifiëren met persoonlijke toegangstokens van Azure Databricks (verouderd).

Werkruimtesysteemgroepen krijgen binnenkort vaste rechtentoelagen

In een toekomstige release hebben werkruimtesysteemgroepen (users en admins) vaste rechtentoelagen die niet kunnen worden gewijzigd. Wanneer deze wijziging van kracht wordt:

• De users groep heeft geen rechten.
• De admins groep heeft alle werkruimterechten.
• Bestaande rechten voor de users groep worden automatisch gemigreerd naar een gekloonde groep, zodat huidige gebruikers hun toegang behouden.

Dit is een belangrijke wijziging voor klanten die gebruikmaken van automatisering (Terraform, SCIM-API's voor werkruimten of scripts) om rechten voor systeemgroepen te beheren. Deze werkstromen moeten in plaats daarvan worden bijgewerkt om zich te richten op reguliere groepen.

Binnenkort wordt er een opt-in-instelling beschikbaar. Zie Standaard toegang voor werkruimten wijzigen naar consumententoegang voor meer informatie.

ai_parse_document is binnenkort standaard beschikbaar voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld

ai_parse_document is standaard beschikbaar voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld en HIPAA-, HITRUST-, C5- en TISAX-besturingselementen die medio mei 2026 zijn geselecteerd.

Gebruik ai_parse_document om gestructureerde inhoud van ongestructureerde documenten te parseren, waaronder PDF-bestanden, afbeeldingen, Word documenten en PowerPoint bestanden.

Zie ai_parse_document de functie.

Aanstaande gedragswijziging: VOID kolommen opgenomen in Delta-tabellezingen

In medio juni 2026 biedt Delta Lake volledige ondersteuning voor VOID kolommen. VOID Voorheen werden kolommen stilletjes overgeslagen door padgebaseerde DataFrame-lezen (bijvoorbeeld spark.read.format("delta").load(path)) en tijdreisquery's. Na deze wijziging bevatten deze query's VOID kolommen in de uitvoer.

Query's die afhankelijk zijn van het aantal kolommen of de positie, zoals INSERT INTO ... SELECT *, kunnen mislukken of onjuiste resultaten opleveren na deze wijziging. Bekijk alle query's die uit Delta Lake-tabellen met VOID kolommen worden gelezen om ervoor te zorgen dat ze de extra kolommen correct verwerken.

Zie VOID type.

Aanstaande belangrijke wijziging: standaardgedrag bij het verwijderen van een Unity Catalog-pijplijn

In een toekomstige release verandert het standaardgedrag bij het verwijderen van een Unity Catalog-pijplijn. Als u een pijplijn verwijdert, worden momenteel ook alle gekoppelde gerealiseerde weergaven, streamingtabellen en weergaven verwijderd. Na deze wijziging blijven gekoppelde tabellen behouden, maar inactief nadat de pijplijn is verwijderd. De API zal ook standaard veranderen om tabellen te behouden, maar door het cascade veld op true in te stellen, wordt dit overschreven en blijft het huidige gedrag behouden.

Het cascade veld is nu beschikbaar. Werk uw code bij om het huidige gedrag, waarbij alle tabellen worden verwijderd wanneer een pijplijn wordt verwijderd, te behouden door cascade=true in te stellen.

Zie Een pijplijn verwijderen en Een pijplijn verwijderen.

Implementatie op basis van Git voor Databricks-apps is binnenkort beschikbaar voor werkruimten waarvoor het beveiligingsprofiel voor naleving is ingeschakeld

Begin mei 2026 wordt op Git gebaseerde implementatie voor Databricks-apps automatisch ingeschakeld voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld. Implementeer apps rechtstreeks vanuit een Git-opslagplaats om uw CI/CD-werkstroom te stroomlijnen.

Zie Een Databricks-app implementeren.

Nieuwe standaardinschakeling voor de SQL-editor en buitengebruikstelling van de verouderde SQL-editor

De nieuwe SQL-editor is algemeen beschikbaar sinds oktober 2025. Als onderdeel van de overgang naar de nieuwe editor zijn de volgende wijzigingen gepland:

• Vanaf eind mei 2026: De nieuwe SQL-editor wordt standaard ingeschakeld voor alle werkruimten. De mogelijkheid om de functie op werkruimteniveau uit te schakelen, is niet meer beschikbaar. Afzonderlijke gebruikers kunnen hun query's nog steeds overschakelen naar de verouderde SQL-editor nadat deze periode is begonnen.
• Vanaf eind juli 2026: De verouderde SQL-editor wordt buiten gebruik gesteld. Alle gebruikers gebruiken de nieuwe SQL-editor en de afzonderlijke opt-out is niet meer beschikbaar.

Zie Query's schrijven en gegevens verkennen in de nieuwe SQL-editor voor meer informatie over de nieuwe SQL-editor. Neem contact op met uw accountteam als u vragen hebt over deze overgang.

Volgorde wijzigen van dashboards-API lijst

Op 4 mei 2026 wordt de sorteervolgorde van de resultaten gewijzigd door een nieuwe versie van de API Lijstdashboards . Dashboards worden geretourneerd in omgekeerde chronologische volgorde op datum van laatste wijziging, met het laatst gewijzigde dashboard eerst, in plaats van alfabetisch op titel.

Dit is een belangrijke wijziging voor gebruikers die resultaten pagineren met behulp van next_page_token. Tokens die zijn gegenereerd door een eerdere versie van de API, zijn niet geldig met de nieuwe versie. Als u een token van een vorige versie gebruikt, retourneert de API een fout:

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

Als u wilt doorgaan met pagineren na deze wijziging, start u een nieuwe aanvraag zonder een next_page_token.

Lakebase wordt standaard ingeschakeld voor werkruimten met het beveiligingsprofiel voor naleving

Op of na 30 april 2026 wordt Lakebase standaard ingeschakeld voor werkruimten met het nalevingsbeveiligingsprofiel wanneer de nalevingsstandaard is ingesteld op HIPAA, C5, TISAX of Geen.

Zie Lakebase compliance.

Wijzigingen in het openen van ontvangerstokens voor Delta Delen

Delta Sharing voor open ontvangers zal overgaan naar een ontvanger-specifiek URL-formaat. De overgangsdatum is bijgewerkt en is nu 1 juli 2026. Nieuwe tokens die zijn gemaakt op of na 1 juli 2026, gebruiken automatisch de nieuwe URL-indeling. Deze wijziging verbetert de netwerkbeveiliging en stelt ontvangers in staat om voor zichzelf specifiek netwerkbeleid en firewallregels te configureren.

Voor Azure China wordt de overgang later aangekondigd.

De nieuwe URL's bevatten de ontvanger-id in het domein:

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

Ter referentie bevatten URL's die vóór deze wijziging zijn gemaakt, de geadresseerde-id niet.

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

De oude URL's blijven gedurende een bepaalde periode werken. De specifieke duur is afhankelijk van het type ontvanger en de aanmaakdatum van het token. Gegevensproviders moeten overschakelen naar de nieuwe URL-indeling voordat de oude URL-indeling ongeldig wordt.

OIDC Federation delen:

Gegevensproviders moeten controleren of hun geadresseerden de nieuwe URL-indeling vóór 1 juli 2027 gebruiken. Vanaf 1 juli 2026 kunnen providers de nieuwe URL vinden in de gebruikersinterface van Delta Sharing. Na 1 juli 2027 is de oude URL-indeling niet geldig.

Bearer-token delen:

Gegevensclassificatie is binnenkort standaard beschikbaar voor sommige werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld

Medio maart 2026 is gegevensclassificatie standaard beschikbaar voor werkruimten waarvoor het nalevingsbeveiligingsprofiel is ingeschakeld en hipAA-besturingselementen zijn geselecteerd.

EventBridge-ondersteuning is binnenkort beschikbaar voor bestandsevenementen in wachtrijen

Eind februari 2026 is eventbridge-ondersteuning beschikbaar voor bestandsgebeurtenissen die wachtrijen bieden voor S3-locaties. Op dit moment kunnen bestandsevenementen alleen worden ingesteld met behulp van SNS of door opslagevenementen rechtstreeks naar SQS te routeren.

Zie Een opgegeven wachtrij voor S3 gebruiken.

Nieuwe segmenteringslogica voor tijdlijntabellen voor taken

Vanaf 19 januari 2026 gebruiken de tijdlijntabellen voor werkzaamheden een nieuwe klokuur-uitgelijnde snijlogica. Tijdsegmenten worden nu uitgelijnd op standaard klokuurgrenzen (17:00-18:00, 18:00-17:00 uur, enzovoort) in plaats van intervallen van één uur op basis van de begintijd van de uitvoering. Nieuwe rijen maken gebruik van de nieuwe segmenteringslogica, terwijl bestaande rijen ongewijzigd blijven.

Zie de uitgelijnde segmenteringslogica die uur per uur is uitgelijnd.

Navigatie-updates voor Catalogusverkenner

Catalog Explorer ontvangt binnenkort navigatieverbeteringen om werkstromen te stroomlijnen en u te helpen gegevensassets efficiënter te detecteren en te beheren.

Vereenvoudigde navigatie:

Het tabblad Duplicative Catalogs wordt verwijderd om redundantie te verminderen en zich te richten op één catalogusnavigatieoppervlak. DBFS en De acties Feedback verzenden gaan naar het Voor een schonere indeling.

Nieuwe voorgestelde sectie:

Een nieuw tabblad Aanbevolen op de startpagina van Catalog Explorer markeert veelgebruikte objecten, voorbeeldobjecten voor eerste gebruikers en favorieten van gebruikers. Dit helpt u snel opnieuw in contact te komen met belangrijke assets of nuttige uitgangspunten te ontdekken.

Geconsolideerde toegangspunten:

Gerelateerde mogelijkheden worden gegroepeerd onder duidelijkere categorieën om visuele ruis te verminderen en de vindbaarheid te verbeteren:

• Beheren : toegangspunt voor beheerde tags, metastore-beheer en gegevensclassificatie
• Verbinding maken : toegangspunten voor externe locaties, externe gegevens, referenties en verbindingen
• Delen – Toegangspunten voor Delta Sharing en Clean Rooms

Deze groeperingen vervangen verspreide subtabbladen en maken een intuïtievere, schaalbare informatiearchitectuur.

Lakehouse Federation deling en standaard opslag

Delta Sharing on Lakehouse Federation is bèta, waardoor gegevensproviders voor Delta Sharing buitenlandse catalogi en tabellen kunnen delen. Standaard moeten gegevens tijdelijk worden gematerialiseerd en opgeslagen in de standaardopslag (Private Preview). Op dit moment moeten gebruikers de Delta Sharing voor Standaardopslag – Uitgebreide Toegang functie inschakelen in de accountconsole om Lakehouse Federation-sharing te kunnen gebruiken.

Nadat Delta Sharing for Default Storage – Expanded Access standaard is ingeschakeld voor alle Azure Databricks gebruikers, is Delta Sharing on Lakehouse Federation automatisch beschikbaar in regio's waar standaardopslag wordt ondersteund.

Zie de standaardopslag in Databricks en voeg buitenlandse schema's of tabellen toe aan een share.

Opnieuw laden van meldingen in werkruimtes

In een komende release wordt er een bericht weergegeven dat vraagt uw tabblad van uw werkruimte opnieuw te laden als het tabblad al lange tijd is geopend zonder te vernieuwen. Dit helpt ervoor te zorgen dat u altijd de nieuwste versie van Databricks gebruikt met de nieuwste functies en oplossingen.

Delta Sharing voor tabellen in standaardopslag wordt binnenkort standaard ingeschakeld (bèta)

** Deze standaardopslagupdate voor Delta Sharing heeft uitgebreide mogelijkheden voor delen, zodat providers tabellen vanuit standaardopslag kunnen delen met elke ontvanger van Delta Sharing (open of Azure Databricks), inclusief ontvangers die gebruikmaken van klassieke computing. Deze functie is momenteel beschikbaar in de bètaversie en vereist dat providers Delta Sharing handmatig inschakelen voor standaardopslag: uitgebreide toegang in de accountconsole. Binnenkort wordt dit standaard ingeschakeld voor alle gebruikers.

Zie beperkingen.

Updates voor de openbare IP-adressen van het uitgaande besturingsvlak

Azure Databricks werkt de openbare IP-adressen van het outbound besturingsvlak en Azure-servicetags bij voor verbeterde beveiliging en beschikbaarheid van zones. Deze wijzigingen maken deel uit van een update van het besturingsvlak die op 20 mei 2025 is geïmplementeerd.

Als uw organisatie resourcefirewalls gebruikt om binnenkomende toegang te beheren:

• Als uw firewallregels verwijzen naar de Azure Databricks servicetag, is er geen actie vereist.
• Als u specifieke openbare IP-adressen van het besturingsvlak toestaat, moet u alle uitgaande ip-adressen van het besturingsvlak toevoegen op 26 september 2025.

De vorige ip-adressen van het uitgaande besturingsvlak worden nog steeds ondersteund.

Gedragswijziging voor de optie voor incrementele directoryvermeldingen van de Auto Loader

In een toekomstige Databricks Runtime-release wordt de waarde van de afgeschafte autolader cloudFiles.useIncrementalListing optie standaard ingesteld op false. Wanneer u deze waarde instelt op false, zorgt dat ervoor dat Auto Loader elke keer dat het wordt uitgevoerd, een volledige mapvermelding uitvoert. Op dit moment is de standaardwaarde van de cloudFiles.useIncrementalListing optie auto, waarbij de Auto Loader wordt geïnstrueerd om zijn uiterste best te doen om te detecteren of een incrementele lijst kan worden gebruikt met een directory.

Als u de functie voor incrementele vermeldingen wilt blijven gebruiken, stelt u de optie cloudFiles.useIncrementalListing in op auto. Wanneer u deze waarde instelt op auto, doet Auto Loader zijn uiterste best om een volledige vermelding uit te voeren na elke zeven incrementele vermeldingen, wat overeenkomt met het gedrag van deze optie vóór deze wijziging.

Zie Configureer Auto Loader-streams in directory listing-modus om meer te leren over Auto Loader directorylijstinstellingen.

Gedragswijziging wanneer gegevenssetdefinities worden verwijderd uit Lakeflow Spark-declaratieve pijplijnen

Een toekomstige release van Lakeflow Spark-declaratieve pijplijnen verandert het gedrag wanneer een gerealiseerde weergave of streamingtabel wordt verwijderd uit een pijplijn. Met deze wijziging wordt de verwijderde gerealiseerde weergave of streamingtabel niet automatisch verwijderd wanneer de volgende pijplijnupdate wordt uitgevoerd. In plaats daarvan kunt u de opdracht DROP MATERIALIZED VIEW gebruiken om een gerealiseerde weergave of de opdracht DROP TABLE te verwijderen om een streamingtabel te verwijderen. Nadat u een object hebt verwijderd, wordt het object niet automatisch hersteld door een pijplijnupdate uit te voeren. Er wordt een nieuw object gemaakt als een gerealiseerde weergave of streamingtabel met dezelfde definitie opnieuw wordt toegevoegd aan de pijplijn. U kunt echter een object herstellen met behulp van de opdracht UNDROP.

Het veld sourceIpAddress in auditlogboeken bevat geen poortnummer meer

Vanwege een fout bevatten bepaalde verificatie- en verificatiecontrolelogboeken een poortnummer naast het IP-adres in het sourceIPAddress veld (bijvoorbeeld "sourceIPAddress":"10.2.91.100:0"). Het poortnummer, dat wordt geregistreerd als 0, biedt geen echte waarde en is inconsistent met de rest van de Databricks-auditlogboeken. Om de consistentie van auditlogboeken te verbeteren, is Databricks van plan de indeling van het IP-adres voor deze auditlogboekgebeurtenissen te wijzigen. Deze wijziging wordt vanaf begin augustus 2024 geleidelijk uitgerold.

Als het auditlogboek een sourceIpAddress van 0.0.0.0 bevat, kan Databricks stoppen met loggen.