Cuándo crear particiones de tablas en Azure Databricks

Nota:

Databricks recomienda el uso de la agrupación en clústeres líquidos para todas las tablas Delta nuevas. Consulte Uso de clústeres líquidos para tablas Delta.

A veces, los clústeres líquidos también se conocen como “particiones líquidas”. En este artículo solo se hace referencia a la creación de particiones Delta heredadas y no a la agrupación en clústeres líquidos.

En este artículo se proporciona información general sobre cómo crear particiones de tablas en Azure Databricks y recomendaciones específicas sobre cuándo debe usar la creación de particiones para las tablas respaldadas por Delta Lake. Debido a las características y optimizaciones integradas, la mayoría de las tablas con menos de 1 TB de datos no requieren particiones.

De manera predeterminada, Azure Databricks usa Delta Lake para todas las tablas. En las siguientes recomendaciones se supone que está trabajando con Delta Lake para todas las tablas.

En Databricks Runtime 11.3 LTS y versiones posteriores, Azure Databricks agrupa automáticamente los datos en tablas no particionadas por tiempo de ingesta. Consulte Uso de la agrupación en clústeres de tiempo de ingesta.

¿Es necesario crear particiones de tablas pequeñas?

Databricks recomienda no crear particiones de tablas que contengan menos de un terabyte de datos.

¿Cuál es el tamaño mínimo de cada partición de una tabla?

Databricks recomienda que todas las particiones contengan al menos un gigabyte de datos. Las tablas con menos particiones más grandes tienden a superar a las tablas con muchas particiones más pequeñas.

Uso de la agrupación en clústeres de tiempo de ingesta

Mediante Delta Lake y Databricks Runtime 11.3 LTS o superior, las tablas sin particiones que se crean se benefician automáticamente de la agrupación en clústeres de tiempo de ingesta. El tiempo de ingesta proporciona ventajas de consulta similares a las estrategias de creación de particiones basadas en campos datetime sin necesidad de optimizar ni optimizar los datos.

Nota:

Para mantener la agrupación en clústeres de tiempo de ingesta al realizar un gran número de modificaciones mediante instrucciones UPDATE o MERGE en una tabla, Databricks recomienda ejecutar OPTIMIZE con ZORDER BY con una columna que coincida con el orden de ingesta. Por ejemplo, podría tratarse de una columna que contiene una marca de tiempo de evento o una fecha de creación.

¿Delta Lake y Parquet comparten estrategias de creación de particiones?

Delta Lake usa Parquet como formato principal para almacenar datos y algunas tablas Delta con particiones especificadas muestran la organización similar a las tablas Parquet almacenadas con Apache Spark. Apache Spark usa la creación de particiones de estilo Hive al guardar datos en formato Parquet. La creación de particiones de estilo de Hive no forma parte del protocolo Delta Lake y las cargas de trabajo no deben depender de esta estrategia de creación de particiones para interactuar con las tablas Delta.

Muchas características de Delta Lake interrumpen las suposiciones sobre el diseño de datos que podrían haberse transferido desde las versiones del protocolo Parquet, Hive o incluso versiones anteriores del protocolo Delta Lake. Siempre debe interactuar con los datos almacenados en Delta Lake mediante clientes y API compatibles oficialmente.

¿En qué se diferencian las particiones de Delta Lake de otras particiones de otros lagos de datos?

Aunque Azure Databricks y Delta Lake se basan en tecnologías código abierto como Apache Spark, Parquet, Hive y Hadoop, las motivaciones y estrategias de creación de particiones útiles en estas tecnologías no suelen aplicarse a Azure Databricks. Si decide particionar la tabla, tenga en cuenta los siguientes hechos antes de elegir una estrategia:

• Las transacciones no se definen mediante límites de partición. Delta Lake da garantías ACID a través de los registros de transacciones, por lo que no es necesario separar un lote de datos por una partición para garantizar la detección atómica.
• Los clústeres de proceso de Azure Databricks no tienen localidad de datos vinculada a medios físicos. Los datos ingeridos en Lakehouse se almacenan en el almacenamiento de objetos en la nube. Mientras que los datos se almacenan en caché en el almacenamiento en disco local durante el procesamiento de datos, Azure Databricks usa estadísticas basadas en archivos para identificar la cantidad mínima de datos para la carga en paralelo.

¿Cómo funcionan juntos el orden Z y las particiones?

Puede usar índices de orden Z junto con particiones para acelerar las consultas en grandes conjuntos de datos.

Nota:

La mayoría de las tablas pueden aprovechar la agrupación en clústeres de tiempo de ingesta para evitar tener que preocuparse por el orden Z y el ajuste de particiones.

Las reglas siguientes son importantes tener en cuenta al planear una estrategia de optimización de consultas basada en límites de partición y orden Z:

• El orden Z funciona en conjunto con el comando OPTIMIZE. No se pueden combinar archivos entre límites de partición y, por tanto, la agrupación en clústeres de orden Z solo puede producirse dentro de una partición. En el caso de las tablas sin particiones, los archivos se pueden combinar en toda la tabla.
• La creación de particiones solo funciona bien en campos de cardinalidad baja o conocida (por ejemplo, campos de fecha o ubicaciones físicas), pero no para campos con cardinalidad alta, como marcas de tiempo. El orden Z funciona en todos los campos, incluidos campos de cardinalidad alta y campos que pueden crecer infinitamente (por ejemplo, marcas de tiempo o el identificador de cliente en una tabla de transacciones o pedidos).
• No se puede ordenar Z en los campos usados para la creación de particiones.

Si las particiones son tan malas, ¿por qué algunas características de Azure Databricks las usan?

Las particiones pueden ser beneficiosas, especialmente para tablas muy grandes. Muchas mejoras de rendimiento en torno a la creación de particiones se centran en tablas muy grandes (cientos de terabytes o más).

Muchos clientes migran a Delta Lake desde lagos de datos basados en Parquet. La instrucción CONVERT TO DELTA permite convertir una tabla basada en Parquet existente en una tabla Delta sin volver a escribir los datos existentes. Por lo tanto, muchos clientes tienen tablas grandes que heredan estrategias de creación de particiones anteriores. Algunas optimizaciones desarrolladas por Databricks buscan aprovechar estas particiones cuando sea posible, atenuando algunas posibles desventajas de las estrategias de creación de particiones no optimizadas para Delta Lake.

Delta Lake y Apache Spark son tecnologías de código abierto. Aunque Databricks sigue introduciendo características que reducen la dependencia de la creación de particiones, la comunidad de código abierto podría seguir generando nuevas características que agregan complejidad.

¿Es posible superar las optimizaciones integradas de Azure Databricks con particiones personalizadas?

Es posible que algunos usuarios experimentados de Apache Spark y Delta Lake puedan diseñar e implementar un patrón que proporcione un mejor rendimiento que la agrupación en clústeres de tiempo de ingesta. La implementación de un estado de partición incorrecta puede tener repercusiones muy negativas en el rendimiento de bajada y puede requerir una reescritura completa de los datos que corregir. Databricks recomienda que la mayoría de los usuarios usen la configuración predeterminada para evitar que se introduzcan ineficiencias costosas.