共计 5207 个字符，预计需要花费 14 分钟才能阅读完成。
作者|程伟，MetaAPP 大数据研发工程师
【我的项目地址】
GitHub |https://github.com/ByConity/ByConity
ByConity 是字节跳动开源的云原生数据仓库，在满足数仓用户对资源弹性扩缩容，读写拆散，资源隔离，数据强一致性等多种需要的同时，并提供优异的查问，写入性能。
MetaApp 是国内当先的游戏开发与运营商，专一挪动端信息高效散发，致力于构建面向全年龄段的虚拟世界。截至 2023 年，MetaApp 注册用户已超 2 亿，联运单干 20 万款游戏，累计散发量过 10 亿。MetaApp 在 ByConity 开源晚期便放弃关注，是最早进行测试并在生产环境上线的用户之一。抱着理解开源数仓我的项目能力的想法，MetaApp 大数据研发团队对 ByConity 进行了初步测试。其存算拆散的架构、优良的性能，尤其在日志剖析场景中，对于大规模数据简单查问的反对，吸引 MetaApp 对 ByConity 进行了深刻测试，最终在生产环境全量替换 ClickHouse，使资源老本升高超 50%。
本文将次要介绍 MetaApp 数据分析平台的性能，业务场景中遇到的问题及解决方案以及引入 ByConity 对其业务的帮忙。
MetaApp OLAP 数据分析平台架构及性能
随着业务的增长，精细化经营的提出，产品对数据部门提出了更高的要求，包含须要对实时数据进行查问剖析，疾速调整经营策略；对小局部人群做 AB 试验，验证新性能的有效性；缩小数据查问工夫，升高数据查问难度，让非专业人员能够自主剖析、探查数据等。为满足业务需要，MateApp 实现了集事件剖析、转化剖析、自定义留存、用户分群、行为流剖析等性能于一体的 OLAP 数据分析平台。
这是一个典型的 OLAP 的架构，分成两局部，一部分是离线，一部分是实时。
在离线场景中，咱们应用 DataX 把 Kafka 的数据集成到 Hive 数仓，再生成 BI 报表。BI 报表应用了 Superset 组件来进行后果展现；
在实时场景中，一条线应用 GoSink 进行数据集成，把 GoSink 的数据集成到 ClickHouse，另外一条线应用 CnchKafka 把数据集成到 ByConity。最初通过 OLAP 查问平台获取数据进行查问。
ByConity 和 ClickHouse 性能比照
ByConity 是基于 ClickHouse 内核研发的开源云原生数据仓库，采纳存算拆散的架构。两者都具备以下特点：
写入速度十分快，实用于大量数据的写入，写入数据量可达 50MB – 200MB/s
查问速度十分快，在海量数据下，查问速度可达 2 -30GB/s
数据压缩比高，存储成本低，压缩比 可达 0.2～0.3
ByConity 领有 ClickHouse 的长处，与 ClickHouse 放弃了较好的兼容性，在读写拆散、弹性 扩缩容、数据强统一方面进行了加强。两者对于以下 OLAP 场景均实用：
数据集可能很大 – 数十亿或数万亿行
数据表中蕴含许多列
仅查问特定几列
后果必须以毫秒或秒为单位返回
在之前的分享中，ByConity 社区对二者从应用角度进行过比照，概括总结如下：
在 OLAP 平台构建过程中，咱们次要关注资源隔离、在 扩缩容、简单查问，以及对 分布式事务 的反对。
应用 ClickHouse 遇到的问题
问题一：读写一体容易抢占资源，无奈保障读 / 写稳固
业务高峰期时，数据写入将大量挤占 IO 和 CPU 资源，导致查问受到影响（查问工夫变长）。数据查问也是如此。
问题二：扩 / 缩容 麻烦，周期长
- 扩 / 缩容工夫长：因为机器在 IDC，属于公有云，其中一个问题在于，节点减少周期特地长。从减少节点需要收回到真正减少好节点须要一周到两周的工夫，影响业务；
- 无奈疾速进行扩缩容：扩缩容当前要从新进行数据分布，否则节点压力十分大。
问题三：运维繁琐，业务高峰期无奈保障 SLA
- 经常因为业务的节点故障导致数据查问迟缓，数据写入提早（从提早几小时到几天的水平）；
- 业务高峰期时资源呈现严重不足，短期内无奈扩容资源，只能通过删减局部业务的数据，为优先级高的业务提供服务；
- 业务低峰期时，资源大量闲暇，老本虚高。尽管咱们在 IDC，然而 IDC 的机器购买也受老本管制，且不能无限度的节点扩容，另外在失常应用时也有肯定的老本耗费；
- 无奈和云上资源进行交互应用。
引入 ByConity 后的改善成果
首先，ByConity 读写拆散计算资源隔离能够保障读写工作比较稳定。如果读的工作不够，能够扩大相应资源，哪里不够补哪里，包含应用云上资源进行扩容。
其次，扩缩容比较简单，能够在分钟级别进行扩缩容。因为应用 HDFS/S3 分布式存储，计算存储拆散，所以扩容当前不须要进行数据重散布，扩容后能够间接应用。
另外，云原生部署，运维绝对简略。
- HDFS/S3 的组件绝对成熟稳固，扩缩容，灾备计划成熟，呈现问题可疾速解决；
- 业务高峰期时，能够通过疾速扩容资源保障 SLA；
- 业务低峰期时，能够通过缩减存储 / 计算资源达到降低成本的目标。
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 在业务数据中的查问比照
测试数据集及资源配置
- 数据条数：按日期做分区，单日 40 亿条，10 日共计 400 亿
- 表列数据：2800 列
由上表能够看出：
ClickHouse 集群查问应用的资源为：400 核 2560G 内存
ByConity 8 worker 集群查问应用的资源为：120 核 880G 内存
ByConity 16 worker 集群查问应用的资源为：240 核 1760G 内存
业务 SQL 查问后果汇总
这里的汇总都采纳的是平均值，能够看到：
- 惯例 OLAP- 去重、留存、转化、点查都能够通过比拟小的资源代价（120C, 880G）达到与 ClickHouse 集群（400C, 2560G）统一的查问成果，并且能够通过扩大一倍资源（240C, 1760G）达到查问速度晋升翻倍的成果。如果须要更高的查问速度，能够扩大更多的资源；
- not in 过滤可能须要适中的资源代价（240C, 1760G）能够达到和 ClickHouse 集群（400C, 2560G）类似的成果；
- bitmap 可能须要更大的资源代价能够达到和 ClickHouse 集群类似的成果。
惯例查问 / 事件剖析查问
由上图可知：
去重查问场景上 ByConity 开启优化与不开启优化区别不大；
8 worker (120C 880G) 基本上达到与 ClickHouse 靠近的查问工夫；
去重场景上，能够通过扩大计算资源来放慢查问速度。
留存计算
由上图可知：
留存计算场景上 ByConity 开启优化后查问工夫是不开启优化查问工夫的 33%；
8 worker (120C 880G) 开启优化的查问工夫是 查问工夫的 30%；
留存计算场景，能够通过扩大计算资源 + 优化的形式来将查问速度减速至 CK 查问工夫的 16%。
转化计算
由上图可知：
转化计算场景上 ByConity 开启优化后查问工夫是不开启优化查问工夫的 60%；
8 worker (120C 880G) 开启优化的查问工夫与 ClickHouse 查问工夫靠近；
转化计算场景，能够通过扩大计算资源 + 优化的形式将查问速度减速至 ClickHouse 查问工夫的 53%。
not in 过滤
not in 过滤次要利用于用户分群场景，以及用户打标签场景。
由上图可知：
no in 过滤场景上 ByConity 开启优化后比 ByConity 不开启优化差，所以此场景下咱们间接应用不开启优化的形式；
8 worker (120C 880G) 不开启优化的查问工夫比 ClickHouse 查问工夫慢一些，但并不多；
no in 过滤场景，能够通过扩大计算资源形式来将查问速度减速至 ClickHouse 查问工夫的 86%。
点查计算
由上图可知：
点查场景上 ByConity 开启优化后比 ByConity 不开启优化好；
8 worker (120C 880G) 不开启优化的查问工夫与 ClickHouse 查问工夫靠近；
点查场景，能够通过扩大计算资源 + 开启优化的形式来将查问速度减速至 ClickHouse 查问工夫的 26%。
bitmap 查问
bitmap 查问是在 AB 测试中应用更多的一种场景。
由上图可知：
bitmap 过滤场景上 ByConity 开启优化后比 ByConity 不开启优化好一点；
8 worker (120C 880G) 不开启优化的查问工夫比 ClickHouse 查问工夫慢很多；
bitmap 过滤场景，扩大资源至 16 worker(240C 1769G) 比 ClickHouse 查问慢。
ByConity 全量迁徙后的播种
资源升高
以下未统计 CPU 的差异性，数据仅供参考
应用 ByConity 进行全量迁徙之后
- 查问合并资源耗费比照，CPU 耗费比之前缩小了 75% 左右；
- 数据写入资源比照，CPU 耗费比之前缩小了进 35% 左右；
- 只须要购买一半的固定资源，剩下一半靠工作日（早 10 晚 8）定时弹性，老本相比全量购买资源升高了 25% 左右；
以后应用的耗费状况
从以后应用的后果表中能够看到，ByConity 的 CPU 和 内存占比别离为 ClickHouse 的 34% 和 48%。
加上近程存储后的耗费状况
咱们在 IDC 应用 minio 来进行数据存储，应用 640 核的 CPU，4096G 内存，16 个节点，单节点 40 核，256G，磁盘为 36T，把这些老本加在 ByConity 上之后，ByConity 的 CPU 和 内存占比仍然低于 ClickHouse，别离为 ClickHouse 的 48% 和 68%。能够说，在资源的应用上，如按包年包月购买资源计算，ByConity 比原来至多 升高 50% 左右；如按需启停，相比全量购买资源，老本将再升高 25% 左右。
运维老本升高
- 更简略的配置数据写入形式。之前咱们专门配置的写入服务，经常呈现 Too many parts 等问题。
- 顶峰查问扩容更加简略，增加 pod 数量就能够很快扩容，再也没有人来问“数据查了半小时为啥没进去”。
ByConity 替换 ClickHouse 的倡议
- 在业务中测试你的 SQL 是否能够在 ByConity 平台上失常运行，如果可能兼容，则根本都可运行。如个别情况下呈现一些小问题，能够在社区中提出获取疾速反馈；
- 管制测试集群的资源，测试数据集大小，比照 ByConity 集群与 ClickHouse 集群的查问后果，看是否合乎预期。如果合乎预期，能够进行替换打算。对于更偏重计算的工作，可能在 ByConity 中体现更好；
- 依据测试数据集的大小，耗费的 S3 和 HDF 空间、带宽、QPS 计算资源的使用量，来评估全量数据时存储与计算须要应用的资源；
- 将数据同时打入 ByConity 或者 ClickHouse 集群，开始一段时间的双跑，解决双跑期间呈现的问题。例如咱们公司在资源有余的状况下，应用是按业务进行，咱们能够先在云上建一个 ByConity 集群，迁入某一部分的业务，之后逐渐按业务来替换，腾出 IDC 资源当前，再把这一部分的数据迁徙到线下；
- 双跑没有问题后就能够退订 ClickHouse 集群。
在此过程中有一些注意事项：
- S3 和 HDFS 近程存储的读取带宽与 QPS 可能会要求高一些，须要做肯定的筹备。例如，咱们峰值每秒读写带宽为：写 2.5GB/ 读 6GB，峰值每秒 QPS 为：2～6k；
- Worker 节点的带宽用满，也会造成查问瓶颈；
- Default 节点（也就是读取计算节点）的缓存盘能够配置的适当大一些，能够升高查问时 S3 的带宽压力，放慢查问速度。
- 如果遇到未缓存的数据，可能会有冷启动问题。对此 ByConity 也有一些操作倡议，具体还须要更多联合本人的业务进行，比方咱们应用在早上进行预查的形式来将这一部分的冷启动问题进行缓解。
将来布局
将来咱们将推动 ByConity 数据湖计划的测试与落地。另外，咱们会将数据指标治理与数仓实践相结合，将 80% 的查问落到数仓上。欢送大家一起退出体验。
GitHub |https://github.com/ByConity/ByConity
扫码增加 ByConity 小助手
