En esta página, se muestra cómo resolver problemas con Cloud Data Fusion.
Soluciona problemas de canalizaciones por lotes
La canalización simultánea está detenida
En Cloud Data Fusion, ejecutar muchas canalizaciones por lotes simultáneas puede ejercer presión en la instancia y hacer que los trabajos se detengan en los estados Starting, Provisioning o Running. Como resultado, las canalizaciones no se pueden detener a través de la interfaz web ni de las llamadas a la API. Cuando se ejecutan muchas canalizaciones de forma simultánea, la interfaz web puede volverse lenta o dejar de responder. Este problema ocurre debido a múltiples solicitudes a la IU que se realizan al controlador HTTP en el backend.
Recomendación
Para resolver este problema, controla la cantidad de solicitudes nuevas con el control de flujo de Cloud Data Fusion, que está disponible en instancias que se ejecutan en la versión 6.6 y en versiones posteriores.
Se agota el tiempo de espera de la conexión SSH mientras se ejecuta una canalización
El siguiente error ocurre cuando ejecutas una canalización por lotes:
`java.io.IOException: com.jcraft.jsch.JSchException:
java.net.ConnectException: Connection timed out (Connection timed out)`
Recomendación
Para resolver el error, verifica los siguientes problemas:
- Verifica si falta una regla de firewall (por lo general, el puerto 22). Para crear una regla de firewall nueva, consulta Configuración de red de clústeres de Dataproc.
- Comprobar que el ejecutor de Compute Engine permita la conexión entre su instancia de Cloud Data Fusion y el clúster de Dataproc
Código de respuesta: 401. Error: error desconocido
El siguiente error ocurre cuando ejecutas una canalización por lotes:
`java.io.IOException: Failed to send message for program run program_run:
Response code: 401. Error: unknown error`
Recomendación
Para resolver este error, debes otorgar el rol de Ejecutor de Cloud Data Fusion (roles/datafusion.runner) a la cuenta de servicio que usa Dataproc.
La canalización con el complemento de BigQuery falla con el error Access Denied
Existe un problema conocido en el que una canalización falla con un error Access Denied cuando se ejecutan trabajos de BigQuery. Esto afecta a las canalizaciones que usan los siguientes complementos:
- Fuentes de BigQuery
- Receptores de BigQuery
- Receptores de varias tablas de BigQuery
- Envío de transformaciones
Ejemplo de error en los registros (puede variar según el complemento que uses):
POST https://bigquery.googleapis.com/bigquery/v2/projects/PROJECT_ID/jobs
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Access Denied: Project xxxx: User does not have bigquery.jobs.create permission in project PROJECT_ID",
"reason" : "accessDenied"
} ],
"message" : "Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.",
"status" : "PERMISSION_DENIED"
}
En este ejemplo, PROJECT_ID es el ID del proyecto que especificaste en el complemento. La cuenta de servicio del proyecto especificado en el complemento no tiene permiso para realizar al menos una de las siguientes acciones:
- Ejecutar un trabajo de BigQuery
- Leer un conjunto de datos de BigQuery
- Crea un bucket temporal
- Cree un conjunto de datos de BigQuery
- Crea la tabla de BigQuery
Recomendación
Para resolver este problema, otorga los roles faltantes al proyecto (PROJECT_ID) que especificaste en el complemento:
Para ejecutar un trabajo de BigQuery, otorga el rol de usuario de trabajo de BigQuery (
roles/bigquery.jobUser).Para leer un conjunto de datos de BigQuery, otorga el rol de visualizador de datos de BigQuery (
roles/bigquery.dataViewer).Para crear un bucket temporal, otorga el rol de administrador de almacenamiento (
roles/storage.admin).Para crear un conjunto de datos o una tabla de BigQuery, otorga el rol de editor de datos de BigQuery (
roles/bigquery.dataEditor).
Para obtener más información, consulta la documentación de solución de problemas del complemento (Solución de problemas del receptor de varias tablas de Google BigQuery).
La canalización no se detiene en el umbral de error
Es posible que una canalización no se detenga después de varios errores, incluso si estableces el umbral de error en 1.
El umbral de error está diseñado para cualquier excepción que genere la directiva en caso de una falla que no se controle de otra manera. Si la directiva ya usa la API de emisor, significa que el umbral de error no está activado.
Recomendación
Para diseñar una canalización que falle cuando se alcanza un umbral determinado, usa la directiva FAIL.
Cuando se cumple la condición pasada a la directiva FAIL, se cuenta de acuerdo con el umbral de error y la canalización falla después de que se alcanza el límite.
El complemento de fuente por lotes de Oracle convierte NUMBER en string
En las versiones de origen por lotes de Oracle 1.9.0, 1.8.3 y anteriores, el tipo de datos NUMBER de Oracle, con precisión y escala indefinidos, se asigna al tipo de datos decimal(38,0) de CDAP.
Las versiones de complementos 1.9.1, 1.8.4 y 1.8.5 son incompatibles con versiones anteriores, y las canalizaciones que usan versiones anteriores podrían no funcionar después de actualizar a las versiones 1.9.1, 1.8.5 y 1.8.4, si una etapa descendente en la canalización se basa en el esquema de salida de la fuente porque el esquema de salida cambió. Cuando hay un esquema de salida definido para el tipo de datos NUMBER de Oracle definido sin precisión y escala en la versión anterior del complemento, después de actualizar a las versiones 1.9.1, 1.8.5 o 1.8.4, el complemento de fuente por lotes de Oracle arroja el siguiente error de discrepancia de esquema para los tipos: Schema field '<field name>' is expected to
have type 'decimal with precision <precision> and scale <scale> but found
'string'. Change the data type of field <field name> to string.
Las versiones 1.9.1, 1.8.5 y 1.8.4 funcionarán con un esquema de salida del tipo de datos string de CDAP para el tipo de datos NUMBER de Oracle definido sin precisión y escalamiento. Si hay algún tipo de datos NUMBER de Oracle definido sin precisión y escala presente en el esquema de salida de origen de Oracle, no se recomienda usar la versión anterior del complemento de Oracle, ya que puede generar errores de redondeo.
El caso especial es cuando usas una macro para el nombre de la base de datos, del esquema o de la tabla, y si no especificaste de forma manual un esquema de salida. Se detecta y asigna el esquema en el entorno de ejecución. La versión anterior del complemento de fuente por lotes de Oracle asigna el tipo de datos NUMBER de Oracle definido sin precisión y escala al tipo de datos decimal(38,0) de CDAP, mientras que las versiones 1.9.1, 1.8.5, 1.8.4 y posteriores asignan los tipos de datos a string en el entorno de ejecución.
Recomendación
Para resolver el posible problema de pérdida de precisión mientras trabajas con los tipos de datos NUMBER de Oracle con precisión y escalamiento indefinidos, actualiza tus canalizaciones a fin de que usen las versiones 1.9.1, 1.8.5 o 1.8.4 del complemento de fuente por lotes de Oracle.
Después de la actualización, el tipo de datos NUMBER de Oracle definido sin precisión y escala se asigna al tipo de datos string de CDAP en el entorno de ejecución. Si tienes una etapa descendente o un receptor que consume el tipo de datos decimal de CDAP original (en el que se asignó el tipo de datos NUMBER de Oracle definido sin precisión y escala), actualízalo o espera que consuma datos de string.
Si comprendes el riesgo de una posible pérdida de datos debido a errores de redondeo, pero eliges usar el tipo de datos NUMBER de Oracle definido sin precisión y escala como tipo de datos decimal(38,0) de CDA, implementa el complemento de Oracle versión 1.8.6 (para Cloud Data Fusion 6.7.3) o 1.9.2 (para Cloud Data Fusion 6.8.1) desde Hub y actualiza las canalizaciones a fin de usarlas en su lugar.
Para obtener más información, consulta la referencia de fuente por lotes de Oracle.
Borra un clúster efímero de Dataproc
Cuando Cloud Data Fusion crea un clúster efímero de Dataproc durante el aprovisionamiento de ejecución de la canalización, el clúster se borra después de que finaliza la ejecución de la canalización. En casos excepcionales, la eliminación del clúster falla.
Muy recomendada: Actualiza a la versión más reciente de Cloud Data Fusion para garantizar un mantenimiento adecuado del clúster.
Establecer tiempo de inactividad máximo
Para resolver este problema, configura la opción Max Idle Time. Esto permite que Dataproc borre clústeres automáticamente, incluso si falla una llamada explícita en la canalización.
Max Idle Time está disponible en las versiones 6.4 y posteriores de Cloud Data Fusion.
Recomendación: Para versiones anteriores a la 6.6, configura Max Idle Time de forma manual en 30 minutos o más.
Borra clústeres de forma manual
Si no puedes actualizar tu versión o configurar la opción Max Idle Time, borra los clústeres inactivos de forma manual:
Obtén cada ID del proyecto en el que se crearon los clústeres:
En los argumentos del entorno de ejecución de la canalización, verifica si el ID del proyecto de Dataproc está personalizado para la ejecución.
Si no se especifica un ID del proyecto de Dataproc de forma explícita, determina qué aprovisionador se usa y, luego, verifica un ID del proyecto:
En los argumentos del entorno de ejecución de la canalización, verifica el valor
system.profile.name.
Abre la configuración del aprovisionador y verifica si el ID del proyecto de Dataproc está configurado. Si la configuración no está presente o el campo está vacío, se usa el proyecto en el que se ejecuta la instancia de Cloud Data Fusion.
Para cada proyecto:
Abre el proyecto en la consola de Google Cloud y ve a la página Clústeres de Dataproc.
Ordena los clústeres por la fecha en que se crearon, de los más antiguos a los más recientes.
Si el panel de información está oculto, haz clic en Mostrar panel de información y ve a la pestaña Etiquetas.
Por cada clúster que no esté en uso (por ejemplo, si haya transcurrido más de un día), verifica si tienen una etiqueta de versión de Cloud Data Fusion. Esta es una indicación de que se creó con Cloud Data Fusion.
Selecciona la casilla de verificación junto al nombre del clúster y haz clic en Borrar.
No se pudo crear la instancia de Cloud Data Fusion
Cuando crees una instancia de Cloud Data Fusion, es posible que encuentres el siguiente problema:
Read access to project PROJECT_NAME was denied.
Recomendación
Para resolver este problema, inhabilite y vuelva a habilitar la API de Cloud Data Fusion. Luego, crea la instancia.
Las canalizaciones fallan cuando se ejecutan en clústeres de Dataproc con trabajadores secundarios
En las versiones 6.8 y 6.9 de Cloud Data Fusion, se produce un problema que causa que las canalizaciones fallen si se ejecutan en clústeres de Dataproc en los que están habilitados los trabajadores secundarios:
ERROR [provisioning-task-2:i.c.c.i.p.t.ProvisioningTask@161] - PROVISION task failed in REQUESTING_CREATE state for program run program_run:default.APP_NAME.UUID.workflow.DataPipelineWorkflow.RUN_ID due to
Caused by: io.grpc.StatusRuntimeException: CANCELLED: Failed to read message.
Caused by: com.google.protobuf.GeneratedMessageV3$Builder.parseUnknownField(Lcom/google/protobuf/CodedInputStream;Lcom/google/protobuf/ExtensionRegistryLite;I)Z.
Recomendación
Para resolver el problema, quita los nodos trabajadores secundarios de las siguientes maneras.
Si usas un aprovisionador efímero de Dataproc, resuelve el error con estos pasos:
- Ve a tu canalización en la interfaz web de Cloud Data Fusion.
- En los argumentos del entorno de ejecución de la canalización, establece
system.profile.properties.secondaryWorkerNumNodesen0.
- Haz clic en Guardar.
- Si usas un espacio de nombres, inhabilita a los trabajadores secundarios en él:
- Haz clic en Administrador del sistema > Espacios de nombres y selecciona el espacio de nombres.
- Haz clic en Preferencias > Editar.
- Establece el valor de
system.profile.properties.secondaryWorkerNumNodesen0.
- Haz clic en Guardar y cerrar.
Si usas un aprovisionador de Dataproc existente, resuelve el error con estos pasos:
En la consola de Google Cloud, ve a la página Clústeres de Dataproc.
Selecciona el clúster y haz clic en Editar.
En el campo Nodos trabajadores secundarios, ingresa
0.
Haz clic en Guardar.