分析型数据库：分布式分析型数据库

分析型数据库的另外一个发展方向就是以分布式技术来代替 MPP 的并行计算，一方面分布式技术比 MPP 有更好的可扩展性，对底层的异构软硬件支持度更好，可以解决 MPP 数据库的几个关键架构问题。本文介绍分布式分析型数据库。

— 背景介绍—

目前在分布式分析型数据库领域，学术界今年的研究不多，主要是工业界在推动相关的技术发展。分布式分析型数据库的存储层一般采用分布式存储或云存储，而计算引擎层采用独立的分布式计算引擎，而 MPP 数据库的存储层和计算层都是由多个数据库实例来承担的，这是两者最大的架构区别。

在 Hadoop 开始兴起的时候，分布式架构的可扩展性和弹性优势就逐渐显现出来，以 HDFS 为代表的大数据技术使大数据的处理在扩展性、弹性、容错性、成本等方面取得进步，但是却牺牲了传统 SQL 数据库例如事务、SQL 语句、关系模型、安全管控等关键特性。SQL 作为数据库领域的事实标准语言，相比较用 API（如 MapReduce API，Spark API 等）来构建大数据分析的解决方案有着先天的优势。从 2013 年开始大量的 SQL on Hadoop 引擎的出现和快速成熟，并且在国内外企业获得了大量生产落地，充分说明了 SQL 的重要性。

分布式分析型数据库用于数据仓库的建设，就需要解决分布式事务以及高并发的批处理问题，因此需要重新构建分布式事务引擎和计算引擎。当前行业内不同的数据库采用的技术方案不尽相同，分布式事务引擎大多需要从 0 到 1 的构建，而分布式计算引擎有采用类似 DAG 的计算模型。

分布式数据库与 MPP 数据库的一个典型区别就是计算和存储的部分分离，也就是存储服务和计算服务不再绑定在一个进程中，数量可以不一致，这样就实现了计算的弹性。在真实生产业务中，计算的弹性需求比较大，而存储相当来说可预测性更强。一些厂商采用自研存储的方式如星环科技的 ArgoDB，而另外部分企业就直接基于云存储的方式来构建其数据库，将目标市场直接定位在公有云端，如 AWS Redshift、Snowflake 和 Databricks SQL。不过私有云和公有云场景下的分析型数据库的设计理念差异非常大，实际架构区别也非常明显，我们将在后续章节展开。

— 总体架构 —

由于分布式数据库起步较晚，设计者在做架构设计的时候就能充分吸收 MPP 数据库和 Hadoop 等技术的优势，避开 MPP 数据库的架构缺陷，并且解决弹性化、多租户隔离等方面的各种问题。分布式分析型数据图的逻辑架构如下图所示，主要包含了服务层、SQL 引擎、分布式事务引擎、分布式计算引擎和存储引擎。与 MPP 数据库的逻辑架构最主要的区别在于计算引擎和存储引擎独立，而 MPP 数据库底层基于某一种关系数据库，包含了 SQL、事务、计算和存储能力。由于几个引擎相对独立，架构上的灵活性就保证了有多种方式可以解决原有 MPP 数据库的架构问题。

• 分布式存储引擎

  
  

在分布式存储引擎这一层，目前行业内有比较多的基于 Paxos 或 Raft 协议打造的高可用的分布式存储。由于用于分析型场景，数据存储格式一般都采用列式数据存储，典型的实现有 ORC 和 Parquet 文件格式。在分析场景下仅读取需要的列数据而无需读取其他不相关列，节省了 IO 从而有很高的数据读吞吐；另外一个列的数据采用同样的编码方式（如 RLE、Delta、字典编码等），因此数据有很高的数据压缩率，一般可以做到 5~10x 的压缩比。另外，由于不同的列已经分开存储，一般会设计并行读数据的 API，每个线程读取不同的列数据，从而提高并行读数据能力。基于列式存储的另外一个好处就是更好的支持各种结构化和非结构化数据，从而可以在一个平台内支持多样的数据类型的数据分析。

列式存储对读数据有很大的性能优势，一般都会设计接口跟上层的计算层对接，提供读取、过滤下推、索引等读写接口。在支持数据写入的能力上，列式存储不如行式存储，一般需要通过在上层增加一个内存 buffer 的方式来加速，如 MariaDB 的 Version Buffer。

