SparkThriftserver no puede ejecutar HDFS_DELEGATION_TOKEN durante mucho tiempo
Después de ejecutar sparkThriftserver durante un día, alguien informó que la consulta reportó un error. Lo probé yo mismo y efectivamente fue así.
Aquí, aprendí sobre HDFS_DELEGATION_TOKEN y luego respondí. esta pregunta
/apache/spark/pull/9168 arriba. Explicaré brevemente la causa del problema.
En el modo hadoop HA, hay tres tokens
1. ha token
2. namenode1 token
3. namenode2 token
Spark actualiza el token ha llamando a UserGroupInformation.getCurrentUser.addCredentials(tempCreds) y copia el token ha en el token de namenode a través de HAUtil.cloneDelegationTokenForLogicalUri.
Spark agregó dos parámetros "-keytab" y "-principal" para resolver fallas de DT, que especifican las claves utilizadas para el archivo de tabla de claves de inicio de sesión de Kerberos y el principal, respectivamente.
El parámetro --keytab especifica un archivo keytab. Spark generará un token HDFS basado en el archivo de autenticación Kerberos especificado por --keytab y luego colocará la información del token generado en un directorio en HDFS para que sea utilizado por. Ejecutor y Conductor.
Cuando el token de autorización está a punto de caducar (75 del intervalo de actualización), Spark ApplicationMaster se volverá a autenticar y obtendrá un nuevo token de autorización del archivo Keytab, y luego escribirá el nuevo token de autorización en el especificado. Directorio HDFS. token al archivo HDFS especificado;
Spark Executor leerá el archivo de token de autorización más reciente en HDFS cuando el token de autorización esté a punto de caducar (período de validez 80) y luego actualizará su propio token de autorización
En teoría, esto resuelve el problema de la caducidad del token, pero sigue siendo un problema en los clústeres de Hadoop configurados con HA antes de la versión 2.9.0. Porque en un clúster de Hadoop configurado con HA, el ejecutor solo actualizará la dirección lógica de HDFS después de leer la nueva información del token sin sincronizar la actualización con el Namenode HDFS real. El token correspondiente al URI de Namenode HDFS real no se actualizará sincrónicamente, lo que hará que el token bajo el URI de Namenode caduque lentamente.
1.Spark AM obtendrá el token de autorización HDFS (llamado hatoken) y lo agregará a las credenciales del usuario actual.
"ha-hdfs: hadoop-namenode" -gt; "Tipo: HDFS_DELEGATION_TOKEN, Servicio: ha-hdfs: hadoop-namenode, Ident: (HDFS_DELEGATION_TOKEN token 328709 para prueba)".
2.DFSClient generará otros 2 tokens (tokens de namenode) para cada NameNode.
"ha-hdfs://xxx.xxx.xxx.xxx:8020" -gt; "Tipo: HDFS_DELEGATION_TOKEN, Servicio: xxx.xxx.xxx.xxx:8020, Ident: (token HDFS_DELEGATION_TOKEN 328709 para prueba)"
" ha-hdfs://yyyy:yyyy:yyyy:yyyy:8020 " -gt; "Tipo: HDFS_DELEGATION_TOKEN, Servicio: yyyy:yyyy:yyyy:8020, Ident: ( HDFS_DELEGATION_TOKEN token 328709 para prueba)"
3. Cuando Spark actualiza el token ha, DFSClient no generará automáticamente el token de namenode.
El DFSClient solo se comunicará con 2 Namenodes utilizando tokens de namenode.
4 FileSystem tiene un caché; al llamar a FileSystem.get se obtendrá un DFSClient almacenado en caché con el antiguo token de namenode.
Spark solo actualizará el token ha, pero DFSClient usará el token namenode.
Por lo tanto, provocará una falla
Deshabilite el almacenamiento en caché configurando con spark.hadoop.fs.hdfs.impl.disable.cache=true y obtenga el último DFSClient para actualizar el token de namenode.
Relacionado