【Elasticsearch】跨集群检索（Cross-Cluster Search）

1.什么是跨集群检索 ？

跨集群检索（Cross-Cluster Search，CCS）是 Elasticsearch 提供的一项核心功能，它允许你 从一个 Elasticsearch 集群（称为本地集群）发起搜索请求，并透明地查询一个或多个远程 Elasticsearch 集群中的数据。对于执行搜索的客户端或用户来说，这个过程就像在查询本地集群的一个超大索引一样简单。

2.为什么要有跨集群检索 ？

主要有以下几个关键原因：

• 数据物理隔离与逻辑统一：
  • 地域隔离：数据可能因合规性（如 GDPR）、低延迟访问需求或灾难恢复等原因，必须存储在不同地理区域的数据中心。每个区域有自己的集群。
  • 业务 / 部门隔离：不同业务线、部门或租户可能管理着自己的独立集群。
  • 环境隔离：生产、预发布、归档数据可能存放在不同的集群。
  • 逻辑统一需求：尽管数据物理分散，但业务上常常需要全局视图进行分析、监控、报告或搜索（例如：全球销售报表、全平台日志分析、跨部门客户信息查询）。CCS 解决了这种物理分散与逻辑统一之间的矛盾。
• 避免不必要的数据迁移：将分散在多个集群的海量数据集中迁移到一个 “中央” 集群成本高昂（网络带宽、存储、计算资源、时间），且可能违反数据驻留要求。CCS 允许你 “查询在原地”，避免迁移。
• 提升本地集群性能与稳定性：将特定区域或业务的查询压力分散到其本地集群处理，避免所有查询都冲击一个庞大的中央集群，提高各集群的独立性和整体系统的可扩展性、稳定性。
• 简化应用架构：应用程序只需连接到一个 “网关” 集群（执行 CCS 的本地集群），即可访问所有关联的远程集群数据，无需在应用层实现复杂的多集群连接和结果聚合逻辑。
• 实时性：直接查询远程集群的数据，结果是实时的，无需等待数据同步到中央存储。

3.实际案例讲解：电商公司的全球订单分析

• 场景：一家大型电商公司 “GlobalShop” 在北美（cluster_us）、欧洲（cluster_eu）和亚太（cluster_ap）三个主要区域部署了独立的 Elasticsearch 集群。每个集群存储和处理其所在区域产生的订单数据（索引名为 orders-<region>-<date>）。公司总部位于北美，其 BI 团队需要生成 实时的全球销售仪表盘，展示：
  • 过去 24 小时全球总销售额。
  • 各区域热门商品排行。
  • 特定跨国客户的全球订单历史。
