Directiva de creación de particiones
La directiva de creación de particiones define si y cómo se deben particionar las extensiones (particiones de datos) para una tabla específica o una vista materializada.
La directiva desencadena un proceso en segundo plano adicional que tiene lugar después de la creación de extensiones, después de la ingesta de datos. Este proceso incluye la reasignación de datos de las extensiones de origen y la producción de extensiones homogéneas , en las que todos los valores de la columna designados como clave de partición residen dentro de una sola partición.
El objetivo principal de la directiva de creación de particiones es mejorar el rendimiento de las consultas en escenarios admitidos específicos.
Nota
De forma predeterminada, cuando no se define una directiva de creación de particiones de datos (es null
), las extensiones se particionan en el momento de la creación (ingesta). En la mayoría de los casos, no es necesario establecer una directiva de creación de particiones de datos.
Escenarios admitidos
A continuación se muestran los únicos escenarios en los que se recomienda establecer una directiva de creación de particiones de datos. En todos los demás escenarios, no se recomienda establecer la directiva.
- Filtros frecuentes en una cardinalidad
string
media o alta oguid
columna:- Por ejemplo: soluciones multiinquilino o una tabla de métricas donde la mayoría o todas las consultas filtran en una columna de tipo
string
o , como oTenantId
MetricId
.guid
- La cardinalidad media es de al menos 10 000 valores distintos.
- Establezca la clave de partición hash para que sea la
string
columna oguid
y establezca laPartitionAssigmentMode
propiedaduniform
en .
- Por ejemplo: soluciones multiinquilino o una tabla de métricas donde la mayoría o todas las consultas filtran en una columna de tipo
- Agregaciones o combinaciones frecuentes en una cardinalidad
string
oguid
columna alta:- Por ejemplo, información de IoT de muchos sensores diferentes o registros académicos de muchos alumnos diferentes.
- La cardinalidad alta es de al menos 1000 000 valores distintos, donde la distribución de valores de la columna es aproximadamente uniforme.
- En este caso, establezca la clave de partición hash para que sea la columna agrupada con frecuencia por o combinada y establezca la
PartitionAssigmentMode
propiedadByPartition
en .
- Ingesta de datos desordenados:
- Es posible que los datos ingeridos en una tabla no se ordenen y particionen en extensiones (particiones) según una columna específica
datetime
que represente el tiempo de creación de datos y se use normalmente para filtrar los datos. Esto podría deberse a un reposición de archivos de origen heterogéneos que incluyen valores datetime durante un intervalo de tiempo grande. - En este caso, establezca la clave de partición datetime de intervalo uniforme para que sea la
datetime
columna. - Si necesita directivas de retención y almacenamiento en caché para alinearse con los valores datetime de la columna, en lugar de alinearse con la hora de ingesta, establezca la
OverrideCreationTime
propiedadtrue
en .
- Es posible que los datos ingeridos en una tabla no se ordenen y particionen en extensiones (particiones) según una columna específica
Precaución
- No hay límites codificados de forma rígida establecidos en el número de tablas con la directiva de creación de particiones definida. Sin embargo, cada tabla adicional agrega sobrecarga al proceso de creación de particiones de datos en segundo plano que se ejecuta en los nodos del clúster. Establecer una directiva en más tablas dará lugar a que se usen más recursos de clúster y un costo mayor debido a las transacciones de almacenamiento subyacentes. Para más información, consulte Capacidad.
- No se recomienda establecer una directiva de creación de particiones si se espera que el tamaño comprimido de los datos por partición sea inferior a 1 GB.
- El proceso de creación de particiones da como resultado artefactos de almacenamiento residual para todas las extensiones reemplazadas durante el proceso de creación de particiones y durante el proceso de combinación. Se espera que la mayoría de los artefactos de almacenamiento residual se eliminen durante el proceso de limpieza automática. Aumentar el valor de la
MaxPartitionCount
propiedad aumenta el número de artefactos de almacenamiento residual y puede reducir el rendimiento de limpieza. - Antes de aplicar una directiva de creación de particiones en una vista materializada, revise las recomendaciones para la directiva de creación de particiones de vistas materializadas.
Claves de partición
Se admiten los siguientes tipos de claves de partición.
Clase | Tipo de columna | Propiedades de la partición | Valor de partición |
---|---|---|---|
Hash | string o guid |
Function , MaxPartitionCount , Seed , PartitionAssignmentMode |
Function (ColumnName , MaxPartitionCount , Seed ) |
Rango uniforme | datetime |
RangeSize , Reference , OverrideCreationTime |
bin_at (ColumnName , RangeSize , Reference ) |
Clave de partición hash
Si la directiva incluye una clave de partición hash, todas las extensiones homogéneas que pertenecen a la misma partición se asignarán al mismo nodo de datos del clúster.
Nota
La operación de creación de particiones de datos agrega una carga de procesamiento significativa. Se recomienda aplicar una clave de partición hash en una tabla solo en las condiciones siguientes:
- Si la mayoría de las consultas usan filtros de igualdad (
==
,in()
). - La mayoría de las consultas agregan o unen en una columna específica de tipo
string
oguid
que es de gran dimensión (cardinalidad de 10 M o superior), como ,device_ID
ouser_ID
. - El patrón de uso de las tablas con particiones está en alta carga de consultas de simultaneidad, como en aplicaciones de supervisión o paneles.
- Se usa una función hash-modulo para particionar los datos.
- La clave de partición hash ordena los datos en extensiones homogéneas (con particiones).
- No es necesario incluir la clave de partición hash en la directiva de orden de fila, si se define una en la tabla.
- Se espera que las consultas que usan la estrategia de orden aleatorio y en la que
shuffle key
se usa enjoin
,summarize
omake-series
es la clave de partición hash de la tabla, funcionen mejor porque se reduce la cantidad de datos necesarios para moverse por los nodos del clúster.
Propiedades de la partición
Propiedad | Descripción | Valores admitidos | Valor recomendado |
---|---|---|---|
Function |
Nombre de una función hash-modulo que se va a usar. | XxHash64 |
|
MaxPartitionCount |
Número máximo de particiones que se van a crear (el argumento modulo a la función hash-modulo) por período de tiempo. | En el intervalo (1,2048] . |
Los valores más altos provocan una mayor sobrecarga del proceso de creación de particiones de datos en los nodos del clúster y un mayor número de extensiones durante cada período de tiempo. 128 es el valor recomendado. Los valores más altos aumentarán significativamente la sobrecarga de crear particiones de los datos después de la ingesta y el tamaño de los metadatos, por lo que no se recomiendan. |
Seed |
Use para aleatoriar el valor hash. | Un número entero positivo. | 1 , que también es el valor predeterminado. |
PartitionAssignmentMode |
Modo que se usa para asignar particiones a nodos del clúster. | ByPartition : todas las extensiones homogéneas (con particiones) que pertenecen a la misma partición se asignan al mismo nodo. Uniform : se omiten los valores de partición de las extensiones. Las extensiones se asignan uniformemente a los nodos del clúster. |
Si las consultas no se unen ni agregan en la clave de partición hash, use Uniform . En otros casos, use ByPartition . |
Ejemplo de clave de partición hash
Una clave de partición hash a través de una string
columna con tipo denominada tenant_id
.
Usa la XxHash64
función hash, con MaxPartitionCount
establecido en el valor 128
recomendado y el valor predeterminado Seed
de 1
.
{
"ColumnName": "tenant_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 128,
"Seed": 1,
"PartitionAssignmentMode": "Uniform"
}
}
Clave de partición datetime de intervalo uniforme
Nota
Solo se aplica una clave de partición datetime de intervalo uniforme en una datetime
columna con tipo en una tabla cuando es poco probable que los datos ingeridos en la tabla se ordenan según esta columna.
En estos casos, puede reorganizar los datos entre extensiones para que cada extensión incluya registros de un intervalo de tiempo limitado. Este proceso hace que los filtros de la columna sean más eficaces en el momento de la datetime
consulta.
La función de partición usada es bin_at() y no es personalizable.
Propiedades de la partición
Propiedad | Descripción | Valor recomendado |
---|---|---|
RangeSize |
Constante timespan escalar que indica el tamaño de cada partición datetime. |
Comience con el valor 1.00:00:00 (un día). No establezca un valor más corto, ya que puede dar lugar a que la tabla tenga un gran número de extensiones pequeñas que no se puedan combinar. |
Reference |
Constante datetime escalar que indica un punto fijo en el tiempo, según las particiones datetime que se alinean. |
Comience con 1970-01-01 00:00:00 . Si hay registros en los que la clave de partición datetime tiene null valores, su valor de partición se establece en el valor de Reference . |
OverrideCreationTime |
Que bool indica si el intervalo de valores de la clave de partición debe invalidar o no los tiempos de creación mínimo y máximo de la extensión de resultado. |
Tiene como valor predeterminado false . true Se establece en si los datos no se ingieren en orden de llegada. Por ejemplo, un único archivo de origen puede incluir valores datetime que están distantes, o puede que desee aplicar retención o almacenamiento en caché en función de los valores datetime en lugar de la hora de ingesta.Cuando OverrideCreationTime se establece true en , es posible que se pierdan extensiones en el proceso de combinación. Se pierden las extensiones si su tiempo de creación es anterior al Lookback período de la directiva de combinación Extensiones de la tabla. Para asegurarse de que se pueden detectar las extensiones, establezca la Lookback propiedad en HotCache . |
Ejemplo de partición datetime de intervalo uniforme
El fragmento de código muestra una clave de partición uniforme de intervalo de fecha y hora en una datetime
columna con tipo denominada timestamp
.
datetime(2021-01-01)
Usa como punto de referencia, con un tamaño de 7d
para cada partición y no invalida los tiempos de creación de las extensiones.
{
"ColumnName": "timestamp",
"Kind": "UniformRange",
"Properties": {
"Reference": "2021-01-01T00:00:00",
"RangeSize": "7.00:00:00",
"OverrideCreationTime": false
}
}
El objeto de directiva
De forma predeterminada, la directiva de creación de particiones de datos de una tabla es null
, en cuyo caso los datos de la tabla no se vuelven a particionar después de ingerirlos.
La directiva de creación de particiones de datos tiene las siguientes propiedades principales:
PartitionKeys:
- Colección de claves de partición que definen cómo particionar los datos en la tabla.
- Una tabla puede tener hasta
2
claves de partición, con una de las siguientes opciones: - Cada clave de partición tiene las siguientes propiedades:
ColumnName
: :string
el nombre de la columna según el cual se particionarán los datos.Kind
: :string
el tipo de creación de particiones de datos que se va a aplicar (Hash
oUniformRange
).Properties
:property bag
: define los parámetros según el cual se realiza la creación de particiones.
EffectiveDateTime:
- Fecha y hora UTC desde la que la directiva es efectiva.
- Esta propiedad es opcional. Si no se especifica, la directiva surtirá efecto para los datos ingeridos después de aplicar la directiva.
Precaución
- Puede establecer un valor datetime en el pasado y crear particiones de datos ya ingeridos. Sin embargo, esta práctica puede aumentar significativamente los recursos usados en el proceso de creación de particiones.
- En la mayoría de los casos, se recomienda tener solo particiones de datos recién ingeridos y evitar la creación de particiones de grandes cantidades de datos históricos.
- Si decide particionar datos históricos, considere la posibilidad de hacerlo gradualmente estableciendo EffectiveDateTime en un anterior
datetime
en pasos de hasta unos días cada vez que modifique la directiva.
Ejemplo de creación de particiones de datos
Objeto de directiva de creación de particiones de datos con dos claves de partición.
- Una clave de partición hash a través de una
string
columna con tipo denominadatenant_id
.- Usa la
XxHash64
función hash, conMaxPartitionCount
establecido en el valor128
recomendado y el valor predeterminadoSeed
de1
.
- Usa la
- Clave de partición uniforme de intervalo de fecha y hora en una
datetime
columna de tipo denominadatimestamp
.datetime(2021-01-01)
Usa como punto de referencia, con un tamaño de7d
para cada partición.
{
"PartitionKeys": [
{
"ColumnName": "tenant_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 128,
"Seed": 1,
"PartitionAssignmentMode": "Uniform"
}
},
{
"ColumnName": "timestamp",
"Kind": "UniformRange",
"Properties": {
"Reference": "2021-01-01T00:00:00",
"RangeSize": "7.00:00:00",
"OverrideCreationTime": false
}
}
]
}
Propiedades adicionales
Las siguientes propiedades se pueden definir como parte de la directiva. Estas propiedades son opcionales y se recomienda no cambiarlas.
Propiedad | Descripción | Valor recomendado | Valor predeterminado |
---|---|---|---|
MinRowCountPerOperation | Destino mínimo para la suma del recuento de filas de las extensiones de origen de una sola operación de creación de particiones de datos. | 0 |
|
MaxRowCountPerOperation | Destino máximo para la suma del recuento de filas de las extensiones de origen de una sola operación de creación de particiones de datos. | Establezca un valor inferior a 5M si ve que las operaciones de creación de particiones consumen una gran cantidad de memoria o CPU por operación. | 0 , con un destino predeterminado de 5 000 000 registros. |
MaxOriginalSizePerOperation | Destino máximo para la suma del tamaño original (en bytes) de las extensiones de origen de una sola operación de creación de particiones de datos. | Si las operaciones de creación de particiones consumen una gran cantidad de memoria o CPU por operación, establezca un valor inferior a 5 GB. | 0 , con un destino predeterminado de 5 368 709 120 bytes (5 GB). |
Proceso de creación de particiones de datos
- La creación de particiones de datos se ejecuta como un proceso en segundo plano posterior a la ingesta en el clúster.
- Se espera que una tabla que se ingiere continuamente en siempre tenga una "cola" de datos que aún no se van a particionar (extensiones nohomogenas).
- La creación de particiones de datos solo se ejecuta en extensiones activas, independientemente del valor de la
EffectiveDateTime
propiedad en la directiva.- Si se requieren extensiones inactivas de creación de particiones, debe ajustar temporalmente la directiva de almacenamiento en caché.
Puede supervisar el estado de partición de las tablas con directivas definidas en una base de datos mediante el comando .show database extents partitioning statistics .
Capacidad de creación de particiones
- El proceso de creación de particiones de datos da como resultado la creación de más extensiones. El clúster puede aumentar gradualmente su capacidad de combinación de extensiones, de modo que el proceso de combinación de extensiones pueda mantenerse al día.
- Si hay un alto rendimiento de ingesta o un gran número suficiente de tablas que tienen definida una directiva de creación de particiones, el clúster puede aumentar gradualmente su capacidad de partición Extensiones, de modo que el proceso de particiones de extensiones pueda mantenerse al día.
- Para evitar consumir demasiados recursos, estos aumentos dinámicos están limitados. Es posible que se le pida que aumente gradualmente y linealmente más allá del límite, si se usan completamente.
- Si aumentar las capacidades provoca un aumento significativo en el uso de los recursos del clúster, puede escalar verticalmente el clúster/, ya sea manualmente o habilitar el escalado automático.
Limitaciones
- Se limitarán los intentos de crear particiones de datos en una base de datos que ya tenga más de 5000 000 extensiones.
- En tales casos, la
EffectiveDateTime
propiedad de las directivas de creación de particiones de las tablas de la base de datos se retrasará automáticamente varias horas, de modo que pueda volver a evaluar la configuración y las directivas.
- En tales casos, la
Valores atípicos en columnas con particiones
- Las situaciones siguientes pueden contribuir a la distribución desequilibrado de los datos en los nodos del clúster y degradar el rendimiento de las consultas:
- Si una clave de partición hash incluye valores mucho más frecuentes que otros, por ejemplo, una cadena vacía o un valor genérico (como
null
oN/A
). - Los valores representan una entidad (como
tenant_id
) que es más frecuente en el conjunto de datos.
- Si una clave de partición hash incluye valores mucho más frecuentes que otros, por ejemplo, una cadena vacía o un valor genérico (como
- Si una clave de partición datetime de intervalo uniforme tiene un porcentaje suficientemente grande de valores que están "lejos" de la mayoría de los valores de la columna, se aumenta la sobrecarga del proceso de creación de particiones de datos y puede dar lugar a muchas pequeñas extensiones de las que el clúster necesitará realizar un seguimiento. Un ejemplo de esta situación es los valores datetime del pasado lejano o futuro.
En ambos casos, ya sea "corregir" los datos o filtrar los registros irrelevantes de los datos antes o en el momento de la ingesta, para reducir la sobrecarga de la creación de particiones de datos en el clúster. Por ejemplo, use una directiva de actualización.
Contenido relacionado
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea:Enviar y ver comentarios de