Desalineación y dificultades de la tabla de campos insertada en Hive
Primero, pruebe la consulta de los datos de la tabla de origen:
La consulta. los datos no ocurren. De hecho, no hay ningún problema si ve los datos campo por campo y luego inserta los datos campo por campo. De hecho, la inserción de un panal no es exactamente lo que uno imaginaría que sería una inserción tradicional.
Dado que no es toda la tabla la que está desalineada, sino filas individuales, primero consultamos las filas desalineadas en la colmena en función de las palabras clave y exportamos el texto al local. Descubrí que algunos de ellos eran "caracteres confusos" (caracteres anormales: ^M, si tiene experiencia, puede ver que esto es \001, que se puede exportar con Ctrl + a en vim). por caracteres anormales, así que pasé El comando od de Linux verificó la codificación hexadecimal, como se muestra en la figura: hay varios \001, lo cual es muy familiar: este es el separador de campo predeterminado de Hive.
Generalmente, al insertar A desde la selección B, no prestaremos atención al delimitador de campo de la tabla A. Cuando vemos \001, intuimos que está relacionado con el delimitador de campo de la tabla A:
Al observar la estructura de la tabla de A, el delimitador de campo por defecto es \001. Tipo de almacenamiento: archivo de texto.
Análisis adicional: el archivo de texto es la estructura de almacenamiento predeterminada de Hive, que es el almacenamiento en filas. La estructura de datos real es consistente con la estructura lógica de la tabla. Al importar datos, los archivos de datos se copian directamente a HDFS sin procesarlos. El archivo fuente se puede ver directamente a través de hadoop fs -cat, por ejemplo, delimitador de campo de texto: \001, nueva línea: \002, delimitador de campo de texto: \003, nueva línea: \004: \001, nueva línea: en el texto Lo invisible El carácter \001 se inserta en una tabla que utiliza \001 como separador de campos, lo que provoca una desalineación de los campos de consulta.
Veamos este SQL nuevamente:
Podemos restaurar todo el proceso de este SQL desde la inserción hasta la excepción de consulta:
El primer método es factible. también es más razonable;
El segundo método es factible y es un remedio, pero formatos como orc no admiten operaciones de carga.
El tercer método resuelve un Una solución temporal no puede resolver fundamentalmente el problema;
El tercer método es una solución temporal, pero no puede resolver fundamentalmente el problema.
El tercer método es improvisar y no puede resolver el problema fundamentalmente.
El conocimiento básico de la colmena es insuficiente, lo que resulta en una resolución de problemas lenta.
Se debe realizar la limpieza ETL necesaria de los datos de origen y los delimitadores de campo se deben manejar con cuidado.
Las tablas de Hive intentan utilizar métodos de almacenamiento como el parquet orc, que consume menos espacio y mejora en gran medida la eficiencia de las consultas en comparación con los archivos de texto. Al mismo tiempo, puede evitar problemas como la separación y desalineación de campos.
Obtén más información sobre cómo se implementa Hive Orc.
Obtén más información sobre cómo se implementa Hive Orc.