Limitações do conector do SQL Server
Visualização
O conector do Microsoft SQL Server está em Public Preview.
Esta página lista as limitações e considerações para a ingestão de SQL Server usando Databricks LakeFlow Connect.
Limitações gerais do conector de banco
As limitações desta seção se aplicam a todos os conectores de banco de dados em LakeFlow Connect.
-
Quando o senhor executa um pipeline agendado, o alerta não é acionado imediatamente. Em vez disso, eles são acionados quando a próxima atualização é executada.
-
Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do pipeline declarativo LakeFlow.
-
Durante os períodos de manutenção da fonte, a Databricks pode não conseguir acessar seus dados.
-
Se um nome de tabela de origem entrar em conflito com um nome de tabela de destino existente, a atualização do pipeline falhará.
-
O suporte a pipeline de vários destinos é somente de API.
-
Opcionalmente, você pode renomear uma tabela que você ingere. Se o senhor renomear uma tabela no pipeline, ela se tornará um pipeline somente de API e não será mais possível editar o pipeline na interface do usuário.
-
Se o senhor selecionar uma coluna depois que um pipeline já tiver começado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, o senhor deve executar manualmente um refresh completo na tabela.
-
O Databricks não pode ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes.
-
O sistema de origem presume que as colunas do cursor estão aumentando monotonicamente.
-
O pipeline de ingestão gerenciar não é compatível com o espaço de trabalho em AWS GovCloud regiões (FedRAMP High).
-
O pipeline de ingestão de gerenciar não é compatível com o espaço de trabalho FedRAMP Moderate nas regiões
us-east-2
ouus-west-1
.
Específico do conector
As limitações desta seção são específicas do conector do SQL Server.
Autenticação
- O conector só oferece suporte à autenticação de nome de usuário e senha.
- As configurações de clustering de failover de várias sub-redes devem fornecer um único endereço IP de encaminhamento.
Variações do banco de
-
O conector é compatível com os bancos de dados SQL do Azure SQL e do Amazon RDS. Isso inclui o SQL Server em execução nas máquinas virtuais (VMs) do Azure e no Amazon EC2. O conector também oferece suporte ao SQL Server no local usando o Azure ExpressRoute e a rede AWS Direct Connect.
-
Para usar o site Microsoft captura de dados de alterações (CDC) (CDC):
-
O senhor deve ter o SQL Server 2012 serviço pack 1 (SP1) cumulative update pacote 3 (CU3) ou superior.
Essa atualização introduziu a coluna
__$command_id
. Sem essa coluna, o gateway de ingestão não pode distinguir de forma confiável os tipos de operações de modificação de dados (por exemplo,UPDATE
operações que se manifestam como paresDELETE-INSERT
com valores__$seqval
idênticos). Isso pode causar inconsistências nos dados. -
Para versões anteriores ao SQL Server 2016, o Enterprise Edition também é necessário.
-
-
Para usar o Microsoft change acompanhamento, o senhor deve ter o SQL Server 2012 ou o acima.
tubulação
- Cada pipeline de ingestão deve estar associado a exatamente um gateway de ingestão.
- Embora a ingestão pipeline seja executada em serverless compute, o gateway de ingestão deve ser executado no clássico compute.
evolução do esquema
O conector processa automaticamente colunas novas e excluídas, a menos que você opte por não participar.
- Quando uma nova coluna aparece na fonte, o Databricks a ingere automaticamente na próxima execução do pipeline. No entanto, você pode optar por não participar disso.
- Quando uma coluna é excluída da fonte, o Databricks não a exclui automaticamente. Em vez disso, o conector usa uma propriedade de tabela para definir a coluna excluída como
inactive
no destino. Se outra coluna aparecer posteriormente com um nome conflitante com a colunainactive
, o pipeline falhará. Nesse caso, o senhor pode executar um refresh completo da tabela ou eliminar manualmente a coluna inativa.
Isso vale para tabelas novas e excluídas em um esquema se você ingerir todo o esquema.
Por fim, o conector pode lidar com renomeações de colunas, embora isso exija um refresh completo da tabela.
Alterações adicionais no esquema (por exemplo, alterações no tipo de dados) também exigem um refresh completo das tabelas de destino.
Encenação
O catálogo de teste não pode ser um catálogo estrangeiro.
Tabelas
- A Databricks recomenda a ingestão de 250 ou menos tabelas por pipeline. No entanto, não há limite para o número de linhas ou colunas suportadas nesses objetos.
- O Databricks não pode ingerir duas tabelas cujos nomes diferem apenas no caso (por exemplo,
MyTable
eMYTABLE
) usando um pipeline. Para dar suporte a esses casos, crie dois pares gateway-ingestion pipeline que publiquem em esquemas de destino. - Os nomes
source_catalog
,source_schema
esource_table
diferenciam maiúsculas de minúsculas. Por exemplo, se o catálogo do banco de dados de origem for especificado comoMarketing
emsys.databases
, você não poderá especificá-lo comomarketing
noingestion_definition
. - Embora o senhor possa fazer a ingestão de vários catálogos ou esquemas de origem em um pipeline, não é possível fazer a ingestão de duas tabelas com o mesmo nome. Por exemplo, o senhor não pode ingerir tanto
schema1.Marketing
quantoschema2.Marketing
no mesmo pipeline. - Várias especificações de tabela ou esquema podem ser incluídas no campo
objects
doingestion_definition
. No entanto, os nomes das tabelas de origem em diferentes esquemas de origem não podem se sobrepor. Isso resulta em falha no pipeline de ingestão.