另外分布式事务也是分布式存储的一个重要特性与要求，一般都采用 MVCC 和 Compaction 机制来实现。在列式存储中去修改给定一行的数据是比较复杂的，因此在实际操作每个事务操作并不会直接修改对应的字段的值，而是在生成一个新的版本，并在对应字段的 block 生成一个只包含要修改的数据的新版本的数据块。每个新版本操作就生成一个新数据块，在读取数据的时候，会根据有效的事务号来读取相关的数据块并和基础数据合并生成最终的数据值。随着数据库的版本增加，数据读的速度会下降，因此需要启动 Compaction 机制来合并，将大量的多版本文件合并为少量的文件，从而实现读写能力的有效平衡。

在实际功能中，还需要考虑关于分布式管理和运维方面的能力，包括对磁盘或节点的增删管理能力，数据迁移能力等。

• 分布式计算引擎

  
  

分布式计算引擎是另外一个重要的组成，一个优秀的引擎包括计算框架、各种分布式计算的算子、优化器以及资源管理能力。在计算框架方面，一般选择 DAG 或 MPP 模式，根据不同的设计需求来选择。在计算算子方面，围绕着 SQL 的原语，可以设计大量的算子，譬如 JOIN 算法就可以有包括 hash join、sort merge join、index scan join、skew scan join 等多种不同的实现，并对接到 CBO 优化器来做自动化的选择。这个方向的长期演进方向就是自治数据库，通过大量的优化规则和机器学习能力来产生针对用户场景的更多优化规则，从而让数据库可以自动的选择最合适的执行计划，无需 DBA 的手工干预。

在资源管理方面，如果跟现有的资源管理框架有效结合也是分布式数据库的重要工作之一，包括 YARN、Kubernetes 以及各个公有云平台。无论是 Spark、Flink 等开源资源管理框架，还是各个商业的分析型数据库，都在大力的推动资源管理模式的优化，从而更好的支持多租户以及与云计算的结合。

• 分布式事务引擎

在分布式数据库领域，分布式事务处理和优化是非常热门的关键技术，如何在复杂的系统架构和容错设计下保证数据的一致性，以及有多种事务隔离级别的支持（串行化、可重复度、Read committed 等），能够拓展数据库去支撑更多的应用。两阶段提交（2PC）、MVCC、基于快照的事务隔离等都是重要的技术实现。由于分析型数据库主要处理低并发度的事务操作，比较多的都是批量的数据修改或插入，因此对事务的并发度要求不高。在实现中，甚至可以采用一些低并发度但是实现简单的算法，如两阶段封锁（2PL）等算法。

• SQL 引擎

SQL 引擎为开发者提供 SQL 开发能力，是业务开发的核心接口，因此各个数据库都在努力提供完善的 SQL 支持，以及完整的 SQL 优化能力。由于 Oracle、Teradata 等数据库的 SQL 功能非常完善，提供 Oracle 与 Teradata 的数据库兼容性是个非常有挑战的工作，也需要长期持续的投入。

— 星环分析型数据库 ArgoDB —

随着大数据技术在企业中应用得越来越深，国内的企业数据架构变得越来越复杂，主要体现在离线业务与在线业务并存，分析型业务与检索型业务并存，结构化数据与非结构化数据并存，对数据库性能、多租户服务能力的要求也越来越高。企业对性能要求超过弹性或者成本，因此亟需有极致性能的分布式分析型数据库，这也是私有云领域分析型数据库的主要发展方向。

软件的设计需要充分考虑硬件的特性，从 SAS 硬盘，到 SATA SSD，到 PCIE-SSD，再到 Memory，性能都有着数量级的增长，也推动着数据库架构的重新设计。在应用需求和技术架构的双重推动下，星环科技从 2014 年即开始规划不依赖于 Hadoop 存储的分析型数据库，重用已有的 SQL、事务和分布式计算引擎的能力，自研新一代的基于闪存的分布式存储，到 2018 年正式推出了闪存数据库 ArgoDB，目标能够作为数据仓库、数据湖和数据集市的统一解决方案。

ArgoDB 的架构如上图所示，主要的核心组件主要包括分布式计算引擎 Crux、SQL 编译器、分布式存储管理层 TDDMS 以及存储引擎 Holodesk。

SQL 编译器继承了 Inceptor 产品的优秀能力，实现了 SQL 99 的完整兼容性，支持 PL/SQL 以及 DB2 SQL PL 存储过程规范，并且原创的支持了 Oracle、DB2 和 Teradata 的方言。为了满足企业的数仓需求，ArgoDB 也支持分布式事务管理和四种隔离级别。

