稳定、省钱的 ClickHouse 读写分离方案:基于 JuiceFS 的主从架构实践

原创
05/17 15:03
阅读数 112

Jerry 是一家位于北美的科技公司,利用人工智能和机器学习技术,简化汽车保险和贷款的比价和购买流程。在美国,Jerry 的应用在其所属领域排名第一。

随着数据规模的增长,Jerry 在使用 AWS Redshift 时遇到了一些性能与成本的挑战。Jerry 重新设计了系统架构,使用 ClickHouse 后,数据查询性能提升了 20 倍,并大幅降低了成本。但在使用过程中也遇到了磁盘损坏和数据恢复等诸多存储挑战。作为初创公司,Jerry 希望避免对 ClickHouse 集群进行大量的维护工作。

于是,Jerry 采纳了 JuiceFS, 并创新性地使用其快照功能实现了 ClickHouse 主从架构。这一架构不仅确保了数据的高可用性和稳定性,还显著提高了系统的性能和数据恢复能力。在超过一年的时间里无停机和无复制错误,并提供了可预期的性能。

01 Jerry 数据架构:从 Redshift 到 ClickHouse

起初,我们很自然地选择使用 Redshift 来满足分析查询的需求。然而,随着数据量的急剧增长,我们开始遭遇严重的性能和成本挑战。例如,在生成漏斗和 AB 测试报表时,我们面临着长达数十分钟的加载等待时间。即便在规模合理的 Redshift 集群上,这些操作也耗时过长,导致数据服务一度陷入不可用状态。

我们需要一个更快、更经济的解决方案,并且我们可以接受其不支持实时的更新和删除操作的特性。基于这些条件,在三四年前的时间背景下,ClickHouse 成为了我们的首选。随后,我们成功切换到 ClickHouse,并引入了全新的数据仓库设计,最终取得的成果如下:

重要报表的加载时间从原先的十几分钟到几十分钟大幅缩短至几秒,显著提升了数据处理的效率。我们的总成本降低至原来的四分之一,甚至更低。这一变革让我们的团队以及其他相关部门倍感欣喜,因为他们现在能够更高效地工作,迭代速度更快,且能够编写直观的 SQL 查询。对于 Jerry 而言,是一次巨大的成功。

Jerry 目前采用的架构以 ClickHouse 为核心,辅以 Snowflake。在大部分场景下,即 99% 的数据应用场景中,都依赖 ClickHouse 的高效处理能力。当面临 ClickHouse 无法处理的 1%的数据任务时,我们采取将数据转移至 Snowflake 进行处理的策略。我们做了一些工作以确保用户平滑地在 ClickHouse 与 Snowflake 之间进行数据交换。

02 ClickHouse 部署方式与挑战

我们预计在较长一段时间内维持单机状态。在决定采用此种方法前,我们审慎地评估了单机部署的可持续性,并非仅着眼于眼前的部署需求,而是基于对未来几年内是否适合我们方案的长期考量。

  • 首要考虑因素是性能。在同等计算资源条件下,由于避免了集群的开销,单机部署表现出色,这也符合官方的推荐。我们可以坚持采用单机部署,直至其无法满足业务需求。

  • 另一重要原因在于单机部署对我们而言具有最低的维护成本。这不仅涵盖了集成维护成本,还涉及应用数据设置以及应用层暴露的维护成本。

  • 我们发现目前的硬件条件已经可以支持很大规模的单机 ClickHouse。例如,现在我们可以在 AWS上 买到 24TB 内存和 488 个 vCPU 的 EC2 实例,这个规模比很多投入部署的 ClickHouse 集群都大,使用最新的硬件技术,硬盘带宽也能达到我们设想的规划容量。

因此,从内存、CPU 和存储带宽等角度考虑,单机 ClickHouse 是一个可行的方案,预计在可预见的未来将继续有效

当然,ClickHouse 方案亦存在其固有的问题。

  • 首先,当遭遇硬件故障时,ClickHouse 的宕机时间相对较长,这对业务的连续性和稳定性构成了威胁。

  • 其次,数据迁移和备份在 ClickHouse 中至今仍是一项具有挑战性的任务,实现良好的数据备份和迁移方案尚显困难。

在我们部署该项目后,还遇到了一些问题。

首要问题是常规的存储扩展和维护需求,由于数据量迅猛增长,保持合理的磁盘利用率变得尤为重要,每次操作都需要我们投入大量精力。

另一问题则是由磁盘故障引发的一系列连锁反应。ClickHouse 被设计为疯狂使用硬件资源以提供最好的查询性能,它对磁盘的读写操作非常频繁,经常接近最高带宽,这就带来更大的硬盘硬件故障的可能性。当发生硬件故障的时候,根据数据量的大小,故障恢复通常需要几小时到十几小时,我们也在一些使用者中听到了类似的情况。虽然数据分析系统通常被看作是其他系统的数据副本,但这带来的影响还是非常大的。因此,我们必须对可能出现的硬件故障做好充分准备,而数据备份、恢复和迁移等任务也极具挑战性,需要我们投入更多的精力和资源来应对。

