Solución:
Fraccionamiento los datos se utilizan a menudo para distribuir la carga horizontalmente, esto tiene un beneficio de rendimiento y ayuda a organizar los datos de una manera lógica. Ejemplo: si se trata de una gran employee tabla y, a menudo, ejecutar consultas con WHERE cláusulas que restringen los resultados a un país o departamento en particular. Para una respuesta de consulta más rápida, la tabla Hive puede ser PARTITIONED BY (country STRING, DEPT STRING). Las tablas de particionamiento cambian la forma en que Hive estructura el almacenamiento de datos y Hive ahora creará subdirectorios que reflejan la estructura de particionamiento 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 directorio country=ABC. Esto puede mejorar drásticamente el rendimiento de las consultas, pero solo si el esquema de partición refleja un 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 sobrecargan a NameNode, ya que debe mantener todos los metadatos del sistema de archivos en la memoria.
Agrupamiento es otra técnica para descomponer conjuntos de datos en partes más manejables. Por ejemplo, suponga que una tabla usa date como la partición de nivel superior y employee_id ya que la partición de segundo nivel conduce a demasiadas particiones pequeñas. En cambio, si cubrimos la tabla de empleados y usamos employee_id como la columna de agrupamiento, el valor de esta columna se dividirá en grupos con un número definido por el usuario. Registros con el mismo employee_id siempre se almacenará en el mismo cubo. Suponiendo el número de employee_id es mucho mayor que la cantidad de cubetas, cada cubeta tendrá muchos employee_id. Mientras crea la tabla, puede especificar como CLUSTERED BY (employee_id) INTO XX BUCKETS; donde XX es el número de cubos. El agrupamiento tiene varias ventajas. El número de depósitos es fijo, por lo que no fluctúa con los datos. Si dos tablas están agrupadas por employee_id, Hive puede crear un muestreo lógicamente correcto. El agrupamiento también ayuda a realizar uniones eficientes en el lado del mapa, etc.
Faltan algunos detalles en las explicaciones anteriores. Para comprender mejor cómo funciona la partición y el agrupamiento, debe observar cómo se almacenan los datos en Hive. 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
luego Hive 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, particiona 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 puede tener un campo. Por ejemplo, si tiene un campo de ‘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 miles de millones. En general, al elegir un campo para particionar, no debe tener una cardinalidad alta, porque terminará con demasiados directorios en su sistema de archivos.
Por otro lado, la agrupación en clústeres, también conocida como agrupación, dará como resultado un número fijo de archivos, ya que usted especifica la cantidad de depósitos. Lo que hará Hive es tomar el campo, calcular un hash y asignar un registro a ese depósito. Pero, ¿qué sucede si usa, digamos, 256 depósitos y el campo en el que está agrupando tiene una cardinalidad baja (por ejemplo, es un estado de EE. UU., Por lo que solo puede tener 50 valores diferentes)? Tendrá 50 depósitos con datos y 206 depósitos sin datos.
Alguien ya mencionó cómo las particiones pueden reducir drásticamente la cantidad de datos que está consultando. Entonces, en mi tabla de ejemplo, si desea consultar solo desde una fecha determinada en adelante, la partició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 combinaciones con otras tablas. que tienen exactamente el mismo agrupamiento, entonces, en mi ejemplo, si está uniendo dos tablas en el mismo employee_id, hive puede hacer la unión cubo por cubo (incluso mejor si ya están ordenados por employee_id, ya que va a combinar partes que ya están ordenadas, lo que funciona en tiempo lineal también conocido como O (n)).
Por lo tanto, el agrupamiento funciona bien cuando el campo tiene una cardinalidad alta y los datos se distribuyen uniformemente entre los grupos. La partición funciona mejor cuando la cardinalidad del campo de partición no es demasiado alta.
También, puede particionar en varios campos, con un pedido (año / mes / día es un buen ejemplo), mientras que puede depositar en un solo campo.
Creo que llegué tarde a responder esta pregunta, pero sigue apareciendo en mi feed.
Navneet ha proporcionado una excelente respuesta. Añadiendo visualmente.
El particionamiento ayuda en la eliminación de datos, si se usa en la cláusula WHERE, mientras que el agrupamiento ayuda a organizar los datos de cada partición en varios archivos, por lo que el mismo conjunto de datos siempre se escribe en el mismo depósito. Ayuda mucho en la unión de columnas.
Supongamos que tiene una tabla con cinco columnas, nombre, fecha_servidor, algunos_col3, algunos_col4 y algunos_col5. Suponga que ha dividido la tabla en fecha_servidor y agrupados en nombre columna en 10 cubos, la estructura de su archivo se verá similar a la siguiente.
- fecha_servidor = xyz
- 00000_0
- 00001_0
- 00002_0
- ……..
- 00010_0
Aquí fecha_servidor = xyz es la partición y 000 los archivos son los depósitos en cada partición. Los depósitos se calculan en función de algunas funciones hash, por lo que las filas con nombre = Sandy siempre irá en el mismo cubo.