本文根据陈晓新老师在〖2021 Gdevops全球敏捷运维峰会-广州站〗现场演讲内容整理而成。
陈晓新
建信金科 DB产品负责人
- 具有8年MPP数据库工作经验，建行自研新一代MPP架构数据库龙趺MPP DB产品负责人，负责建行4000台Greenplum集群规划、搭建、运维和优化。
分享概要
一、研发背景
二、应用解决方案
三、运维解决方案
大家好，我是来自建信金融科技的陈晓新。很荣幸今天能够在这里跟大家分享我们在超大规模数仓集群建设的经验，我们建信金科通过引进多家合作公司的技术，联合开发出了名为龙趺MPP DB的新一代云原生数据仓库。
该数仓采用元数据、计算、存储三层分离的架构设计，在保留MPP数据库高性能计算能力的前提下，同时具备高并发、高扩展性、资源动态伸缩、故障自愈等能力，为超大规模数据集群的建设提供了基础。
2020年3月，第一个应用在该数仓集群上完成上线。随后，贴源、公共访问、旅程管理、集团并表、不良资产等等，都陆续上线成功。截止到2021年6月，该数仓集群规模已经达到16000台服务器，数据量超过9PB，每天运行上百万作业，运行SQL达到千万级别。
表（1）
图（2）
图（3）是我们整个龙趺MPP DB的监控大屏图。可以看到，目前我们的版本是3.9.8，计算集群规模79套，还有近24小时运行SQL数、近1个小时运行SQL数、连接数、资源使用率、各种健康情况等等信息。
图（3）
从传统MPP数据库，到龙趺MPP DB，这里我们先做一个简单的性能对比。
以建行的贴源集成应用为例，如图（4）。目前我们贴源应用所使用的龙趺MPP DB的计算资源，和以前传统MPP的计算资源基本相等，但是承载的数据量已经达到了传统MPP（200TB）的5倍，也就是1000TB。
贴源每天运行7万个作业，100万条左右SQL。图（4）左边的曲线图是我们统计的每个时间段完成的作业的数量，上面是base作业对比，上面是stage作业对比。大家可以看到，在每个时间点，红色代表的龙趺MPP DB的作业完成数量，基本都大于蓝色代表的传统MPP 的作业完成数量。也就是说，在数据量膨胀了5倍的情况下，龙趺MPP DB的性能仍旧可以很好的满足应用要求。
图（4）
一、研发背景
建行在这二十几年的数仓建设中，取得了很大的成果，但也遇到了很多的问题。传统MPP数据库产品，普遍存在以下几个问题：
- 并发能力和扩展性不足，大量分库分表造成严重数据冗余；
- 数据的存储和计算不分离，导致数据库孤岛情况严重；
- 升级、扩容、故障恢复等操作复杂耗时长，运维成本高；
- 非云原生架构，资源动态调度困难，且难以融入建行云建设。
为解决上面的几个问题，我们的龙趺MPP DB应运而生。
龙趺MPP DB逻辑架构可以分成两个模块，一个是管理模块，一个是用户模块，如图（5）。管理模块主要负责基础资源的管理、集群创建、启停、扩缩容和监控告警等服务。用户模块分成3层，也就是元数据层、计算层和共享存储层。
图（5）
图（6）就是我们管理控制台的UI界面。所有的资源创建、销毁、扩缩容、升级、故障自愈，以及监控等操作，都这可以在控制台上完成。
图（6）
用户模块方面，图（7）是我们的元数据集群，主要用来提供元数据持久化存储和读写、事务、锁管理等服务。元数据集群使用ETCD作为服务发现和负载均衡，使用FDB作为数据存储层。中间的无状态服务层负责接收和处理所有计算集群的元数据请求。每一层服务都可以根据负载需求进行扩容，以提升服务能力。
图（7）
接下来是计算层，如图（8）。计算层里，每个计算集群就是一个独立计算资源的数据库服务，用户可以按需对计算集群进行创建、删除、扩缩容等操作，作业也可以在已有计算集群间灵活调配。一套计算集群并发和扩展能力不足时，用户可以通过新建集群来实现并发能力的线性扩展。
图（8）
最后是共享存储层，如图（9）。共享存储采用对象存储来持久化存储用户数据，数据一次写入，所有计算集群共享使用。通过利用对象存储的海量文件存储、高并发、数据高可用性和持久性等能力，满足了应用海量数据存取、高作业并发、数据安全等方面的需求。
图（9）
二、应用解决方案
通过采用龙趺MPP DB这样一种服务分层，数据共享的架构方式，我们对应用解决方案进行优化。如图（10），原来采用传统的MPP数据库，应用建设是立烟囱式的，每个应用需要创建一个甚至多个独立集群。不同的集群间需要进行大量复制数据，管理复杂，且资源浪费严重。而采用龙趺MPP DB，应用的计算和并发需求可以通过创建一个个计算集群去满足，不再需要数据复制，同时应用作业可以根据需求灵活的实时调度到不同的集群上，大大提升应用灵活度以及资源利用率。
如图（10）
三、运维解决方案
在运维方面，龙趺MPP DB也提供了更为高效便捷的解决方案，如图（11）。由于龙趺MPP DB的计算集群都是无状态的，借助IaaS服务的快速资源供给，我们可以很快速的完成部分节点乃至整个集群的创建或者销毁。这样子，我们就可以实现集群的动态扩容、缩容、升级等操作。当出现节点故障时，也可以快速隔离和恢复故障节点，实现故障自愈，大大提升了运维效率。
图（11）
过去一年多时间里，建行龙趺MPP DB集群的服务器规模增加了50倍，数据量增加了45倍，已经有几十个应用在上面运行。但是随着集群规模的不断增大和应用负载的不断增加，原来各种不起眼的小问题也开始被无限方法大，导致严重的连锁反应：
- 每天百亿级别的元数据RPC请求如何稳定响应；
- 对象存储海量的数据存取需求如何高效满足；
- 超大规模的集群如何高效运行维护；
- 银行级别的高可用需求要求如何保障。
针对这些问题，我们进行了下面几个方面的研究和开发。
元数据服务能力提升方面，根据服务类型及负载情况，我们对元数据服务进行了拆分和分布式改造，从原来每天可以处理十亿级别的RPC请求，提升至可以处理百亿级别的RPC请求，服务能力提升的同时，也提高了高可用性，如图（12）：
图（12）
存储服务能力提升这块，一方面我们通过小文件合并、数据预取、统一缓存层建立等方式，大大减少了对存储的压力；另一方面，针对对象存储每个bucket可以存储的对象数和IO能力有限的问题，我们给每个应用都创建独立的tablespace，每个tablespace根据需求对应若干个bucket。这样通过bucket拆分，实现了对共享存储IO隔离和流量控制，并且避免了单bucket能力不足和倾斜等方面的问题。
图（13）
而在自动化监控运维方面，前面提到了，龙趺MPP DB已经具备了故障自愈的功能。同时，通过实时收集作业、SQL、存储、服务器等运行数据，并对这些数据进行聚合分析，如负载是否符合历史预期、关键作业完成情况等，我们可以进一步判断数据库性能是否正常、负载是否倾斜、资源是否充足，并为资源的动态调度和故障分析定位提供支持，如图（14）、图（15）。
图（14）
图（15）
最后是高可用保障。大家都知道，银行所使用的系统，对于高可用要求非常高。在原有分布式架构以及故障自愈高可用保障基础上，我们为了应对集群级别整体故障、AZ级别服务故障、数据丢失/误删除等情况，我们还提供了跨AZ部署、元数据持续备份、双活部署等方案，进一步提升了龙趺MPP的高可用服务能力，如图（16）。
图（16）
过去几年，我们完成了无数次的版本迭代和上线优化。一款数据库产品的成熟发展，需要产品、架构、研发、运维、应用等许许多多人的长期合作和投入。在龙趺MPP DB上，我们：
- 集合了大批建信金科和业界优秀的研发人员；
- 提供了业界最复杂、最丰富、负载最高的应用场景；
- 拥有建行二十几年的数据仓库建设和运行经验，能够最快的发现产品痛点，提出最贴合用户需求的产品设计。
