微信ClickHouse实时数仓的最佳实践

腾讯程序员云加社区

一、微信遇到的挑战

一般来说,微信主要的数据分析场景包含以下几个方面:

科学探索:服务于数据科学家,通过即席查询做业务上的归因推断;

看板:服务于运营和管理层,展示所关注的核心指标;

A/B实验平台:服务于算法工程师,把新的模型,放在A/B实验平台上做假设检验,看模型是否符合预期。

除此以外,还有实时监控、日志系统明细查询等场景。

在所有的场景当中,使用者都有非常重要的诉求——快:希望查询响应更快,指标开发更快完成,看板更新更及时。与此同时,微信面临的是海量的数据,业务场景中“单表日增万亿”很常见,这就对下一代“数据分析系统”提出新的挑战。

在使用ClickHouse之前,微信使用的是Hadoop生态为主的数仓,存在以下这些问题:

响应慢,基本上是分钟级,可能到小时,导致决策过程长;

开发慢,由于传统的数仓理念的多层架构,使得更新一个指标的成本很高;

架构臃肿,在微信业务体量规模的数据下,传统架构很难做到流批一体。进而导致,代码需要写多套、数据结果难以对齐、存储冗余。经过十几年的发展之后,传统的Hadoop生态的架构变得非常臃肿,维护难度和成本都很大。

所以,微信一直在寻求更轻量、简单敏捷的方案来解决这些问题。经过一番调研,在百花齐放的OLAP产品中,最终选定了ClickHouse作为微信OLAP的主要核心引擎。主要有两个原因:

效率:在真实数据的实验场景下,ClickHouse要比Hadoop生态快10倍以上(2020年底测试);

开源:微信的A/B实验、线上特征等场景会有些个性化需求,需要对引擎内核做较多改动;

因此,微信尝试在OLAP场景下,构建基于ClickHouse计算存储为核心的“批流一体”数仓。

但是,使用原生的ClickHouse,在真正放量阶段出现了很多问题:

稳定性:ClickHouse的原始稳定性并不好,比如说:在高频写入的场景下经常会出现too many part等问题,整个集群被一个慢查询拖死,节点OOM、DDL请求卡死都比较常见。另外,由于ClickHouse原始设计缺陷,随数据增长的依赖的zookeeper瓶颈一直存在,无法很好解决;微信后期进行多次内核改动,才使得它在海量数据下逐步稳定下来,部分issue也贡献给了社区。

使用门槛较高:会用ClickHouse的,跟不会用ClickHouse的,其搭建的系统业务性能可能要差3倍甚至10倍,有些场景更需要针对性对内核优化。

二、微信和腾讯云数据仓库共建

此时,腾讯云数据仓库Clickhouse团队积极深入业务,主动与微信团队合作,双方开始共同解决上述问题。腾讯云数据仓库Clickhouse提供全托管一站式的全面服务,使得微信团队不需要过多关注稳定性问题。另外,双方团队积累了丰富查询优化经验,共享经验更有利于Clickhouse性能极致提升。

微信跟腾讯云数据仓库Clickhouse的合作,从今年3月份开始,在验证期小规模试用ClickHouse后,业务一直在快速增长,双方开始共建进行稳定性和性能上的优化。主要做了两件事:一个是建立了整个ClickHouse OLAP的生态,另外一个是做了的探索出贴近业务的查询优化方法。

三、共建ClickHouse OLAP的生态

要想比较好地解决ClickHouse易用性和稳定性,需要生态支撑,整体的生态方案有以下几个重要的部分:

QueryServer:数据网关,负责智能缓存,大查询拦截,限流;

Sinker:离线/在线高性能接入层,负责削峰、hash路由,流量优先级,写入控频;

OP-Manager:负责集群管理、数据均衡,容灾切换、数据迁移;

Monitor:负责监控报警,亚健康检测,查询健康度分析,可与Manager联动;

微信WeOLAP团队和腾讯云重点在以下方面进行了合作攻坚:

高性能接入

微信的吞吐达到了十亿级别,实时接入方面,通过令牌、反压的方案,比较好地解决了流量洪峰的问题。另外通过Hash路由接入,使数据落地了之后可直接做Join,无需shuffle实现的更快Join查询,在接入上也实现了精确一次。离线同步方案上,微信跟大多数业界的做法基本上一致,在通过预构Merge成建成Part,再送到线上的服务节点,这其实是种读写分离的思想,更便于满足高一致性、高吞吐的场景要求。

极致的查询优化

ClickHouse整个的设计哲学,要求在特定的场景下,采用特定的语法,才能得到最极致的性能。为解决ClickHouse使用门槛高的问题,微信把相应的优化经验落地到内部BI平台上,沉淀到平台后,使得小白用户都可以方便使用ClickHouse。通过一系列优化手段,在直播、视频号等多个Case实现10倍以上性能提升。