Co se chystá?

Seznamte se s funkcemi a změnami chování v nadcházejících verzích Azure Databricks.

Služby MCP poskytované službou Azure Databricks budou brzy obecně dostupné

Služby MCP poskytované platformou Azure Databricks pro aplikace SaaS, jako jsou Slack, GitHub, Atlassian a Google Drive, budou brzy všeobecně dostupné, přičemž operace čtení i zápisu budou ve výchozím nastavení povolené. Správci a uživatelé můžou ve službě Unity AI Gateway zakázat služby MCP a jednotlivé nástroje.

Viz Připojení agentů k nástrojům třetích stran pomocí služeb MCP.

konektor SharePoint v Lakeflow Connect bude brzy obecně dostupný.

Konektor SharePoint v Lakeflow Connect bude brzy obecně dostupný. Do Azure Databricks můžete načítat soubory a strukturovaná data z webů SharePointu pro transformaci, analýzu a navazující datové kanály.

Viz konektor SharePoint.

Konektor Google Drive v Lakeflow Connect bude brzy obecně dostupný.

Konektor Google Drive ve službě Lakeflow Connect bude brzy obecně dostupný. Soubory z Google Drive můžete načítat do Azure Databricks za účelem transformace, analýzy a navazujících datových kanálů.

Viz konektor Google Drive.

Změna výchozího editoru kanálů pro pracovní prostory s povoleným profilem zabezpečení dodržování předpisů

Editor kanálů Lakeflow je obecně dostupný od května 2026. V srpnu se stane výchozím editorem pro vývoj a ladění pipeline v pracovních prostorech s povoleným profilem zabezpečení pro dodržování předpisů. V té době se starší verze editoru odebere.

Další informace o editoru kanálů Lakeflow najdete v tématu Vývoj a ladění kanálů ETL pomocí Editoru kanálů Lakeflow. Pokud máte dotazy k tomuto přechodu, obraťte se na svůj tým účtů.

Změny chování pro průběžné úlohy a kanály

Na začátku srpna 2026 budou průběžné kanály a úlohy Lakeflow dostávat aktualizace pro zjednodušení konfigurace a správy stavu.

Průběžné kanály

Budete moci nakonfigurovat průběžný plán přímo ze stránky pipeline, včetně nastavení na úrovni úlohy, jako je výkonnostní režim. Konfigurace průběžného plánu tímto způsobem převede pipeline na nepřetržitou úlohu.

Databricks doporučuje spouštět průběžné kanály s průběžnou úlohou místo integrovaného průběžného nastavení kanálu. Když průběžná úloha zabalí kanál, úloha bude spravovat životní cyklus spuštění kanálu. Integrované průběžné nastavení se neodebere, ale nové průběžné kanály by měly používat vzor průběžné úlohy.

Průběžné úlohy

Správa stavu u kontinuálních úloh se zjednoduší. Projeví se následující zásadní změny:

• Přidání kontinuálního plánování k úloze zruší všechna aktivní spuštění bez ohledu na to, zda je plánování pozastavené, nebo nepozastavené.
• Odebrání průběžného plánu z úlohy zruší všechna aktivní spuštění.
• Spuštění pozastavené průběžné úlohy ji odblokuje.
• Pozastavení průběžné úlohy také zruší aktivní spuštění.
• Zastavení aktivního spuštění průběžné úlohy také pozastaví úlohu.

Nové pole rozhraní API jen pro čtení bude sledovat stav průběžné úlohy.

Zkontrolujte všechny automatizace nebo pracovní postupy, které spoléhají na aktuální chování průběžné úlohy, a aktualizujte je před touto verzí.

Úloha upozornění SQL v úlohách Lakeflow bude ve výchozím nastavení dostupná.

Úloha upozornění SQL v úlohách Lakeflow je obecně dostupná a bude ve výchozím nastavení dostupná ve vašem pracovním prostoru. Pomocí této úlohy vyhodnoťte výstrahu Databricks SQL jako součást úlohy Lakeflow Job. Úkol vrací svůj stav vyhodnocení jako výstupní hodnotu úkolu, takže se následující úkoly mohou větvit podle výsledku.

Viz úkol upozornění SQL pro úlohy.

Vytvoření klasického pracovního prostoru s virtuální sítí spravovanou Azure Databricks brzy přestane fungovat

