Disponibilize dados lakehouse com tabelas sincronizadas.

As tabelas sincronizadas permitem que você disponibilize dados lakehouse por meio do Lakebase Postgres. As tabelas Unity Catalog são sincronizadas com o Postgres, permitindo que os aplicativos consultem os dados lakehouse diretamente com baixa latência. Esse processo é comumente conhecido como ETL reverso. O lakehouse é otimizado para análises e enriquecimento de dados, enquanto o Lakebase foi projetado para cargas de trabalho operacionais que exigem consultas rápidas no estilo de pesquisa e consistência transacional.

Diagrama de arquitetura mostrando o fluxo de dados do lakehouse para o Lakebase e, em seguida, para os aplicativos.

O que são tabelas sincronizadas?

As tabelas sincronizadas permitem que você forneça dados de nível analítico do Unity Catalog por meio Lakebase Postgres, disponibilizando-os para aplicativos que precisam de consultas de baixa latência e ACID completo. Eles preenchem a lacuna entre o armazenamento analítico e os sistemas operacionais, mantendo seus dados prontos para uso em aplicações em tempo real.

Fontes compatíveis

As tabelas sincronizadas são compatíveis com os seguintes tipos de origem Unity Catalog :

gerenciamento e tabelas Delta externas
gerenciar e mesas Iceberg externas
vista e vista materializada

Como funciona

As tabelas sincronizadas Databricks criam uma cópia gerenciada dos dados do seu Unity Catalog no Lakebase. Ao criar uma tabela sincronizada, você obtém:

Uma tabela sincronizada no Unity Catalog que faz referência ao pipelinede sincronização.
Uma tabela Postgres no Lakebase (somente leitura, consultável por seus aplicativos)

Diagrama mostrando a relação entre as três tabelas em tabelas sincronizadas.

Por exemplo, você pode sincronizar tabelas ouro, recursos projetados ou saídas ML de analytics.gold.user_profiles em uma nova tabela sincronizada analytics.gold.user_profiles_synced. No Postgres, o nome do esquema do Unity Catalog torna-se o nome do esquema do Postgres, portanto, isso aparece como gold.user_profiles_synced:

SQL
SELECT * FROM gold.user_profiles_synced WHERE user_id = 12345;

Os aplicativos se conectam com drivers padrão do Postgres e consultam os dados sincronizados juntamente com seu próprio estado operacional.

atenção

Embora seja possível modificar uma tabela sincronizada diretamente no Postgres, Databricks recomenda enfaticamente a execução apenas de consultas de leitura para proteger a integridade dos dados com a fonte. Para obter informações sobre as operações suportadas em tabelas sincronizadas, consulte a lista de operações permitidas em tabelas sincronizadas no Postgres.

Pipelines de sincronização usam Lakeflow pipelines gerenciados para atualizar continuamente tanto a tabela sincronizada do Unity Catalog quanto a tabela Postgres com as alterações da tabela de origem. Cada sincronização pode usar até 16 conexões para o seu banco de dados Lakebase.

O Lakebase Postgres suporta até 1.000 conexões simultâneas com garantias transacionais, permitindo que os aplicativos leiam e enriqueçam dados enquanto também lidam com inserções, atualizações e exclusões no mesmo banco de dados.

Sincronização inicial acelerada

O LTAP Direct Writes é um recurso beta da arquitetura LTAP que reduz o tempo necessário para carregamentos iniciais e full refresh. Ele carrega dados diretamente na camada de armazenamento que suporta sua branch do Lakebase em vez de rotear a gravação em massa pelo endpoint de compute ativo. Como resultado, carregamentos grandes terminam mais rápido e não adicionam carga de query ao endpoint enquanto são executados.

A funcionalidade LTAP Direct Writes acelera a carga inicial para cada modo de sincronização . Toda tabela sincronizada começa carregando uma cópia completa da origem, e essa primeira carga usa LTAP Direct Writes, independentemente de você escolher o modo Snapshot , Triggered ou Continuous . Ele também acelera refresh completo, incluindo as cargas completas recorrentes que o modo Snapshot executa em cada sincronização subsequente.

nota

O LTAP Direct Writes não se limita ao modo Snapshot . Todo modo de sincronização obtém uma carga inicial acelerada. O modo Snapshot obtém adicionalmente um refresh completo acelerado em cada sincronização subsequente, enquanto os modos Triggered e Continuous aplicam atualizações posteriores incrementalmente por meio do Change Data Feed, em vez de cargas em massa.

