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

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

La partición de datos a menudo se usa para distribuir la carga horizontalmente, esto tiene un beneficio de rendimiento y ayuda a organizar los datos de manera lógica. Ejemplo : si se trata de una employeetabla grande y, a menudo, ejecutamos consultas con WHEREclá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 reflejen la estructura de partición como

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

Si la consulta limita para el empleado 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 el filtrado común. La función de partición 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 que 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 para el sistema de archivos en la memoria.

El agrupamiento es otra técnica para descomponer conjuntos de datos en partes más manejables. Por ejemplo, suponga que una tabla que se usa datecomo partición de nivel superior y employee_idcomo partición de segundo nivel conduce a demasiadas particiones pequeñas. En cambio, si agrupamos la tabla de empleados y la utilizamos employee_idcomo columna de agrupación, el valor de esta columna se dividirá en un grupo definido por el usuario. Los registros con el mismo employee_id siempre se almacenarán en el mismo depósito. Suponiendo que el número de employee_ides mucho mayor que el número de cubos, cada cubo tendrá muchos employee_id. Al crear la tabla, puede especificar comoCLUSTERED BY (employee_id) INTO XX BUCKETS;donde XX es el número de cubos. Bucketing 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 employee_id, Hive puede crear un muestreo lógicamente correcto. Bucketing también ayuda a hacer eficientes uniones en el lado del mapa, etc.

Faltan algunos detalles de las explicaciones anteriores. Para comprender mejor cómo funciona el particionamiento y el almacenamiento, debe observar 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

luego 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, realiza la 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 puede tener un campo. 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 la partición, no debe tener una alta cardinalidad, porque terminará con demasiados directorios en su sistema de archivos.

