Pular para o conteúdo principal

Mover tabelas entre LakeFlow Pipeline declarativo

Este artigo descreve como mover tabelas de transmissão e visualizações materializadas entre pipelines. Após a movimentação, o pipeline para o qual o fluxo é movido atualiza a tabela, em vez do pipeline original. Isso é útil em muitos cenários, incluindo:

  • Dividir um pipeline grande em pipelines menores.
  • mesclar vários pipelines em um único pipeline maior.
  • Altere a frequência do refresh para algumas tabelas em um pipeline.
  • Mova tabelas de um pipeline que utiliza o modo de publicação antigo para o modo de publicação default. Para obter detalhes sobre o modo de publicação legado, consulte Modo de publicação legado para pipeline. Para saber como migrar o modo de publicação de um pipeline inteiro de uma só vez, consulte Ativar o modo de publicação default em um pipeline.

Requisitos​

A seguir estão os requisitos para mover uma tabela entre pipelines.

  • É necessário utilizar o Databricks Runtime 16.3 ou superior ao executar o comando ALTER ....

  • Tanto o pipeline de origem quanto o de destino devem ser:

    • No mesmo workspace
    • De propriedade do usuário Databricks account ou da entidade de serviço que executa as operações

  • O destino pipeline deve utilizar o modo de publicação default. Isso permite que você publique tabelas em vários catálogos e esquemas.

    Alternativamente, ambos os pipelines devem utilizar o modo de publicação legado e ambos devem ter o mesmo catálogo e valor de destino nas configurações. Para obter informações sobre o modo de publicação legado, consulte Esquema LIVE (legado).

nota

Este recurso não suporta a movimentação de um pipeline usando o modo de publicação default para um pipeline usando o modo de publicação legado.

Mover uma tabela entre pipelines​

As instruções a seguir descrevem como mover uma tabela de transmissão ou materializada view de um pipeline para outro.

  1. Interrompa o pipeline de origem se ele estiver em execução. Espere que ele pare completamente.

  2. Remova a definição da tabela do Notebook ou arquivo de origem pipelinee armazene-a em algum lugar para referência futura.

    Inclua qualquer consulta ou código de suporte necessário para que o site pipeline seja executado corretamente.

  3. Em um Notebook ou em um editor SQL, execute o seguinte comando SQL para reatribuir a tabela da origem pipeline para o destino pipeline:

    SQL
    ALTER [MATERIALIZED VIEW | STREAMING TABLE | TABLE] <table-name>
      SET TBLPROPERTIES("pipelines.pipelineId"="<destination-pipeline-id>");

    O comando utiliza ALTER MATERIALIZED VIEW e ALTER STREAMING TABLE para Unity Catalog gerenciar as tabelas de visualização materializada e transmissão, respectivamente. Para realizar a mesma ação em uma tabela do Hive metastore, utilize ALTER TABLE.

    Por exemplo, se quiser mover uma tabela de transmissão chamada sales para uma pipeline com o ID abcd1234-ef56-ab78-cd90-1234efab5678, o senhor executaria o seguinte comando:

    SQL
    ALTER STREAMING TABLE sales
      SET TBLPROPERTIES("pipelines.pipelineId"="abcd1234-ef56-ab78-cd90-1234efab5678");
nota

O endereço pipelineId deve ser um identificador de pipeline válido. O valor null não é permitido.

  1. Adicione a definição da tabela ao Notebook/file do site pipelinede destino.
nota

Se o catálogo ou o esquema de destino diferirem entre a origem e o destino, copiar a consulta com exatidão pode não funcionar. Tabelas parcialmente qualificadas na definição podem ser resolvidas de forma diferente. Talvez seja necessário atualizar a definição durante a movimentação.

A mudança está completa. Agora é possível executar o pipeline de origem e o pipeline de destino. O pipeline de destino atualiza a tabela.

Solução de problemas​

A tabela a seguir descreve os erros que podem ocorrer ao mover uma tabela entre pipelines.

Erro

Descrição

DESTINATION_PIPELINE_NOT_IN_DIRECT_PUBLISHING_MODE

A origem pipeline está no modo de publicação default e o destino usa o modo de esquema LIVE (legado). Isso não é suportado. Se a origem usar o modo de publicação default, o destino também deverá usar.

PIPELINE_TYPE_NOT_WORKSPACE_PIPELINE_TYPE

Apenas é possível mover tabelas entre um pipeline declarativ LakeFlow. O pipeline para tabelas de transmissão e visualizações materializadas criadas com Databricks SQL não é compatível.

DESTINATION_PIPELINE_NOT_FOUND

O endereço pipelines.pipelineId deve ser um pipeline válido. O pipelineId não pode ser nulo.

A tabela não é atualizada no destino após a mudança.

Para mitigar rapidamente neste caso, mova a tabela de volta para o pipeline de origem seguindo as mesmas instruções.