O LTAP Direct Writes está em beta e requer um projeto Lakebase executando o Postgres 17. Para usá-lo, um administrador do workspace ativa a prévia do LTAP Direct Writes na página Pré-visualizações nas configurações do workspace.

Modos de sincronização

Escolha o modo de sincronização adequado com base nas necessidades da sua aplicação:

Mode	Descrição	Quando usar	Desempenho
Snapshot	Cópia única de todos os dados	Alterações na origem > 10% das linhas por ciclo	10 vezes mais eficiente se modificar mais de 10% dos dados de origem.
Acionado	Atualizações programadas que são executadas sob demanda ou em intervalos regulares.	As linhas de origem mudam em uma cadência conhecida. Inserções, atualizações e exclusões são propagadas a cada refresh.	Bom equilíbrio entre custo e atraso. Caro se a execução intervalos de <5min
Contínuo	tempo real transmissão com segundos de latência	As alterações devem aparecer no Lakebase em tempo real quase instantâneo.	Menor latência, maior custo. Intervalos mínimos de 15 segundos

Mode	Descrição	Quando usar	Desempenho
Snapshot	Cópia única de todos os dados	Alterações na origem > 10% das linhas por ciclo	10 vezes mais eficiente se modificar mais de 10% dos dados de origem.
Acionado	Atualizações programadas que são executadas sob demanda ou em intervalos regulares.	As linhas de origem mudam em uma cadência conhecida. Inserções, atualizações e exclusões são propagadas a cada refresh.	Bom equilíbrio entre custo e atraso. Caro se a execução intervalos de <5min
Contínuo	tempo real transmissão com segundos de latência	As alterações devem aparecer no Lakebase em tempo real quase instantâneo.	Menor latência, maior custo. Intervalos mínimos de 15 segundos

O requisito da fonte depende do modo de sincronização:

O Snapshot copia todos os dados a cada sincronização, portanto, a fonte só precisa ser compatível com SELECT *.
Triggered e Continuous aplicam alterações em nível de linha incrementalmente, portanto, a origem deve fornecer um change data feed. Ative o change data feed no momento da gravação na origem ou use o change data feed automático. Se uma origem Trigger ou Continuous não tiver um change data feed, a interface mostrará um aviso com o comando ALTER TABLE exato a ser executado.

O Automatic change data feed (prévia pública) calcula as alterações em nível de linha no momento da leitura, em vez de exigir o change data feed no momento da gravação na origem. Isso permite que mais tipos de origem, incluindo tabelas Apache Iceberg e views materializadas , sejam sincronizados no modo Triggered ou Continuous . Para os tipos de origem compatíveis com o Automatic change data feed, consulte a documentação do Automatic change data feed.

O feed de dados de alterações automático para tabelas sincronizadas está em visualização. Enquanto estiver em visualização, conclua dois passos extras:

Ative a prévia. Um administrador do workspace ativa a prévia do Automatic change data feed na página Pré-visualizações nas configurações do workspace.
Defina o canal do pipeline como preview. Ao criar a tabela sincronizada, defina o canal do pipeline como PREVIEW. Esta opção está disponível atualmente apenas por meio da API:
JSON
```
{
  "spec": {
    "new_pipeline_spec": {
      "pipeline_channel": "PREVIEW"
    }
  }
}
```

Exemplos de casos de uso

Você pode usar tabelas sincronizadas para casos de uso de fornecimento de dados, como:

Mecanismos de personalização que fornecem perfis de usuário atualizados para Databricks Apps
Aplicações que servem para previsões de modelos ou valores de recursos são computadas na lakehouse
Painéis de controle voltados para o cliente que exibem KPIs em tempo real.
Serviço de detecção de fraudes que fornece pontuações de risco para ação imediata.
Ferramentas de suporte que fornecem registros de clientes enriquecidos a partir de dados lakehouse .

Criar uma tabela sincronizada

Pré-requisitos

Você precisa de:

Um workspace Databricks com o Lakebase ativado.
Um projeto Lakebase (consulte Criar um projeto).
Uma tabela Unity Catalog para sincronizar.
Permissões para criar tabelas sincronizadas. Você precisa de USE_SCHEMA e CREATE_TABLE em qualquer esquema que utilizar.

