Search before asking
Description
在 AWS 等公有云上跨多个可用区（AZ）部署 DeepFlow 和 ClickHouse 时，跨 AZ 的数据传输会产生高昂的双向流量费用。
目前，DeepFlow 采集的观测数据（Metrics、Tracing、Logging）吞吐量极大。如果 deepflow-server 向 ClickHouse 写入数据时没有可用区感知能力，位于 AZ-A 的 deepflow-server 可能会把数据发送到位于 AZ-B 的 ClickHouse 节点。这种跨可用区的数据路由会导致海量的无效跨 AZ 流量，极大地增加了云账单成本。
Use case
我们希望在多可用区场景下，采用 “各 AZ 独立分片存储、仅在查询时跨 AZ 汇总” 的低成本轻量化架构。这需要 deepflow-server 能够支持就近写入/可用区亲和性路由：就近写入本地表（Local Table）：位于 us-east-1a 的 deepflow-server 实例，应当优先或强制将数据写入部署在相同可用区（us-east-1a）的 ClickHouse 本地表节点，从而保证写入阶段的跨 AZ 流量成本为 $0$。分布式表负责查询：数据在写入时无需跨 AZ 同步。当需要全局视图或追踪链路时，再通过 ClickHouse 的 Distributed 分布式表引擎跨可用区下推并聚合查询结果。
Related issues
No response
Are you willing to submit a PR?
Code of Conduct
Search before asking
Description
在 AWS 等公有云上跨多个可用区（AZ）部署 DeepFlow 和 ClickHouse 时，跨 AZ 的数据传输会产生高昂的双向流量费用。
目前，DeepFlow 采集的观测数据（Metrics、Tracing、Logging）吞吐量极大。如果 deepflow-server 向 ClickHouse 写入数据时没有可用区感知能力，位于 AZ-A 的 deepflow-server 可能会把数据发送到位于 AZ-B 的 ClickHouse 节点。这种跨可用区的数据路由会导致海量的无效跨 AZ 流量，极大地增加了云账单成本。
Use case
我们希望在多可用区场景下，采用 “各 AZ 独立分片存储、仅在查询时跨 AZ 汇总” 的低成本轻量化架构。这需要 deepflow-server 能够支持就近写入/可用区亲和性路由：就近写入本地表（Local Table）：位于 us-east-1a 的 deepflow-server 实例，应当优先或强制将数据写入部署在相同可用区（us-east-1a）的 ClickHouse 本地表节点，从而保证写入阶段的跨 AZ 流量成本为$0$ 。分布式表负责查询：数据在写入时无需跨 AZ 同步。当需要全局视图或追踪链路时，再通过 ClickHouse 的 Distributed 分布式表引擎跨可用区下推并聚合查询结果。
Related issues
No response
Are you willing to submit a PR?
Code of Conduct