Comparteix via

Mover tablas entre pipelines

En este artículo se describe cómo mover tablas de streaming y vistas materializadas entre canalizaciones. Después de moverlo, la canalización a la que trasladas el flujo actualiza la tabla, en lugar de la canalización original. Esto es útil en muchos escenarios, entre los que se incluyen:

  • Dividir una canalización grande en otras más pequeñas.
  • Combine varias canalizaciones en una sola más grande.
  • Cambie la frecuencia de actualización de algunas tablas de una canalización.
  • Mueva tablas de una canalización que use el modo de publicación heredado al modo de publicación predeterminado. Para más información sobre el modo de publicación heredado, consulte Modo de publicación heredado para canalizaciones. Para ver cómo puede migrar el modo de publicación de una canalización completa a la vez, consulte Habilitación del modo de publicación predeterminado en una canalización.
  • Mueva tablas a través de canalizaciones en diferentes espacios de trabajo.

Requisitos

A continuación se muestran los requisitos para mover una tabla entre canalizaciones.

  • Debe usar Databricks Runtime 16.3 o superior al ejecutar el ALTER ... comando y Databricks Runtime 17.2 para mover la tabla entre áreas de trabajo.

  • Las canalizaciones de origen y destino deben ser:

    • Propiedad de la cuenta de usuario de Azure Databricks o de la entidad de servicio que ejecuta la operación
    • En áreas de trabajo que comparten un metastore. Para comprobar el metastore, consulte current_metastore la función.

  • La canalización de destino debe usar el modo de publicación predeterminado. Esto le permite publicar tablas en varios catálogos y esquemas.

    Como alternativa, ambas canalizaciones deben usar el modo de publicación heredado y ambos deben tener el mismo valor de catálogo y destino en la configuración. Para obtener información sobre el modo de publicación heredado, vea LIVE schema (legacy).

Nota:

Esta característica no admite mover una canalización mediante el modo de publicación predeterminado a una canalización mediante el modo de publicación heredado.

Mover una tabla entre canalizaciones

En las instrucciones siguientes se describe cómo mover una tabla de streaming o una vista materializada de una canalización a otra.

  1. Detenga la canalización de origen si se está ejecutando. Espere a que se detenga completamente.

  2. Quite la definición de la tabla del código de la canalización de origen y almacénela en algún lugar para futuras referencias.

    Incluya cualquier consulta auxiliar o código necesario para que la canalización se ejecute correctamente.

  3. Desde un cuaderno o un editor de SQL, ejecute el siguiente comando SQL para reasignar la tabla de la canalización de origen a la canalización de destino:

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

    Tenga en cuenta que el comando SQL debe ejecutarse desde el área de trabajo de la canalización de origen.

    El comando usa ALTER MATERIALIZED VIEW y ALTER STREAMING TABLE para las vistas materializadas administradas por el catálogo de Unity y las tablas de streaming, respectivamente. Para realizar la misma acción en una tabla de metastore de Hive, use ALTER TABLE.

    Por ejemplo, si desea mover una tabla de streaming denominada sales a una canalización con el identificador abcd1234-ef56-ab78-cd90-1234efab5678, ejecutaría el siguiente comando:

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

    Nota:

    pipelineId debe ser un identificador de canalización válido. No se permite el null valor.

  4. Agregue la definición de la tabla al código de la canalización de destino.

    Nota:

    Si el catálogo o el esquema de destino difieren entre el origen y el destino, es posible que la copia de la consulta no funcione exactamente. Las tablas parcialmente calificadas en la definición pueden resolverse de forma diferente. Es posible que tenga que actualizar la definición para completar los nombres de tabla al moverlos completamente.

    Nota:

    Elimine o comente los flujos anexados una sola vez (en Python, las consultas con append_flow(once=True), en SQL, consultas con la instrucción INSERT INTO ONCE) en el código de la canalización de destino. Para obtener más información, consulte Limitaciones.

La mudanza está completa. Ahora puede ejecutar las canalizaciones de origen y destino. La canalización de destino actualiza la tabla.

Solución de problemas

En la tabla siguiente se describen los errores que podrían producirse al mover una tabla entre canalizaciones.

