Azure Data Explorer分区与合并策略疑问及多分区键解析

1. 未配置自定义策略时，ADX自动创建Extents的机制与默认配置 #

• Extent是ADX存储数据的最小物理单元，无论是否手动配置分区/合并策略，数据摄入时都会生成Extents——这是ADX的核心存储逻辑，每次数据摄入（批量、实时或流式）都会根据摄入批次生成至少一个Extent。
• 默认分区策略：如果未显式设置Partitioning Policy，ADX会自动使用基于**摄入时间（IngestionTime）**的UniformRange分区规则，默认时间范围为1天。系统会按数据的摄入时间，将每天的摄入数据划分到对应时间分区中。
• 默认合并策略：未配置自定义Merge Policy时，ADX启用LogMergePolicy（日志合并策略）。该策略会在后台自动合并同一分区内的小Extents：当同一分区内的小Extents数量或总大小达到阈值（默认阈值为：同一分区内存在5个以上小Extents，或总数据量超过1GB），系统会异步将它们合并为更大的Extents，优化查询性能和存储效率。

2. 多分区键组合的工作逻辑（以给定配置为例） #

给定的多分区键配置如下：

{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

其工作逻辑为分层组合：

1. 哈希分区层：首先对tenant_id字段使用XxHash64哈希函数计算哈希值，将所有租户均匀分配到128个固定的哈希分区桶中（MaxPartitionCount:128定义的是哈希分区的总数量，而非每个租户对应一个分区）。无论新增多少租户，都会被映射到这128个桶里，避免因租户数量过多导致分区爆炸。
2. 时间范围分区层：在每个哈希分区桶内，再按照timestamp字段进行UniformRange分区——以2021-01-01T00:00:00为起始参考点，每7天划分为一个时间分区。

• 总结：最终的分区是哈希桶 × 7天时间块的组合，而非为每个新租户单独创建7天分区。比如128个哈希桶，每个桶下每7天生成一个分区，总分区数随时间递增，但每个时间窗口内的分区数固定为128个。

3. 先生成小Extents再合并的优势（而非直接生成大Extents） #

小Extents的设计是ADX兼顾摄入效率、容错性和灵活性的核心选择，优势包括：

• 低延迟摄入：实时/流式摄入场景下，无法等待攒够大Extents的体量再写入，小Extents可以快速完成数据持久化，保证数据摄入的低延迟。
• 高并发写入：多个小Extents的写入操作可以并行执行，避免大Extents写入时的锁竞争问题，提升系统的写入吞吐量。
• 精准分区对齐：数据摄入时可以直接将小Extents分配到对应的分区中，后续合并仅在同一分区内进行，严格保证分区规则的有效性，避免跨分区数据混合。
• 容错成本更低：小Extents写入失败时，仅需重试该小批次数据，影响范围小；若直接写入大Extents，失败后重试成本高，且可能导致数据丢失风险增加。

内容的提问来源于stack exchange，提问作者FakieKickflip