数据资源管理器：自定义分区策略的大量范围

如何解决数据资源管理器：自定义分区策略的大量范围

我们运行一个相当小的 V2 Kusto 集群（2-3 个节点，目前是 L4）。有问题的表有 15TB 的总数据，400GB 的热缓存。热点数据设置为 31 天。

由于查询延迟很高，我们按 device_id 和时间戳对数据进行了分区。这发生在一年前。但是，我们现在看到了这个警告：

“AttentionrequiredReason”：总范围 >= 500000，表“mydb.mytable”每台机器的范围比推荐的多(30693 >= 5000)

仔细观察，我们有接近 2,500,000 个扩展（“总范围计数”）用于该表。

这是我们的分区策略：

"PartitionKeys": [
    {
        "ColumnName": "device_id","Kind": "Hash","Properties": {
            "Function": "XxHash64","MaxPartitionCount": 256,"Seed": 1,"PartitionAssignmentMode": "Default"
        }
    },{
        "ColumnName": "customTimestampField","Kind": "UniformRange","Properties": {
            "Reference": "1970-01-01T00:00:00","RangeSize": "1.00:00:00","OverrideCreationTime": false
        }
    }
],

时间戳字段的示例值为 2021-06-15T17:51:54.7401603Z。

我研究了一下，发现 "MaxPartitionCount": 256 可能太高了，因为我们只配置了 2-3 个实例。

我的主要问题是：为什么我们有这么多范围？我们目前每天获得大约 2.000 个新范围。鉴于分区策略，由于散列，我们每天不应该最多只能获得 256 吗？这是否与警告说每台机器 30693 个盘区有关，即使我们有 250 万个盘区分布在两个实例上？

.show table mytable extents  
| where MaxCreatedOn > ago(90d)
| summarize count()  by bin(MaxCreatedOn,1d)
| render timechart    

解决方法

在 Azure 的支持和更多调查下，我们找到了原因：

我们收到了很多带有自定义时间戳的邮件，而不是当前日期。发生这种情况时，Kusto 无法像往常一样合并范围，我们正在处理其中的许多范围。解决方案是在我们的分区策略中设置 "OverrideCreationTime": true。这可以称为 Backfill or unordered ingestion。

解决这个问题后，我们继续不断地获取过去几天的数据，这使得即使集群无法足够快地跟上合并的速度，我们也有很多范围。我们通过使用不同的时间戳字段来改进这一点，该字段保证接近当前日期。