Para os modos Triggered ou Continuous , a origem deve fornecer um feed de dados de alterações. Habilite o feed de dados de alterações em tempo de gravação em uma tabela de origem Delta qualificada ou use Feed de dados de alterações automático para fontes como tabelas Apache Iceberg e views materializadas. O feed de dados de alterações automático está em Visualização Pública e requer a configuração extra descrita em Modos de sincronização.

Para ativar o feed de dados alterados em tempo de gravação em uma tabela de origem Delta, execute:

SQL
ALTER TABLE your_catalog.your_schema.your_table
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)

Para planejamento de capacidade e compatibilidade de tipos de dados, consulte Tipos de dados e compatibilidade e Planejamento de capacidade.

UI
CLI
Python SDK
Java SDK
curl

Acesse o Catálogo na barra lateral workspace e selecione a tabela Unity Catalog que deseja sincronizar.
Na view de detalhes da tabela, clique em Criar > Tabela sincronizada .
Na caixa de diálogo Criar tabela sincronizada :

As listas de catálogo e esquema incluem apenas os esquemas do Unity Catalog nos quais o usuário atual possui privilégios USE_SCHEMA e CREATE_TABLE . Se você não encontrar o esquema esperado, confirme suas permissões com o administrador do catálogo.
1. Nome da tabela : Insira um nome para a sua tabela sincronizada (ela será criada no mesmo catálogo e esquema que a sua tabela de origem). Isso cria uma tabela sincronizada com Unity Catalog e uma tabela do Postgres que você pode consultar.
2. Tipo de banco de dados : Escolha Lakebase serverless (autoscale) .
3. Modo de sincronização : Escolha Snapshot , Acionado ou Contínuo, de acordo com suas necessidades (consulte os modos de sincronização acima).
4. Configure seu projeto, ramificação e seleções de banco de dados.
5. Verifique se a keyprimária está correta (geralmente detectada automaticamente).

importante

As colunas da key primária não podem ser nulas na tabela sincronizada. As linhas com valores nulos nas colunas key primária são excluídas da sincronização .

(Opcional) Se duas linhas puderem compartilhar a mesma key primária na tabela de origem, selecione uma keyde série temporal para configurar a desduplicação. Quando uma key de série temporal é especificada, a tabela sincronizada contém apenas a linha com o valor key de série temporal mais recente para cada key primária. Para o modo de falha sem uma key de série temporal, consulte Chave duplicada.

Se você selecionou o modo Acionado ou Contínuo e ainda não ativou a opção Alterar Feed de Dados, verá um aviso com o comando exato a ser executado. Para questões de compatibilidade de tipos de dados, consulte Tipos de dados e compatibilidade.

Clique em Criar para criar a tabela sincronizada. 4. Monitore a tabela sincronizada no Catálogo . A tab Visão geral mostra o status da sincronização, a configuração, o status pipeline e o registro de data e hora da última sincronização. Use a opção Sincronizar agora para refresh manual.

Bash
databricks postgres create-synced-table my-catalog.sales.orders \
  --json '{
    "spec": {
      "source_table_full_name": "main.sales.orders",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["order_id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true
    }
  }'

O argumento posicional SYNCED_TABLE_ID usa o formato catalog.schema.table. No Postgres, a tabela {table} é criada no esquema {schema}, dentro do banco de dados que você definiu com postgres_database (aqui, mydb). Por default, o comando espera a operação ser concluída. Para todas as opções disponíveis, consulte databricks postgres create-synced-table.

Python
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.postgres import (
    SyncedTable,
    SyncedTableSyncedTableSpec,
    SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy,
)

w = WorkspaceClient()

synced_table = w.postgres.create_synced_table(
    synced_table=SyncedTable(spec=SyncedTableSyncedTableSpec(
        source_table_full_name="main.sales.orders",
        branch="projects/my-project/branches/production",
        primary_key_columns=["order_id"],
        scheduling_policy=SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy.SNAPSHOT,
        postgres_database="mydb",
        create_database_objects_if_missing=True,
    )),
    synced_table_id="my-catalog.sales.orders",
).wait()

print(f"Synced table created: {synced_table.name}")

O synced_table_id usa o formato catalog.schema.table e se torna o nome da tabela sincronizada Unity Catalog . No Postgres, a tabela {table} é criada no esquema {schema}, dentro do banco de dados que você definiu com postgres_database (aqui, mydb).