PIPELINE_PERMISSION_DENIED_NOT_OWNER

Tanto o pipeline de origem quanto o de destino devem pertencer ao usuário que está realizando as operações de movimentação.

TABLE_ALREADY_EXISTS

A tabela listada na mensagem de erro já existe. Isso pode ocorrer se já existir uma tabela de apoio para o pipeline. Nesse caso, DROP na tabela listada no erro.

Exemplo com várias tabelas em um pipeline​

O pipeline pode conter mais de uma tabela. Ainda é possível mover uma tabela por vez entre o pipeline. Neste cenário, existem três tabelas (table_a, table_b, table_c) que se leem sequencialmente na pipeline de origem. Desejamos transferir uma tabela, table_b, para outro pipeline.

Código inicial do pipeline de origem:

Python
import dlt
from pyspark.sql.functions import col

@dlt.table
def table_a():
    return spark.read.table("source_table")

# Table to be moved to new pipeline:
@dlt.table
def table_b():
    return (
        spark.read.table("table_a")
        .select(col("column1"), col("column2"))
    )

@dlt.table
def table_c():
    return (
        spark.read.table("table_b")
        .groupBy(col("column1"))
        .agg(sum("column2").alias("sum_column2"))
    )

Movemos table_b para outro pipeline copiando e removendo a definição da tabela da fonte e atualizando o pipelineId de table_b.

Primeiro, interrompa qualquer programa e aguarde a conclusão das atualizações no pipeline de origem e no pipeline de destino. Em seguida, modifique o pipeline de origem para remover o código da tabela que está sendo movida. O código de exemplo atualizado do pipeline de origem fica assim:

Python
import dlt
from pyspark.sql.functions import col

@dlt.table
def table_a():
    return spark.read.table("source_table")

# Removed, to be in new pipeline:
# @dlt.table
# def table_b():
#     return (
#         spark.read.table("table_a")
#         .select(col("column1"), col("column2"))
#     )

@dlt.table
def table_c():
    return (
        spark.read.table("table_b")
        .groupBy(col("column1"))
        .agg(sum("column2").alias("sum_column2"))
    )

Acesse o editor do SQL para executar o comando ALTER pipelineId.

SQL
ALTER MATERIALIZED VIEW table_b
  SET TBLPROPERTIES("pipelines.pipelineId"="<new-pipeline-id>");

Em seguida, acesse o pipeline de destino e adicione a definição de table_b. Se o catálogo e o esquema default forem os mesmos nas configurações pipeline, não será necessário alterar o código.

O código do pipeline de destino:

Python
import dlt
from pyspark.sql.functions import col

@dlt.table(name="table_b")
def table_b():
    return (
        spark.read.table("table_a")
        .select(col("column1"), col("column2"))
    )

Se o catálogo e o esquema default diferirem nas configurações pipeline, é necessário adicionar o nome totalmente qualificado usando o catálogo e o esquema pipeline.

Por exemplo, o código do pipeline de destino poderia ser:

Python
import dlt
from pyspark.sql.functions import col

@dlt.table(name="source_catalog.source_schema.table_b")
def table_b():
    return (
        spark.read.table("source_catalog.source_schema.table_a")
        .select(col("column1"), col("column2"))
    )

execução (ou reativar programar) para o pipeline de origem e de destino.

Os pipelines estão agora separados. A consulta para table_c é lida em table_b (agora no pipeline de destino) e table_b é lida em table_a (no pipeline de origem). Quando você realiza uma execução acionada na fonte pipeline, table_b não é atualizado porque não é mais gerenciado pela fonte pipeline. O pipeline de origem trata table_b como uma tabela externa ao pipeline. Isso é comparável a definir uma leitura materializada view a partir de uma tabela Delta em Unity Catalog que não é gerenciada pelo pipeline.

Limitações​

A seguir, as limitações para mover tabelas entre pipelines.

  • Não há suporte para tabelas de visualização materializada e transmissão criadas com Databricks SQL.
  • Não há suporte para tabelas ou visualizações privadas.
  • O pipeline de origem e destino deve ser pipeline. Pipelines nulos não são suportados.
  • Tanto o pipeline de origem quanto o de destino devem estar no mesmo site workspace.
  • Tanto o pipeline de origem quanto o de destino devem ser de propriedade do usuário que está executando as operações de movimentação.
  • Se a fonte pipeline usar o modo de publicação default, o destino pipeline também deverá estar usando o modo de publicação default. O senhor não pode mover uma tabela de um pipeline usando o modo de publicação default para um pipeline que usa o esquema LIVE (legado). Consulte esquema LIVE (legado).
  • Se o pipeline de origem e o de destino estiverem usando o esquema LIVE (legado), eles deverão ter os mesmos valores catalog e target nas configurações.
Última atualização em