03 在 JuiceFS 上运行 ClickHouse

因此,我们萌生了一个思路,即考虑将 ClickHouse 迁移到基于 JuiceFS 的共享存储环境中运行。这篇文章当时给我提供了一些参考:ClickHouse 存算分离架构探索

为了验证此方案的可行性,我们进行了一系列测试。测试结果显示,在启用缓存的情况下,JuiceFS 的读取性能与本地硬盘的性能接近,与 JuiceFS 博客中展示的结果相似。

写入性能虽降至写入磁盘速度的 10%至 50% ,但对于我们而言,这是一个可接受的范围。

以下是我们对 JuiceFS 挂载进行了针对性的调优操作:

  • 首先,我们启用了 writrback 功能,以实现异步写入,从而避免潜在的阻塞问题。
  • 其次,在缓存设置方面,我们设定了 attrcacheto 为 3600.0 秒,cache-size 为 2300000,并启用了 metacache 功能。
  • 此外,针对 JuiceFS 上 IO 运行时间可能较长于本地磁盘的情况,我们调整了相应策略,引入了 block-interrupt 功能。

最主要的调优目标是提高缓存命中率。由于我们使用的是 JuiceFS 云服务版,我们成功将缓存命中率提升至 95%。若仍需进一步提高,我们将考虑增加硬盘资源。

ClickHouse 结合 JuiceFS 的方案显著减少了运维工作。我们不再需要频繁进行硬盘扩展,而是着重监控缓存命中率,从而大大减轻了扩展硬盘的紧迫性。其次,在硬件故障发生时,我们无需进行数据迁移,这极大地减少了潜在的风险和损失。

JuiceFS 快照(snapshot)功能提供了方便的数据备份与恢复手段,这对我们来说非常有价值。使用快照功能,我可以在未来某个时刻再次运行在数据快照上运行数据库服务,以查看其原始状态,这在文件系统层面上解决了以往需要在应用层面解决的问题。(社区版用户使用克隆功能,实现类似功能,点击此处了解。)

此外,由于无需进行数据迁移,宕机时间得到了大幅减少。我们能够迅速应对故障,或者让自动化系统在另一台机器上挂载目录,确保业务的连续性。值得一提的是,ClickHouse 的启动时间仅需几分钟,这进一步提升了系统的故障恢复速度。

再者,我们的读取性能在迁移后保持稳定,整个公司都未察觉到任何变化,这充分证明了该方案在性能方面的稳定性。

最后,我们的成本也得到了大幅下降。通过将昂贵的云存储产品替换为廉价的对象存储,我们实现了成本的优化,进一步提升了整体效益

为何要搭建主从架构?

在迁移 ClickHouse 后,我们遇到了如下问题,这些问题最终促使我们考虑构建主从架构。

第一:资源竞争所引发的性能下降。在当前的 ClickHouse 使用方式中,我们把所有的任务都放在了这个架构中,当时 ETL 任务与报表任务之间时常发生冲突,影响了整体性能。

第二:硬件故障导致的宕机问题。对于需要随时查看数据的公司而言,长期的宕机是不可接受的。因此,我们考虑在现有基础上寻找解决方案,从而引出了构建主从架构的构想。

JuiceFS 支持在不同地点挂载多个挂载点。于是我们尝试在其他地方直接挂载 JuiceFS 文件系统,并在相同位置运行 ClickHouse。然而,在实施过程中我们遇到了一些问题。

首先,ClickHouse 通过文件锁机制限制同一份文件只能由一个实例运行,这确实带来了一些挑战。但幸运的是,这个问题相对容易解决,我们只需修改 ClickHouse 的源代码并对其进行锁定即可。

其次,即便在应用过程中仅进行只读操作,ClickHouse 仍会保留一些状态信息,如写入时的缓存。

最后,元数据同步也是一个问题。当 JuiceFS 上运行多个 ClickHouse 实例时,写入实例的部分数据可能无法被其他实例感知,这需要我们重启实例以解决问题。

这当然是不理想的,所以我们决定利用 JuiceFS snapshot 功能来实现主从架构。这个架构的使用方式与常规理解的主从架构并无显著差异。所有的数据更新操作均发生在主实例上,包括数据同步和 ETL 等任务;而从实例则专注于为用户提供查询能力。

怎样创建 ClickHouse 从实例?

  1. 使用 JuiceFS 的快照功能命令:从主实例的 ClickHouse 数据目录创建出一个快照目录,并在此目录上部署一个 ClickHouse 服务。

  2. 暂停 Kafka 消费队列:在启动可用于 ClickHouse 的实例之前,必须确保停止对其他数据源的有状态内容的消费。对于我们而言,这意味着暂停 Kafka 消息队列的运行,以避免与主实例竞争 Kafka 数据。

  3. 在快照目录上运行 ClickHouse: 启动 ClickHouse 服务后,我们还将注入一些元数据,以向访问者提供关于 ClickHouse 创建时间等信息。

  4. 删除 ClickHouse data mutation:在从实例上删除所有的 data mutation,这有助于提升系统性能。

  5. 如何进行连续复制:值得注意的是,快照仅保留创建时的状态,为了让“从实例”读到最新的数据,我们定期重新创建副本实例,并替换原有实例。这种方法直观且高效,每个副本实例都从两个副本开始,并有一个指向某个副本的指针。我们可以根据时间间隔或特定条件来重新创建另一个副本,并将指针指向新创建的副本实例,从而无需停机更新。我们设定的最小时间间隔为 10 分钟,通常每小时运行一次即可满足需求。

