Para mejorar el rendimiento de tus canalizaciones de datos, puedes enviar algunas operaciones de transformación a BigQuery en lugar de Apache Spark. El envío de transformaciones hace referencia a una configuración que permite que una operación de una canalización de datos de Cloud Data Fusion se envíe a BigQuery como un motor de ejecución. Como resultado, la operación y sus datos se transfieren a BigQuery y la operación se realiza allí.
El envío de transformaciones mejora el rendimiento de las canalizaciones que tienen varias operaciones JOIN complejas, o bien otras transformaciones compatibles. Ejecutar algunas transformaciones en BigQuery puede ser más rápido que ejecutarlas en Spark.
Las transformaciones no compatibles y todas las transformaciones de vista previa se ejecutan en Spark.
Transformaciones compatibles
El envío de transformaciones está disponible en Cloud Data Fusion 6.5.0 y versiones posteriores, pero algunas de las siguientes transformaciones solo son compatibles con versiones posteriores.
JOIN operaciones
El envío de transformaciones está disponible para las operaciones
JOINen Cloud Data Fusion 6.5.0 y versiones posteriores.Se admiten las operaciones
JOINbásicas (en claves) y avanzadas.Las uniones deben tener exactamente dos etapas de entrada para que la ejecución se lleve a cabo en BigQuery.
Las uniones configuradas para cargar una o más entradas en la memoria se ejecutan en Spark en lugar de BigQuery, excepto en los siguientes casos:
- Si alguna de las entradas a la unión ya se envió hacia abajo.
- Si configuraste la unión a fin de que se ejecute en SQL Engine (consulta la opción Etapas para forzar la ejecución).
Receptor de BigQuery
La transferencia de transformación está disponible para el receptor de BigQuery en Cloud Data Fusion 6.7.0 y versiones posteriores.
Cuando el receptor de BigQuery sigue una etapa que se ejecutó en BigQuery, la operación que escribe registros en BigQuery se realiza directamente en BigQuery.
Para mejorar el rendimiento con este receptor, necesitas 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 transferencia de transformación y el receptor de BigQuery deben almacenarse en la misma ubicación.
- La operación debe ser una de las siguientes:
Insert(no se admite la opciónTruncate Table)UpdateUpsert
GROUP BY agregaciones
El envío de transformaciones está disponible para agregaciones GROUP BY en Cloud Data Fusion 6.7.0 y versiones posteriores.
Las agregaciones GROUP BY en BigQuery están disponibles para las siguientes operaciones:
AvgCollect List(los valores nulos se quitan del array de salida)Collect Set(los valores nulos se quitan del array de salida)ConcatConcat DistinctCountCount DistinctCount NullsLogical AndLogical OrMaxMinStandard DeviationSumSum of SquaresCorrected Sum of SquaresVarianceShortest StringLongest String
Las agregaciones GROUP BY se ejecutan en BigQuery en los siguientes casos:
- Sigue una etapa que ya se bajó.
- Configuraste que se ejecute en SQL Engine (consulta la opción Etapas para forzar la ejecución).
Anula agregaciones duplicadas
El envío de transformaciones está disponible para anular las agregaciones duplicadas en Cloud Data Fusion 6.7.0 y versiones posteriores en las siguientes operaciones:
- No se especificó ninguna operación de filtro
ANY(un valor no nulo para el campo deseado)MIN(el valor mínimo para el campo especificado)MAX(el valor máximo para el campo especificado)
No se admiten las siguientes operaciones:
FIRSTLAST
Las agregaciones de anulación de duplicados se ejecutan en el motor de SQL en los siguientes casos:
- Sigue una etapa que ya se bajó.
- Configuraste que se ejecute en SQL Engine (consulta la opción Etapas para forzar la ejecución).
Desplegable de origen de BigQuery
El envío directo de fuente de BigQuery está disponible en Cloud Data Fusion 6.8.0 y versiones posteriores.
Cuando una fuente de BigQuery sigue una etapa compatible con el envío de BigQuery, la canalización puede ejecutar todas las etapas compatibles dentro de BigQuery.
Cloud Data Fusion copia los registros necesarios para ejecutar la canalización dentro de BigQuery.
Cuando usas BigQuery Source Pushdown, las propiedades de partición y agrupamiento en clústeres se conservan, lo que te permite usar estas propiedades para optimizar otras operaciones, como las uniones.
Requisitos adicionales
Para usar el pushdown de origen de BigQuery, se deben cumplir los siguientes requisitos:
La cuenta de servicio configurada para el envío de Transformación de BigQuery debe tener permisos para leer tablas en el conjunto de datos de origen de BigQuery.
Los conjuntos de datos que se usan en la fuente de BigQuery y el conjunto de datos configurado para el pushdown de la transformación deben almacenarse en la misma ubicación.
Agregaciones de ventana
El envío de transformaciones está disponible para las agregaciones de ventana en las versiones 6.9 y posteriores de Cloud Data Fusion. Las agregaciones de ventana en BigQuery son compatibles con las siguientes operaciones:
RankDense RankPercent RankN tileRow NumberMedianContinuous PercentileLeadLagFirstLastCumulative distributionAccumulate
Las agregaciones de ventana se ejecutan en BigQuery en los siguientes casos:
- Sigue una etapa que ya se bajó.
- La configuraste para que se ejecute en SQL Engine (consulta la opción Etapas para forzar la pushdown).
Retiro del filtro Wrangler
El envío de filtro de Wrangler está disponible en las versiones 6.9 y posteriores de Cloud Data Fusion.
Cuando usas el complemento Wrangler, puedes enviar filtros, conocidos como operaciones Precondition, para que se ejecuten en BigQuery en lugar de Spark.
La inserción de filtros solo es compatible con el modo SQL para las condiciones previas, 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 están inhabilitadas para el complemento Wrangler, ya que no son compatibles con las condiciones previas en el modo SQL.
El modo SQL para condiciones previas no es compatible con los complementos Wrangler con varias entradas cuando la transferencia de transformación está habilitada. Si se usa con varias entradas, esta etapa Wrangler con condiciones de filtro de SQL se ejecuta en Spark.
Los filtros se ejecutan en BigQuery en los siguientes casos:
- Sigue una etapa que ya se bajó.
- La configuraste para que se ejecute en SQL Engine (consulta la opción Etapas para forzar la pushdown).
Métricas
Para obtener más información sobre las métricas que proporciona Cloud Data Fusion sobre la parte de la canalización que se ejecuta en BigQuery, consulta las métricas de canalización pushdown de BigQuery.
Cuándo usar la transformación pushdown
La ejecución de transformaciones en BigQuery implica lo siguiente:
- Escribir registros en BigQuery para las etapas compatibles en tu canalización
- Ejecución de etapas compatibles en BigQuery.
- Leer registros de BigQuery después de que se ejecuten las transformaciones compatibles, a menos que estén seguidos de un receptor de BigQuery
Según el tamaño de tus conjuntos de datos, puede haber una sobrecarga de red considerable, lo que puede tener un impacto negativo en el tiempo general de ejecución de la canalización cuando la transferencia de transformación está habilitada.
Debido a la sobrecarga de la red, recomendamos la transferencia de transformación en los siguientes casos:
- Se ejecutan varias operaciones admitidas en secuencia (sin pasos entre las etapas).
- Las ganancias de rendimiento que obtiene BigQuery cuando ejecutan las transformaciones, en relación con Spark, superan la latencia del movimiento de datos dentro y posiblemente fuera de BigQuery.
Cómo funciona
Cuando ejecutas una canalización que usa Transformation Pushdown, Cloud Data Fusion ejecuta las etapas de transformación admitidas en BigQuery. Todas las demás etapas de la canalización se ejecutan en Spark.
Cuando ejecutes transformaciones, ten en cuenta lo siguiente:
Cloud Data Fusion carga los conjuntos de datos de entrada en BigQuery; para ello, escribe registros en Cloud Storage y, luego, ejecuta un trabajo de carga de BigQuery.
Luego, las operaciones
JOINy las transformaciones admitidas se ejecutan como trabajos de BigQuery mediante instrucciones de SQL.Si se necesita procesamiento adicional después de que se ejecutan los trabajos, los registros se pueden exportar de BigQuery a Spark. Sin embargo, si la opción Intento de copiar directamente a los receptores de BigQuery está habilitada y el receptor de BigQuery sigue una etapa que se ejecutó en BigQuery, los registros se escriben directamente en la tabla del receptor de BigQuery de destino.
En el siguiente diagrama, se muestra cómo el pushdown de transformación ejecuta las transformaciones compatibles en BigQuery en lugar de Spark.
prácticas recomendadas
Ajusta los tamaños de los clústeres y ejecutores
Para optimizar la administración de recursos en tu canalización, haz lo siguiente:
Usa la cantidad correcta de trabajadores del clúster (nodos) para una carga de trabajo. En otras palabras, aprovecha al máximo el clúster de Dataproc aprovisionado mediante el uso completo de la CPU y la memoria disponibles para tu instancia, a la vez que te beneficias de la velocidad de ejecución de BigQuery en trabajos grandes.
Mejora el paralelismo en tus canalizaciones mediante clústeres de ajuste de escala automático.
Ajustar la configuración de los recursos en las etapas de la canalización en las que se envían o se extraen los registros de BigQuery durante la ejecución de la canalización
Recomendado: Experimenta aumentando la cantidad de núcleos de CPU para los recursos del ejecutor (hasta la cantidad de núcleos de CPU que usa tu nodo 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.
Un beneficio de ejecutar transformaciones en BigQuery es que tus canalizaciones pueden ejecutarse en clústeres de Dataproc más pequeños. Si las uniones son las operaciones que más recursos consumen en tu canalización, puedes experimentar con tamaños de clúster más pequeños, ya que las operaciones JOIN pesadas ahora se realizan en BigQuery, lo que te permite reducir los costos de procesamiento generales.
Recupera datos más rápido con la API de Storage Read de BigQuery
Después de que BigQuery ejecuta las transformaciones, tu canalización puede tener etapas adicionales para ejecutarse en Spark. En la versión 6.7.0 y posteriores de Cloud Data Fusion, Transformation Pushdown admite la API de BigQuery Storage Read, que mejora la latencia y da como resultado operaciones de lectura más rápidas en Spark. Puede reducir el tiempo total de ejecución de la canalización.
La API lee registros en paralelo, por lo que recomendamos ajustar los tamaños de los ejecutores según corresponda. Si se ejecutan operaciones de uso intensivo de recursos en BigQuery, reduce la asignación de memoria para los ejecutores a fin de mejorar el paralelismo cuando se ejecute la canalización (consulta Ajusta los tamaños de clústeres y ejecutores).
La API de Storage Read de BigQuery está inhabilitada de forma predeterminada. Puedes habilitarlo en entornos de ejecución en los que Scala 2.12 esté instalado (incluidos Dataproc 2.0 y Dataproc 1.5).
Considera el tamaño del conjunto de datos
Considera los tamaños de los conjuntos de datos en las operaciones JOIN. Para las operaciones de JOIN que generan una cantidad considerable de registros de salida, como algo que se parece a una operación JOIN cruzada, el tamaño del conjunto de datos resultante puede ser órdenes de magnitud más grande que el conjunto de datos de entrada. Además, considera la sobrecarga de extraer estos registros a 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 JOIN para datos muy sesgados pueden hacer que el trabajo de BigQuery supere los límites de uso de recursos, lo que hace que la operación JOIN falle. Para evitar esto, ve a la configuración del complemento Joiner y, luego, identifica la entrada sesgada en el campo Skewed Input Stage. Esto permite que Cloud Data Fusion organice las entradas de una manera que reduzca el riesgo de que la declaración de BigQuery exceda los límites.
