2. Elastic数据共享的技术底座

跨团队数据共享在 Elastic 中并不是一个独立功能，而是建立在集群、节点、索引、文档、分片与副本这六个基础概念之上的能力组合。理解它们之间的层级与协作关系，才能判断一次跨团队访问为什么成功、为什么变慢、为什么被拒绝，以及应该在哪一层做隔离与授权。

从集群到文档：共享对象的层级

Elastic 的最小部署单元是集群（cluster），它由一个唯一名称标识，并统一管理元数据、分片分配和集群状态。集群之下是节点（node），节点是真正承载计算与存储的进程，按角色可分为主节点、数据节点、协调节点、摄取节点等。跨团队共享时，集群边界通常就是信任边界：同一集群内的团队共享同一套元数据与安全域，跨集群则需要 Remote Cluster 或跨集群搜索（CCS）来打通。

数据组织的基本单位是索引（index），它类似关系数据库中的表，是映射（mapping）、设置（settings）和别名的载体。索引内部存放文档（document），文档是以 JSON 表示的、可被检索的最小记录，拥有唯一 _id。团队之间共享数据，实际共享的往往是“某个索引的读权限”或“某个索引别名的查询入口”，而不是整个集群。

索引在物理上被切分为分片（shard），每个分片是一个独立的 Lucene 实例，可分布在不同数据节点上，从而实现水平扩展与并行查询。每个分片还有副本（replica），副本是主分片的完整拷贝，承担高可用与读请求分流。主分片数量在索引创建时确定且不可随意更改，副本数则可动态调整，这一点直接影响跨团队共享时的容量规划与故障容忍度。

分片与副本如何决定共享的可用性与性能

分片数量决定了索引的并行度上限。假设一个团队要共享 200 GB 的日志数据，创建索引时设置 number_of_shards: 4，则每个主分片约 50 GB；若设置 number_of_replicas: 1，则总存储约 400 GB，且每个主分片都有一个副本分布在不同节点上。当某个数据节点宕机时，副本可被提升为主分片，查询不中断。跨团队共享时，如果多个团队同时高频查询同一索引，副本数不足会导致查询排队；副本过多则会放大写入开销与存储成本。

一个常见的误区是：把“共享数据”理解为“把整个索引开放给其他团队”。更合理的做法是通过索引别名和文档级安全控制访问范围。例如，为团队 A 创建别名 logs-team-a 指向 logs-2024，并在角色中限定该别名只能读取 team: "alpha" 的文档。这样，物理上仍是同一份分片与副本，逻辑上却实现了团队隔离。

跨团队访问的典型配置示例

下面是一个可参考的索引创建与别名绑定示例，用于支撑两个团队共享同一份日志索引但只看到各自数据：

PUT /logs-shared-2024
{
  "settings": {
    "number_of_shards": 4,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "team":    { "type": "keyword" },
      "message": { "type": "text" },
      "@timestamp": { "type": "date" }
    }
  }
}

POST /_aliases
{
  "actions": [
    { "add": { "index": "logs-shared-2024", "alias": "logs-team-alpha",
               "filter": { "term": { "team": "alpha" } } } },
    { "add": { "index": "logs-shared-2024", "alias": "logs-team-beta",
               "filter": { "term": { "team": "beta" } } } }
  ]
}

配置完成后，团队 A 只需查询 logs-team-alpha，Elastic 会自动在分片层面应用过滤条件。此时，协调节点会把查询分发到 P0～P3 及其副本，各分片在本地执行过滤并返回匹配文档，最终由协调节点合并结果。团队 A 看不到团队 B 的文档，但两者共享同一套分片与副本资源。

节点角色与共享稳定性的关系

跨团队共享往往意味着查询来源增多、并发上升。此时节点角色划分就变得关键：协调节点负责接收请求、分发到数据节点并合并结果，如果协调节点与数据节点混部，重查询可能拖慢写入。建议在共享场景中至少将主节点与数据节点分离，必要时增加专用协调节点。对于跨集群共享，Remote Cluster 的 remote_cluster_client 角色节点负责转发跨集群请求，其网络延迟与连接数会直接影响共享查询的响应时间。

把这六个概念串起来看：集群划定共享边界，节点提供计算与存储资源，索引和别名定义共享入口，文档是共享的实际内容，分片决定并行能力，副本决定容错与读吞吐。跨团队数据访问的每一次成功或失败，都可以沿着这条链路逐层排查——先看集群与节点是否健康，再看索引与别名是否正确，最后看分片与副本是否均衡。掌握这条链路，后续的权限配置、跨集群搜索和性能调优才有稳定的落脚点。