ClickHouse 的主从架构已稳定运行超过一年,期间完成了超过 2 万次的复制操作而未曾失败,展现了其极高的可靠性。工作负载隔离和数据副本的稳定性是提升性能的关键。我们成功地将整体报表的可用性从不足 95% 提升至 99% ,而且这一提升无需任何应用层面的优化。此外,该架构支持弹性扩展,极大地增加了灵活性,使我们能够根据需求随时开发和部署新的 ClickHouse 服务,而无需额外的复杂操作。

未来展望

  1. 我们期望开发一个更为优化的控制界面,以实现自动化实例的生命周期管理、创建操作以及缓存管理功能。

  2. 在运行主从架构的过程中,我们观察到主实例在 JuiceFS 上相较于本地硬盘更易发生崩溃现象。尽管大多数情况下可以同步数据,并且同步的数据通常随时可由其他副本访问,但在处理失败时仍需考虑这一特殊情况。尽管我们从概念和原则上对崩溃原因有所了解,但至今仍未完全解决这一问题。简而言之,由于文件系统上的 I/O 系统调用时间较本地硬盘更长,这些异常情况可能会传导至其他组件,进而引发主实例的崩溃。

  3. 优化写入性能。主要涉及两个方面。首先,从应用层面来看,由于当前对 Parquet 开放格式的支持已经相当完善,因此,对于大部分负载,我们可以在 ClickHouse 之外将其直接写入 JuiceFS,以便于访问。这样,我们可以采用传统方式实现并行写入,从而提高写入性能。

  4. 我们注意到一个新项目 chDB,该项目允许用户在 Python 环境中直接嵌入 ClickHouse 功能,无需 ClickHouse Server。结合 CHDB 和 JuiceFS 我们可以实现完全 serverless 的 ClickHouse。这是一个我们在探索的方向。

04 为什么选择 JuiceFS

第一个原因十分明确,JuiceFS 在当时是我们唯一可选的能在对象存储上运行的 POSIX 文件系统。

第二个原因在于其无限的容量特性。自我们使用以来,基本上无需再为容量问题而担忧。

第三个原因则是其成本优势显著,相较于其他方案,JuiceFS 的成本大幅降低。

第四个令人称道的功能是其强大的快照(snapshot) 能力。它巧妙地将 Git 分支的思维模型引入文件系统层面,并正确、高效地实现了这一模型。当两个不同层面的概念结合得如此完美时,往往能带来极具创意的解决方案,使得之前需要付出巨大努力才能解决的问题变得轻而易举。正如我们之前所面临的主从架构问题,若在其他层面处理,无疑会是一个庞大的项目。

05 JuiceFS 在各场景的应用

数据交换:我们聚焦于 ClickHouse 的应用。利用其访问共享存储的特性进行数据交换,为我们提供了诸多有趣的场景。其中,将 JuiceFS 挂载在 JupyterHub 上尤为引人注目。一些数据科学家将数据输出到特定目录中,这使得在编写报表时,我们可以用这个数据直接对所有 ClickHouse 中的表进行联合查询,极大地优化了整个工作流程。尽管许多工程师认为将数据同步写入并不困难,但长期累积下来,若每日都能省去这一步骤,将极大地减轻心智负担。

机器学习管线:在 JuiceFS 上存储所有机器学习管线所需的数据,包括训练数据等,JuiceFS 为我们打通工作流提供了便捷的途径。通过这种方式,我们可以轻松地将训练时的 notebook 输出放置到指定位置,从而在 JupyterHub 上实现快速访问,使得整个管线流畅无阻。

Kafka + JuiceFS:我们将 Kafka 存储在 JuiceFS 上,尽管我们直接访问 Kafka的应用场景并不多,但考虑到其作为数据资产的长期存储价值,我们仍选择采用这种方式。相较于使用 AWS 相应产品,我们通过这种方式保守估计节省了约 10-20 倍的成本。经过性能测试,我们发现单机性能有所下降,但是这个方案具备良好的水平扩展能力,可以通过添加节点获得我们所需要的吞吐量。该方案的信息延迟相较于本地存储稍大,且存在某些不稳定问题,不适合用在需要实时流处理的场景。

最初,我作为个人用户开始使用 JuiceFS, 在我看来,JuiceFS 的设计优雅、是一个能让开发者的生活变得简单的产品,这一点非常重要。当我在工作中引入 JuiceFS 时,它也总能把事情变得简单。希望这篇文章能给创业型公司,或者大公司里的小型业务,带来有价值的参考。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
返回顶部
顶部