Limitações conhecidas dos notebooks do Databricks

2025-08-04

Este artigo aborda as limitações conhecidas dos notebooks do Databricks. Para obter limites dos recursos adicionais, consulte Limites de recursos.

Notebook sizing

As células individuais do notebook possuem um limite de entrada de 6 MB.
O tamanho máximo do notebook para salvamento automático, importação, exportação e clonagem dos instantâneos de revisão é de 10 MB.
Você pode salvar manualmente os notebooks de até 32 MB.

Saídas de célula do notebook

Os resultados da tabela são limitados a 10.000 linhas ou 2 MB, o que for menor.
Os clusters de trabalho têm um tamanho máximo de saída do notebook de 30 MB.
No Databricks Runtime 17.0 e versões superiores, e no ambiente sem servidor 3:
- O tamanho máximo de saída da célula é definido como padrão para 10 MB.
- Esse limite pode ser personalizado em células Python para qualquer valor entre 1 MB e 20 MB (inclusive) usando a seguinte mágica de célula: %set_cell_max_output_size_in_mb <size_in_MB>. Esse limite será aplicado a todas as células do notebook.
- Quando a saída da célula excede o limite de tamanho configurado, a saída é truncada para se ajustar dentro do limite. O truncamento é aplicado de forma a preservar o máximo possível de resultado útil.
No Databricks Runtime 16.4 LTS e abaixo, e ambiente sem servidor 2 e abaixo.
- Os resultados do texto retornam um máximo de 50.000 caracteres.
- No Databricks Runtime 12.2 e posteriores, você pode aumentar esse limite até 20 MB definindo a propriedade de configuração do Spark. spark.databricks.driver.maxReplOutputLength
- Quando a saída da célula excede o limite de tamanho configurado, a saída é totalmente descartada.

Notebook debugger

Limitações do depurador do notebook:

O depurador funciona apenas com Python. Ele não dá suporte a Scala ou R.
Para acessar o depurador, seu notebook deve estar conectado a um dos seguintes recursos de computação:
- Serverless compute
- Computação com modo de acesso definido como Standard (anteriormente compartilhado) no Databricks Runtime 14.3 LTS e superior
- Computação com modo de acesso definido como Dedicado (anteriormente usuário único) no Databricks Runtime 13.3 LTS e superior
- Computação com modo de acesso definido como Sem Isolamento Compartilhado no Databricks Runtime 13.3 LTS e superior
O depurador não dá suporte à entrada em arquivos ou módulos externos.
Você não pode executar outros comandos no notebook quando uma sessão de depuração estiver ativa.
O depurador não dá suporte à depuração em subprocessos quando conectado a clusters e computação sem servidor com o modo de acesso definido como Standard.

Notebooks do SQL Warehouse

Limitações dos Notebooks do SQL Warehouses:

Quando anexados a um SQL warehouse, os contextos de execução têm um tempo limite ocioso de 8 horas.

ipywidgets

Limitações do ipywidgets:

Um notebook que usa ipywidgets precisa ser anexado a um cluster em execução.
Os estados do Widget não são preservados entre as sessões do notebook. Você precisará executar novamente as células do widget para renderizá-las sempre que anexar o notebook a um cluster.
Não há suporte para ipywidgets de senha e controlador.
Os widgets HTMLMath e Label com expressões LaTeX não são renderizados corretamente. (Por exemplo, widgets.Label(value=r'$$\frac{x+1}{x-1}$$') não é renderizado corretamente.)
Os widgets podem não ser renderizados corretamente quando o notebook está no modo escuro, principalmente os widgets coloridos.
As saídas de widget não podem ser usadas nas exibição de painel do notebook.
O tamanho máximo do conteúdo da mensagem de um ipywidget é de 5 MB. Widgets que usam imagens ou dados de texto grandes podem não ser renderizados corretamente.

Databricks widgets

Limitações dos Widgets do Databricks:

Um máximo de 512 widgets pode ser criado em um notebook.
O nome do widget está limitado a 1024 caracteres.
Um rótulo do widget está limitado a 2048 caracteres.
Um máximo de 2048 caracteres pode ser inserido em um widget de texto.
Pode haver um máximo de 1024 opções para um widget de seleção múltipla, caixa de combinação ou menu suspenso.
Há um problema conhecido em que é possível que o estado de um widget não seja limpo corretamente após clicar em Executar Todos, mesmo depois de limpar ou remover o widget no código. Se isso acontecer, você verá uma discrepância entre o visual do widget e os estados impressos. Executar novamente as células individualmente pode ignorar esse problema. Para evitar esse problema completamente, o Databricks recomenda usar ipywidgets.

Você não deve acessar o estado do widget diretamente em contextos assíncronos, como threads, subprocessos ou Fluxo Estruturado (foreachBatch), pois o estado do widget pode ser alterado enquanto o código assíncrono está em execução. Se você precisar acessar o estado do widget em um contexto assíncrono, passe-o como um argumento. Por exemplo, se você tiver o seguinte código que usa threads:

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()

Em vez disso, o Databricks recomenda usar um argumento:

# 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()

Os widgets geralmente não podem passar argumentos entre diferentes idiomas em um notebook. É possível criar um widget arg1 em uma célula do Python e usá-lo em uma célula do SQL ou Scala se você executar uma célula de cada vez. No entanto, isso não funcionará se você usar Executar todos ou executar o notebook como trabalho. Algumas soluções alternativas são:
- Para notebooks que não combinam idiomas, você pode criar um notebook para cada idioma e passar os argumentos ao executar o notebook.
- Você pode acessar o widget usando uma chamada spark.sql(). Por exemplo, em Python: spark.sql("select getArgument('arg1')").take(1)[0][0].