V budoucí verzi Azure Databricks plánuje vyřazení klasického vytváření pracovních prostorů pomocí virtuální sítě spravované Azure Databricks. Pro nové pracovní prostory Azure Databricks doporučuje bezserverový pracovní prostor pro nejjednodušší rychlý start nebo injektáž virtuální sítě, pokud potřebujete klasický pracovní prostor. Podrobná časová osa migrace se bude sdělovat samostatně.

Viz klasickou výpočetní síť.

Zabezpečené připojení ke clusteru se brzy stane povinným pro klasické pracovní prostory.

V budoucí verzi Azure Databricks plánuje vyžadovat zabezpečené připojení clusteru pro všechny klasické pracovní prostory. Pracovní prostory vytvořené s parametrem enableNoPublicIp nastaveným na false již nebudou podporovány a tento parametr se stane povinným. Podrobná časová osa migrace se bude sdělovat samostatně.

Viz Povolení zabezpečeného připojení ke clusteru.

Nadcházející změny fakturace Azure pro OpenSharing SecureConnect

Azure Databricks bude brzy účtovat poskytovatelům využívajícím OpenSharing SecureConnect poplatky za odchozí přenos dat mezi oblastmi a přes veřejný internet.

Poplatky se účtují v případech:

• Příjemce je v jiné oblasti než úložiště poskytovatele.
• Provoz odchází do veřejného internetu.

Za příchozí přenos dat do služby SecureConnect ani za odchozí přenos dat zpět příjemcům ve stejné oblasti se neúčtují žádné poplatky.

Informace o cenách a nejčastějších dotazech najdete v tématu Přenos dat a ceny připojení.

Zerobus Ingest bude již brzy ve výchozím nastavení k dispozici v pracovních prostorech s povoleným bezpečnostním profilem pro dodržování předpisů.

Konektor Zerobus Ingest v Lakeflow Connect bude ve výchozím nastavení povolený pro pracovní prostory s povoleným profilem zabezpečení dodržování předpisů v polovině července 2026.

Zerobus Ingest je rozhraní API pro příjem dat na základě přenosu, který zapisuje data přímo do tabulek Unity Catalog Delta. Přehled konektoru Zerobus Ingest

Návrhář Lakeflow bude ve výchozím nastavení dostupný pro pracovní prostory s povoleným profilem zabezpečení dodržování předpisů.

Lakeflow Designer bude ve výchozím nastavení k dispozici v pracovních prostorech s povoleným profilem zabezpečení pro dodržování předpisů koncem července 2026.

Lakeflow Designer je vizuální prostředí bez nutnosti psaní kódu pro přípravu a transformaci dat na plátně s funkcí drag-and-drop, přičemž všechny pracovní postupy jsou podporovány produkčně připraveným kódem spravovaným pomocí Unity Catalog.

Viz Návrhář Lakeflow.

Deklarativní balíčky automatizace budou brzy ve výchozím nastavení používat modul přímého nasazení.

Od 24. července 2026 budou deklarativní balíčky automatizace ve výchozím nastavení používat modul direct deployment namísto modulu Terraform deployment. Tím se spustí migrace pro všechny balíčky, které stále používají modul pro nasazení Terraform.

Další informace o modulu přímého nasazení a migraci z modulu nasazení Terraform naleznete v tématu Migrace do přímého modulu nasazení.

Modul nasazení Terraform se nakonec odebere a už nebude dostupný.

ai_extract a ai_classify brzy bude ve výchozím nastavení k dispozici pro pracovní prostory s povoleným profilem zabezpečení dodržování předpisů.

Funkce ai_extract AI a ai_classify SQL budou ve výchozím nastavení dostupné pro pracovní prostory s povoleným profilem zabezpečení dodržování předpisů a ovládacími prvky HIPAA, HITRUST, C5 a TISAX vybranými v polovině července 2026.

Slouží ai_extract k extrakci strukturovaných polí z nestrukturovaného textu proti uživatelsky definovanému schématu. Slouží ai_classify ke klasifikaci textu do uživatelsky definovaných popisků pro směrování, označování a pracovní postupy kategorizace dokumentů. Pomocí agentů Bricks můžete také vytvořit agenta pro extrakci informací a klasifikačního agenta.

Nadcházející změna chování: Při přidávání objektů zabezpečení do pracovních prostorů zvolte oprávnění

