共计 2831 个字符，预计需要花费 8 分钟才能阅读完成。
前言
对于剖析型数据库产品，通过减少服务节点实现集群程度扩容，并晋升集群性能和容量，是运维的必要伎俩。
然而对于相熟 ClickHouse 的工程师而言，听到“扩容”二字肯定会头疼不已。开源 ClickHouse 的 MPP 架构导致扩容老本高，已是 ClickHouse 运维的外围痛点。
次要体现在：
·流程全手动，无数据可靠性保障。
·扩容期间性能开销大，通常须要暂停服务。
基于字节跳动内宽泛的应用场景，ByteHouse 企业版基于开源社区 ClickHouse 进行了诸多优化，现已正式公测“程度扩容”性能。
如果将“ClickHouse”比作一辆汽车，那么此次 ByteHouse 降级则实现了扩容“手动挡”变“自动挡”，同时“自动档 ” 过程中还能省油减速，使得扩容整体操作更顺滑晦涩。
开源社区的实现计划
在 开源社区文档 中，社区工程师通常举荐应用“数据重散布”思路来解决扩容问题，但存在以下问题：
1. 新增节点后，手动晋升新节点的导入权重，或临时进行旧节点的数据导入，直至数据平衡。这种配置要求 Distributed 表的分片键（Sharding-key）设置为 random，对于设定了指定的 sharding-key 的表，无奈采纳这种模式。此外，如果存量数据很大，通过该形式实现平衡十分迟缓，可能破费数天乃至数个月能力追平。
2. 手动在节点之间挪动分区，使节点间平衡。该形式须要大表均已设置比拟正当的分区键（Partition Key），并且分片键也只能为 Random，并且须要手动计算分区的挪动指标节点。
3. 应用 ClickHouse Copier 或 Insert Into Select 形式，将现存表全副从新插入实现平衡。该形式开销十分高，将占用大量的 CPU / 存储 IO / 网络 IO 资源。
此外，不论是哪种形式，都须要用户手动在新节点复制元数据、校验数据，拼装各环节流程，因而被称为“手动挡”。
ByteHouse 的优化计划
在字节跳动外部，业务的快速增长带来集群布局性能有余、亟需扩容的问题。ByteHouse 对内次要撑持数据看板、用户行为剖析性等业务模块，因而对服务继续在线、性能迅速晋升要求高，并且用户表的表构造也异样丰盛。因而，社区提供的计划均不能满足字节外部业务诉求。
基于以上背景，ByteHouse 自研集群扩容能力，解决自动化流程的问题，也为用户提供了性能开销更低的扩容形式。
具体咱们通过数据库引擎优化和操作界面优化两方面来实现。
** 数据库引擎优化
ByteHouse 的数据库引擎自研 Alter Table…Resharding 命令，将一张表以分区的粒度进行重散布到另一张表。该命令反对两种形式：
·重散布到其余集群的另一张表
·重散布到本集群的另一张表
命令格局如下：
alter table <db>.<table> resharding partition <partition_expr> with <sharding_expr> to shard [shard_list]
通过该命令，能够实现提交从源表扩容到指标表的工作，该工作将实现 Split – Fetch，在原表拆分 Part，指标表拉取 Part，实现扩容。
具体操作步骤如下：
1. 对于要扩容的表 table，新建指标表，如 table1_new；
2. 提交 Alter Table table1 Resharding Partition <partition_expr> with <sharding_expr> to table [table1_new_list]；的工作会被存储到 ZooKeeper 上，后盾线程负责调度执行；
3. 所有提交的工作一一开始执行。每个工作首先执行 Part 拆分，将一个 Part 依据 Sharding-key 拆分为 N 份（N 为扩容后的分片数）；
4.Part 拆分完结后，将 Part 信息公布到对应的分片上，对应不同分片上的指标表 table1_new 会进入 FETCHING 状态，开始拉取 Part；
5. 期待这些 Part 被拉取实现，而后开始执行下一个工作，直至一张表的所有 Part 都被重散布实现在一张表实现后，能够进行校验数据，删除旧表（table1），重命名新表（table1_new -> table1）。实现了一张表的扩容。
扩容全程能够通过零碎表 system.reshard_partition 追踪进度，获得状态。
这种扩容形式相比社区举荐的形式，有以下劣势：
1. 扩容的适应性好，对于是否设置分片键、分区键，均无硬性要求，都能够进行扩容。
2. 性能损耗小。整个重散布过程为一个旁路计算工作，开销远低于 insert into select 全局数据从新插入的形式。
3. 执行过程中，数据放弃可查问，上游数据看板、数据分析等服务不必暂停。目前在扩容过程中，ByteHouse 临时不反对写入。但就原理而言，扩容进度 90% 前都可写入，只须要最初阶段一次性 Resharding 在扩容工作执行过程中新写入的 Part 即可。因而，ByteHouse 将来性能也有持续晋升的空间。
操作界面优化
ByteHouse 数据库实现了 SQL 的底层能力进行数据重散布，实现了开销更低、适应性更强的重散布能力，但对于普通用户而言仍有应用门槛。
因而 ByteHouse 在控制台也反对程度扩容性能，组装底层能力，实现产品化。
通过 ByteHouse 控制台，可通过以下步骤实现集群的程度扩容：
1. 在集群列表 / 详情页抉择“更改配置”，抉择“程度更配”。
2. 用户抉择集群更配后节点数，反对减少节点（程度扩容），也反对缩小节点（程度缩容）；
3. 可在扩容前勾选“实现后主动重散布”，也可不勾选，在扩容后再手动重散布；如果勾选“主动重散布”，则须要抉择须要在扩容后立刻重散布的表。
4. 界面会给出预估扩容工夫。用户能够依据理论状况，对上游业务收回扩容布告。
5. 提交扩容工作，集群进入“运维工作中”状态。后盾执行两阶段工作：
a. 阶段 1，新增节点。理论在进行新节点的初始化，并在新节点上新建元数据；b. 阶段 2，集群节点实现减少后，则开始重散布，能够查看每张表的重散布进度。6. 上述步骤实现，集群复原“运行中”状态。
通过界面化操作，ByteHouse 给用户的扩容流程带来了全新的便当：
·全流程自动化，不再须要自行编写脚本。
·也凋谢一小部分手动空间。例如，在扩容前可选立刻重散布的表，对于残余的表，可在扩容后再抉择工夫重散布工作，适应一些心愿在业务低峰时扩容大表，进一步升高大表只读带来的影响。
·蕴含容错解决，主动校验数据，流程便当牢靠。
总结
ByteHouse 团队通过自研“程度扩容”能力，实现了数据库底层与界面反对数据重散布。相比于开源社区的形式，ByteHouse 的数据重散布有以下劣势：
·低 CPU / IO 开销，数据重散布期间可读；
·全程自动化，界面化；
·不依赖其余外置工具，在 ByteHouse 产品内闭环；
目前，程度扩容性能现已在 ByteHouse 企业版公测上线，同时反对私有化部署与火山引擎版本，欢送体验。
点击跳转【云原生数据仓库 ByteHouse】理解更多
