共计 3011 个字符，预计需要花费 8 分钟才能阅读完成。
导语 | 微信作为一款国民级利用，曾经笼罩了社交、领取、出行等人们生存的方方面面。海量多样化的业务状态，对数据分析提出了新的挑战。为了满足业务数据分析的需要，微信 WeOLAP 团队联手腾讯云，共建千台规模、数据 PB 级、批流一体的 ClickHouse 数据仓库，实现了 10 倍以上的性能晋升。下文将由浅入深，为大家揭晓微信在 ClickHouse 实时数仓实际中积攒的教训及办法。
本文作者：微信 WeOLAP 团队 & 腾讯云数据仓库 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 倍以上性能晋升。
基于共建的 ClickHouse 生态，在微信有以下的典型利用场景：
1.BI 剖析 / 看板：因为迷信摸索是随机的，很难通过预构建的形式来解决，之前用 Hadoop 的生态只能实现小时到分钟的级别。目前 ClickHouse 优化完之后，在单表万亿的数据量下，大多数的查问，P95 在 5 秒以内。数据科学家当初想做一个验证，十分快就能够实现。
2.A/ B 试验平台：晚期做 A / B 试验的时候，前一天早晨要把所有的试验统计后果，事后聚合好，第二天能力查问试验后果。在单表数据量级千亿 / 天、大表实时 Join 的场景下，微信前后经验了几个计划，实现了近 50 倍的性能晋升。从离线到实时剖析的飞跃，使得 P95 响应 <3S，A/ B 试验论断更加精确，试验周期更短，模型验证更快。
3. 实时特色计算：尽管大家普遍认为 ClickHouse 不太善于解决实时相干的问题，但最终通过优化，能够做到扫描量数十亿，全链路时延 <3 秒，P95 响应近 1 秒。
四、性能的显著晋升
目前，微信以后规模千台，数据量 PB 级，每天的查问量上百万，单集群 TPS 达到了亿级，而查问耗时均值仅需秒级返回。ClickHouse OLAP 的生态绝对于之前的 Hadoop 生态，性能晋升了 10 倍以上，通过流批一体提供更稳固牢靠的服务，使得业务决策更迅速，试验论断更精确。
五、共建存算拆散的云原生数仓
ClickHouse 原始的设计和 Shard-Nothing 的架构，无奈很好地实现秒级伸缩与 Join 的场景；因而下一个微信和腾讯云数据仓库 ClickHouse 的共建指标，是实现存算拆散的云原生数仓：
- 弹性扩容：秒级弹性能力，用户只为应用付费，实现顶峰查问更快，低峰老本更省；
- 稳定性：无 ZK 瓶颈，读写易拆散，异地容灾；
- 易运维：数据容易平衡，存储无状态；
- 性能全：专一于查问优化与 Cache 策略、反对高效多表 Join；
存算拆散的云原生数仓能力，明年将会在腾讯云官网上线，敬请期待！
本文章由微信技术架构部 -WeOLAP 团队出品，「WeOLAP」专一于用前沿大数据技术解决微信海量数据高性能查问问题。
腾讯云数据仓库 Clickhouse 10 元新客体验流动火爆进行中↓↓↓
