Kända begränsningar För Databricks-notebook-filer

2025-10-04

Den här artikeln beskriver kända begränsningar för Databricks-notebook-filer. Ytterligare resursgränser finns i Resursgränser.

Notebook-storlekar

Automatisk lagring av versionsbilder, manuell lagring och kloning stöds för alla anteckningsböcker upp till 100 MB.
Import och export stöds för IPYNB-notebook-filer på upp till 100 MB.
Import och export stöds för DBC-arkiv, HTML, R Markdown och källanteckningsböcker upp till 10 MB.
Enskilda notebook-celler har en indatagräns på 6 MB.

Anteckningsbokscellernas utdata

Tabellresultat är begränsade till 10 000 rader eller 2 MB, beroende på vilket som är lägre.
Jobbkluster har en maximal utdatastorlek för notebook-filer på 30 MB.
I Databricks Runtime 17.0 och senare, och i serverless environment 3:
- Den maximala cellutdatastorleken är som standard 10 MB.
- Den här gränsen kan anpassas i Python-celler till valfritt värde mellan 1 MB och 20 MB (inklusive) med hjälp av följande cellmagi: %set_cell_max_output_size_in_mb <size_in_MB>. Den här gränsen gäller sedan för alla celler i notebook-filen.
- När cellutdata överskrider den konfigurerade storleksgränsen trunkeras utdata så att de passar inom gränsen. Trunkeringen tillämpas på ett sätt som bevarar så mycket användbara utdata som möjligt.
I Databricks Runtime 16.4 LTS och nedan, och serverlös miljö 2 och nedan:
- Textresultat returnerar högst 50 000 tecken.
- I Databricks Runtime 12.2 och senare kan du öka den här gränsen med upp till 20 MB genom att ange spark-konfigurationsegenskapen . spark.databricks.driver.maxReplOutputLength
- När cellutdata överskrider den konfigurerade storleksgränsen ignoreras utdata helt.

Notebook-felsökare

Begränsningar för notebook-felsökningsprogrammet:

Felsökningsprogrammet fungerar bara med Python. Det stöder inte Scala eller R.
För att få åtkomst till felsökningsprogrammet måste notebook vara ansluten till någon av följande beräkningsresurser:
- Serverlös databearbetning
- Beräkning med åtkomstläge inställt på Standard (tidigare delat) i Databricks Runtime 14.3 LTS och senare
- Beräkning med åtkomstläge inställt på Dedicated (tidigare enanvändare) i Databricks Runtime 13.3 LTS och senare
- Beräkning med åtkomstläge inställt på Ingen isolering (delad) i Databricks Runtime 13.3 LTS eller senare
Felsökningsprogrammet har inte stöd för att gå in i Python-bibliotek.
Du kan inte köra andra kommandon i notebook-filen när en felsökningssession är aktiv.
Felsökningsprogrammet stöder inte felsökning på underprocesser när det är anslutet till serverlös beräkning och kluster med åtkomstläge inställt på Standard.

NOTEBOOK-filer för SQL-lager

Begränsningar för NOTEBOOK-filer för SQL-lager:

När de är anslutna till ett SQL-lager har körningskontexter en tidsgräns för inaktivitet på 8 timmar.

ipywidgets

Begränsningar för ipywidgets:

En notebook-fil med ipywidgets måste vara ansluten till ett kluster som körs.
Widgettillstånd bevaras inte mellan notebook-sessioner. Du måste köra widgetceller på nytt för att återge dem varje gång du kopplar notebook-filen till ett kluster.
Ipywidgets för lösenord och kontrollant stöds inte.
HTMLMath- och Label-widgetar med LaTeX-uttryck återges inte korrekt. (Renderas till exempel widgets.Label(value=r'$$\frac{x+1}{x-1}$$') inte korrekt.)
Widgetar kanske inte återges korrekt om notebook-filen är i mörkt läge, särskilt färgade widgetar.
Widgetutdata kan inte användas i notebook-instrumentpanelvyer.
Den maximala meddelandenyttolaststorleken för en ipywidget är 5 MB. Widgetar som använder bilder eller stora textdata kanske inte återges korrekt.

Databricks-widgets

Begränsningar för Databricks-widgetar:

Högst 512 widgetar kan skapas i en notebook-fil.
Ett widgetnamn är begränsat till 1 024 tecken.
En widgetetikett är begränsad till 2 048 tecken.
Högst 2 048 tecken kan matas in till en textwidget.
Det kan finnas högst 1 024 alternativ för en widget med flera val, kombinationsrutor eller listrutor.
Det finns ett känt problem där ett widgettillstånd kanske inte rensas korrekt när du trycker på Kör alla, även efter att widgeten har rensats eller tagits bort i koden. Om detta händer ser du en avvikelse mellan widgetens visuella objekt och utskrivna tillstånd. Om du kör cellerna individuellt kan det här problemet kringgås. För att undvika det här problemet helt rekommenderar Databricks att du använder ipywidgets.

Du bör inte komma åt widgettillståndet direkt i asynkrona kontexter som trådar, underprocesser eller strukturerad direktuppspelning (foreachBatch), eftersom widgettillståndet kan ändras medan den asynkrona koden körs. Om du behöver komma åt widgettillståndet i en asynkron kontext skickar du in det som ett argument. Om du till exempel har följande kod som använder trådar:

import threading

def thread_func():
  # Unsafe access in a thread
  value = dbutils.widgets.get('my_widget')
  print(value)

thread = threading.Thread(target=thread_func)
thread.start()
thread.join()

Databricks rekommenderar att du använder ett argument i stället:

# Access widget values outside the asynchronous context and pass them to the function
value = dbutils.widgets.get('my_widget')

def thread_func(val):
  # Use the passed value safely inside the thread
  print(val)

thread = threading.Thread(target=thread_func, args=(value,))
thread.start()
thread.join()

Widgetar kan vanligtvis inte skicka argument mellan olika språk i en notebook-fil. Du kan skapa en widget arg1 i en Python-cell och använda den i en SQL- eller Scala-cell om du kör en cell i taget. Detta fungerar dock inte om du använder Kör alla eller kör notebook-filen som ett jobb. Några lösningar är:
- För notebook-filer som inte blandar språk kan du skapa en notebook-fil för varje språk och skicka argumenten när du kör notebook-filen.
- Du kan komma åt widgeten med hjälp av ett spark.sql() anrop. Till exempel i Python: spark.sql("select getArgument('arg1')").take(1)[0][0].

Feedback

Var den här sidan till hjälp?