MetaApp 是国内领先的游戏开发与运营商，专注移动端信息高效分发，致力于构建面向全年龄段的虚拟世界。截至 2023 年，MetaApp 注册用户已超 2 亿，联运合作 20 万款游戏，累计分发量过 10 亿。
MetaApp 在 ByConity 开源早期便保持关注，是最早进行测试并在生产环境上线的用户之一。抱着了解开源数仓项目能力的想法，MetaApp 大数据研发团队对 ByConity 进行了初步测试。其存算分离的架构、优秀的性能，尤其在日志分析场景中，对于大规模数据复杂查询的支持，吸引 MetaApp 对 ByConity 进行了深入测试，最终在生产环境全量替换 ClickHouse， 使资源成本降低超 50%。
本文将主要介绍 MetaApp 数据分析平台的功能，业务场景中遇到的问题及解决方案以及引入 ByConity 对其业务的帮助。
MetaApp OLAP 数据分析平台架构及功能
随着业务的增长，精细化运营的提出，产品对数据部门提出了更高的要求，包括需要对实时数据进行查询分析，快速调整运营策略；对小部分人群做 AB 实验，验证新功能的有效性；减少数据查询时间，降低数据查询难度，让非专业人员可以自主分析、探查数据等。为满足业务需求，MateApp 实现了集事件分析、转化分析、自定义留存、用户分群、行为流分析等功能于一体的 OLAP 数据分析平台。
这是一个典型的 OLAP 的架构，分成两部分，一部分是离线，一部分是实时。
在 离线场景 中，我们使用>在 实时场景 中，一条线使用 GoSink 进行数据集成，把 GoSink 的数据集成到 ClickHouse，另外一条线使用 CnchKafka 把数据集成到 ByConity。最后通过 OLAP 查询平台获取数据进行查询。
ByConity 和 ClickHouse 功能对比
ByConity 是基于 ClickHouse 内核研发的开源云原生数据仓库，采用存算分离的架构。两者都具有以下特点：
ByConity 拥有 ClickHouse 的优点，与 ClickHouse 保持了较好的兼容性，在 读写分离、弹性扩缩容、数据强一致 方面进行了增强。两者对于以下 OLAP 场景均适用：
在之前的分享中，ByConity 社区对二者从使用角度进行过对比，概括总结如下：
> 详见：从使用的角度看 ByConity 和 ClickHouse 的差异
在 OLAP 平台构建过程中，我们主要关注 资源隔离、在扩缩容、复杂查询， 以及 对分布式事务的支持 。
使用 ClickHouse 遇到的问题
问题一：读写一体容易抢占资源，无法保证读/写稳定
业务高峰期时，数据写入将大量挤占 IO 和 CPU 资源，导致查询受到影响（查询时间变长）。数据查询也是如此。
问题二：扩/缩容麻烦，周期长
问题三：运维繁琐，业务高峰期无法保证 SLA
引入 ByConity 后的改善效果
首先，ByConity 读写分离计算资源隔离可以保证读写任务比较稳定。如果读的任务不够，可以扩展相应资源，哪里不够补哪里，包括使用云上资源进行扩容。
其次，扩缩容比较简单，可以在分钟级别进行扩缩容。由于使用 HDFS/S3 分布式存储，计算存储分离，所以扩容以后不需要进行数据重分布，扩容后可以直接使用。
另外，云原生部署，运维相对简单。
ByConity 的使用与运维
ByConity集群使用情况
目前，我们平台已经在业务场景稳定使用 ByConity。通过陆续迁移，ByConity 已经完全接管了 ClickHouse 集群的数据，并已经开始稳定提供服务。我们使用云上 S3 加 K8s 的模式搭建了 ByConity 集群；同时使用了定时扩缩容方案，可以在工作日早上 10 点进行扩容，晚上 8 点进行缩容，一天只需要使用十多个小时的资源。通过计算，此方式比直接使用包年包月降低资源 40%- 50% 左右。另外，我们也正在推进 私有云 + 公有云 相结合的方式，以达到降低成本与提升服务稳定性的目的。
下图为我们目前的使用情况，通过 OLAP 服务器对线下 IDC 机房的 ClickHouse 集群和 ByConity 进行联合查询。短期内 ClickHouse 集群将依然使用，作为部分依赖 ClickHouse 业务的过渡。
未来我们会在线下进行查询和合并数据，而 Kafka 消耗的资源放到线上使用。在资源扩容时，可以将 vw_default 和 vw_write 的资源扩到线上，合理使用公有云的资源应对资源不足的问题。同时在业务低峰时进行缩容，降低公有云消耗。
ByConity 和 ClickHouse 在业务数据中的查询对比
测试数据集及资源配置
|
|
|
|
|
|
|
|
由上表可以看出：
ClickHouse 集群查询使用的资源为：400 核 2560G 内存
ByConity 8 worker 集群查询使用的资源为：120 核 880G 内存
ByConity 16 worker 集群查询使用的资源为：240 核 1760G 内存
业务 SQL 查询结果汇总
这里的汇总都采用的是平均值，可以看到：
常规查询/事件分析查询
由上图可知：
留存计算
由上图可知：
转化计算
由上图可知：
not in 过滤
not in 过滤主要应用于用户分群场景，以及用户打标签场景。
由上图可知：
点查计算
由上图可知：
bitmap 查询
bitmap 查询是在 AB 测试中使用更多的一种场景。
由上图可知：
ByConity 全量迁移后的收获
资源降低
使用 ByConity 进行全量迁移之后
当前使用的消耗情况
从当前使用的结果表中可以看到，ByConity 的 CPU 和 内存占比分别为 ClickHouse 的 34%和 48%。
加上远程存储后的消耗情况
我们在 IDC 使用 minio 来进行数据存储，使用 640 核的 CPU，4096G 内存，16 个节点，单节点 40 核，256G，磁盘为 36T，把这些成本加在 ByConity 上之后，ByConity 的 CPU 和 内存占比依然低于 ClickHouse，分别为 ClickHouse 的 48% 和 68%。 可以说，在资源的使用上，如按包年包月购买资源计算，ByConity 比原来至少降低 50% 左右；如按需启停，相比全量购买资源，成本将再降低 25% 左右。
运维成本降低
ByConity 替换 ClickHouse 的建议
在此过程中有一些注意事项：
未来规划
未来我们将推动 ByConity 数据湖方案的测试与落地。
另外，我们会将数据指标管理与数仓理论相结合，将 80%的查询落到数仓上。欢迎大家一起加入体验。
