Quickwit是一种全新的全文搜索引擎，其成本效率比 Elasticsearch 高十倍，配置和管理显著更简单，并且能够扩展到 PB 级别的数据。

1.需求场景

公司A是一个加密货币交易所，每天处理着巨大的交易量，每笔交易都会产生对安全、合规性和运营洞察至关重要的日志。这导致了大约每秒处理 2100万条日志记录，相当于每秒 18.5GB，或每天 1.6PB 的日志量。

2.基于Elasticsearch的日志云解决方案

公司A为了管理如此庞大的数据量，一开始使用Elasticsearch的日志云系统，架构如下图所示：

为了处理大数据量，Vector中大约有600个pod，用于将kafka中的数据写入Elasticsearch中。下游Elasticsearch集群的数量为20。

在运行一段时间后，这种架构带来了下面几个严重的问题：

（1）运维复杂性：Elasticsearch 集群数量众多，运维工作极其繁重。

（2）有限的保留期限：目前公司A仅保留大部分日志几天的时间。目标是将此期限延长至数月，这意味着需要存储和管理 100PB 的日志，这对于他们的 Elasticsearch 设置来说成本高昂且复杂。

（3）有限的可靠性：为了限制基础设施成本，高吞吐量的 Elasticsearch 集群被配置为没有副本，这损害了持久性和可用性。

为此，公司A还需要找到其他的方案。

3.基于Quickwit的日志云解决方案

公司A的工程师发现了Quickwit，对于当前的场景，Quickwit有以下几个重要的优势：

（1）原生 Kafka 集成：支持kafka exactly-once语义，避免数据丢失和数据重复问题，提供了巨大的运维好处。具体而言，您可以拆除集群，在一分钟内重新创建，不会丢失任何数据，准备好以每天 1.6PB 的速度摄入或搜索 PB 级别的数据，并且可以根据临时峰值上下调整规模。

（2）对象存储作为主要存储：所有索引的数据都保留在对象存储上，消除了在集群侧配置和管理存储的需求。

（3）更好的数据压缩：Quickwit 通常比 Elasticsearch 实现好两倍的数据压缩，进一步减少了索引的存储占用。

Quickwit 扩展到多 PB 级别，任何工程师都知道将系统扩展 10 倍或 100 倍可能会暴露出意想不到的问题。但这并没有阻止他们，他们准备迎接这一挑战！首先解决索引扩展，再解决搜索扩展。

3.1.索引扩展

架构如下所示：

经过一段时间的实践和优化，公司A终于实现了 1.6 PB 的索引吞吐量，使用了10个kafka topic，每个topic对应一个Quickwit Indexer集群，共10个Quickwit Indexer集群，包括700 个 Pod、2800 vCPU、6 TB 内存，平均每个 vCPU 达到 6.6 MB/s。在一个特定的高吞吐量 Kafka topic 上，这个数字上升到了每个 vCPU 11 MB/s。

3.2.搜索扩展

现在 Quickwit 已经能够高效地每天索引 1.6PB 的数据，挑战转向了搜索 PB 级别的日志。如果有 10 个集群，公司A通常需要为每个集群部署搜索 Pod，这削弱了 Quickwit 的一个优势：汇聚搜索资源以访问所有索引共享的对象存储。

将每个索引集群元存储中的所有元数据复制到一个PostgreSQL 数据库中，创建了一个统一的元存储。这个统一的元存储使得部署一个独特的集中式搜索集群成为可能，该集群能够搜索所有索引！

架构如下图所示：

目前，公司A管理着一个适度规模的搜索集群，包含 30 个搜索 Pod，每个 Pod 请求 40 个 vCPU 和 100GB 内存。

3.3.Quickwit日志云系统的优势

公司A成功地将多个 PB 级别的 Elasticsearch 集群迁移到 Quickwit上，并获得了性能和成本上的提升：

（1）将索引扩展到了每天 1.6 PB。

（2）运行了一个处理100 PB 日志的搜索集群。

（3）每年节省数百万美元，通过降低 80% 的计算成本和减少 20 倍的存储成本（对于相同的保留期）。

（3）在基础设施成本和维护操作方面都是经济可行的大规模日志管理解决方案。

（4）配置微调最少，一旦确定了正确的 Pod 数量和资源，就能够高效工作。

（5）根据日志类型，将日志保留期限增加到一个月或几个月，提高了内部故障排查的能力。