Diseñar e implementar un esquema de partición de datos

La creación de particiones de datos afecta directamente a la eficacia de la ejecución de las consultas y a la cantidad de recursos de proceso que consume. Al particionar una tabla, los datos se dividen en segmentos discretos en función de los valores de columna, lo que permite que el motor de consultas lea solo las partes pertinentes del conjunto de datos. Este enfoque, denominado eliminación de particiones, puede reducir drásticamente los exámenes de datos cuando los filtros se alinean con los límites de partición.

Considere la posibilidad de que una empresa minorista procese millones de transacciones de ventas diarias. Los analistas suelen consultar datos por intervalos de fechas para generar informes semanales, comparar tendencias mensuales a mes y analizar patrones estacionales. Sin particiones, cada consulta examina todo el historial de transacciones. Con la creación de particiones adecuada por fecha, las consultas de una semana específica solo tocan una fracción de los archivos almacenados.

Determinar cuándo se aplica la creación de particiones

Databricks recomienda no crear particiones de tablas que contengan menos de 1 TB de datos. En el caso de las tablas más pequeñas, la sobrecarga de administrar metadatos de partición y la posibilidad de crear muchos archivos pequeños supera las ventajas de rendimiento de las consultas. Las tablas Delta sin particiones en versiones recientes de Databricks Runtime se benefician automáticamente de la agrupación en clústeres de tiempo de ingesta, lo que proporciona ventajas de consulta similares sin configuración explícita.

Cuando las tablas superan los 1 TB, la creación de particiones se convierte en una técnica de optimización valiosa. A esta escala, las ventajas de leer solo los segmentos de datos relevantes compensan significativamente los costos de administración de particiones. La creación de particiones también permite el procesamiento paralelo, ya que Spark puede distribuir diferentes particiones entre nodos de clúster para la ejecución simultánea.

En el caso de tablas muy grandes en el rango de cientos de terabytes, la creación de particiones ofrece aún más ventajas. A esta escala, la eliminación de particiones reduce drásticamente la cantidad de datos que el motor de consultas necesita procesar, lo que mejora tanto el rendimiento como la rentabilidad.

Elección de claves de partición eficaces

La selección de clave de partición requiere que comprenda las características de los datos y los patrones de consulta. Las claves de partición eficaces comparten rasgos comunes que maximizan las ventajas de rendimiento a la vez que evitan problemas comunes.

Las columnas de cardinalidad baja funcionan mejor

Elija columnas con un número limitado de valores distintos. Las columnas de fecha, las regiones geográficas, las categorías de producto y los campos de estado hacen excelentes claves de partición porque crean un número manejable de particiones. Una columna con miles o millones de valores únicos, como el identificador de cliente o el identificador de transacción, conduce a un exceso de particiones y un rendimiento deficiente.

Por ejemplo, particionar una tabla de ventas por sale_date a nivel diario podría crear 365 particiones por año. Si cada día contiene suficiente volumen de datos, esta granularidad funciona bien. Sin embargo, la creación de particiones por sale_timestamp en el segundo nivel crearía millones de particiones, cada una con datos mínimos.

Alineación con patrones de consulta

La clave de partición debe coincidir con las columnas que los usuarios filtran con más frecuencia. Si los analistas consultan de forma coherente los datos de ventas por intervalos de fechas, la creación de particiones por fecha permite una eliminación eficaz. Si las consultas filtran principalmente por región, considere la región como clave de partición en su lugar.

Cuando existen varios patrones de filtro, priorice las consultas más comunes o críticas para el rendimiento. Puede definir un esquema de partición por tabla, por lo que elija columnas que beneficien a la mayoría de la carga de trabajo. Para patrones de consulta significativamente diferentes, considere la posibilidad de crear vistas materializadas o tablas de resumen optimizadas independientes para casos de uso específicos.

Considerar el crecimiento de los datos a lo largo del tiempo

Seleccione un esquema de partición que se escale correctamente a medida que crezcan los datos. La creación de particiones por año funciona correctamente inicialmente, pero podría crear particiones demasiado grandes con el tiempo. Por el contrario, la creación de particiones por hora podría funcionar para datos de gran volumen, pero crea demasiadas particiones pequeñas para volúmenes moderados.

Evalúe la tasa de crecimiento de datos esperada al elegir la granularidad de partición. Un equilibrio entre el tamaño de la partición y el número de particiones ayuda a mantener el rendimiento coherente de las consultas a medida que se expande el conjunto de datos.

Considere también la posibilidad de distribuir datos entre particiones. Los tamaños de partición severamente desiguales pueden crear cuellos de botella en el procesamiento, ya que los nodos que manejan particiones más grandes tardan más en completarse mientras otros permanecen inactivos.

Implementación de particiones en Azure Databricks

