3. 数据平面隔离设计：数据写入路径的租户路由策略

在可观测性数据平面中，写入路径是租户隔离的第一道防线。所有来自 Agent、SDK 或批处理管道的遥测数据（Metrics、Logs、Traces）必须经过一个明确的租户路由决策点，才能被写入后端存储。本章聚焦于基于租户 ID 的 Sharding 与 Partitioning 方案，确保数据在物理存储层面实现强隔离。

3.1 写入路径的租户路由决策模型

数据写入路径的租户路由并非简单的哈希取模，而是一个包含识别、验证、映射、写入四个阶段的决策流水线。每个阶段都直接影响隔离的准确性和写入性能。

3.2 基于租户 ID 的 Sharding 方案

Sharding 将数据水平切分到多个独立的物理节点（Shard）上，每个 Shard 承载一组租户的全部数据。这是实现租户级资源隔离和故障域隔离的基础。

3.2.1 一致性哈希 Sharding

使用一致性哈希环将租户 ID 映射到 Shard。相比简单取模，一致性哈希在 Shard 扩缩容时仅需迁移少量租户数据，适合多租户场景下的动态扩缩。

// 伪代码：一致性哈希租户路由
class TenantRouter:
    def __init__(self, virtual_nodes=150):
        self.ring = ConsistentHashRing(virtual_nodes)
        self.shards = {}  # shard_id -> ShardNode

    def route(self, tenant_id: str) -> ShardNode:
        shard_id = self.ring.get_node(tenant_id)
        return self.shards[shard_id]

    def add_shard(self, shard_node: ShardNode):
        self.ring.add_node(shard_node.id)
        self.shards[shard_node.id] = shard_node

    def remove_shard(self, shard_id: str):
        self.ring.remove_node(shard_id)
        del self.shards[shard_id]

3.3 基于租户 ID 的 Partitioning 方案

Partitioning 是在单个 Shard 内部或分布式存储系统（如 Kafka、ClickHouse）中，将数据按租户 ID 进一步划分为更小的物理分区。Partitioning 决定了数据在存储引擎内部的布局，直接影响查询扫描范围和写入并行度。

3.3.1 时间 + 租户 ID 复合分区

在时序数据场景中，最常用的分区策略是按时间范围分区（如按天/小时），然后在每个时间分区内按租户 ID 哈希或列表进行二级分区。这种设计兼顾了时间维度的数据生命周期管理和租户维度的查询隔离。

-- ClickHouse 示例：按天 + 租户 ID 分区表
CREATE TABLE otel_metrics (
    TenantID UInt64,
    MetricName String,
    Timestamp DateTime,
    Value Float64,
    Attributes String
) ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(Timestamp)
ORDER BY (TenantID, Timestamp)
-- 二级分区通过 ORDER BY 中的 TenantID 前缀实现查询裁剪
-- 写入时按 TenantID 哈希路由到不同分区

3.4 Sharding + Partitioning 联合架构

在实际生产环境中，Sharding 和 Partitioning 通常组合使用，形成两层隔离：Sharding 负责跨节点资源隔离，Partitioning 负责节点内数据布局优化。下图展示了完整的写入路径租户路由架构。

3.5 性能优化要点

• 路由缓存：在 Agent 或 Gateway 侧缓存租户 ID → Shard/Partition 的映射关系，减少每次写入的路由计算开销。缓存 TTL 建议设置为 60~300 秒，配合路由表版本号实现主动失效。
• 批量写入亲和性：将同一租户的批量数据在客户端预先按 Partition 分组，减少写入路径上的数据重排和网络连接数。对于 Kafka 生产者，可使用自定义 Partitioner 按租户 ID 发送到指定 Partition。
• 避免热点 Shard：当某些租户的写入量远超平均水平时，采用子租户 Sharding 策略：将大租户的 TenantID 拆分为多个虚拟子 ID（如 TenantID + 后缀 0~N），均匀分布到不同 Shard，查询时通过 Scatter-Gather 模式合并结果。
• 写入路径无锁化：路由决策层应设计为无状态、无锁的幂等操作。所有状态变更（如 Shard 扩缩容、租户迁移）通过外部协调服务（如 Etcd/ZooKeeper）异步更新路由表，避免在写入关键路径上引入分布式锁。

3.6 方案对比总结

选择哪种方案取决于你的业务场景：如果租户数量少但单租户数据量大，优先强化 Sharding；如果租户数量多且查询隔离要求高，优先强化 Partitioning。对于大多数中大规模可观测性平台，一致性哈希 Sharding + 时间/租户复合 Partitioning 的联合架构是最佳实践。