Error Description
DESTINATION_PIPELINE_NOT_IN_DIRECT_PUBLISHING_MODE La canalización de origen está en el modo de publicación predeterminado y el destino usa el modo de esquema LIVE (heredado). Esto no se admite. Si el origen usa el modo de publicación predeterminado, el destino también debe,
PIPELINE_TYPE_NOT_WORKSPACE_PIPELINE_TYPE Solo se admite el movimiento de tablas entre canalizaciones. No se admite el traslado de tablas de streaming ni vistas materializadas creadas con Databricks SQL.
DESTINATION_PIPELINE_NOT_FOUND pipelines.pipelineId debe ser una canalización válida. pipelineId no puede ser NULL.
La tabla no se puede actualizar en el destino después del traslado. Para mitigar rápidamente en este caso, lleve la tabla de regreso al canal de origen siguiendo las mismas instrucciones.
PIPELINE_PERMISSION_DENIED_NOT_OWNER Tanto las canalizaciones de origen como de destino deben ser propiedad del usuario que realiza la operación de traslado.
TABLE_ALREADY_EXISTS La tabla que aparece en el mensaje de error ya existe. Esto puede ocurrir si ya existe una tabla de respaldo para la canalización. En este caso, se ejecuta DROP para la tabla mencionada en el error.

Ejemplo con varias tablas en una canalización

Las canalizaciones pueden contener más de una tabla. Todavía puede mover una tabla a la vez entre canalizaciones. En este escenario, hay tres tablas (table_a, table_b, table_c) que se leen entre sí secuencialmente en la canalización de origen. Queremos mover una tabla, table_b, a otra canalización.

Código de canalización de origen inicial:

from pyspark import pipelines as dp
from pyspark.sql.functions import col

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

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

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

Movemos table_b a otra canalización al copiar y quitar la definición de tabla del origen y actualizar el pipelineId de table_b.

En primer lugar, pause las programaciones y espere a que se completen las actualizaciones en las canalizaciones de origen y de destino. A continuación, modifique la canalización de origen para quitar el código de la tabla que se va a mover. El código de ejemplo de canalización de origen actualizado se convierte en:

from pyspark import pipelines as dp
from pyspark.sql.functions import col

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

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

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

Vaya al editor de SQL para ejecutar el ALTER pipelineId comando.

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

A continuación, vaya a la canalización de destino y agregue la definición de table_b. Si el catálogo y el esquema predeterminados son los mismos en la configuración de la canalización, no se requieren cambios en el código.

El código de canalización de destino:

from pyspark import pipelines as dp
from pyspark.sql.functions import col

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

Si el catálogo y el esquema predeterminados difieren en la configuración de la canalización, debe agregar el nombre completamente calificado mediante el catálogo y el esquema de la canalización.

Por ejemplo, el código de canalización de destino podría ser:

from pyspark import pipelines as dp
from pyspark.sql.functions import col

@dp.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"))
    )

Ejecute (o vuelva a habilitar programaciones) para las canalizaciones de origen y de destino.

Las canalizaciones ahora están separadas. La consulta de table_c lee de table_b (ahora en la canalización de destino) y table_b lee de table_a (en la canalización de origen). Cuando se realiza una ejecución desencadenada en la canalización table_b de origen no se actualiza porque la canalización de origen ya no la administra. La canalización de origen trata table_b como una tabla externa a la canalización. Esto es comparable a definir una lectura de vista materializada de una tabla Delta en el catálogo de Unity que no está administrada por la canalización.

Limitaciones

A continuación se presentan las limitaciones para mover tablas entre canalizaciones.

  • No se admiten vistas materializadas y tablas de streaming creadas con Databricks SQL.
  • No se admiten los flujos append once; flujos de Python append_flow(once=True) y flujos de SQL . Sus estados de ejecución no se preservan y es posible que se ejecuten nuevamente en la canalización de destino. Quite o comente los flujos de anexado único de la canalización de salida para evitar ejecutar estos flujos nuevamente.
  • No se admiten tablas o vistas privadas.
  • Las tuberías de origen y destino deben ser tuberías. No se admiten canalizaciones nulas.
  • Las canalizaciones de origen y destino deben estar en la misma área de trabajo o en áreas de trabajo diferentes que compartan el mismo metastore.
  • Tanto las canalizaciones de origen como de destino deben ser propiedad del usuario que ejecuta la operación de movimiento.
  • Si la canalización de origen usa el modo de publicación predeterminado, la canalización de destino también debe usar el modo de publicación predeterminado. No se puede mover una tabla de una canalización mediante el modo de publicación predeterminado a una canalización que use el esquema LIVE (heredado). Consulte el esquema LIVE (heredado).
  • Si las canalizaciones de origen y destino usan el esquema LIVE (heredado), deben tener los mismos catalog valores y target en la configuración.
  • Last updated on