Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Os níveis de isolamento e o comportamento de conflito de escrita determinam o que acontece quando operações concorrentes leem e escrevem a mesma tabela Delta Lake no Azure Databricks.
Quando vários trabalhos ou utilizadores escrevem na mesma tabela ao mesmo tempo, algumas dessas escritas podem falhar com uma exceção de conflito. Use as páginas desta secção quando precisar:
- Resolver ou reduzir falhas causadas por escritas concorrentes, como
ConcurrentAppendException. Ver exceções de conflito. - Decida se uma tabela precisa de isolamento mais forte do que o padrão. Ver Níveis de isolamento (WriteSerializable e Serializable).
A Delta Lake garante transações ACID entre leituras e escritas:
- Escritores: Múltiplos escritores em vários clusters podem modificar simultaneamente uma partição de tabela. Os escritores veem uma vista instantânea consistente da tabela e as gravações ocorrem em uma ordem sequencial.
- Leitores: Os leitores continuam a ver uma vista instantânea consistente da tabela com que o trabalho Azure Databricks começou, mesmo quando uma tabela é modificada durante um trabalho.
Consulte Quais são as garantias ACID no Azure Databricks?
Observação
O Azure Databricks usa o Delta Lake para todas as tabelas por padrão.
Temas de isolamento
| Tópico | Descrição |
|---|---|
| Níveis de isolamento (WriteSerializable e Serializable) | Como os dois níveis de isolamento afetam as operações simultâneas e como os configurar. |
| Concorrência ao nível das linhas | Como a deteção de conflitos ao nível de linha reduz conflitos de escrita para operações concorrentes nos mesmos ficheiros de dados. |
Para informações sobre isolamento de transações, comportamento de snapshots e gestão de conflitos, consulte Isolamento de Transações.
Conflitos de alterações de metadados
Alterações aos metadados podem causar a falha de todas as operações de escrita simultâneas. Essas operações incluem alterações no protocolo da tabela, nas propriedades da tabela ou no esquema de dados.
As leituras de streaming falham quando encontram uma confirmação que altera os metadados da tabela. Se quiseres que a transmissão continue, tens de a reiniciar. Para obter os métodos recomendados, consulte Considerações de produção para streaming estruturado.
Exemplos de consultas que alteram metadados incluem:
-- Set a table property
ALTER TABLE table_name SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')
-- Enable a feature using a table property and update the table protocol
ALTER TABLE table_name SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);
-- Drop a table feature
ALTER TABLE table_name DROP FEATURE deletionVectors;
-- Upgrade to UniForm
REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));
-- Update the table schema
ALTER TABLE table_name ADD COLUMNS (col_name STRING);