一、背景技术

目前行业中实时数仓一般有两种架构：

• Lambda架构。该架构（图1）需要同时存在离线计算和实时计算两条链路。离线一般消费T+1历史数据，覆盖前一天实时计算的结果。实时计算通过消息队列采用增量消费方式消费实时数据。该架构数据准确性好，可靠性高，但是架构相对复杂，运维难度大，综合成本高。

                  图1 Lambda架构

• Kappa架构。该架构（图2）只保留了实时计算链路。通过消息队列的偏移量达到消费历史数据的目的。这种架构相对简单，但是缺点在消息队列中必须保留相对久的历史数据，同时计算层压力大。

                  图2 Kappa架构

该架构存在一个变种，将数据聚合等逻辑在数据服务层迁移至olap引擎中，从而减轻数据聚合层面的压力。这个方案的优点是查询灵活度更高，但是对olap引擎的性能和健壮性提出了很高的要求。

二、设计目标

超大量级日志数据应用系统（图3）设计的目的在于既能保证超大量级数据导入的实时性，又能即席进行数据分析，同时可以做到整个应用体系的高性能，高可用，高扩展。

                  图3 系统架构

三、技术方案

本系统主要包括两大部分：基于clickhouse的分布式实时数仓系统，高性能实时导入组件。

分布式实时数仓系统，基于kubernetes进行clickhouse集群搭建，其集群架构较常规的方式进行优化，并通过引入自研分流组件，优化使用方式等可以做到快速部署和扩容，热更新集群配置，动态降低系统负载等。

自研特大量级实时导入组件，基于disruptor进行实时消费组件建设，容器化部署，可以实现弹性扩缩容，通过配置生产者和消费者比例解决速度匹配问题提高写入能力。可通过配置字典，实现兼容多种日志模板和字段配置。通过结合系统架构的节点分流体系，避免物理节点单点流量过高。

• 详细设计

   本章节包含两块内容：

• 基于clickhouse的分布式实时数仓系统
• 自研特大量级实时导入组件

    基于clickhouse的分布式实时数仓系统

较常规的clickhouse系统集群架构，随着集群数据量级越来越大，如何快速热扩容，如何跨数据中心应用的同时保证元数据不超载，如何快速使配置热生效，这是本系统架构（图4）解决的痛点，具体的技术方案如下：

      1、整个集群采用kubernetes容器化部署，所有组件配置均可采用configmap的形式直接挂载/宿主机挂载/在容器内生成的方式进行挂载。

     2、集群的拓扑结构/用户配置/权限/配额不再单节配置，统一在zookeeper中管理，实现user/quota/cluster的热更新。

     3、集群较常规单zookeeper系统架构转换为多zookeeper系统架构，每组zookeeper只负责一定量级的分片（特大集群需要N组 zookeeper），从而分散zookeeper负载压力，有利于扩容和故障隔离。

     4、架构层面增加一层Proxy，所有读场景甚至部分特殊的写场景全部走Proxy，不会直接暴露集群节点。同时Proxy层可以进行账号校验和请求拓扑调整。

     5、引入自研分流组件，定时更新节点健康度和负载情况。

     6、至此，完成集群架构建设。此时集群已具备热扩容，热更新配置，高可用的能力。

                            图4 本系统架构

 自研特大量级实时导入组件（图5）除了对数据层面进行适配，还对常规的写入过程进行了调整，具体技术方案如下：

     1、生产者直接消费消息中间件的数据，数据进入本地的无锁环形队列。

     2、组件多个消费者加载配置字典和格式模板。

     3、消费者向数据分流组件请求可用节点，经判断后建立应用于当前数据批次直连clickhouse节点的连接。

     4、在消费新数据前判断是否满足写入当前批次的条件。若满足一定时间阈值或满足批次大小时，将数据写入clickhouse集群，并重新执行步骤3，获取新的节点并创建连接，否则继续消费数据。

     5、消费者从环形队列中消费新数据。根据适配条件，依次进行时间阈值判断，格式判断，分隔符判断，字段映射等流程，解析日志内容并进行封装。

     6、将步骤5中处理好的数据写入statement。

     7、重复步骤4至6，持续消费数据并写入clickhouse。

     8、至此，完成数据消费阶段。这种方式直接写入本地表，在大数据量级消费的同时兼顾了集群的稳定性。

                         图5 消费组件架构

六、优点和效果。

本系统具备以下优点：

1. 降低了clickhouse集群后期维护的成本，通过分散为多个子集群，每组子集群内只需要维护部分shard的元数据，线性降低了zookeeper的负载，很大程度避免了元数据不一致的问题，降低了ddl/insert操作的风险。
2. 集群配置可以热更新，可以动态添加用户，修改配置，修改集群拓扑，添加分片/节点进行扩容，故障节点可以快速剔除/替换，从而大大提高了集群的健壮性。
3. 通过引用proxy/分流组件，可以进行账号/密码的映射，不再直接暴露操作clickhouse集群的账号密码，可以将后者作为资源池使用，有利于平台saas化。同时可以做全局的限流和资源配置。
4. 有利于感知故障节点后，自动调整集群拓扑，保证集群健壮性，并保证集群数据一致性。
5. 改进的clickhouse写入方式避免了流量全走proxy，导致proxy节点网络阻塞的问题，同时监控集群健康情况和节点负载，避免故障节点对集群写入的影响。
6. 改进的数据消费方式使用无锁环境队列提高了消费处理效率，在等待数据达到阈值前做好了push准备，较数据齐备后再处理，缩短了处理时间。同时解耦了消息中间件和业务逻辑，减少了扩容时，对消息中间件的影响，如缩短了rebalance的时间。