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

【问题标题】：Data Explorer: Large number of extents for custom partitioning policy数据资源管理器：自定义分区策略的大量范围
【发布时间】：2021-07-12 03:19:37
【问题描述】：

我们运行一个相当小的 V2 Kusto 集群（2-3 个节点，目前是 L4s）。有问题的表有 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 门户为您的资源提出支持请求，以进一步了解这一点。

标签： azure azure-data-explorer

【解决方案1】：

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

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

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

【讨论】：