Por otro lado, la agrupación también conocida como "bucketing" dará como resultado una cantidad fija de archivos, ya que usted especifica la cantidad de buckets. Lo que hará la colmena es tomar el campo, calcular un hash y asignar un registro a ese cubo. Pero, ¿qué sucede si usa, digamos, 256 cubos y el campo en el que está colgando tiene una cardinalidad baja (por ejemplo, es un estado de EE. UU., Por lo que puede tener 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. Entonces, en mi tabla de ejemplo, si desea consultar solo a partir de una determinada fecha, la partición por año / mes / día reducirá drásticamente la cantidad de E / S. 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 está uniendo dos tablas en el mismo employee_id, la colmena puede unir el bloque por cubo (aún mejor si ya están ordenados por employee_id ya que va a fusionar partes que ya están ordenadas, lo que funciona en tiempo lineal, también conocido como O (n)).

Por lo tanto, el depósito funciona bien cuando el campo tiene una alta cardinalidad y los datos se distribuyen uniformemente entre los depósitos. La partición funciona mejor cuando la cardinalidad del campo de partición no es demasiado alta.

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

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

Navneet ha proporcionado una excelente respuesta. Agregando a esto visualmente.

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

Supongamos que tiene una tabla con cinco columnas, name, server_date, some_col3, some_col4 y some_col5. Supongamos que ha particionado la tabla en server_date y se ha agrupado en la columna de nombre en 10 cubos, la estructura de su archivo se verá como a continuación.

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

Aquí server_date = xyz es la partición y 000 archivos son los cubos 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án en el mismo depósito.

Particionamiento de colmena:

La partición divide una gran cantidad de datos en varios sectores según el valor de una columna o columnas de la tabla.

Suponga que está almacenando información de personas en todo el mundo repartidas en más de 196 países que abarcan alrededor de 500 millones de entradas. Si desea consultar a personas de un país en particular (ciudad del Vaticano), en ausencia de particiones, debe escanear las 500 millones de entradas incluso para obtener mil entradas de un país. Si particiona la tabla en función del país, puede ajustar el proceso de consulta simplemente comprobando los datos de solo una partición de país. La partición de Hive crea un directorio separado para el valor de una columna (s).

Pros:

1. Distribuya 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 la " ciudad del Vaticano " vuelve muy rápido en lugar de buscar en toda la población del mundo.

Contras:

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

Colmena de colmena:

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

Con la partición, existe la posibilidad de que pueda crear múltiples particiones pequeñas basadas en valores de columna. Si opta por el depósito, 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 cargar manualmente el mismo volumen de datos.

Antes de entrar Bucketing, necesitamos entender qué Partitioninges. Tomemos la siguiente tabla como ejemplo. Tenga en cuenta que solo he dado 12 registros en el ejemplo a continuación para la comprensión de nivel principiante. En escenarios en tiempo real, es posible que tenga millones de registros.

PARTICIONAMIENTO
---------------------
Partitioning se utiliza para obtener rendimiento mientras se consultan los datos. Por ejemplo, en la tabla anterior, si escribimos el siguiente sql, debe escanear todos los registros de la tabla, lo que reduce el rendimiento y aumenta la sobrecarga.

select * from sales_table where product_id='P1'

Para evitar el escaneo completo de la tabla y leer solo los registros relacionados product_id='P1', podemos particionar (dividir los archivos de la tabla de la colmena) en varios archivos según la product_idcolumna. De esta manera, el archivo de la tabla de la colmena se dividirá en dos archivos, uno con product_id='P1'y otro con product_id='P2'. Ahora, cuando ejecutamos la consulta anterior, escaneará solo el product_id='P1'archivo.

../hive/warehouse/sales_table/product_id=P1
../hive/warehouse/sales_table/product_id=P2

La sintaxis para crear la partición se proporciona a continuación. Tenga en cuenta que no debemos usar la product_iddefinición de columna junto con las columnas no particionadas en la sintaxis a continuación. Esto debería estar solo en la partitioned bycláusula.

create table sales_table(sales_id int,trans_date date, amount int) 
partitioned by (product_id varchar(10))

Contras : debemos tener mucho cuidado al realizar la partición. Es decir, no debe usarse para las columnas donde el número de valores repetidos es muy inferior (especialmente las columnas de clave principal) ya que aumenta el número de archivos particionados y aumenta la sobrecarga para el Name node.

BUCKETING
------------------
Bucketing se usa para superar lo consque mencioné en la sección de particionamiento. Esto debe usarse cuando hay muy pocos valores repetidos en una columna (ejemplo: columna de clave principal). Esto es similar al concepto de índice en la columna de clave primaria en el RDBMS. En nuestra tabla, podemos tomar la Sales_Idcolumna para el bucketing. Será útil cuando necesitemos consultar la sales_idcolumna.

A continuación se muestra la sintaxis para el bucketing.

create table sales_table(sales_id int,trans_date date, amount int) 
partitioned by (product_id varchar(10)) Clustered by(Sales_Id) into 3 buckets

Aquí dividiremos aún más los datos en unos pocos archivos más en la parte superior de las particiones.

Como hemos especificado 3depósitos, se divide en 3 archivos cada uno para cada uno product_id. Se usa internamente modulo operatorpara determinar en qué cubo se sales_iddebe almacenar cada uno . Por ejemplo, para product_id='P1', sales_id=1se almacenará en el archivo 000001_0 (es decir, 1% 3 = 1), sales_id=2se almacenará en el archivo 000002_0 (es decir, 2% 3 = 2), sales_id=3se almacenará en el archivo 000000_0 (es decir, 3% 3 = 0) etc.

La diferencia está cántaros divide los archivos por Nombre de la columna, y la partición divide los archivos en una mesa dentro Por un valor particular

Ojalá lo haya definido correctamente

Hay excelentes respuestas aquí. Me gustaría mantenerlo breve para memorizar la diferencia entre partición y cubos.

Generalmente particiona en una columna menos única. Y ahorrando en la columna más singular.

Ejemplo si considera la población mundial con país, nombre de persona y su identificación biométrica como ejemplo. Como puede adivinar, el campo del país sería la columna menos exclusiva y la identificación biométrica sería la columna más exclusiva. Entonces, idealmente, necesitaría dividir la tabla por país y agruparla por identificación biométrica.

Usar particiones en la tabla Hive es muy recomendable por la siguiente razón:

• Insertar en la tabla de Hive debería ser más rápido (ya que usa múltiples hilos para escribir datos en particiones)
• La consulta de la tabla Hive debe ser eficiente con baja latencia.

Ejemplo:

Suponga que el archivo de entrada (100 GB) se carga en la tabla temporal-colmena y contiene datos bancarios de diferentes geografías.

Mesa colmena sin particion

Insert into Hive table Select * from temp-hive-table

/hive-table-path/part-00000-1  (part size ~ hdfs block size)
/hive-table-path/part-00000-2
....
/hive-table-path/part-00000-n

El problema con este enfoque es: analizará datos completos para cualquier consulta que ejecute en esta tabla. El tiempo de respuesta será alto en comparación con otros enfoques en los que se utilizan particiones y Bucketing.

Mesa de colmena con partición

Insert into Hive table partition(country) Select * from temp-hive-table

/hive-table-path/country=US/part-00000-1       (file size ~ 10 GB)
/hive-table-path/country=Canada/part-00000-2   (file size ~ 20 GB)
....
/hive-table-path/country=UK/part-00000-n       (file size ~ 5 GB)

Pros: aquí se puede acceder a los datos más rápido cuando se trata de consultar datos para transacciones geográficas específicas. Contras: la inserción / consulta de datos puede mejorarse aún más dividiendo los datos dentro de cada partición. Ver la opción de Bucketing a continuación.

Mesa de colmena con partición y bucketing

Nota: Cree una tabla de colmena ..... con "CLUStered BY (Partiton_Column) en 5 cubos

Insert into Hive table partition(country) Select * from temp-hive-table

/hive-table-path/country=US/part-00000-1       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-2       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-3       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-4       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-5       (file size ~ 2 GB)

/hive-table-path/country=Canada/part-00000-1   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-2   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-3   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-4   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-5   (file size ~ 4 GB)

....
/hive-table-path/country=UK/part-00000-1       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-2       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-3       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-4       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-5       (file size ~ 1 GB)

Pros: inserción más rápida. Consulta más rápida

Contras: Bucketing creará más archivos. Podría haber problemas con muchos archivos pequeños en algunos casos específicos

Espero que esto ayude !!