Las particiones se definen al crear una tabla mediante la PARTITIONED BY cláusula en SQL o el partitionBy método de PySpark. Una vez que establezca particiones, Azure Databricks enruta automáticamente los datos entrantes a los directorios de partición adecuados en función de los valores de columna.

Creación de una tabla con particiones con SQL

En el ejemplo siguiente se crea una tabla de transacciones de ventas particionada por la fecha de transacción:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_date DATE
)
PARTITIONED BY (transaction_date);

Al consultar esta tabla con un filtro de fecha, el motor de consultas lee solo las particiones que coinciden con los criterios de filtro:

SELECT product_id, SUM(total_amount) AS revenue
FROM sales.transactions
WHERE transaction_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY product_id;

Creación de una tabla con particiones con PySpark

Al usar PySpark, especifique la creación de particiones durante la operación de escritura:

df.write.format("delta") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

Para las escrituras posteriores, mantenga la coherencia mediante la inclusión de la misma especificación de partición:

new_transactions_df.write.format("delta") \
    .mode("append") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

Uso de columnas generadas para la flexibilidad de las particiones

Las columnas generadas proporcionan una manera de derivar valores de partición de columnas existentes sin almacenar datos redundantes. Este enfoque es útil cuando los datos de origen contienen marcas de tiempo, pero desea crear particiones por fecha:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_timestamp TIMESTAMP,
    transaction_date DATE GENERATED ALWAYS AS (CAST(transaction_timestamp AS DATE))
)
PARTITIONED BY (transaction_date);

Evitar errores comunes de creación de particiones

Comprender lo que se debe evitar es tan importante como saber qué hacer. Varios errores comunes pueden degradar significativamente el rendimiento y complicar la administración de datos.

La creación de particiones excesivas crea problemas de archivos pequeños

La creación de demasiadas particiones, cada una de las cuales contiene datos insuficientes, provoca problemas de archivos pequeños. Cuando las particiones contienen archivos menores que el tamaño del archivo de destino, el rendimiento de las consultas sufre de operaciones de metadatos excesivas y reduce la eficacia de lectura. Apunte a particiones con al menos 1 GB de datos.

Los signos de sobreparticionamiento incluyen un rendimiento lento de las consultas a pesar de la poda de particiones, una gran cantidad de archivos pequeños en los directorios de particiones y tiempos de optimización de tablas prolongados. Si observa estos síntomas, considere la posibilidad de elegir una granularidad de partición gruesa.

Se produce un error en la creación de particiones en columnas de alta cardinalidad

Las columnas con muchos valores únicos hacen que las claves de partición sean deficientes. La creación de particiones por identificador de cliente, identificador de transacción u otras columnas de cardinalidad alta crea millones de particiones que se degradan en lugar de mejorar el rendimiento. Reserve la optimización de columnas de alta cardinalidad para otras técnicas diseñadas para este propósito.

El cambio de particiones requiere reescritura de datos

Las columnas de partición forman parte de la estructura de la tabla. Cambiar la estrategia de creación de particiones requiere volver a escribir toda la tabla en una nueva ubicación con diferentes límites de partición. Esta operación consume importantes recursos de proceso y tiempo para tablas grandes.

Planee cuidadosamente su estrategia de particionamiento antes de cargar datos a gran escala. Considere los patrones de consulta futuros y el crecimiento de los datos para evitar una reestructuración costosa más adelante.

Decisiones de creación de particiones de documentos

Registre sus opciones de clave de partición y el razonamiento detrás de ellas. Esta documentación ayuda a los miembros del equipo a comprender las oportunidades de optimización de consultas y evita cambios accidentales que podrían afectar al rendimiento. Incluya información sobre los tamaños de partición esperados, los patrones de consulta que se benefician del esquema y las restricciones que influyeron en sus decisiones.

Considere la posibilidad de agrupar en clústeres líquidos como alternativa

Cuando se producen desafíos de creación de particiones, especialmente con columnas de alta cardinalidad , como marcas de tiempo o cuando los patrones de consulta no son seguros, la agrupación en clústeres líquidos proporciona una alternativa moderna. A diferencia de la creación de particiones tradicionales, la agrupación en clústeres líquidos ofrece:

• Flexibilidad para ajustar las estrategias de optimización sin volver a escribir datos
• El mantenimiento automático conforme las tablas crecen
• Reducción de la sobrecarga de administración de particiones

La agrupación en clústeres líquidos es el enfoque recomendado para las nuevas tablas en las que las restricciones de creación de particiones limitarían el rendimiento o crearían una carga excesiva de mantenimiento. Es especialmente eficaz para las tablas que superan los 1 TB y requieren filtrado en columnas que crearían demasiadas particiones mediante enfoques tradicionales.

Para obtener detalles de implementación, sintaxis y estrategias de optimización, consulte diseño e implementación de una unidad de estrategia de agrupación en clústeres más adelante en este módulo.