Azure Data Explorer分区策略 [英] Azure Data Explorer partitioning strategy

问题描述

我在Azure数据资源管理器中有一个从IoT传感器收集数据的表。在不久的将来，它每天将收集数百万条记录。因此，为了获得最佳查询性能，我正在考虑设置分区策略：https://docs.microsoft.com/en-us/azure/data-explorer/kusto/management/partitioningpolicy

我的表有5个重要列：TenantID、DeviceID、SensorID、Value、Timestamp

(TenantID，deviceID，VariableID)的组合使传感器具有全局唯一性，并且几乎所有查询都将包含TenantID=‘xx’and deviceID=‘xx’and VariableID=‘xx’的部分。所有这些列都是字符串类型，并且基数很高(10.000+租户，1000+设备ID，10.000+可变ID)

两个问题：

1. 基于一个或多个字符串列对该表应用分区是否明智？它遵循文档中的建议：

   • 大多数查询使用相等过滤器(==，in())。
   • 大多数查询在大维(基数为10M或更高)的特定字符串类型列上进行聚合/联接，如APPLICATION_ID、TRANMENT_ID或USER_ID。

但在页面的后面，对于MaxPartitionCount，他们说它不应该高于1024，并且低于列的基数。因为我有高基数列，所以这不符合，所以我有点困惑。

2. 在摄取和分区新列之前合并字符串列是否最好？还是只在TenantID上使用？

推荐答案

几乎所有查询都将包含TenantID=‘xx’、deviceID=‘xx’和VariableID=‘xx’的部分。

考虑到这一点(假设您不经常在这3列中的任何一列上join)，您可以使用一个新列来扩展您的数据集，该列是这3列的串联(例如strcat_delim("_", TenantId, DevideId, VariableId)。

您可以在摄取Kusto之前执行此操作(更好)，或在摄取时使用update policy。

然后，将该新列设置为表data partitioning policy中的hash partition key。

---

对于MaxPartitionCount，他们说它不应该高于1024并低于列的基数。因为我有高基数列，所以这不符合，所以我有点困惑。

假设您有一个具有20节点的集群，一个具有基数10,000,000的列10,000,000，并且您希望将其设置为表的hash partition key。

遵循文档中有关MaxPartitionCount的准则：

• 支持的值在(1,1024]范围内。->；MaxPartitionCount应大于1且小于或等于1024。
• 该值应大于群集中的节点数->；MaxPartitionCount应大于20。
• 该值应小于列的基数->；MaxPartitionCount应小于10,000,000。
• 我们建议您从256的值开始。 根据上述考虑因素，或根据查询性能相对于接收后分区数据的开销的优势，根据需要调整该值。

因为我在这里没有看到任何相互冲突的信息(256>；1，256<；=1024，256>；20，256<；10M)-您可能希望澄清混淆来自哪里。

这篇关于Azure Data Explorer分区策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！