Java
import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.postgres.*;
import java.util.List;

WorkspaceClient w = new WorkspaceClient();

SyncedTable syncedTable = w.postgres().createSyncedTable(
    new CreateSyncedTableRequest()
        .setSyncedTableId("my-catalog.sales.orders")
        .setSyncedTable(new SyncedTable()
            .setSpec(new SyncedTableSyncedTableSpec()
                .setSourceTableFullName("main.sales.orders")
                .setBranch("projects/my-project/branches/production")
                .setPrimaryKeyColumns(List.of("order_id"))
                .setSchedulingPolicy(SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy.SNAPSHOT)
                .setPostgresDatabase("mydb")
                .setCreateDatabaseObjectsIfMissing(true))))
    .waitForCompletion();

System.out.println("Synced table created: " + syncedTable.getName());

Bash
curl -X POST "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables?synced_table_id=my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "source_table_full_name": "main.sales.orders",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["order_id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true
    }
  }'

Isso retorna uma operação de longa duração. Consulte o campo retornado name até done: true. Veja Operações de longa duração. Para configurar a autenticação, consulte Autenticação.

programar ou acionar sincronizações subsequentes

A execução inicial do Snapshot ocorre automaticamente na criação do sistema. Nos modos Snapshot e Acionado , as sincronizações subsequentes devem ser acionadas explicitamente. O modo contínuo é autogerenciável.

tarefa pipeline sincronização de tabela de banco de dados

A tarefa pipelinesincronização de tabela de banco de dados em LakeFlow Jobs executa um pipeline de tabela sincronizada como um fluxo de trabalho ou passo. Configure a tarefa com um gatilho de atualização de tabela ou um gatilho programático.

Acionar gatilho em atualizações da tabela de origem

Executa a tarefa quando a tabela de origem Unity Catalog é atualizada. Com o modo Acionado , apenas as novas alterações são aplicadas incrementalmente, proporcionando atualizações quase em tempo real sem o custo de estar sempre ativo do modo Contínuo.

Na barra lateral, clique em fluxo de trabalho .
Clique em Criar trabalho ou abra um trabalho existente.
Na tab de tarefas , clique em + Adicionar outro tipo de tarefa .
Em Ingestão e transformações , selecione pipelinede sincronização de tabela de banco de dados .
No campo "pipeline" , selecione o pipeline associado à sua tabela sincronizada.
Em Programar e Gatilhos , clique em Adicionar gatilho .
Selecione Atualização de tabela como o tipo de gatilho.
Em Tabelas , selecione a tabela Unity Catalog de origem que deseja monitorar.
Clique em Salvar .

Acionar em um programa

execução da sincronização em uma cadência fixa. Ideal para o modo Snapshot , onde uma refresh completa noturna ou semanal costuma ser o padrão mais eficiente.

Siga as etapas 1 a 5 acima para adicionar uma tarefa pipelinesincronização de tabela de banco de dados a um trabalho.
Em Programar e Gatilhos , clique em Adicionar gatilho .
Selecione "Agendado" como o tipo de gatilho.
Configure seu agendador cron e fuso horário e clique em Salvar .

Verificar status de sincronização

Para verificar o estado atual e a última hora de sincronização de uma tabela sincronizada:

UI
Python SDK
Java SDK
curl

No Catálogo , navegue até a tabela sincronizada e selecione a tab Visão geral . Mostra o estado de sincronização atual, o status do pipeline e o registro de data e hora da última sincronização.

Python
from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

table = w.postgres.get_synced_table("synced_tables/my-catalog.sales.orders")
print(f"State: {table.status.detailed_state}")
print(f"Last sync: {table.status.last_sync_time}")
print(f"Message: {table.status.message}")

Java
import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.postgres.SyncedTable;

WorkspaceClient w = new WorkspaceClient();

SyncedTable table = w.postgres().getSyncedTable("synced_tables/my-catalog.sales.orders");
System.out.println("State: " + table.getStatus().getDetailedState());
System.out.println("Last sync: " + table.getStatus().getLastSyncTime());
System.out.println("Message: " + table.getStatus().getMessage());

Bash
curl "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables/my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Tipos de dados e compatibilidade

Os tipos de dados do Unity Catalog são mapeados para os tipos do Postgres ao criar tabelas sincronizadas. Tipos complexos (ARRAY, MAP, STRUCT) são armazenados como JSONB no Postgres.

