为期两天的Distributed Cloud|2020全球分布式云大会，为5G商用时代的到来，在新一轮云计算技术变革的关口，呈现出分布式云生态全景，影响2021年分布式云战略科技趋势，共享新商业引擎，共寻亿万级苍穹，开创未来新篇。
在12月18日下午的“分布式数据论坛”上，星环科技高级产品专家赵志强带来了《国产分布式数据库KunDB开发实践》的主题演讲。
赵志强在演讲开始时表示：分布式数据库今年特别火，离不开中国数据库技术者的分享和合作。今天分享的KunDB是星环科技自研的国产分布式数据库，属于OLTP产品，以往主要是面向星环已有客户提供，今年开始市场化推广。随后赵志强介绍了星环科技公司的相关信息。
我们总部在上海，最开始是做大数据起步的公司，2018年成为全球第一家通过TPCDS测试的厂商，目前在主流行业都有案例，产品覆盖了主要的基础软件，也就是我们常说的ABC，人工智能、大数据和云。星环产品一般也带有两个大的基因，一个是大数据基因，一个是云的基因，非常契合今天会场的主题：云原生+分布式。
分布式的到来并非是突然的，这几年企业的很多业务都开始了分布式的实践，金融、工业、民生的系统都有了解决高并发问题和数据海量存储和访问的技术需求，需要用分布式数据库来解决。
而从运维角度来讲，分布式数据库和新型的基础设施，企业有海量数据的各种管理需求，也有复杂的分布式架构的运维需求。需要基于分布式数据架构对传统的方法做改变，往往还要结合云化的技术，来实现系统的弹性扩展、自动化运维和备份恢复。
综合来说，现在业务系统对数据库的要求超出了传统集中式数据库的能力，数据库需要具备持续高并发写入，线性扩展，数据全局强一致，支撑混合负载等能力，需要用新的架构来实现，KunDB也是基于这些场景需求来设计的。
赵志强介绍了KunDB的产品架构，主要包括数据库内核引擎，数据开发管理工具，系统运维管理工具等部分。其中最核心的KunDB内核分为SQL接入、计算和调度、存储管理、全局事务管理、元数据管理、运维管理等模块。
KunDB的SQL接入模块，对SQL语句进行解析和语法检查，通过计算和调度模块把SQL分解给底层存储引擎执行，复杂的计算场合，除了分解执行，还会把数据调度到计算节点进行复杂的计算。存储管理集群是由多个高可用的主备MySQL Cluster组成的分片存储集群，每个MySQL Cluster叫做Shard。
每个Shard里除了MySQL，还包括KunTablet，用来代理MySQL集群参与整个集群的通信、安全、事务管理。全局事务管理用来分配全局事务，支持二阶段提交和RR隔离级别。运维模块提供了图形化的数据重分布、扩缩容等运维功能，能够管理和配置分布式系统，以及集群状态与流水监控。
KunDB的SQL接入模块，对SQL语句进行解析和语法检查，通过计算和调度模块把SQL分解给底层存储引擎执行，复杂的计算场合，除了分解执行，还会把数据调度到计算节点进行复杂的计算。存储管理集群是由多个高可用的主备MySQL Cluster组成的分片存储集群，每个MySQL Cluster叫做Shard。
每个Shard里除了MySQL，还包括KunTablet，用来代理MySQL集群参与整个集群的通信、安全、事务管理。全局事务管理用来分配全局事务，支持二阶段提交和RR隔离级别。运维模块提供了图形化的数据重分布、扩缩容等运维功能，能够管理和配置分布式系统，以及集群状态与流水监控。
KunDB采用的Share Nothing架构，通过分片技术来实现高并发写和可扩展。数据在KunGate层会根据表定义的分片策略打散到底层的存储节点。目前KunDB支持Hash、Range、Interval、List、Reference、Replication六种分片方案，方便业务方根据实际需求选择灵活的分片方案。
KunDB部署有两种模式，第一种是单Shard模式，赵志强介绍：它有一个比较轻量高可用解决方案，通过一个Shard存储再加上KunGate就可以组成高可用的MySQL集群。用户业务需要分布式数据库的时候，也就是KunDB的第二种模式，可以进行扩容。
从单Shard扩容到分布式集群，会增加一个全局事务的管理组件和分布式计算组件，然后触发一次数据的重分布。整个过程是在线完成保证业务不中断。这样的设计兼顾了业务系统短期因资源紧张或者业务规模不够等原因不上分布式数据库，但是未来又会扩容的场景。
从单Shard扩容到分布式集群，会增加一个全局事务的管理组件和分布式计算组件，然后触发一次数据的重分布。整个过程是在线完成保证业务不中断。这样的设计兼顾了业务系统短期因资源紧张或者业务规模不够等原因不上分布式数据库，但是未来又会扩容的场景。
KunDB可以水平分片存储的同时，也支持健全的分布式事务管理，保证全局一致性。其中KunDB原子性是通过优化过的二阶段提交实现的。事务的一致性和隔离性，通过引入全局事务管理器模型来解决的。全局事务管理器来生成有序唯一的全局事务ID和可见的快照范围，全局事务ID会下发到各个Shard，Shard的本地事务统一使用同该事务ID完成。数据读取的时候，我们采用本地事务可见性与全局事务可见性结合进行判断，保证全局读一致性。
SQL优化内容方面，赵志强讲到在查询计算的数据链路中，由KunGate提供查询的SQL解析，基于规则和代价选择合适的执行路径，尽可能的下推给底层来并发执行。部分不能下推的复杂计算型的SQL或者没有分片规则可以优化执行的场景，则会通过批处理的方式从底层存储引擎拉取到内存中进行分布式计算。一般来说，对于带有分片键的信息的多维关联查询、以及跟复制表的关联查询，都是可以下推的。没有带分片键信息的表查询语句，可以通过全局二级索引来优化。
SQL优化内容方面，赵志强讲到在查询计算的数据链路中，由KunGate提供查询的SQL解析，基于规则和代价选择合适的执行路径，尽可能的下推给底层来并发执行。部分不能下推的复杂计算型的SQL或者没有分片规则可以优化执行的场景，则会通过批处理的方式从底层存储引擎拉取到内存中进行分布式计算。一般来说，对于带有分片键的信息的多维关联查询、以及跟复制表的关联查询，都是可以下推的。没有带分片键信息的表查询语句，可以通过全局二级索引来优化。
KunDB的所有组件都是分布式模型的，但是各层的实现不一样。比如计算调度层不需要维护持久化的数据，所以都是采用多点多主的高可用模型。而存储集群用的是有主的主从模型，集群内每个时刻都会至少有一个副本，通过二进制日志做强一致性的同步复制，集群内各个副本是最终一致性。故障时通过主备切换保证可用性，因为同时只有一个主节点工作，不会有脑裂的现象。这样的架构保证了RPO=0，RTO<30秒。KunDB的元数据服务和全局事务管理器也是通过机群的方式保证可用性的。
分布式数据库除了有一致性保证，通过数据的水平分片、高可用的策略来解决集群的分布式要求之外，还要解决和云技术的融合。星环从2015年开始云原生实践，KunDB设计开发也是基于云原生架构的：
云原生数据库是数据库新的部署形态。KunDB支持在星环TDH和TDC两种模式下部署和交付。两种模式下，KunDB的服务组件都是通过容器服务化的，区别在于存储方面，TDH里KunDB还是用的裸存储设备，而在TDC里则用的池化的存储设备。
产品的云化方面赵志强介绍说，数据库作为一种持久化的服务，使用容器服务化相比于业务应用会复杂的多。星环很早就使用Docker、Kubenetes框架对大数据类服务和应用服务进行改造，KunDB基于这些经验积累做了云化改造。主要是从几个方面解决云化问题，一个是容器云平台的架构，第二是服务编排调度，包括内部服务角色的拆分，服务调度怎么跟云平台相结合，第三个是安全层面的，整个云平台从底到上的安全策略，第四个云管平台的运维管理体系。
赵志强进一步介绍说：KunDB的分布式架构，对不同的核心功能做了服务拆分，也就是解耦成十几个不同的服务，封装成不同Pod在云上以多个实例的方式运行保证可用性。云平台中，数据库作为关键服务，对资源的调度优先级比其他业务应用要高，保证数据库服务本身是持久可用的。尤其是存储部分，使用了池化的资源后，为了降低存储时延，采用了多级存储和对数据感知的调度。星环自研的WarpDrive等基础设施组件为KunDB持久化存储提供了数据可见性、数据加密等高级特性。
赵志强认为KunDB有MySQL的生态优势，各层之间是支持MySQL协议的方式去通信的，可以直接复用社区的很多组件来用，特别是JDBC，中间件框架可以直接用。现在KunDB做了部分MySQL8.0适配，同时也持续增加了很多Oracle语法的支持，对于MySQL和Oracle迁移到KunDB，减少了很多工作量。
演讲的最后赵志强还重点分享了KunDB的HTAP方案：目前星环的关系型数据库主要由两大产品组成，一个是OLTP的KunDB，基于行存，一个是OLAP的ArgoDB，基于列存，两个数据库既可以单独部署，也可以组成异构的HTAP方案。在HTAP里，由KunDB的KunGate作为SQL的入口，对复杂的分析型SQL进行判断，如果ArgoDB效率更高，就会派发给ArgoDB执行，KunGate做汇总返回业务。
目前我们也在持续改进HTAP方案，比如说我们让它们在存储层做行列存储的实时同步，因为两个产品都是我们自己的产品，所以改造起来都是可控，有各种技术方案的改造实践，追求更低延迟的HTAP的方案。
赵志强从技术视角诠释KunDB作为分布式数据库和云原生数据库的内容，分享了对数据库开发技术的思考和实践。分布式数据库仍有很多技术需要攻关，期待以后KunDB在技术驱动下，市场上越来越多的客户能了解和使用KunDB，越来越多的前沿技术和实践经验可以分享。
责任编辑：吴昊