ArgoDB 在数据库内部实现了自己的资源调度以更好的支持不同业务的并发 SQL 任务，并与平台本身的调度系统结合，实现了两个层级的更加细化的资源管理和调度能力。首先 ArgoDB 有个常驻服务，数据库启动后就预先申请了 CPU 和内存资源，并将资源划分为多个资源池。除了基于 FIFO 或 FAIR 策略为每个 SQL 分配资源以外，ArgoDB 还增加了一个 Furion 机制，基于一个树形的结构来资源管理，同一个树节点下的各个子节点允许资源互借资源，每个树节点允许不同的用户或者应用设定 ACL 或 affinity，实际调度的时候，只要有一个 CPU core 资源空闲，就调度某个 task，最大程度的让资源有效利用。为了更好的支持多业务，ArgoDB 允许根据用户名、IP、业务类型、提交时间等特性来设定不同的优先级和调度策略，允许抢占式调度。另外每个资源池都保证最小的资源，从而避免饥饿调度问题。

ArgoDB 将分布式存储引擎解构为通用分布式存储管理层 TDDMS 与底层存储引擎 Holodesk 两块。TDDMS 将底层存储引擎抽象为一组接口，包括存储的读写操作接口、事务操作接口、计算引擎的优化接口等，任何实现这些接口的存储引擎都能以插件的形式接入 ArgoDB。TDDMS 基于分布式一致性协议 Raft 实现的存储引擎，利用它可以实现存储引擎管理的高可用和备份灾备能力，并且提供运维管理能力。由于 TDDMS 在设计上的使用了数据存储的引擎化管理，它能够接入新的专用存储，从而解决了对 Hadoop 生态技术的依赖问题。TDDMS 在设计上可以接入多模态的存储，既而与上层计算引擎配合，实现多模态的统一存储和统一分析能力，在实际业务中是个重要的创新，避免每个数据库都要垂直的实现存储管理的工作。

Holodesk 通过基于闪存的行列混合存储，针对闪存 SSD 强大的随机 IO 能力，以及优于普通 HDD 盘顺序读写能力，做了数据读写的专项优化，实现了数据快速的读写能力，进而可以是业务获得更优秀的分析能力。Holodesk 也支持多种辅助索引技术，支持数据块级别的预先聚合，极大地增强了数据的检索性能，能更好地适配混合型的业务场景。但 Holodesk 并不仅仅只能使用 SSD，也支持内存+闪存+磁盘的三级混合存储。多级存储使得用户可以更好的在性能和硬件预算间找到平衡点。

分布式计算引擎 Crux 是一个向量化的计算引擎，采用的基于 DAG 模式的计算框架，内部由多个无状态的执行器组成，可以根据业务负载来调整计算弹性化。计算引擎既可以快速读取批量存储文件，也可以高速地运行少量数据的简单查询和复杂查询。内存数据格式的设计与列式存储适配，最大程度地减少了数据在内存中转换的时间。同时，能够动态分析 SQL 结构，基于向量化的思想选取高效的运行时行列对象模型，在提升性能的同时显著节省内存使用。ArgoDB 的整体的业务查询架构如下所示，用户的 SQL 业务经过 SQL 编译器生产执行计划和 Runtime Context，然后发送给 Crux Executor；Executor 通过 TDDMS 来访问存储层的数据，其中 F1/F2/F3/F4 等都代表一个数据块，Holodesk 默认采用 3 副本方式存储，然后经过 TDDMS Tablet Server 来访问本地文件系统上的存储的实际数据块。

Crux Executor 和 TDDMS 存储是独立分层的，它们各自可以根据负载情况来独立的弹性扩缩容，因此解决了可扩展性问题，尤其是计算的可扩展。未来，我们计划将 TDDMS Tablet Server 与各个云平台对接，可以直接与云上的文件系统高速交互打造云上的数据分析能力，服务于公有云的企业客户。ArgoDB 本身实现了数据库内的资源管理，底层基于容器技术和 Kubernetes 做系统层的资源调度，通过两层资源调度机制实现了非常好的多租户能力。

基于先进的架构设计与规划，ArgoDB 在 2 年内也落地了大量的金融级生产案例。此外，在国际基准组织 TPC 的数据分析决策测试 TPC-DS 的测试中，星环 Inceptor 是国际上首个通过测试的产品，而 ArgoDB 是全球第四个，这也充分说明了整体架构的先进性。

— 小结—

本文介绍了分布式分析型数据库的架构原理，以及星环分析型数据库 ArgoDB 的核心能力。分布式数据库相比于 MPP 数据库能够实现存算分离，这样就能实现了计算的弹性。那么更进一步的，在传统的企业数据运用中，常常会出现企业的系统数据散落在各个数据存储中的状况，数据分析需求往往是跨库的，这类需求又该如何解决呢？下一篇将介绍数据联邦架构。