Azure数据资源管理器分区策略

问题描述

我在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'和deviceid ='xx'和VariableId ='xx'的部分。所有这些列都是字符串类型，并且具有高基数（10.000+个租户，1000 + deviceid，10.000 + VariableIds）

两个问题：

1. 基于一个或多个字符串列在此表上应用分区是否明智？它符合说明文件中的建议：

   • 大多数查询使用相等过滤器（==，in（））。
   • 大多数查询在特定的，大字符串（基数为10M或更高）的字符串类型的列上聚集/联接，例如application_ID，tenant_ID或user_ID。

但是在页面的后面，他们说对于MaxPartitionCount，它应该不大于1024并且小于列的基数。由于我的基数高，这不符合要求，所以我有点困惑。

1. 在提取新列并对其进行分区之前，最好先合并字符串列吗？还是仅以TenantId为例？

解决方法

几乎所有查询都将包含TenantId ='xx'和DeviceId ='xx'和VariableId ='xx'的部分。

鉴于此（并且假设您不经常在这3列中的任何一列上使用join，则可以用新列扩展数据集，这是这3列的串联（例如{{1} }。

您可以在（更好）摄取到Kusto中​​之前执行此操作，或者-在摄取时使用strcat_delim("_",TenantId,DevideId,VariableId。

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

---

对于MaxPartitionCount，他们说它应该不大于1024并且小于列的基数。由于我的基数高，这不符合要求，所以我有点困惑。

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

遵循文档中有关hash partition key的准则：

• 支持的值在MaxPartitionCount 范围内。 -> (1,1024]应该大于MaxPartitionCount，并且小于或等于1。
• 该值应大于群集中的节点数-> 1024应大于MaxPartitionCount。
• 该值应小于列的基数-> 20应小于MaxPartitionCount。
• 我们建议您以10,000开头。 根据上述考虑，或根据查询性能的好处与对数据输入后进行分区的开销进行调整，以根据需要调整该值。

我在这里看不到任何冲突的信息（256> 256，1 256，1024> 256 ，20 256）-您可能想弄清楚混乱的根源。