Información general sobre la inserción de transformaciones

Para mejorar el rendimiento de tus flujos de procesamiento de datos, puedes enviar algunas operaciones de transformación a BigQuery en lugar de a Apache Spark. La derivación de transformaciones es un ajuste que permite que una operación de un flujo de procesamiento de datos de Cloud Data Fusion se derive a BigQuery como motor de ejecución. Como resultado, la operación y sus datos se transfieren a BigQuery y la operación se realiza allí.

La inserción de transformaciones mejora el rendimiento de las canalizaciones que tienen varias operaciones complejas JOIN u otras transformaciones admitidas. Ejecutar algunas transformaciones en BigQuery puede ser más rápido que ejecutarlas en Spark.

Las transformaciones no admitidas y todas las transformaciones de vista previa se ejecutan en Spark.

Transformaciones admitidas

La inserción de transformaciones está disponible en Cloud Data Fusion 6.5.0 y versiones posteriores, pero algunas de las transformaciones que se indican a continuación solo se admiten en versiones posteriores.

Operaciones de JOIN

  • La inserción de transformaciones está disponible para las operaciones JOIN en Cloud Data Fusion 6.5.0 y versiones posteriores.

  • Se admiten operaciones básicas (con teclas) y avanzadas JOIN.

  • Las combinaciones deben tener exactamente dos fases de entrada para que se ejecuten en BigQuery.

  • Las combinaciones que se configuran para cargar una o varias entradas en la memoria se ejecutan en Spark en lugar de en BigQuery, excepto en los siguientes casos:

    • Si alguna de las entradas de la combinación ya se ha insertado.
    • Si has configurado la combinación para que se ejecute en el motor de SQL (consulta la opción Fases para forzar la ejecución).

Sumidero de BigQuery

La función de envío de transformaciones está disponible para el receptor de BigQuery en Cloud Data Fusion 6.7.0 y versiones posteriores.

Cuando el receptor de BigQuery sigue una fase que se ha ejecutado en BigQuery, la operación que escribe registros en BigQuery se realiza directamente en BigQuery.

Para mejorar el rendimiento con este receptor, necesita lo siguiente:

  • La cuenta de servicio debe tener permiso para crear y actualizar tablas en el conjunto de datos que usa el receptor de BigQuery.
  • Los conjuntos de datos que se usan para la inserción de transformaciones y el sumidero de BigQuery deben almacenarse en la misma ubicación.
  • La operación debe ser una de las siguientes:
    • Insert (la opción Truncate Table no se admite)
    • Update
    • Upsert

GROUP BY agregaciones

La función de envío de transformaciones está disponible para las agregaciones de GROUP BY en Cloud Data Fusion 6.7.0 y versiones posteriores.

Las agregaciones de GROUP BY en BigQuery están disponibles para las siguientes operaciones:

  • Avg
  • Collect List (los valores nulos se eliminan de la matriz de salida)
  • Collect Set (los valores nulos se eliminan de la matriz de salida)
  • Concat
  • Concat Distinct
  • Count
  • Count Distinct
  • Count Nulls
  • Logical And
  • Logical Or
  • Max
  • Min
  • Standard Deviation
  • Sum
  • Sum of Squares
  • Corrected Sum of Squares
  • Variance
  • Shortest String
  • Longest String

Las agregaciones GROUP BY se ejecutan en BigQuery en los siguientes casos:

  • Sigue a una fase que ya se ha desplazado hacia abajo.
  • Lo has configurado para que se ejecute en el motor de SQL (consulta la opción Pasos para forzar la ejecución).

Anular duplicados de agregaciones

La función de pushdown de transformaciones está disponible para las agregaciones de desduplicación en Cloud Data Fusion 6.7.0 y versiones posteriores para las siguientes operaciones:

  • No se ha especificado ninguna operación de filtro
  • ANY (un valor no nulo para el campo deseado)
  • MIN (el valor mínimo del campo especificado)
  • MAX (el valor máximo del campo especificado)

No se admiten las siguientes operaciones:

  • FIRST
  • LAST

Las agregaciones de desduplicación se ejecutan en el motor SQL en los siguientes casos:

  • Sigue a una fase que ya se ha desplazado hacia abajo.
  • Lo has configurado para que se ejecute en SQL Engine (consulta la opción Pasos para forzar la ejecución).

Pushdown de origen de BigQuery

La inserción de BigQuery Source está disponible en las versiones 6.8.0 y posteriores de Cloud Data Fusion.