Tipo de coluna de origem	tipo de coluna do Postgres
BigInt	BigInt
binário	BYTEA
Booleana	Booleana
Data	Data
DECIMAL(p,s)	NUMÉRICO
double	DUPLA PRECISÃO
Float	REAL
INT	Integer
INTERVALO	INTERVALO
INT PEQUENA	INT PEQUENA
String	TEXT
Timestamp	CARIMBO DE DATA E HORA COM FUSO HORÁRIO
TIMESTAMP_NTZ	CARIMBO DE DATA E HORA SEM FUSO HORÁRIO
TINYINT	INT PEQUENA
ARRAY<elementType>	JSONB
MAPA<tipoDeChave,tipoDeValor>	JSONB
ESTRUTURA<nomeDoCampo:tipoDoCampo[, ...]>	JSONB

Tipo de coluna de origem	tipo de coluna do Postgres
BigInt	BigInt
binário	BYTEA
Booleana	Booleana
Data	Data
DECIMAL(p,s)	NUMÉRICO
double	DUPLA PRECISÃO
Float	REAL
INT	Integer
INTERVALO	INTERVALO
INT PEQUENA	INT PEQUENA
String	TEXT
Timestamp	CARIMBO DE DATA E HORA COM FUSO HORÁRIO
TIMESTAMP_NTZ	CARIMBO DE DATA E HORA SEM FUSO HORÁRIO
TINYINT	INT PEQUENA
ARRAY<elementType>	JSONB
MAPA<tipoDeChave,tipoDeValor>	JSONB
ESTRUTURA<nomeDoCampo:tipoDoCampo[, ...]>	JSONB

nota

Os tipos GEOGRAPHY, GEOMETRY, VARIANT e OBJECT não são suportados.

Mapeamentos de tipos personalizados

Ao criar uma tabela sincronizada, você pode substituir o mapeamento de tipo Delta-para-Postgres default para colunas específicas com type_overrides.

nota

Os tipos vector e halfvec exigem uma extensão vetorial na base de dados de destino. A criação da tabela sincronizada não instala extensões, portanto, instale uma antes de criar a tabela sincronizada. Use lakebase_vector, que adiciona pesquisa vetorial de rede neurais artificiais (ANN) por meio do Lakebase Search e instala o pgvector como uma dependência:

SQL
CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;

Para usar os tipos vector e halfvec sem o Lakebase Search, instale o pgvector separadamente com CREATE EXTENSION IF NOT EXISTS vector;. O tipo varchar não requer nenhuma extensão.

Tipo de coluna de origem	Tipo Postgres	Tamanho	Definição (`pg_type`)	Exemplo de caso de uso
`ARRAY<FLOAT>`, `ARRAY<DOUBLE>`	`vector(n)`	Dimensão de incorporação	`PG_SPECIFIC_TYPE_VECTOR`	Armazene as incorporações como um `vector` em vez de `JSONB`, pronto para pesquisa de similaridade com lakebase_vector
`ARRAY<FLOAT>`, `ARRAY<DOUBLE>`	`halfvec(n)`	Dimensão de incorporação	`PG_SPECIFIC_TYPE_HALFVEC`	Incorporações de meia precisão com aproximadamente metade do armazenamento de `vector`
`STRING`	`varchar(n)`	Comprimento máximo	`PG_SPECIFIC_TYPE_VARCHAR`	Mapear para um `varchar` com limite de comprimento em vez do default `TEXT`

Tipo de coluna de origem	Tipo Postgres	Tamanho	Definição (`pg_type`)	Exemplo de caso de uso
`ARRAY<FLOAT>`, `ARRAY<DOUBLE>`	`vector(n)`	Dimensão de incorporação	`PG_SPECIFIC_TYPE_VECTOR`	Armazene as incorporações como um `vector` em vez de `JSONB`, pronto para pesquisa de similaridade com lakebase_vector
`ARRAY<FLOAT>`, `ARRAY<DOUBLE>`	`halfvec(n)`	Dimensão de incorporação	`PG_SPECIFIC_TYPE_HALFVEC`	Incorporações de meia precisão com aproximadamente metade do armazenamento de `vector`
`STRING`	`varchar(n)`	Comprimento máximo	`PG_SPECIFIC_TYPE_VARCHAR`	Mapear para um `varchar` com limite de comprimento em vez do default `TEXT`

nota