Databricks mění způsob, jakým identity získávají oprávnění k pracovnímu prostoru. Po této změně explicitně udělujete oprávnění při přidání objektu identity do pracovního prostoru místo spoléhání na dědičnost ze systémové skupiny users. Správci pracovního prostoru se mohou zapojit od 15. června 2026 a nové chování bude vynucováno pro všechny pracovní prostory dne 14. září 2026.

Tato změna umožňuje přidávat objekty zabezpečení na jakékoli úrovni přístupu, včetně uživatelů, kteří mají pouze přístup pro využívání, aniž by automaticky dědili oprávnění k vytváření obsahu.

Co se mění

Každý pracovní prostor má dvě systémové skupiny: users, která zahrnuje všechny identity, kterým byl udělen přístup k pracovnímu prostoru, a admins, která zahrnuje správce pracovního prostoru. Každý objekt zabezpečení přidaný do pracovního prostoru v současnosti dědí oprávnění udělená users. Ve výchozím nastavení jsou tyto:

• Přístup k pracovnímu prostoru – vytváření a používání poznámkových bloků, úloh, kanálů, aplikací a dalších.
• Přístup k Databricks SQL — vytvářejte a používejte řídicí panely, agenty Genie, upozornění a další.

Po změně:

• Skupina users nebude mít žádná oprávnění. Skupina admins disponuje všemi oprávněními pracovního prostoru. Nároky obou skupin jsou uzamčené.
• Novým identitám musí být při přidání do pracovního prostoru explicitně přiřazena oprávnění.
• users a admins nelze vnořit do jiných skupin jako jejich členy.

Stávající uživatelé a skupiny si zachovají stávající úroveň přístupu. Databricks automaticky migruje oprávnění dříve udělená skupině users do nové lokální klonované skupiny pracovního prostoru s názvem users-clone-<TIMESTAMP> (kde <TIMESTAMP> označuje čas migrace). Klonovací skupinu spravujete stejně jako jakoukoli jinou místní skupinu pracovního prostoru a její název můžete přizpůsobit, když se přihlásíte v rané fázi. Skupina admins nevyžaduje migraci.

Požadovaná akce

• Pokud spravujete nároky na systémovou skupinu prostřednictvím automatizace (Terraform, rozhraní API SCIM pracovního prostoru nebo vlastních skriptů), aktualizujte pracovní postupy tak, aby cílily na standardní skupiny účtů, nikoli na systémové skupiny. Po povolení nového chování se pokusy o úpravu nároků na systémovou skupinu nezdaří.
• Pokud je users nebo admins vnořena jako člen jiné skupiny, zrušte vnoření. Při tomto novém chování není vnoření povoleno.
• Pokud synchronizace SCIM odstraní skupiny pracovního prostoru, které nerozpozná, aktualizujte její konfiguraci tak, aby se zachovala klonovaná skupina pro migraci (users-clone-<TIMESTAMP>). Pokud synchronizace odebere klonovací skupinu, objekty zabezpečení migrované do ní ztratí svá oprávnění.

Časová osa

• 15. června 2026 – Výslovný souhlas v nastavení pracovního prostoru v části Rozšířené > řízení přístupu
• 27. července 2026 – Automaticky se zapne u pracovních prostorů, které se k této funkci výslovně nepřihlásily ani ji výslovně neodmítly. Možnost vypnutí zůstává zachována.
• 14. září 2026 – Pro všechny pracovní prostory se vynucuje nové chování. Odhlášení bylo zrušeno.

Nové chování můžete spravovat z nastavení pracovního prostoru v části Rozšířené > řízení přístupu:

Před udělením souhlasu je aktivní původní chování.

Po přihlášení nebo automatickém povolení je nové chování aktivní.

Další informace najdete v článku Migrace řízení nároků k pracovnímu prostoru.

Profil zabezpečení dodržování předpisů vyžadovaný pro HIPAA, HITRUST a IRAP

Od 1. září 2026 bude nutné, aby profil zabezpečení dodržování předpisů zpracovával data chráněná v rámci HIPAA, HITRUST a IRAP.

Viz profil zabezpečení dodržování předpisů .

Nadcházející změna: Upgrade na automatické škálování LakeBase

Azure Databricks upgraduje všechny zřízené instance Lakebase na platformu automatického škálování Lakebase. Upgrady začínají v červnu 2026 pro zákazníky, kteří si je vyžádali, a zbývající upgrady instancí budou pokračovat v následujících týdnech. Správci pracovního prostoru dostanou e-mail s datem upgradu před zahájením upgradu.