Cuando una fuente de BigQuery sigue una fase compatible con la inserción de BigQuery, la canalización puede ejecutar todas las fases compatibles en BigQuery.

Cloud Data Fusion copia los registros necesarios para ejecutar el flujo de procesamiento en BigQuery.

Cuando usas la inserción de origen de BigQuery, se conservan las propiedades de partición y de clustering de la tabla, lo que te permite usar estas propiedades para optimizar otras operaciones, como las combinaciones.

Requisitos adicionales

Para usar la inserción de origen de BigQuery, se deben cumplir los siguientes requisitos:

  • La cuenta de servicio configurada para la inserción de transformaciones de BigQuery debe tener permisos para leer tablas en el conjunto de datos de la fuente de BigQuery.

  • Los conjuntos de datos que se usan en la fuente de BigQuery y el conjunto de datos configurado para la inserción de transformaciones deben almacenarse en la misma ubicación.

Agregaciones de ventanas

La transformación pushdown está disponible para las agregaciones de ventanas en Cloud Data Fusion 6.9 y versiones posteriores. Las agregaciones de ventana de BigQuery se admiten en las siguientes operaciones:

  • Rank
  • Dense Rank
  • Percent Rank
  • N tile
  • Row Number
  • Median
  • Continuous Percentile
  • Lead
  • Lag
  • First
  • Last
  • Cumulative distribution
  • Accumulate

Las agregaciones de ventanas se ejecutan en BigQuery en los siguientes casos:

  • Sigue a una fase que ya se ha desplazado hacia abajo.
  • Lo has configurado para que se ejecute en el motor SQL (consulta la opción Pasos para forzar la inserción).

Wrangler Filter Pushdown

La función de envío de filtros de Wrangler está disponible en Cloud Data Fusion 6.9 y versiones posteriores.

Cuando usas el complemento Wrangler, puedes enviar filtros, conocidos como Preconditionoperaciones, para que se ejecuten en BigQuery en lugar de en Spark.

El envío de filtros solo se admite con el modo SQL de Preconditions, que también se lanzó en la versión 6.9. En este modo, el complemento acepta una expresión de condición previa en SQL estándar ANSI.

Si se usa el modo SQL para las condiciones previas, las directivas y las directivas definidas por el usuario se inhabilitan en el complemento Wrangler, ya que no se admiten con las condiciones previas en el modo SQL.

El modo SQL para las condiciones previas no se admite en los complementos de Wrangler con varias entradas cuando la inserción de transformaciones está habilitada. Si se usa con varias entradas, esta fase de Wrangler con condiciones de filtro SQL se ejecuta en Spark.

Los filtros se ejecutan en BigQuery en los siguientes casos:

  • Sigue a una fase que ya se ha desplazado hacia abajo.
  • Lo has configurado para que se ejecute en el motor SQL (consulta la opción Pasos para forzar la inserción).

Métricas

Para obtener más información sobre las métricas que proporciona Cloud Data Fusion para la parte de la canalización que se ejecuta en BigQuery, consulta Métricas de canalización de inserción de BigQuery.

Cuándo usar la inserción de transformaciones

Para ejecutar transformaciones en BigQuery, se deben seguir estos pasos:

  1. Escribir registros en BigQuery para las fases admitidas de tu canalización.
  2. Ejecutar fases admitidas en BigQuery.
  3. Leer registros de BigQuery después de que se hayan ejecutado las transformaciones admitidas, a menos que vayan seguidas de un receptor de BigQuery.

En función del tamaño de los conjuntos de datos, puede haber una sobrecarga de red considerable, lo que puede repercutir negativamente en el tiempo de ejecución general de la canalización cuando la inserción de transformaciones está habilitada.

Debido a la sobrecarga de la red, recomendamos usar la inserción de transformaciones en los siguientes casos:

  • Las operaciones admitidas se ejecutan en secuencia (sin pasos entre las fases).
  • Las mejoras de rendimiento que se obtienen al ejecutar las transformaciones en BigQuery, en comparación con Spark, superan la latencia del movimiento de datos hacia y, posiblemente, desde BigQuery.

Cómo funciona

Cuando ejecutas un flujo de procesamiento que usa la inserción de transformaciones, Cloud Data Fusion ejecuta las fases de transformación admitidas en BigQuery. Todas las demás fases de la canalización se ejecutan en Spark.

