时间戳

首页 > 解决方案 > Azure 数据资源管理器分区策略

aggregate - 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' and DeviceId = 'xx' and VariableId = 'xx'的部分。所有这些列都是字符串类型，并且具有高基数（10.000+ Tenants、1000+ DeviceIds、10.000+ VariableIds）

两个问题：

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

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

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

  1. 在新列上摄取和分区之前最好连接字符串列吗？或者仅在 TenantId 上？

标签： aggregatepartitioningazure-data-explorercardinality

解决方案

几乎所有查询都会包含一个部分，即 TenantId = 'xx' and DeviceId = 'xx' and VariableId = 'xx'。

鉴于此（并且假设您不经常join使用这 3 列中的任何一个），您可以使用新列扩展您的数据集，该列是这 3 列的串联（例如strcat_delim("_", TenantId, DevideId, VariableId）。

您可以在摄取到 Kusto 之前执行此操作（更好），或者 - 使用update policy摄取时。

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

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

假设您有一个带有20节点的集群，一个C带有 cardinality的列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） - 您可能想澄清混淆的来源。

推荐阅读