• 挑战：数据物理分散在三个集群。传统方案需将所有数据实时同步到北美的一个中央集群，这带来巨大网络开销、延迟、存储成本和中央集群压力。
• 跨集群检索解决方案：
  1. 集群划分与配置：
     • 北美 BI 团队使用的集群 cluster_bi（位于北美总部）作为 本地集群（执行 CCS 的集群）。
     • 在 cluster_bi 上配置 远程集群连接：

       PUT /_cluster/settings
       {"persistent": {"cluster": {"remote": {"us_orders": {"seeds": ["es-node-us-1:9300", "es-node-us-2:9300"], // `cluster_us` 的传输层地址"transport.ping_schedule": "30s"},"eu_orders": {"seeds": ["es-node-eu-1:9300", "es-node-eu-2:9300"] // `cluster_eu` 的传输层地址},"ap_orders": {"seeds": ["es-node-ap-1:9300", "es-node-ap-2:9300"] // `cluster_ap` 的传输层地址}}}}
       }
       

       这里定义了三个远程集群连接：us_orders 指向北美订单集群，eu_orders 指向欧洲，ap_orders 指向亚太。连接使用传输端口（默认 9300）。
  2. 创建跨集群索引模式 / Alias（可选但推荐）：
     • 为了查询方便，可以在 cluster_bi 上创建一个别名，逻辑上代表全球所有订单索引：

       POST /_aliases
       {"actions": [{"add": {"index": "us_orders:orders-na-*", // 匹配北美集群的订单索引"alias": "global_orders"}},{"add": {"index": "eu_orders:orders-eu-*", // 匹配欧洲集群的订单索引"alias": "global_orders"}},{"add": {"index": "ap_orders:orders-ap-*", // 匹配亚太集群的订单索引"alias": "global_orders"}}]
       }
       

       global_orders 这个别名现在逻辑上包含了三个远程集群中所有符合命名模式的订单索引。
  3. 执行跨集群搜索：
     • 查询过去24小时全球总销售额（聚合）：

       GET /global_orders/_search
       {"size": 0,"query": {"range": {"order_date": {"gte": "now-24h"}}},"aggs": {"global_sales": {"sum": {"field": "total_amount"}}}
       }
       

       BI 团队在 cluster_bi 上向别名 global_orders 发起搜索。Elasticsearch CCS 引擎会自动将请求拆解：
       • 将 global_orders 解析为 us_orders:orders-na-*、eu_orders:orders-eu-*、ap_orders:orders-ap-*。
       • 将相同的聚合查询并行发送到 cluster_us、cluster_eu、cluster_ap 这三个远程集群。
       • 每个远程集群在其本地的 orders-<region>-* 索引上执行查询和 sum(total_amount) 聚合。
       • 各远程集群将本地聚合结果（一个 sum 值）返回给 cluster_bi。
       • cluster_bi 将来自三个集群的 sum 值 相加，得到最终的全球总销售额，返回给 BI 团队。
     • 查询特定客户 “[e-mail]” 的全球订单历史：

       GET /global_orders/_search
       {"query": {"term": {"customer_email.keyword": "[e-mail]"}},"sort": [{"order_date": "desc"}]
       }
       

       过程类似：
       • 请求被拆解并行发送到三个远程集群。
       • 每个集群查找本地匹配该邮箱的订单文档。
       • 各集群将匹配的文档（可能包含部分排序信息）返回给 cluster_bi。
       • cluster_bi 收集所有结果，在本地进行全局排序（按 order_date 降序），然后返回排序后的最终结果列表给用户。
• 效果：BI 团队在北美总部的 cluster_bi 集群上，通过简单的、如同查询本地索引一样的操作，就实时获取了分散在全球三个集群中的订单数据汇总结果和明细记录，无需关心数据实际存储位置。各区域的订单处理集群也独立运行，互不干扰。

4.跨集群检索的优势

• 数据驻留与合规：严格满足数据必须存储在特定地域的法律法规要求。
• 降低延迟：区域用户访问本地集群数据极快，总部通过 CCS 获取全局视图。
• 横向扩展与隔离：轻松添加新区域/业务集群，独立管理、扩展和故障隔离。
• 避免数据搬迁成本：省去集中化数据带来的巨大网络、存储和计算开销。
• 简化应用开发：应用只需连接一个集群，逻辑透明访问多集群数据。
• 实时性：直接查询源数据，结果零延迟（受网络影响）。
• 灵活性：可按需查询特定集群或组合查询所有集群。

5.实际生产应用注意事项

5.1 网络延迟与带宽

• 性能关键路径：CCS 性能 极度依赖 集群间网络质量（延迟、带宽）。跨大洲查询可能有数百毫秒延迟。
• 影响：复杂聚合、深度分页、大规模结果集返回会显著放大延迟影响。排序需要在本地集群合并所有分片结果，非常消耗内存和 CPU。
• 应对：
  • 优化查询：减少返回字段 (_source filtering)，使用更高效的聚合，避免深度分页（用 search_after）。
  • 考虑 ccs_minimize_roundtrips 参数（见下文）。
  • 确保集群间有高速、稳定的专用网络连接。
  • 将 CCS 的 “网关” 集群（执行查询的本地集群）部署在靠近远程集群或用户的位置。

5.2 ccs_minimize_roundtrips 模式

• Elasticsearch 7.4+ 引入。
• true（默认）：最小化网络往返次数。查询先发到远程集群的一个分片获取全局信息（如 _id 用于排序），然后在本地合并协调。
  • 优点：减少网络交互次数，特别有利于排序查询。
  • 缺点：如果某个远程集群响应慢，会拖累整个查询。
• false：避免部分结果。查询并行发送到所有相关远程分片，等待所有分片响应后再合并。
  • 优点：容忍部分集群响应慢，不阻塞其他集群结果返回（但最终结果仍需等待所有）。
  • 缺点：网络交互次数多，尤其排序查询性能较差。
• 选择：根据业务容忍度和查询类型选择。对延迟敏感且能容忍部分集群慢选 false；追求最快完成且能接受一个慢集群拖累整体选 true。

5.3 版本兼容性

• 远程集群版本：执行 CCS 的本地集群版本 必须 >= 所有远程集群版本。例如，本地是 8.13，远程可以是 8.13、8.12、7.17 （如果本地支持向后兼容）。强烈建议所有集群保持相近的主版本。
• 传输协议：不同主版本间传输协议可能不兼容。需查阅官方兼容性矩阵。

5.4 安全配置

• 传输层加密（TLS）：强烈要求 在跨集群通信上启用 TLS（transport.ssl.enabled: true），防止数据在传输过程中被窃听或篡改。
• 认证与授权：
  • 配置远程集群连接时使用有效的用户名 / 密码或 API Key。
  • 确保用于 CCS 连接的用户在 远程集群 上具有足够的权限（read 索引权限）访问目标索引。
  • 本地集群的 CCS 用户也需要有权限执行跨集群搜索。
  • 仔细规划角色和权限，遵循最小权限原则。

5.5 集群配置与发现

• seeds 列表：提供远程集群中多个协调/候选节点地址，保证连接可靠性。
• 网络可达：确保本地集群节点能通过 seeds 中配置的地址和端口（通常是传输端口 9300）访问到远程集群节点。防火墙规则必须允许。
• 节点角色：远程集群中被连接的节点应具有 remote_cluster_client 角色（通常协调节点默认有此角色）。

5.6 监控与运维

• 指标监控：密切监控 CCS 相关的指标：
  • search.remote_cluster.*（请求数、耗时、失败数）
  • 网络延迟、带宽利用率。
  • 网关集群（cluster_bi）的 CPU、内存、堆压力（尤其排序合并时）。
• 日志：关注相关 WARN 或 ERROR 日志（连接失败、权限问题、版本不兼容）。
• 容量规划：CCS 会增加网关集群的负载（协调、结果合并），需为其预留足够资源。

5.7 功能限制

• 不支持跨集群事务：CCS 是只读操作。不能通过 CCS 写入或更新远程集群数据。
• 部分高级功能受限：如跨集群 join、某些机器学习功能、跨集群索引 / 数据流生命周期管理（ILM / DSLM）需要通过其他方式协调。
• 时间同步：如果查询涉及绝对时间范围（如 now-24h），确保所有集群的时钟高度同步（NTP），否则结果可能不准确。

5.8 替代方案评估

对于超低延迟要求或极频繁的跨集群关联查询，有时在应用层做聚合，或者定期 ETL 少量汇总数据到中央集群可能是更优选择。CCS 并非万能。

6.总结

跨集群检索（CCS）是 Elasticsearch 应对分布式数据挑战的利器，完美实现了 “数据物理分散，逻辑集中查询”。它解决了数据驻留、扩展性、简化应用访问等核心问题。然而，其性能高度依赖网络，且在生产中需谨慎处理版本兼容性、安全配置、网络优化、监控运维以及理解其功能限制（如不支持事务）。合理规划和配置 CCS，能极大地提升大规模、分布式 Elasticsearch 部署的灵活性和价值。