布景介绍
ByConity合适多种事务场景，在实时数据接入、大宽表聚合查询、海量数据下杂乱剖析核算、多表关联查询场景下有十分好的功能。咱们用一个实际的事务场景来介绍下，这套行为剖析体系是根据用户多维度行为剖析渠道，供给事情剖析、留存剖析、转化剖析、用户分群、用户留存等多种剖析方法和场景。本文将介绍下该用户多维度行为剖析渠道在运用原ClickHouse集群遇到的问题和应战，以及经过迁移ByConity后怎么处理这些问题并给事务带来的收益。
*图1* *行为剖析体系* *架构规划*
问题和应战
早期这套体系布置在ClickHouse集群，一方面，由于事务的高速发展导致数据量日益膨胀，每日最大新增数据超越320TB，每日新增行数超越2.3万亿条，用户数据维度超越2万多个；另一方面，用户查询需求更加灵敏和多样化，需求一起支撑明细查询、聚合查询以及交互式剖析查询，并快速给出呼应结果。此外，在数据量不断增加的状况下（年增长35%），咱们既要能支撑这么大的数据增量带来的应战，又要把本钱增速控制在一定范围内。
但是在已有的ClickHouse集群上咱们很难做到。原因是ClickHouse是根据Shared-Nothing的架构，每个节点是独立的，不会共享存储资源，因而核算资源和存储资源是紧耦合的，会导致如下问题：
-
扩缩容本钱变高，且会涉及到数据迁移，使咱们不能实时按需的扩缩容，并且会导致资源的浪费，本钱不可控
-
紧耦合的架构会导致多租户在共享集群环境彼此影响，造成用户查询彼此影响
-
由于集群上节点的读写在同一个节点完结，导致读写彼此影响
-
在杂乱查询上例如多表Join等操作的功能支撑并不是很好，无法满意用户查询多样化的需求
技能选型
因而在2022年初事务开始运用核算存储别离架构的ByConity来作为首要的OLAP引擎。ByConity是一个开源的云原生数据仓库，它选用核算存储别离的架构，支撑多个要害功能特性，如核算存储别离、弹性扩缩容、多租户资源阻隔和数据读写的强一致性等。经过利用主流的OLAP引擎优化，如列存储、向量化履行、MPP履行、查询优化等，ByConity能够供给优异的读写功能。
*图2* *ByConity* *三层技能架构图*
ByConity是在开源的ClickHouse架构基础上进行了晋级，引入了核算与存储别离的架构，将原本核算和存储分别在每个节点本地管理的架构，转换为在分布式存储上统一管理整个集群内一切数据的架构，使得每个核算节点成为一个无状况的单纯核算节点，并利用分布式存储的扩展才能和核算节点的无状况特性完结动态的扩缩容。正是由于这种改进，使得ByConity具有以下重要特性：
-
资源阻隔：对不同的租户进行资源的阻隔，租户之间不会受到彼此影响。
-
读写别离：核算资源和存储资源解耦，保证读操作和写操作不会彼此影响。
-
弹性 扩缩容：支撑弹性的扩缩容，能够实时、按需的对核算资源进行扩缩容，保证资源的高效利用。
-
数据强一致：数据读写的强一致性，保证数据始终是最新的，读写之间没有不一致。
-
高功能：选用了主流的OLAP引擎优化，例如列存、向量化履行、MPP履行、查询优化等供给优异的读写功能
事务收益
在咱们引入了ByConity后，全体功能能够到达91%用户查询都能够在10秒内完结，经过来自用户的反应调研，这个功能指标也是在用户可接受的范围内。这里总结下咱们迁移ByConity带来的总体收益和经验：
- 防止资源抢占，查询功能百分百安稳：
在原来ClickHouse的集群上，咱们常常会遇到资源抢占的问题，由于ClickHouse并没有做到资源阻隔和租户阻隔，在多个用户共用集群进行查询时，当一个用户查询资源开销十分大，会涉及资源的抢占，导致这个集群上一切共用的用户查询都不安稳，服务质量达不到满意。但在迁移到ByConity后，由于核算组是彻底物理阻隔，能够到达天然的资源阻隔和租户阻隔，不同用户的查询彼此不受到影响，全体查询功能能够到达91%用户查询都能够在10秒内完结。再者ByConity供给了自研的杂乱查询链路，自研 Disk Cache以削减冷数据读取，并对于高频运用的Array 树立索引等，并且热读功率也优于原ClickHouse集群，比较在原Clickhouse集群上功能折损在10%以内。
- 运维本钱低，故障节点秒级替换：
原本在Clickhouse集群上，如果发现集群中某个节点坏掉，需求先下掉整台机器维修，这是由于ClickHouse的核算资源、存储资源、以及元数据信息都在这个节点上，相当于集群少了一个核算资源，也少了一个存储副本，在替换新的节点之前，需求把对坏掉节点的本地磁盘进行备份迁移到新的节点上，保护本钱比较高，且数据一致性很难得到保证。而对于ByConity来讲，如果发生核算组坏掉的状况，由于核算组不存储数据，只包括无状况的核算节点，因而只需求替换新的核算组即可，数据的可靠性和一致性由HDFS来保证，且本地热读数据缓存的丢失对事务查询功能是可控的，这部分也首要得益于了ByConity存储和核算别离架构完结。
- 无感 扩缩容 ，节约资源本钱：
ByConity是能够完结无感扩缩容，它是一个模块化和容器化的布置，根据Kubernetes的弹性伸缩才能，如果有满足的机器能够无限的扩容，一起如果服务器发生故障，咱们也不用忧虑，由于ByConity的节点只一个无状况的核算节点，直接下掉对整个集群影响不大。并且经过自适应调度回避慢节点，进步吞吐才能，进步节点资源利用率。一起ByConity的压缩率极高，以其中一个事务为例，每日新增460TB数据，压缩后到达100TB，压缩比到达65%，并支撑低基数编码 & ZSTD等等压缩方法，极点状况下存储占用小于parquet。
- 数据一致性强保证，保护杂乱度接近为零：
在迁移到ByConity后，咱们彻底处理了数据一致性问题，由于ByConity不存在本地的主备同步问题，数据一致性问题直接交给底层的对象存储处理，例如HDFS/S3等。这样对一致性保护的杂乱度大大下降，过错概率也更低，现在也少有用户再反应数据一致性问题。但在之前是常常遇到，由于ClickHouse集群是多个副本经过节点间通信去保护的，经过一致性行列去保护一致性问题，完结上也很杂乱，简单出错。另外，ByConity能够经过HDFS直接访问到数据文件，不同核算引擎适配不同连接器，即可读入数据，具有通用才能。
未来展望
经过长达一年半的实践摸索，ByConity已经成为内部运用的首要OLAP引擎，后期会有很多的用户和数据迁入，最终取代原本的ClickHouse集群。能够看出ByConity作为一款核算存储别离的OLAP引擎，具有高功能、高可扩展性和高安稳性等长处，能够满意大规模体量的数据处理和剖析的需求。一起，经过在社区的交流，以及社区发布的Roadmap评论github.com/ByConity/By… 未来阶段ByConity会首要聚焦在以下几个方向：
- 支撑履行层的多Stage履行、ETL才能等
- 支撑数据湖联邦查询如Hudi、Iceberg等
ByConity社区拥有很多的用户，一起是一个十分开放的社区，咱们约请咱们和咱们一起在Github上评论共建，也能够参加咱们的微信群、飞书群或者Discord参与交流。
GitHub：github.com/ByConity/By…
