柏睿数据实时云数仓之「性能优化篇」壹

　　柏睿实时云数仓性能优化篇来也!分为三章。本文为第一章，欢迎阅读。本文作者：柏睿数据产品研发总监陈海富

　　柏睿实时云数仓为BI分析业务提供强劲的计算发动机——数据库服务。如何优化云数仓性能?由于其运行在云计算平台中，与传统物理机优化方法有很大不同。传统物理机运行环境中的数据库优化方法，主要有：

　　　1)CPUNUMA优化大法：物理服务器有多颗物理CPU，由于每颗CPU负责独立的内存控制器，当跨CPU访问内存空间时，会出现很大的延迟。但在云环境中的云主机，没有NUMA造成的跨内存控制器问题。

　　　2)网络巨型帧：巨型帧是指将以太网协议中的帧长大于1522字节的以太网帧，通过将每帧能够多传输内容，来增加网络传输效率。但在云环境中，网络设备主要由虚拟化实现，不建议调整太网帧大小。

　　换网络协议：物理环境中网络传输慢，可以换成IB网(InfiniBand network)。但在云环境中，这几乎是不可能的。

　　　3)换性能更高的硬件：物理环境中的硬盘、CPU都可以换成性能更高的硬件。例如机械硬盘速度太慢，固态硬盘速度提速还不够强，将傲腾内存当做硬盘速度才能飞快。但在云环境中，可能不会有你想换的硬件型号。而且云计算的计费方式是“按需付费”，即按使用量来付费，当需要更高的磁盘IO性能，就需要购买更大的空间，由此性能调优还要考虑成本。

　　当然在云计算环境中，是可以直接租用裸金属服务器来部署应用程序，但需要考虑云中物理服务器配置固定，而且成本会比较高。下图是截至2022年4月17日，华为云裸金属服务器的价格。

　　所以我们在此分享一些柏睿实时云数仓在纯云环境中的优化经验，希望能给大家提供一些性能优化启发。

　　一、先谋后行

　　数据库性能优化需要考虑自身软件所依赖的计算、存储、网络等多个资源，是综合性问题，需要全盘思考，再多方处理。

　　虽然云计算号称“按需付费”，但如果不精打细算，使用成本反而会增加很多。因此我们在优化柏睿实时云数仓的主要思路是：在成本可控的情况下，通过优化相关的云资源，提升柏睿分布式内存数据库的性能。

　　　二、知己知彼

　　优化数据库整体性能，需要先了解优化的数据库业务架构，才能做出更好的调优方法。

　　柏睿实时云数仓使用自研的分布式全内存数据库RapidsDB，属于OLAP分析型数据库。与传统的OLTP交易型数据库从业务到架构是有很大区别的。

　　下表是OLAP与OLTP的一些简单比较，从比较中能看出OLAP主要以读为主，而OLTP主要是写入为主。

　　三、一夫当关or团队作战

　　OLAP与OLTP数据库由于关注的业务不同，所以软件在工作方式和优化方法会有一些不同。

　　OLTP业务主要业务场景是交易记录的准确性，因此需要写入具有唯一性，所以传统针对OLTP数据库的优化方法将负责写入的“一夫”节点性能大幅提升，如使用更快的CPU，增加更多的内存，使用将内存当做磁盘用的傲腾存储，使用IB网络(InfiniBand network)等。

　　但个体设备的配置提升，会遇到天花板。于是近年来有人提出将数据库进行分库分表，增加写入节点的数量而提升写入能力。通过将数据复制到多个只读节点，提升数据读的能力。

　　比如对于一个记录用户名数据库，按姓名拼音的第一个字母拆成26个数据库，这样就可以将原来只能由一个库来写，变成分别由26个库来写入，从而提升写入能力。但每个分开的库还是只能有一个写入，还是有种“一夫当关，万夫莫开”的意思。

　　柏睿自研的分布式全内存数据库RapidsDB基于MPP并行计算架构，集群的性能随着节点规模的增加而增加。

　　MPP架构示例图

　　下图是RapidsDB在同一个业务场景下，不同规模的集群性能比较。能够看到随着数据库节点的增加，整体性能有明显提升。

　　由此可见，RapidsDB的技术架构类似于“团体作战”风格，所有的数据库节点都能同时协同战斗，因此提升的性能不是由个体决定的。

　　例如在一个具有5个数据库节点的RapidsDB集群里，用户要导入1000T的数据文件任务，是由5个数据库节点将1000T任务分散同时完成。如果性能不够，再加数据库节点就可以实现性能提升了。

　　以上分析，仅从技术架构而言，并不能完全说明哪种技术是最好。只有适合业务，才是最好的技术。

　　下章预告：

　　挑兵选将：根据CPU选择云主机;选择内存容量;选择网络能力;选择云硬盘