Upgrade je automatický. Během přechodu se připojení krátce restartují a stávající připojovací řetězce, volání rozhraní API, balíčky deklarativní automatizace a konfigurace Terraformu budou fungovat beze změny.

Po upgradu se použijí následující změny:

• Vaše instance budou podporovat funkce automatického škálování a je možné je spravovat prostřednictvím nového uživatelského rozhraní automatického škálování i známého zřízeného uživatelského rozhraní, které zůstane dostupné do 1. září 2026.

• Každá instance získá nový řetězec připojení pro danou oblast, který zajišťuje optimalizovaný příchozí provoz:

  • Stávající připojovací řetězce: Zřízené připojovací řetězce (bez oblasti) nadále fungují prostřednictvím stávajícího příchozího Private Linku a nevyžadujíService Direct Private Link.
  • Nový regionální připojovací řetězec: Pokud používáte Private Link a připojujete se k Lakebase mimo pracovní prostor Azure Databricks, musíte nakonfigurovat příchozí Private Link pro služby náročné na výkon tak, aby používal nový regionální připojovací řetězec.

• Pokud chcete v balíčcích deklarativní automatizace a konfiguracích Terraformu používat nové funkce automatického škálování, jako je škálování na nulu, aktualizujte je tak, aby používaly sémantiku automatického škálování.

• Platí ceny Lakebase GA. S tím, jak elastický výpočetní výkon nahrazuje instance s pevnou velikostí, většina zákazníků zaznamená snížení nákladů na výpočetní prostředky.

• Funkce Forward ETL a REST API Private Preview ve službě Lakebase Provisioned jsou po upgradu zakázané. Jejich náhrady, Lakebase Change Data Feed a Data API, jsou k dispozici na platformě s automatickým škálováním.

Lakebase Autoscaling přináší automatické škálování a škálování na nulu, obnovení k určitému bodu v čase a snapshoty, plánování oken údržby, větvení databází a další vylepšení. Podrobnosti o tom, co očekávat, jaké změny a jaké akce se mají provést, najdete v tématu Upgrade na automatické škálování.

Pokud chcete požádat o urychlený upgrade nebo pokud máte dotazy, obraťte se na tým účtů nebo Azure Databricks podporu.

Databricks Runtime 19 bude používat jednotný model vydaných verzí.

Počínaje verzí 19 bude Databricks Runtime používat jednotný model vydaných verzí. Namísto více verzí funkcí (například 19.0, 19.1 a 19.2) bude mít každá hlavní verze jednu stránku s poznámkami k vydání.

Po počáteční beta verzi se každá verze Databricks Runtime spustí jako všeobecně dostupná (GA) a bude dostávat nové funkce a opravy přibližně týdně s aktualizacemi odlišenými podle data na jedné stránce. Clustery obdrží aktualizace po restartování. Po přibližně šesti měsících se verze přepíná na dlouhodobou podporu (LTS) se třemi roky podpory.

Databricks Runtime 18 je verze přechodu. Stránky k verzím funkcí 18.0, 18.1 a 18.2 zůstanou k dispozici pro historické účely a Databricks Runtime 18 LTS bude poslední sjednocenou verzí v řadě 18.x.

Power BI připojení se převedou na ADBC

Power BI plánuje v srpnu 2026 převést všechna připojení Power BI ke službě Arrow Database Connectivity (ADBC). Aby se zabránilo přerušení, doporučuje Databricks přepnout vývojové a přípravné sémantické modely na ADBC a ověřovat vaše úlohy.

Ovladač ADBC pro Power BI na Azure Databricks byl od října 2025 ve verzi Public Preview. Od února 2026 všechna nová připojení v Power BI Desktopu a služba Power BI ve výchozím nastavení používají ADBC. Stávající připojení nadále používají rozhraní ODBC, pokud je ručně neaktualizujete.

Viz Konfigurace ovladače ADBC nebo ODBC pro Power BI.

Oprávnění k objektům v pracovním prostoru budou brzy děděna ze všech skupin účtů.

