[FR] can we add mq Middleware for server to save data which write to clickhouse about deepflow

[1473371932]

你好，目前我们已经有做这个 feature 的规划，预计在 6.6 版本，按照版本迭代周期计算，预计时间会在下半年

[LGTH]

nice

[sharang]

ClickHouse 官方的一篇博客，供参考：https://mp.weixin.qq.com/s/GnSRQzE0lP4m3zxyMkajaA

如何利用 ClickHouse 构建一个存储容量达到 19 PB的日志平台，并实现了数百万美元成本的节省

不使用 Kafka 队列作为消息缓冲区

在日志架构中，将 Kafka 队列作为消息缓冲区是一种常见的设计模式，并且由 ELK 堆栈广泛采用。它提供了一些好处；主要是，它有助于提供更强的消息传递保证，并有助于处理背压。消息从收集代理发送到 Kafka 并写入磁盘。理论上，集群化的 Kafka 实例应该提供高吞吐量的消息缓冲区，因为将数据线性写入磁盘的计算开销较小，而不是解析和处理消息 - 例如，在 Elastic 中，标记化和索引化会产生显着的开销。将数据从代理移开还会降低因源头的日志轮换而丢失消息的风险。最后，它提供了一些消息回复和跨区域复制的能力，对某些用例可能会有吸引力。

然而，ClickHouse 可以以极快的速度处理数据插入 - 在中等硬件上每秒能处理数百万行。ClickHouse 几乎不会出现背压。因此，在我们的规模上，使用 Kafka 队列根本没有意义，这只会增加架构的复杂性和成本，而不是必要的。在确定这种架构时，我们还坚持一个重要原则 - 并非所有日志都需要相同的传递保证。在我们的情况下，我们对在途数据的丢失更加宽容，因为如果需要，我们在实例本身上有第二个副本日志 - 尽管我们仍然努力将在途数据的丢失降至最低，因为丢失的消息可能会干扰调查。