size é obrigatório para cada tipo nesta tabela. Os intervalos válidos são:

vector e halfvec: 1 a 16.000, o número de dimensões de incorporação.
varchar: 1 a 10.485.760, o comprimento máximo de caracteres.

Os mapeamentos de tipo personalizados são configuráveis por meio da API, CLI e SDKs do Databricks ao criar uma tabela sincronizada.

Para uma tabela de origem main.docs.chunks(id BIGINT, title STRING, embedding ARRAY<FLOAT>), o seguinte mapeia title para varchar(256) e embedding para vector(1024) no Postgres:

Bash
databricks postgres create-synced-table main.docs.chunks_pg \
  --json '{
    "spec": {
      "source_table_full_name": "main.docs.chunks",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true,
      "type_overrides": [
        { "column_name": "title", "pg_type": "PG_SPECIFIC_TYPE_VARCHAR", "size": 256 },
        { "column_name": "embedding", "pg_type": "PG_SPECIFIC_TYPE_VECTOR", "size": 1024 }
      ]
    }
  }'

Sem a substituição, title seria TEXT e embedding seria JSONB.

Lidar com caracteres inválidos

Certos caracteres, como bytes nulos (0x00), são permitidos em strings Unity Catalog , colunas ARRAY, MAP ou STRUCT, mas não são suportados em colunas TEXT ou JSONB do Postgres. Isso pode causar falhas de sincronização com erros como:

ERROR: invalid byte sequence for encoding "UTF8": 0x00
ERROR: unsupported Unicode escape sequence DETAIL: \u0000 cannot be converted to text

O primeiro erro ocorre quando um byte nulo aparece em uma coluna de strings de nível superior, que mapeia diretamente para Postgres TEXT.
O segundo erro ocorre quando um byte nulo aparece em strings aninhadas dentro de um tipo complexo (STRUCT, ARRAY, ou MAP), que é serializado como JSONB. Durante a serialização, todas as strings são convertidas para Postgres TEXT, onde \u0000 não é permitido.

soluções:

Higienizar campos de texto : Remover caracteres não suportados antes da sincronização. Para bytes nulos em colunas de strings:
SQL
```
SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table
```
Converter para BINÁRIO : Para colunas de strings onde a preservação dos bytes brutos é necessária, converta para o tipo BINÁRIO.

Planejamento de capacidade

Ao planejar a implementação de suas tabelas sincronizadas, considere estes requisitos de recursos:

Uso da conexão : cada tabela sincronizada usa até 16 conexões com seu banco de dados Lakebase, que contam para o limite de conexão do projeto.
**Cota de tamanho**: O total de dados lógicos em todas as tabelas sincronizadas tem uma cota de 16 TB. Entre em contato com o suporte da Databricks se precisar de uma cota maior. Tabelas individuais não têm uma cota, mas a Databricks recomenda não exceder 1 TB para tabelas que exigem refresh.
Tamanho do full-refresh : Ao acionar um full-refresh, a versão antiga no Postgres não é excluída até que a nova sincronização seja concluída. Ambas as versões contam temporariamente para a cota de tamanho do banco de dados lógico durante o refresh.
Tabelas por origem : Uma única tabela de origem pode ter até 20 tabelas sincronizadas.
Requisitos de nomenclatura : Os nomes de banco de dados, esquema e tabela podem conter apenas caracteres alfanuméricos e sublinhados ([A-Za-z0-9_]+).
Orientações sobre identificação da fonte : Evite usar letras maiúsculas ou caracteres especiais em nomes de colunas ou tabelas na tabela de origem Unity Catalog . Se você os mantiver, deverá citar esses identificadores ao referenciá-los no Postgres.
Evolução do esquema : Somente alterações aditivas de esquema (como a adição de colunas) são suportadas nos modos Acionado e Contínuo.
Alteração da definição da tabela : a atualização da definição de uma tabela sincronizada no local não é suportada por meio de nenhuma interface (UI, SDKs, CLI, API REST, Terraform ou DABs). Para alterar a chave primária ou a chave da série temporal, ou para fazer uma alteração de esquema não aditiva, exclua a tabela sincronizada e crie uma nova.
Chave duplicada : Se duas linhas tiverem a mesma key primária na tabela de origem, o pipeline de sincronização falhará, a menos que você configure a desduplicação usando uma keyde série temporal.
Idempotência da API : As APIs de tabelas sincronizadas são idempotentes, portanto, tentam novamente em caso de erros transitórios para garantir operações em tempo hábil.
Taxa de atualização : Para o Lakebase, o pipeline de sincronização suporta gravações contínuas e com Trigger a aproximadamente 150 linhas por segundo por Unidade de Capacidade (CU) e gravações de Snapshot a até 2.000 linhas por segundo por CU.