Al ejecutar transformaciones:

  1. Cloud Data Fusion carga los conjuntos de datos de entrada en BigQuery escribiendo registros en Cloud Storage y, a continuación, ejecutando una tarea de carga de BigQuery.

  2. Las operaciones JOIN y las transformaciones admitidas se ejecutan como tareas de BigQuery mediante instrucciones SQL.

  3. Si se necesita un tratamiento adicional después de ejecutar las tareas, los registros se pueden exportar de BigQuery a Spark. Sin embargo, si la opción Intentar copiar directamente en sumideros de BigQuery está habilitada y el sumidero de BigQuery sigue una fase que se ha ejecutado en BigQuery, los registros se escriben directamente en la tabla de sumidero de BigQuery de destino.

En el siguiente diagrama se muestra cómo se ejecutan las transformaciones admitidas en BigQuery en lugar de en Spark mediante el pushdown de transformaciones.

Pushdown de transformación a BigQuery en las canalizaciones de Cloud Data Fusion.

Prácticas recomendadas

Ajustar los tamaños de clúster y de ejecutor

Para optimizar la gestión de recursos en tu canalización, haz lo siguiente:

  • Usa el número adecuado de trabajadores (nodos) de clúster para una carga de trabajo. Es decir, aprovecha al máximo el clúster de Dataproc aprovisionado usando por completo la CPU y la memoria disponibles de tu instancia, al tiempo que te beneficias de la velocidad de ejecución de BigQuery para las tareas de gran tamaño.

  • Mejora el paralelismo de tus canalizaciones usando clústeres de escalado automático.

  • Ajusta las configuraciones de recursos en las fases de tu canalización en las que se insertan o extraen registros de BigQuery durante la ejecución de la canalización.

Recomendación: prueba a aumentar el número de núcleos de CPU de tus recursos de ejecutor (hasta el número de núcleos de CPU que usa tu nodo de trabajador). Los ejecutores optimizan el uso de la CPU durante los pasos de serialización y deserialización a medida que los datos entran y salen de BigQuery. Para obtener más información, consulta Tamaño del clúster.

Una de las ventajas de ejecutar transformaciones en BigQuery es que tus flujos de procesamiento pueden ejecutarse en clústeres de Dataproc más pequeños. Si las combinaciones son las operaciones que más recursos consumen de tu canalización, puedes probar con tamaños de clúster más pequeños, ya que las operaciones pesadas JOIN ahora se realizan en BigQuery, lo que te permite reducir los costes de computación generales.

Recuperar datos más rápido con la API Storage Read de BigQuery

Una vez que BigQuery ejecute las transformaciones, es posible que tu canalización tenga etapas adicionales que ejecutar en Spark. En Cloud Data Fusion 6.7.0 y versiones posteriores, la inserción de transformaciones admite la API de lectura de almacenamiento de BigQuery, lo que mejora la latencia y acelera las operaciones de lectura en Spark. Puede reducir el tiempo de ejecución general de la canalización.

La API lee los registros en paralelo, por lo que te recomendamos que ajustes los tamaños del ejecutor en consecuencia. Si se ejecutan operaciones que consumen muchos recursos en BigQuery, reduce la asignación de memoria de los ejecutores para mejorar el paralelismo cuando se ejecute la canalización (consulta Ajustar los tamaños de los clústeres y los ejecutores).

La API Storage Read de BigQuery está inhabilitada de forma predeterminada. Puedes habilitarlo en entornos de ejecución en los que esté instalado Scala 2.12 (incluidos Dataproc 2.0 y Dataproc 1.5).

Tener en cuenta el tamaño del conjunto de datos

Ten en cuenta los tamaños de los conjuntos de datos en las operaciones JOIN. En el caso de las operaciones JOIN que generan un número considerable de registros de salida, como las que se parecen a una operación de cruce JOIN, el tamaño del conjunto de datos resultante puede ser órdenes de magnitud mayor que el del conjunto de datos de entrada. También debes tener en cuenta la sobrecarga que supone volver a introducir estos registros en Spark cuando se produce un procesamiento adicional de Spark para estos registros, como una transformación o un receptor, en el contexto del rendimiento general de la canalización.

Mitigar los datos sesgados

Las operaciones de JOIN con datos muy sesgados pueden provocar que la tarea de BigQuery supere los límites de utilización de recursos, lo que hace que la operación de JOIN falle. Para evitarlo, ve a los ajustes del complemento Joiner e identifica la entrada sesgada en el campo Skewed Input Stage (Fase de entrada sesgada). De esta forma, Cloud Data Fusion puede organizar las entradas para reducir el riesgo de que la instrucción de BigQuery supere los límites.

En los ajustes del complemento Joiner, identifica los datos sesgados en el campo Skewed Input Stage (Fase de entrada sesgada).

Siguientes pasos