Principios de Hive CBO

Principios de Hive CBO

CBO es la abreviatura de Optimización Basada en Costos.

Optimizará lo siguiente:

Durante la compilación, el CBO calcula la secuencia de unión más eficiente basándose en tablas y condiciones de consulta implicadas en las sentencias de consulta para reducir el tiempo y los recursos necesarios para la consulta.

En Hive, la CBO se implementa de la siguiente manera:

Hive utiliza el componente de código abierto Apache Calcite para implementar la CBO. Las sentencias SQL se convierten primero en Hive Abstract Syntax Trees (ASTs) y luego en RelNodes que pueden ser identificados por Calcita. Después de que Calcita ajusta la secuencia de unión de RelNodes, RelNodes se convierten en ASTs por Hive para continuar la optimización lógica y física. Figura 1 muestra el flujo de trabajo.

Figura 1 Proceso de implementación de CBO

Calcita ajusta la secuencia de unión de la siguiente manera:

1. Una tabla se selecciona como la primera tabla de las tablas que se van a unir.
2. Las tablas segunda y tercera se seleccionan en función del costo. De esta manera, se obtienen múltiples planes de ejecución diferentes.
3. Se calcula un plan con los costes mínimos y sirve como la secuencia final.

El método de cálculo de costes es el siguiente:

En la versión actual, los costes se miden en función del número de entradas de datos tras la unión. Menos entradas de datos significan menos costo. El número de entradas de datos unidas depende de la tasa de selección de las tablas unidas. El número de entradas de datos en una tabla se obtiene basándose en las estadísticas a nivel de tabla.

El número de entradas de datos en una tabla después del filtrado se estima en función de las estadísticas a nivel de columna, incluidos los valores máximos (max), valores mínimos (min) y Número de valores distintos (NDV).

Por ejemplo, hay una tabla table_a cuyo número total de registros de datos es de 1,000,000 y NDV es de 50. Las condiciones de consulta son las siguientes:

Select * from table_a where colum_a='value1';

El número estimado de entradas de datos consultadas es: 1,000,000 x 1/50 = 20,000. La tasa de selección es del 2%.

A continuación se toma el TPC-DS Q3 como ejemplo para describir cómo el CBO ajusta la secuencia de join:

select 
    dt.d_year, 
    item.i_brand_id brand_id, 
    item.i_brand brand, 
    sum(ss_ext_sales_price) sum_agg 
from 
    date_dim dt, 
    store_sales, 
    item 
where 
    dt.d_date_sk = store_sales.ss_sold_date_sk 
    and store_sales.ss_item_sk = item.i_item_sk 
    and item.i_manufact_id = 436 
    and dt.d_moy = 12 
group by dt.d_year , item.i_brand , item.i_brand_id 
order by dt.d_year , sum_agg desc , brand_id 
limit 10;

Explicación de la sentencia: Esta sentencia indica que la unión interna se realiza para tres tablas: la tabla store_sales es una tabla de hechos con alrededor de 2,900,000,000 entradas de datos, la tabla date_dim es una tabla de dimensiones con alrededor de 73,000 entradas de datos y la tabla item es una tabla de dimensiones con alrededor de 18,000 entradas de datos. Cada tabla tiene condiciones de filtrado. Figura 2 muestra la relación de join.

Figura 2 Relación de join

El CBO debe seleccionar primero las tablas que ofrecen el mejor efecto de filtrado para la unión.

Analizando min, max, NDV y el número de entradas de datos, el CBO estima las tasas de selección de diferentes tablas de dimensiones, como se muestra en Tabla 1.

La tasa de selección se puede estimar de la siguiente manera: Tasa de selección = Número de entradas de datos después del filtrado/Número de entradas de datos originales

Como se muestra en la tabla anterior, la tabla item tiene un mejor efecto de filtrado. Por lo tanto, el CBO se une a la tabla item primero antes de unirse a la tabla date_dim.

Figura 3 muestra el proceso de join cuando el CBO está deshabilitado.

Figura 3 Proceso de join cuando la CBO está deshabilitada

Figura 4 muestra el proceso de join cuando el CBO está habilitado.

Figura 4 Proceso de join cuando el CBO está habilitado

Después de habilitar el CBO, el número de entradas de datos intermedias se reduce de 495,000,000 a 2,900,000 y, por lo tanto, el tiempo de ejecución se puede reducir notablemente.