演化分析可视化（大规模交互式分析）

分享不易，关注转发，随笔感悟，职场心得。

在大数据企业中，需要一个平台，使我们的业务用户能够通过对庞大的数据集执行交互式分析来做出相对清晰的数据驱动决策。这个场景需要一个可以处理大量数据的 OLAP 系统。为了做到这一点，可以利用 ClickHouse（关于ClickHouse之前有发文分析，我们已经投入生产使用了两年，效果客观，结果满意，未来持续跟进），它可以在几秒钟内对数十亿行数据运行分析查询。

但是，管理和维护一个存储和处理 TB 级数据的数据库集群可能是一项艰巨的任务。通过这篇文章，将回顾我们平台的架构来分享一些对设置 ClickHouse 分布式集群有用的最佳实践。我们的很多B端客户也是基于我们的DaaS，基于我们的集群，构建仪表板，使他们能够做出更明智的业务决策。

该平台的架构设计需要保持高度可用且易于扩展，还需要屏蔽底层基础设施的细节，这样我们能够对基础架构进行更改，而不会造成任何停机或对用户产生影响。

架构概述：

以下是对关键组件以及它们如何与系统其余部分交互的说明：

关于负载局衡器的落地可以场景有多种技术方案， 负载均衡器是我们的客户端和平台之间的接口。负载均衡器将流量定向到 Chproxy 服务器，该服务器进一步与 ClickHouse 集群通信。

负载均衡器会配置健康检查，通过LB 不断轮询 Chproxy 服务器将流量定向到健康服务器，并在主服务器不可用的情况下切换到故障转移服务器。

Chproxy 是为 ClickHouse 数据库开发的开源第 3 方代理层。

Chproxy 为我们提供以下好处：

• 用户特定路由：由于 ClickHouse 集群在许多消费者之间共享，因此 Chproxy 使我们能够将用户请求路由到处理请求的数据节点。针对物理集群中存在的特定消费者的数据，可以做指向性的路由策略。
• 缓存：我们已将特定用户的查询，基于Chproxy 配置了缓存，特别是那些不经常刷新数据的用户。这样的操作是为了让底层 ClickHouse 集群免于重复执行复杂的查询，直接从缓存中读取数据，也使用户能够更快地获得结果，。
• Chproxy 充当客户端应用程序和 ClickHouse 集群之间的抽象层。它使我们能够在不影响消费者的情况下对 ClickHouse 基础架构进行更改。

Chproxy 进程在我们的服务器上会配置为自定义 Linux 服务，在出现任何故障时会自动启动。

ClickHouse 集群是平台的核心和灵魂，是一个共享集群，我们的许多客户会在不同的场景下应用它。

• 可扩展性：

此类系统处理 TB 级数据非常常见。在这种情况下，在多个节点之间拆分数据，俗称为Sharding。分片可以水平扩展集群，并结合多台服务器的功能来共同处理资源密集型查询。

• 高可用性：

为了确保高可用性，可创建每个分片的跨 DC 副本。这样可以保证服务器或整个 DC 的故障不会导致平台崩溃。异步复制是使用 ClickHouse 平台的 Replicated 引擎实现的。

• 单独的读写副本：

在我们平台的初始阶段，我们曾经在服务器节点之间进行分片循环复制的方法。ClickHouse 集群中的每个节点都携带一个分片的原始数据以及另一个分片的副本。但是，采用这种方法会对读取查询产生不可预知的影响。

为了解决这个问题，我们决定在集群中分离服务于读取和写入流量的副本。执行复杂写入操作的 ETL 作业的所有流量在写入集群中的副本之间共享。写入副本的数据由 ClickHouse 异步复制到读取副本。使用 ClickHouse 中的first_or_random负载平衡，读取查询由读取集群中的副本处理，但是，如果一个分片的读取副本不可用，它将由写入集群中的副本处理。

总的来说，这种方法提供了以下好处：

• 读取变得更加可预测。由于正在运行的 ETL 作业而必须执行的所有繁重处理都在写入节点上执行。
• 这种架构更容易扩展。如果读取流量急剧增加，可以通过在读取集群中添加更多副本来横向扩展系统，并在它们之间共享流量。
• 只读副本可以利用具有更高 IOPS（本地 SSD）的更快磁盘，这可以进一步提高读取查询的性能。

ClickHouse 使用 Apache ZooKeeper 执行数据复制。ZooKeeper 存储副本的元数据，用于确保所有副本同步。

ZooKeeper 集成由运行在不同机器上的三个 ZooKeeper 服务器创建，确保 ZooKeeper 服务在任何一个 ZooKeeper 服务器崩溃的情况下可用。

这种平台架构设计使客户或者业务用户能够在几秒钟内根据海量数据做数字决策。同时兼顾了高度可用且易于扩展。