operações permitidas em tabelas sincronizadas no Postgres

A Databricks recomenda que, para evitar sobrescritas acidentais ou inconsistências de dados, sejam realizadas apenas as seguintes operações no Postgres para tabelas sincronizadas:

Consultas somente leitura
Criação de índices
Excluindo a tabela (para liberar espaço após remover a tabela sincronizada do Unity Catalog)

Embora seja possível modificar tabelas sincronizadas no Postgres de outras maneiras, isso interfere no pipeline de sincronização.

Propriedade e permissões

Uma tabela sincronizada pertence à função interna databricks_writer_<dbid>, e não ao usuário que a criou, porque o pipeline de sincronização a gerencia (consulte funções do Postgres). Comandos somente para o proprietário, como a configuração de segurança em nível de linha, não podem ser executados diretamente em uma tabela sincronizada.

nota

Esta é uma exceção à regra geral do Postgres, onde os objetos que você cria são de propriedade da sua identidade Databricks, caso seu login exista como uma função no Postgres. O pipeline cria tabelas sincronizadas em seu nome.

Acesso para o usuário que cria uma tabela sincronizada

Quando você cria uma tabela sincronizada, sua identidade Databricks recebe acesso automaticamente para usá-la. Nenhuma ação databricks_superuser é necessária. Sua identidade recebe os seguintes privilégios na tabela sincronizada:

Objeto	Privilégios	Propósito
Tabela Sincronizada	`SELECT`, `DELETE`, `TRUNCATE`	Ler ou limpar a tabela
Esquema	`USAGE`, `CREATE`	Usar o esquema e criar objetos, como índices

Não lhe foi concedido INSERT nem UPDATE. O pipeline é proprietário dos dados da tabela, então as gravações diretas são substituídas no próximo refresh. DELETE e TRUNCATE apenas limpam a tabela. O próximo refresh repreenche a tabela a partir da origem.

Este acesso é derivado das permissões do Unity Catalog na tabela sincronizada e é gerenciado no Unity Catalog. Para alterar, atualize as permissões do usuário no Unity Catalog. Não é possível REVOKE isso a partir de uma identidade Databricks diretamente no Postgres.

nota

Este acesso está vinculado à identidade que criou a tabela sincronizada. Alterar a identidade de Executar como do pipeline não a reatribui. Para usar uma identidade proprietária diferente, recrie a tabela sincronizada sob essa identidade.

gerenciar acesso sincronizado à tabela

Após a criação de uma tabela sincronizada, o databricks_superuser pode ler uma tabela sincronizada do Postgres. O databricks_superuser tem pg_read_all_data, o que permite que esta função leia de todas as tabelas. Também possui o privilégio pg_write_all_data , que permite que esta função escreva em todas as tabelas. Isso significa que um databricks_superuser também pode escrever em uma tabela sincronizada no Postgres. O Lakebase oferece suporte a esse comportamento de gravação caso você precise fazer alterações urgentes na sua tabela de destino. No entanto, a Databricks recomenda que você faça as correções na sua tabela de origem.

O databricks_superuser também pode conceder esses privilégios a outros usuários:

SQL
GRANT USAGE ON SCHEMA synced_table_schema TO user;

SQL
GRANT SELECT ON synced_table_name TO user;

O databricks_superuser pode revogar esses privilégios:

SQL
REVOKE USAGE ON SCHEMA synced_table_schema FROM user;

SQL
REVOKE {SELECT | INSERT | UPDATE | DELETE} ON synced_table_name FROM user;

gerenciamento de operações de tabela sincronizada

O databricks_superuser pode gerenciar quais usuários estão autorizados a executar operações específicas em uma tabela sincronizada. As operações suportadas para tabelas sincronizadas são:

CREATE INDEX
ALTER INDEX
DROP INDEX
DROP TABLE

Todas as outras operações DDL são negadas para tabelas sincronizadas.

Para conceder esses privilégios a usuários adicionais, o databricks_superuser deve primeiro criar uma extensão em databricks_auth:

SQL
CREATE EXTENSION IF NOT EXISTS databricks_auth;

Então, o databricks_superuser pode adicionar um usuário para gerenciar uma tabela sincronizada:

SQL
SELECT databricks_synced_table_add_manager('"synced_table_schema"."synced_table"'::regclass, '[user]');

O databricks_superuser pode remover um usuário do gerenciamento de uma tabela sincronizada:

SQL
SELECT databricks_synced_table_remove_manager('[table]', '[user]');

O databricks_superuser pode view todos os gerentes:

SQL
SELECT * FROM databricks_synced_table_managers;

Excluir uma tabela sincronizada

Excluir uma tabela sincronizada do Unity Catalog também exclui a tabela Postgres correspondente.

UI
Python SDK
Java SDK
curl

No Catálogo , encontre sua tabela sincronizada e clique em menu e selecione Excluir .

Python
from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

w.postgres.delete_synced_table("synced_tables/my-catalog.sales.orders").wait()

Java
import com.databricks.sdk.WorkspaceClient;

WorkspaceClient w = new WorkspaceClient();

w.postgres().deleteSyncedTable("synced_tables/my-catalog.sales.orders").waitForCompletion();

Bash
curl -X DELETE "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables/my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Saber mais

Tarefa	Descrição
Criar um projeto	Configure um projeto Lakebase
Conecte-se ao seu banco de dados.	Conheça as opções de conexão para o Lakebase.
banco de dados de registro no Unity Catalog	Torne seus dados do Lakebase visíveis no Unity Catalog para governança unificada e consultas entre fontes de dados.
Integração com o Unity Catalog	Compreender a governança e as permissões

Tarefa	Descrição
Criar um projeto	Configure um projeto Lakebase
Conecte-se ao seu banco de dados.	Conheça as opções de conexão para o Lakebase.
banco de dados de registro no Unity Catalog	Torne seus dados do Lakebase visíveis no Unity Catalog para governança unificada e consultas entre fontes de dados.
Integração com o Unity Catalog	Compreender a governança e as permissões

Integração de catálogo

Duplicação de catálogo: A criação de uma tabela sincronizada em um catálogo padrão direcionado a um banco de dados Postgres que também está registrado como um catálogo de banco de dados separado faz com que a tabela sincronizada apareça no Unity Catalog tanto no catálogo padrão quanto no catálogo de banco de dados.

Outras opções

Para sincronizar dados com sistemas que não sejam Databricks, consulte as soluções de ETL reverso do Partner Connect, como Census ou Hightouch.

O que são tabelas sincronizadas?​

Fontes compatíveis​

Como funciona​

Sincronização inicial acelerada​

Modos de sincronização​

Exemplos de casos de uso​

Criar uma tabela sincronizada​

Pré-requisitos​

programar ou acionar sincronizações subsequentes​

tarefa pipeline sincronização de tabela de banco de dados​

Acionar gatilho em atualizações da tabela de origem​

Acionar em um programa​

Verificar status de sincronização​

Tipos de dados e compatibilidade​

Mapeamentos de tipos personalizados​

Lidar com caracteres inválidos​

Planejamento de capacidade​

operações permitidas em tabelas sincronizadas no Postgres​

Propriedade e permissões​

Acesso para o usuário que cria uma tabela sincronizada​

gerenciar acesso sincronizado à tabela​

gerenciamento de operações de tabela sincronizada​

Excluir uma tabela sincronizada​

Saber mais​

Integração de catálogo​

Outras opções​

O que são tabelas sincronizadas?

Fontes compatíveis

Como funciona

Sincronização inicial acelerada

Modos de sincronização

Exemplos de casos de uso

Criar uma tabela sincronizada

Pré-requisitos

programar ou acionar sincronizações subsequentes

tarefa pipeline sincronização de tabela de banco de dados

Acionar gatilho em atualizações da tabela de origem

Acionar em um programa

Verificar status de sincronização

Tipos de dados e compatibilidade

Mapeamentos de tipos personalizados

Lidar com caracteres inválidos

Planejamento de capacidade

operações permitidas em tabelas sincronizadas no Postgres

Propriedade e permissões

Acesso para o usuário que cria uma tabela sincronizada

gerenciar acesso sincronizado à tabela

gerenciamento de operações de tabela sincronizada

Excluir uma tabela sincronizada

Saber mais

Integração de catálogo

Outras opções