V nadcházející verzi se oprávnění k objektům pracovního prostoru zdědí ze všech skupin účtů, nejen skupin, které jsou přímo přiřazené k pracovnímu prostoru. Hlavní entity budou dědit oprávnění k objektům pracovního prostoru, jako jsou úlohy, poznámkové bloky, složky, dotazy a řídicí panely, ze všech skupin účtů, jejichž jsou členy, bez ohledu na to, zda jsou tyto skupiny přiřazeny k pracovnímu prostoru. Aby mohli uživatelé tato oprávnění používat, musí být k pracovnímu prostoru stále přiřazeni.

Tato změna také aktivuje neaktivní ("osiřelá") přidělená oprávnění. Jedná se o udělení oprávnění, která zůstanou ve skupině po odebrání z pracovního prostoru. Nepřidávají se žádná nová oprávnění, ale stávající osamocené granty se stanou aktivními, což může členům pracovního prostoru umožnit neočekávaný přístup. Pokud se například skupina "Dodavatelé" odebrala z pracovního prostoru, ale stále má přístup k úpravám složky, získá přístup k této složce každý člen pracovního prostoru v části Dodavatelé.

Databricks doporučuje zkontrolovat oprávnění pracovního prostoru. Pomocí následujícího poznámkového bloku identifikujte neaktivní udělení oprávnění v pracovních prostorech:

Poznámkový blok analýzy opuštěných oprávnění

Pořiďte si notebook

Nadcházející změna narušující kompatibilitu: výchozí chování při odstraňování pipeline v katalogu Unity

V nadcházející verzi se změní výchozí chování při odstranění pipeline katalogu Unity. Odstranění kanálu v současné době také odebere všechna přidružená materializovaná zobrazení, streamované tabulky a zobrazení. Po této změně se přidružené tabulky zachovají, ale neaktivní po odebrání kanálu. Rozhraní API se také změní tak, aby ve výchozím nastavení zachovalo tabulky, ale toto cascade pole true přepíše a zachová aktuální chování.

Pole cascade je teď k dispozici. Chcete-li zachovat současné chování odebrání všech tabulek při odstraňování pipeline, aktualizujte svůj kód, aby nastavil cascade=true.

Viz Odstranění kanálu a Odstranění kanálu.

Nové výchozí povolení editoru SQL a vyřazení starší verze editoru SQL

Nový editor SQL je obecně dostupný od října 2025. V rámci přechodu na nový editor se plánují následující změny:

• Od konce května 2026: Nový editor SQL bude ve výchozím nastavení povolený pro všechny pracovní prostory. Možnost vypnout funkci na úrovni pracovního prostoru už nebude dostupná. Po zahájení tohoto období budou moct jednotliví uživatelé přepnout své dotazy na starší verzi editoru SQL.
• Od konce července 2026: Starší verze editoru SQL bude vyřazena. Všichni uživatelé budou používat nový editor SQL a individuální odhlášení už nebude k dispozici.

Další informace o novém editoru SQL najdete v tématu Psaní dotazů a zkoumání dat v novém editoru SQL. Pokud máte dotazy k tomuto přechodu, obraťte se na svůj tým účtů.

Změny v OpenSharingu (dříve Delta Sharing) – otevřené tokeny příjemců

Poznámka:

Na základě zpětné vazby zákazníků a zavedení OpenSharingu se tato změna odložila od 1. července 2026. Nové datum přechodu se aktualizuje, jakmile bude k dispozici. Nevyžaduje se okamžitá akce. Stávající adresy URL a tokeny příjemců budou dál fungovat stejně jako dnes.

Funkce OpenSharing pro otevřené příjemce přejde do nového formátu adresy URL specifického pro příjemce. Nové tokeny vytvořené po datu přechodu budou automaticky používat nový formát adresy URL. Tato změna zlepšuje zabezpečení sítě a umožňuje příjemcům konfigurovat zásady sítě specifické pro příjemce a pravidla brány firewall.

Pro Azure Čínu bude přechod oznámen později.

Nové adresy URL zahrnují ID příjemce v doméně:

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

Pro informaci, adresy URL vytvořené před touto změnou neobsahují ID příjemce a používají koncový bod Delta Sharing.

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

Staré adresy URL budou po určitou dobu fungovat. Konkrétní doba trvání závisí na typu příjemce a datu vytvoření tokenu. Zprostředkovatelé dat by měli přejít do nového formátu adresy URL předtím, než se starý formát adresy URL stane neplatným.

Sdílení federace OIDC:

Databricks doporučuje, aby poskytovatelé dat začali převádět příjemce do nového formátu adresy URL. I když se datum přechodu nenastavilo, přechod teď umožňuje čas k řešení potíží. Po přechodu můžou poskytovatelé novou adresu URL najít v uživatelském rozhraní OpenSharing. Po vyřazení původního formátu adresy URL už není platný.

Sdílení nosné tokeny:

Datum vytvoření tokenu	Formát adresy URL	Datum vypršení platnosti tokenu	Doporučená akce
Před datem přechodu	Starý formát	Jeden rok od data vytvoření nebo 8. prosince 2026, podle toho, které datum je pozdější.	Poskytovatelé dat musí před vypršením platnosti obměňovat tokeny , aby mohli migrovat do nového formátu adresy URL. Pokud chcete příjemcům poskytnout čas na migraci, nakonfigurujte časový interval výpadku nastavením data vypršení platnosti aktuálního tokenu během rotace. V tomto období jsou podporovány staré i nové formáty adres URL.
V den přechodu nebo po tomto datu	Nový formát	Podle konfigurace až jeden rok od data vytvoření.	None

Sdílení federace Lakehouse a výchozí úložiště

Delta Sharing on Lakehouse Federation je v beta verzi, což umožňuje poskytovatelům dat služby Delta Sharing sdílet cizí katalogy a tabulky. Ve výchozím nastavení musí být data dočasně materializovaná a uložená ve výchozím úložišti (Private Preview). V současné době musí uživatelé ručně povolit funkci Delta Sharing pro výchozí úložiště – Rozšířený přístup v konzole účtu, aby mohli používat sdílení Lakehouse Federation.

Po povolení Delta Sharing pro Výchozí úložiště – Rozšířený přístup ve výchozím nastavení pro všechny uživatele služby Azure Databricks, bude Delta Sharing na Lakehouse Federation automaticky dostupná v oblastech, kde je podporováno Výchozí úložiště.

Viz Výchozí úložiště v Databricks a Přidání cizích schémat nebo tabulek do sdílené složky.

Delta Sharing pro tabulky ve výchozím úložišti bude ve výchozím nastavení povoleno (beta).

Tato výchozí aktualizace úložiště pro Delta Sharing rozšířila možnosti sdílení, což poskytovatelům umožňuje sdílet tabulky zálohované výchozím úložištěm s libovolným příjemcem Delta Sharing (otevřené sdílení nebo Azure Databricks), včetně příjemců používajících klasickou výpočetní techniku. Tato funkce je aktuálně v beta verzi a vyžaduje, aby poskytovatelé ručně povolili rozdílové sdílení pro výchozí úložiště – rozšířený přístup v konzole účtu. Brzy se tato možnost povolí ve výchozím nastavení pro všechny uživatele.

Viz Omezení.

Aktualizace veřejných IP adres odchozí roviny řízení

Azure Databricks aktualizuje veřejné IP adresy řídicí roviny odchozích přenosů a značky služeb Azure pro zlepšené zabezpečení a dostupnost zón. Tyto změny jsou součástí aktualizace kontrolní roviny, která se začala zavádět 20. května 2025.

Pokud vaše organizace používá firewally prostředků pro řízení příchozího přístupu:

• Pokud pravidla brány firewall odkazují na značku Azure Databricks service, nevyžaduje se žádná akce.
• Pokud povolíte konkrétní veřejné IP adresy řídicí roviny, musíte do 26. září 2025 přidat všechny IP adresy řídicí roviny odchozích přenosů.

Předchozí IP adresy řídicí roviny pro odchozí přenosy jsou nadále podporovány.

Pole sourceIpAddress v protokolech auditu už nebude obsahovat číslo portu.

Kvůli chybě obsahují určité protokoly auditu autorizace a ověřování číslo portu kromě IP adresy v sourceIPAddress poli (například "sourceIPAddress":"10.2.91.100:0"). Číslo portu, které se protokoluje jako 0, neposkytuje žádnou skutečnou hodnotu a není konzistentní se zbývajícími protokoly auditu Databricks. Aby se zlepšila konzistence protokolů auditu, Databricks plánuje změnit formát IP adresy pro tyto události protokolu auditu. Tato změna se postupně zavede začátkem srpna 2024.

Pokud protokol auditu obsahuje hodnotu sourceIpAddress0.0.0.0, Databricks ho může přestat zapisovat.