Contentsquare 从 Elasticsearch 迁移到了 ClickHouse

欢迎Contentsquare作为我们博客的嘉宾。请继续阅读，了解他们为什么使用ClickHouse，以及从Elastic迁移到ClickHouse的经历。

在Contentsquare，我们过去在Elasticsearch上运行我们的主要SaaS应用程序。

5年前，我们开始了一个迁移过程，将所有的分析应用程序都迁移到ClickHouse 上运行。我们希望通过迁移来改善水平可扩展性、系统的稳定性以及整体效率（查询时间和成本）。

在这篇博文中，我们将告诉您更多关于迁移过程和所学到的经验。

为什么决定进行迁移？

我们在生产环境中有14个Elasticsearch集群。每个集群有30个节点（3个主节点）。我们使用带有网络附加磁盘的 m5.4xlarge 实例。当时，我们在水平可扩展性方面遇到了困难，因为我们无法组建更大的集群并保持它们适应我们的工作负载的稳定性。

由于我们的集群规模有限，我们无法处理任何无法适应单个集群的租户。这对我们公司的增长能力施加了严重的限制。我们能处理的流量有一个上限，这意味着我们的公司增长因技术原因而放缓。对我们来说，这是不可接受的。

为了消除这个技术限制并支持公司的增长，我们有两个选择：

1. 找到一种方式在多集群环境中高效地托管每个租户。

2. 迁移到一种更可扩展的技术。

我们选择了第二个选项，并开始研究适合我们需求的OLAP数据库引擎：

• 查询的最小延迟。

• 丰富的查询语言。

• 适用于机械硬盘的快速高效。

• 部署和操作简单。

经过广泛的工程研究，并对市场上的大多数OLAP数据库和处理系统进行调查，我们发现ClickHouse符合我们的所有要求，并开始计划迁移。

我们的迁移策略

迁移一个大型的、在生产环境中被数千个客户使用的代码库并不是一件容易的事。我们将迁移工作分为3个阶段：

1. 熟悉ClickHouse并用它构建一个新产品

2. 使用自定义工具复制所有现有功能，以确保没有任何退化

3. 逐个迁移我们的客户

阶段 1: 搭建新产品掌握新技术

我们在迁移现有产品之前，选择了在ClickHouse之上构建一个新产品。我们希望先熟悉这项技术，并在一个更安全的环境中将其投入生产。这个阶段的目标是：

• 熟悉技术并学习如何使用它

• 构建ClickHouse部署的自动化和CI/CD工具

• 设置警报和监控系统 

我们花了大约4个月的时间来发现这项新技术、调整它并构建所需的工具。这个阶段对团队的能力提升非常有价值，并使我们对在更大规模上部署ClickHouse感到更加自信。

阶段2：迁移现有产品

在成功完成第一个里程碑后，我们将注意力转向我们的主要产品。我们将团队分为两个部分：一半负责维护和改进当前的技术栈，另一半则负责将所有现有功能迁移到ClickHouse上。

我们以迭代的方式进行主产品的迁移。我们逐个迁移每个现有的API端点，并重新编写它们，使其使用ClickHouse而不是Elasticsearch。我们监听每个传递到旧端点的查询，并在新端点上重新执行相同的查询。这样，我们可以通过实际生产使用中的比较，对比两个端点的结果，识别错误并逐步修复。一旦我们认为该端点稳定可靠，我们就开始重写下一个端点。

在此期间，所有生产查询仍然由旧的Elasticsearch处理。新的ClickHouse基础架构尚未在生产环境中使用。

阶段 3: 迁移客户

在将所有端点迁移到ClickHouse并进行测试后，我们对将客户迁移到新基础架构感到非常放心。我们再次非常小心地不同时迁移所有客户，以确保有足够的时间和资源来识别潜在问题。

我们最初迁移了一个客户，然后是另一个客户，再然后是更多的客户。在接下来的6个月内，我们的所有客户都完成了迁移，我们的Elasticsearch集群可以关闭。我们自豪地说，在迁移过程中，我们完全没有遇到任何回归问题，这要归功于我们仔细的规划和准备。

我们迁移之后的体验

ClickHouse的运行成本比原来降低了11倍，同时查询的p99性能提升了10倍。因此，我们能够允许客户查询多达3个月的历史数据，而不仅仅是之前的1个月。我们还将数据保留期延长到了13个月，因为现在技术上有可能实现这一点。

我们对 ClickHouse 的设置

在迁移到ClickHouse时，我们进行了两个主要的架构调整，以充分利用ClickHouse的优势。

首先，我们设计了一个自定义的数据导入组件，以降低主要ClickHouse集群中插入操作的开销。其次，我们决定将查询表示为抽象语法树。这使我们能够构建一个查询优化器，利用我们的数据模型所隐含的一些假设。

摄入流水线

我们将数据逐个分片进行插入，但我们确保插入的方式与我们在分布式表中定义的分片键兼容。这样做可以减少集群管理插入操作所需的I/O量。

因此，我们不得不构建一个专门的组件，我们称之为 clickin ，用于处理插入操作。clickin 从Kafka主题中读取数据；Kafka主题中的数据使用ClickHouse的分片键进行分区。因此，分区分配是静态的。

由于我们已经构建了一个组件来最小化插入操作的I/O开销，我们也利用这个机会实现了另一个优化。 clickin 将输入数据使用 clickhouse-local 实例转换为ClickHouse的本地格式，然后将其发送到集群。这样，我们可以节省一些CPU资源，因为数据以对ClickHouse最有效的格式到达。

查询优化器

我们从一开始就选择构建一个库，允许我们将ClickHouse查询构建和操作为抽象语法树。我们需要采用这种方法，因为我们的大多数查询都是动态的，并且使用用户选择的构建模块即时组合而成。这个设计选择使我们能够构建一个查询优化器，为我们进行几个重要的转换：

• 将分区键和排序键条件传播到所有子查询中

• 在适用时，将 distributed_group_by_no_merge 设置传播到嵌套子查询中

• 在适用时将子查询合并在一起 

• 在生成查询之前简化一些冗余/无用的代数表达式。

这些优化使我们最慢的5%查询的速度提高了10倍。

经验教训: 丝滑般迁移的注意事项

• 不要将迁移视为修复功能性错误的机会。这会使您的非回归测试变得非常困难，并且会减慢进展速度。

• 投资于非回归测试的自动化。

• 备份尚不完善，我们不得不构建一个小工具来进行备份。我们利用了这里描述的一种技术。

• ClickHouse非常非常快，但对于查询优化几乎没有什么帮助。

  • 投资足够的时间来了解MergeTree引擎以及查询的执行方式。

  • 确保所有关于实体的数据都在一个单独的分片中。这将允许您使用   distributed_group_by_no_merge = 1 ，并减少网络I/O。

  • 确保可以轻松关闭所有写入表的进程，在进行模式更改之前您需要这样做。 

从Elasticsearch迁移到ClickHouse是一个漫长的过程，但这是我们所做过的最好的技术决策之一。我们没有任何后悔，这释放了新功能、增长和更容易扩展的潜力。

联系我们

手机号：13910395701

邮箱：Tracy.Wang@clickhouse.com

满足您所有的在线分析列式数据库管理需求