hadoop - spark - hive summoners war

¿Cuál es la diferencia entre dividir y dividir una tabla en Hive?

Question

Sé que ambos se realizan en una columna de la tabla, pero ¿cómo es diferente cada operación?

Answer 1

Creo que llegué tarde a responder esta pregunta, pero sigue apareciendo en mi feed.

Navneet ha proporcionado una respuesta excelente. Añadiéndole visualmente.

El particionamiento ayuda a eliminar los datos, si se usan en la cláusula WHERE, donde el agrupamiento ayuda a organizar los datos en cada partición en varios archivos, de modo que el mismo conjunto de datos siempre se escribe en el mismo segmento. Ayuda mucho en la unión de columnas.

Supongamos que tiene una tabla con cinco columnas, nombre, fecha_servidor, alguna_col3, alguna_col4 y alguna_col5. Supongamos que ha dividido la tabla en server_date y la columna de nombre en 10 cubos, su estructura de archivos se verá más abajo.

1. server_date = xyz
   • 00000_0
   • 00001_0
   • 00002_0
   • ........
   • 00010_0

Aquí servidor_fecha = xyz es la partición y 000 archivos son los cubos en cada partición. Los cubos se calculan en función de algunas funciones hash, por lo que las filas con el nombre = Sandy siempre irán en el mismo cubo.

Answer 2

Faltan algunos detalles de las explicaciones anteriores. Para comprender mejor cómo funciona el particionamiento y el agrupamiento, debe ver cómo se almacenan los datos en la colmena. Digamos que tienes una mesa

CREATE TABLE mytable (
name string,
city string,
employee_id int )
PARTITIONED BY (year STRING, month STRING, day STRING)
CLUSTERED BY (employee_id) INTO 256 BUCKETS

entonces colmena almacenará datos en una jerarquía de directorios como

/user/hive/warehouse/mytable/y=2015/m=12/d=02

Por lo tanto, debe tener cuidado al particionar, porque si, por ejemplo, partición por employee_id y tiene millones de empleados, terminará teniendo millones de directorios en su sistema de archivos. El término " cardinalidad " se refiere al número de valores posibles que un campo puede tener. Por ejemplo, si tiene un campo ''país'', los países del mundo son aproximadamente 300, por lo que la cardinalidad sería ~ 300. Para un campo como ''timestamp_ms'', que cambia cada milisegundo, la cardinalidad puede ser de miles de millones. En general, al elegir un campo para particionar, no debería tener una alta cardinalidad, porque terminará con demasiados directorios en su sistema de archivos.

Por otra parte, la agrupación en clúster, al igual que el agrupamiento, dará como resultado una cantidad fija de archivos, ya que se especifica el número de segmentos. Lo que hará la colmena es tomar el campo, calcular un hash y asignar un registro a ese cubo. Pero, ¿qué ocurre si usa 256 cubetas y el campo en el que está trabajando tiene una cardinalidad baja (por ejemplo, es un estado de EE. UU., Por lo que puede haber solo 50 valores diferentes)? Tendrás 50 cubos con datos y 206 cubos sin datos.

Alguien ya mencionó cómo las particiones pueden reducir drásticamente la cantidad de datos que está consultando. Por lo tanto, en mi tabla de ejemplo, si desea consultar solo a partir de una determinada fecha hacia adelante, la división por año / mes / día reducirá drásticamente la cantidad de IO. Creo que alguien también mencionó cómo el agrupamiento puede acelerar las uniones con otras tablas que tienen exactamente el mismo agrupamiento , por lo que en mi ejemplo, si unes dos tablas en el mismo employee_id, colmena puede hacer el unir un cubo por cubo (incluso mejor) si ya están ordenados por employee_id ya que va a un mergesort que funciona en tiempo lineal).

Por lo tanto, el agrupamiento funciona bien cuando el campo tiene una cardinalidad alta y los datos se distribuyen uniformemente entre los segmentos. El particionamiento funciona mejor cuando la cardinalidad del campo de partición no es demasiado alta.

Además, puede realizar particiones en múltiples campos , con un orden (año / mes / día es un buen ejemplo), mientras que puede dividirlo en un solo campo .

Answer 3

La diferencia es que el agrupamiento divide los archivos por nombre de columna, y el particionamiento divide los archivos por debajo de un valor particular dentro de la tabla

Espero haberlo definido correctamente

Answer 4

Los datos de particionamiento a menudo se utilizan para distribuir la carga horizontalmente, esto tiene un beneficio en el rendimiento y ayuda a organizar los datos de una manera lógica. Ejemplo : si se trata de una tabla grande de employee y, a menudo, se ejecutan consultas con cláusulas WHERE que restringen los resultados a un país o departamento en particular. Para una respuesta más rápida, la tabla Hive puede PARTITIONED BY (country STRING, DEPT STRING) . Las tablas de particionado cambian cómo Hive estructura el almacenamiento de datos y Hive ahora creará subdirectorios que reflejen la estructura de particiones como

... / empleados / país = ABC / DEPT = XYZ .

Si los límites de consulta para el empleado de country=ABC , solo escaneará el contenido de un country=ABC directorio country=ABC . Esto puede mejorar drásticamente el rendimiento de las consultas, pero solo si el esquema de particiones refleja el filtrado común. La función de particionamiento es muy útil en Hive, sin embargo, un diseño que crea demasiadas particiones puede optimizar algunas consultas, pero puede ser perjudicial para otras consultas importantes. Otro inconveniente es tener demasiadas particiones es la gran cantidad de archivos y directorios de Hadoop que se crean innecesariamente y sobrecarga a NameNode, ya que debe mantener todos los metadatos del sistema de archivos en la memoria.

El almacenamiento en cubetas es otra técnica para descomponer conjuntos de datos en partes más manejables. Por ejemplo, supongamos que una tabla que utiliza date como la partición de nivel superior y employee_id como la partición de segundo nivel conduce a demasiadas particiones pequeñas. En cambio, si dividimos la tabla de empleados y usamos employee_id como la columna de ordenamiento, el valor de esta columna se dividirá en hash en un cubo definido por un número definido por el usuario. Los registros con el mismo employee_id siempre se almacenarán en el mismo contenedor. Suponiendo que el número de employee_id es mucho mayor que el número de cubos, cada contenedor tendrá muchos employee_id . Al crear la tabla, puede especificar CLUSTERED BY (employee_id) INTO XX BUCKETS; donde XX es el número de cubos. Cubo tiene varias ventajas. La cantidad de cubos es fija para que no fluctúe con los datos. Si employee_id incluye dos tablas, Hive puede crear un muestreo lógicamente correcto. Cubo también ayuda a hacer uniones de mapa eficiente, etc.

Answer 5

Partición de Colmena

La partición divide una gran cantidad de datos en múltiples sectores en función del valor de la (s) columna (s) de la tabla.

Supongamos que está almacenando información de personas en todo el mundo repartidas en más de 196 países que abarcan alrededor de 500 crores de entradas. Si desea consultar personas de un país en particular (Ciudad del Vaticano), en ausencia de particiones, debe escanear los 500 crores de entradas, incluso para obtener miles de entradas de un país. Si divide la tabla según el país, puede ajustar el proceso de consulta simplemente verificando los datos de una sola partición de país. La partición Hive crea un directorio separado para el valor de columna (s).

Pros:

1. Distribuir la carga de ejecución horizontalmente
2. Ejecución más rápida de consultas en caso de partición con bajo volumen de datos. Por ejemplo, obtener la población de " Ciudad del Vaticano " regresa muy rápido en lugar de buscar toda la población del mundo.

Contras:

1. Posibilidad de demasiadas creaciones de particiones pequeñas: demasiados directorios.
2. Eficaz para datos de bajo volumen para una partición dada. Pero algunas consultas como agrupar por alto volumen de datos aún tardan mucho tiempo en ejecutarse. Por ejemplo, la agrupación de la población de China llevará mucho tiempo en comparación con la agrupación de la población en la ciudad del Vaticano. La partición no resuelve el problema de la capacidad de respuesta en caso de sesgo de datos hacia un valor de partición particular.

Cubo de la colmena

El almacenamiento en bloques descompone los datos en partes más manejables o iguales.

Con el particionamiento, existe la posibilidad de que pueda crear múltiples particiones pequeñas basadas en valores de columna. Si opta por el agrupamiento, está restringiendo el número de depósitos para almacenar los datos. Este número se define durante los scripts de creación de tablas.

Pros

1. Debido a volúmenes iguales de datos en cada partición, las uniones en el lado del Mapa serán más rápidas.
2. Respuesta de consulta más rápida, como particionamiento

Contras

1. Puede definir el número de depósitos durante la creación de la tabla, pero los programadores deben realizar la carga de igual volumen de datos manualmente.