Trip.com 如何从 Elasticsearch 迁移到 ClickHouse 并构建了 50PB 的日志解决方案

本文字数：8721；估计阅读时间：22 分钟

审校：庄晓东（魏庄）

本文在公众号【ClickHouseInc】首发

在 Trip.com，我们为用户提供广泛的数字产品，包括酒店和机票预订、景点、旅游套餐、商务旅行管理和与旅行相关的内容。正如你所猜的那样，我们需要一个可扩展、可靠且快速的日志平台，这对于我们的运营至关重要。

在我们开始之前，为了激起你的好奇心，让我展示一些我们在 ClickHouse 上构建的平台的关键数据：

这篇博客文章将讲述我们日志平台的故事，包括为什么我们最初构建它、我们使用的技术，以及我们在 ClickHouse 上利用 SharedMergeTree 等功能对其未来的规划。

以下是我们在旅程中将讨论的不同主题：

• 我们如何构建一个集中的日志平台

• 我们如何扩展日志平台并从 Elasticsearch 迁移到 ClickHouse

• 我们如何改进我们的运营体验

• 我们如何在阿里云上测试 ClickHouse Cloud

为了简化，让我们把这些内容放在一个时间线上：

构建一个集中的日志平台

每个伟大的故事都始于一个巨大的挑战。在我们的案例中，这个项目起源于 2012 年之前，因为 Trip.com 没有统一或集中的日志平台。每个团队和业务单元（BU）各自收集和管理自己的日志，这带来了许多不同的问题：

• 需要大量人力来开发、维护和操作所有这些环境，不可避免地导致了大量重复工作。

• 数据治理和控制变得复杂。

• 公司内部没有统一的标准。

基于这些问题，我们意识到需要构建一个集中和统一的日志平台。

2012 年，我们推出了第一个平台。它建立在 Elasticsearch 之上，开始定义 ETL、存储、日志访问和查询的标准。

尽管我们不再使用 Elasticsearch 作为我们的日志平台，但值得探讨我们当初是如何实现这个解决方案的。它驱动了我们后来的许多工作，这是我们在后续迁移到 ClickHouse 时必须考虑的。

存储

我们的 Elasticsearch 集群主要由主控节点、协调节点和数据节点组成。

主控节点

每个 Elasticsearch 集群至少由三个主控节点组成。其中一个将被选为主节点，负责维护集群状态。集群状态是包含有关各种索引、分片、副本等信息的元数据。任何修改集群状态的操作都会由主控节点执行。

数据节点

数据节点存储数据并用于执行增删改查（CRUD）操作。它们可以分为多个层次：热层、暖层等。

协调节点

这种类型的节点没有其他功能（如主控、数据、摄取、转换等），并通过考虑集群状态作为智能负载均衡器。如果协调节点接收到带有 CRUD 操作的查询，它会被发送到数据节点。相反，如果接收到添加或删除索引的查询，它会被发送到主控节点。

可视化

基于 Elasticsearch 我们使用 Kibana 作为可视化层。你可以在下方看到一个可视化示例：

日志插入

我们的用户有两种方式将日志发送到平台：通过 Kafka 和通过代理。

通过 Kafka

第一种方法是使用公司的框架 TripLog 将数据导入 Kafka 消息代理（使用 Hermes）。

private static final Logger log = LoggerFactory.getLogger(Demo.class);

public void demo (){
  TagMarker marker = TagMarkerBuilder.newBuilder().scenario("demo").addTag("tagA", "valueA").addTag("tagA", "valueA").build();
  log.info(marker, "Hello World!");
}

这为用户提供了一个轻松将日志发送到平台的框架。

通过代理工具

另一种方法是使用代理工具，如 Filebeat、Logstash、Logagent 或定制客户端，直接写入 Kafka。你可以在下面看到一个 Filebeat 配置示例：

filebeat.config.inputs:
  enabled: true
  path: "/path/to/your/filebeat/config"
filebeat.inputs:
  - type: