一种云原生大数据分析引擎的制作方法

1.本发明涉及大数据分析技术领域，具体涉及一种云原生大数据分析引擎。


背景技术：

2.olap分析型数据库是公有云服务的基石之一，它使分析人员能够迅速、一致、交互地从各个方面洞察数据，以达到深入理解数据的目的。公有云的olap数据库包含如下几类：把开源的olap数据库搬迁到公有云，提供dbaas(database as a service)服务；公有云提供商依靠自身力量研发出专门面向云端用户的olap数据库。不同企业在公有云上部署应用的时候，对于olap数据库的选择也有两种不同的方式：一种是直接采用上述公有云的两类托管olap数据库服务，另一种是购买公有云基础设施，包含计算和存储，然后自行部署和维护开源的olap数据库。
3.现有技术存在以下不足：企业在迁移到云原生架构的过程中，面临各种困难的选择，这不仅在于olap本身技术的复杂和各种限制，还在于公有云能够购买的资源相比私有化部署也有其特殊性：公有云能购买的基础计算资源包含虚拟机和物理主机，后者价格昂贵，前者通常只提供很小的本地存储，而且公有云的大数据型虚拟机，通常是给单个机器挂载很大的本地存储，因此这难以利用更多的并行计算资源。因此选择公有云托管的开源olap：不论是行存、列存、还是基于索引的方案，既不能廉价，也无法高性能，它们在存储上不能做到高性价比，性能上不能做到最优。


技术实现要素：

4.为此，本发明提供一种云原生大数据分析引擎，通过提出一种新型olap分析型数据库的设计实现，它适合为企业利用公有云基础设施部署，提供廉价而高速的olap分析型数据库解决方案，是企业云原生基础架构的重要组件之一；同时，本发明也不单纯只适用于公有云部署，在私有化机房中，也同样可以提供快速廉价的高性能olap分析引擎，因此，采用本发明的作为基础组件的企业应用，可以容易的在不同公有云和私有云之间切换，以解决现有技术中由于选择公有云托管的开源olap导致的价格高、性能低的问题。
5.为了实现上述目的，本发明实施例提供如下技术方案：一种云原生大数据分析引擎，包括以下内容：
6.s1、将olap数据库按照数据的分布划分成为不同的分区，并将每个分区称为shard，每个shard都把数据文件保存在s3对象存储当中；
7.s2、针对每一条插入的记录，将记录存储为行存格式，保存到s3对象存储；将记录的每一列，都产生对应的列存，保存到s3存储；为每条记录分配一个自增的整数id，然后为记录的绝大多数列，采用bitmap位图技术(bsi)构建对应的倒排索引；
8.s3、为行存和bitmap倒排索引底层采用通常的key value接口存储：采用开源key value嵌入式引擎pebble来提供key value接口；pebble底层是sst文件，在不同的level上会进行相应的压缩；为列存实现单独的批量接口：在内存中构建简单区块索引：记录每固定
数目的列的最大和最小值，从而在扫描时尽力避免无效的io；
9.s4、提供一个全局的wal日志服务，供所有的shard所共享访问，在插入数据时，数据首先插入到全局wal，然后才分别插入到不同的shard当中；
10.s5、提供全面充分的sql支持：sql的执行层基于关系代数构建而非基于plan构建，并且能够直接根据属性来判断：假设属性a存在倒排索引，则执行index plan，否则走列存，全表扫描后过滤。
11.进一步地，所述bsi索引包含一组bitmap，它根据选定的列数值转换为二进制表示，并将其垂直切为bitmap，对于基数较高的字符串的列选择不构建倒排索引。
12.进一步地，所有shard内部的存储，包括key value接口的pebble存储、以及列存专有存储，都关闭wal日志功能。
13.进一步地，每个shard挂载到块存储的文件缓存，针对行存和bitmap倒排索引所依赖的pebble，还有列存的专有格式，分别提供不同的缓存机制；针对pebble存储，缓存的对象以pebble底层的sst文件为单元；具体来说，在level 0和level 1的sst文件，都会优先存储到文件缓存，然后再推送到s3对象存储，针对列存，则是以列存文件单元为单位的常规lru缓存机制。
14.进一步地，所述全局wal日志服务的选型为开源的pulsar，全局wal日志服务在底层包含一个块存储和配套的s3对象存储。
15.进一步地，每个所述shard默认只启动一个实例，其工作顺序为：新虚拟机从共享s3对象存储当中加载某shard存放的对象文件，并继续从全局wal日志服务消费数据，确保后续数据的一致性。
16.进一步地，所述云原生大数据分析引擎支持schema free的数据导入，此时接受任意的json数据作为输入，对于基础的json类型，会将其解释为基础的sql类型string，number，boolean，对于null则当成sql的null处理。
17.进一步地，所述原生大数据分析引擎服务于公有云环境和私有云环境。
18.本发明具有如下优点：
19.1、本发明是一个依托于公有云s3对象存储的olap分析型数据库，为兼顾成本和高性能，本发明采用了多种数据格式存储，包含行存、列存和倒排索引，使得采用不同格式服务不同种类查询，能够充分利用行存、列存和索引的不同优势服务不同种类查询，尽可能减少用户的选择成本，为用户提供高性能的查询服务；
20.2、本发明解决了普通倒排索引难以服务全sql能力的问题，对于数值类型包括浮点数，依然采用倒排索引提供了高并发的sql过滤和sql聚合能力，并且让倒排索引工作于s3对象存储之上；
21.3、本发明提供了在公有云对象存储之上，一种应对多变业务场景的schema free的插入手段，通过提供schema free的数据入库能力，使得用户插入数据时无需事先定义数据库字段和类型，这样极大的方便了用户入库操作，并且针对复杂多变的业务场景对数据库schema却无需任何修改；本发明不仅提供了在公有云对象存储之上的部署能力，还能够对私有化环境中提供同样的查询分析服务，这依赖于本发明对于已有的multi
‑
raft机制的封装，使得它能够以单独库的方式运行，能够同时管理常规的key value引擎和定制的列存，并且本发明将对基于multi
‑
raft机制管理本地存储和管理s3对象存储的机制统一封
装。
附图说明
22.为了更清楚地说明本发明的实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，下面描述中的附图仅仅是示例性的，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图引伸获得其它的实施附图。
23.本说明书所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。
24.图1为本发明提供的基本框架图；
25.图2为本发明提供的bsi索引的二进制示意图；
26.图3为本发明提供的云环境示意图。
具体实施方式
27.以下由特定的具体实施例说明本发明的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本发明的其他优点及功效，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
28.参照说明书附图1
‑
3，本发明提供的一种云原生大数据分析引擎，包括以下内容：
29.olap数据库按照数据的分布划分成为不同的分区，并将每个分区称为shard。每个shard都把数据文件保存在s3对象存储当中。同时，为克服s3文件系统吞吐量不足的缺点，每个shard本身都挂载一块存储，用来作为s3存储的文件缓存。
30.针对每一条插入的记录，本发明都做如下处理：
31.1.将记录存储为行存格式，保存到s3对象存储。
32.2.将记录的每一列，都产生对应的列存，保存到s3存储。
33.3.为每条记录分配一个自增的整数id，然后为记录的绝大多数列，都产生对应的倒排索引。具体来说，是采用bitmap位图技术构建倒排索引。bitmap索引，同样存入到s3对象存储当中。
34.因此，本发明中，任何数据，都有行存、列存和bitmap倒排索引三种格式的数据。数据尽管相比原始记录会膨胀至少3倍，但是因为数据存放在s3对象存储中，相比本地磁盘或者块存储，成本仅有后者的不到1/10，因此整体开销相比其他olap数据库不仅没有增加，反而减少很多。在sql查询计划中，只要涉及到的查询列存在bitmap倒排索引，就会通过bitmap倒排索引完成sql的执行。
35.不是所有的列都能够创建倒排索引。通常的倒排索引，仅能针对枚举型的字符串建立倒排索引，例如elasticsearch就是这样。针对数值类型，后者采用了不是很有效的bkd tree，它的查询过滤性能不太好，并且无法满足在数值列类型之上的聚合型查询。本发明采用bsi技术建立bitmap倒排索引。bsi索引包含一组bitmap，它根据选定的列数值转换为二
进制表示，并将其垂直切为bitmap，如图2所示。图2的例子，只需要15个bitmap即可表示从0到30000的值，因此可以方便的在这些bitmap里设置行号，从而为整数类型的字段也建立了bitmap倒排索引。对于浮点数字段，本发明也采用bsi技术，只需要针对基数和尾数分别考虑。bsi索引解决了倒排索引难以针对数值型字段建立聚合查询和高速范围过滤的缺点。然而对于字符串的列，并且基数很高，建立bitmap索引就没有任何优势了，一个典型例子是md5加密的用户字符串id。本发明针对这种场景可以选择不构建倒排索引。
36.本发明中，行存和列存可以通过配置关闭。因为对于olap数据库来说，行存只在很少情况下会采用，这就是随机点查询。这种查询对于oltp型数据库比较常见。因为用户根据需求关闭行存，可以进一步节省资源。列存在大多数情况下，也不会来采用，一般在查询涉及的列没有倒排索引，或者对列的分析查询包含like类型等需要大范围扫描的，才会用列存来进行。
37.本发明中，行存和bitmap倒排索引，其底层采用通常的key value接口存储。其中倒排索引的key为该列的具体取值，value为该具体取值在哪些行中存在的行号列表。由于bitmap本身是稀疏数据结构，因此本发明采用roaring bitmap格式对bitmap倒排索引压缩，减少io开销。为避免倒排索引持续更新带来的开销，本发明对倒排索引首先在内存中构建，待内存桶满之后才写入存储。本发明采用开源key value嵌入式引擎pebble来提供key value接口。pebble底层是sst文件，在不同的level上会进行相应的压缩，其工作机理类似于流行的rocksdb，但无需wal日志和多行事务保证，具有高于rocksdb数倍的吞吐量。
38.本发明中，列存没有依赖key value接口，因为会大大降低列存扫描记录的吞吐量，因此本发明为列存实现了单独的批量接口，其特点在于针对每条记录每列的数据，都是直接存储而没有任何序列化开销。在内存中构建简单区块索引：记录每固定数目的列的最大和最小值，从而在扫描时尽力避免无效的io。本发明的列存格式借鉴了开源olap引擎clickhouse的单机存储引擎格式，因为后者是目前最快的开源olap数据库。
39.本发明中，每个shard挂载到块存储的文件缓存，针对行存和bitmap倒排索引所依赖的pebble，还有列存的专有格式，分别提供不同的缓存机制。针对pebble存储，缓存的对象以pebble底层的sst文件为单元。具体来说，在level 0和level 1的sst文件，都会优先存储到文件缓存，然后在推送到s3对象存储。针对列存，则是以列存文件单元为单位的常规lru缓存机制。
40.本发明，所有shard内部的存储，包括key value接口的pebble存储，以及列存专有存储，都关闭wal日志功能，目的是为减少io开销。本发明另外提供一个全局的wal日志服务，可以供所有的shard所共享访问。在插入数据时，数据首先插入到全局wal，然后才分别插入到不同的shard当中。这样，即使某个shard所在的虚拟机出现故障，也能够很快重建另一个虚拟机，从全局wal当中恢复重建数据。
41.全局wal日志服务的选型为开源的pulsar，全局wal日志服务在底层包含一个块存储，和配套的s3对象存储。由pulsar负责将wal当中的冷数据搬迁到s3当中。没有选择流行的kafka的原因在于后者对云原生十分不友好，缺乏数据冷热自动搬迁的能力。
42.本发明中每个shard默认只启动一个实例，然而在某些情况下，会需要针对某些shard启动额外的副本实例，其工作顺序为：新虚拟机从共享s3对象存储当中加载某shard存放的对象文件，并继续从全局wal日志服务消费数据，确保后续数据的一致性。
43.启动额外副本实例的典型场景在于：如果系统的吞吐量达到限制，需要通过增加副本的方式增加吞吐量。因此，为使得该过程尽可能迅速，本发明采用kubernetes容器进行编排。因此本发明的shard实例，其实运行于容器当中，而并不一定是虚拟机。本发明会根据查询的负载动态向kubernetes容器云请求容器资源。
44.本发明提供全面充分的sql支持。sql的执行层基于关系代数构建而非基于plan构建。
45.本发明则直接根据属性来判断：假设属性a存在倒排索引，则执行index plan，否则走列存，全表扫描后过滤。
46.本发明可以配置为支持schema free的数据导入，此时接受任意的json数据作为输入，对于基础的json类型，会将其解释为基础的sql类型string，number，boolean，对于null则当成sql的null处理。json的object作为sql子关系处理，array则作为数组存在，但是数组的每个元素的类型可以不同。本发明中，特定属性的各个值的类型可以是不同的，不过每个值都有其确定的类型，此外还支持子关系这种特殊类型。比如对于属性a，接受了两个值{"a":"b"}和{"c":1,"a":"c"}，则对于属性a而言存在一个子关系，该关系的属性为a和c，该关系包含2个元组。
47.本发明虽然主要服务于公有云环境，但在私有云环境中同样可以部署使用。这包含两种方案：如果私有云可以提供兼容s3的对象存储接口，例如ceph分布式文件系统等，那么本发明可以直接部署。如果私有云只提供物理机，那么本发明将依赖自有的存储抽象库来管理底层存储，具体定义如图3所示。图3是一个基于multi
‑
raft多组强一致协议实现的分布式存储库。一些新型数据库如tidb都采用了类似的机制提供底层存储。本发明把multi
‑
raft机制抽象出来，使之跟底层存储引擎分离，并且跟上层应用解耦，因此这是一个嵌入式的分布式存储管理工具而不是独立运行的进程。由于本发明的计算和存储分离架构，前述的所有设计，在私有化环境中可运行于上述multi
‑
raft框架之上。multi
‑
raft框架负责管理pebble的key value存储引擎，也同时管理专有列存引擎，并提供这些存储引擎的多副本机制和自动负载均衡。
48.虽然，上文中已经用一般性说明及具体实施例对本发明作了详尽的描述，但在本发明基础上，可以对之作一些修改或改进，这对本领域技术人员而言是显而易见的。因此，在不偏离本发明精神的基础上所做的这些修改或改进，均属于本发明要求保护的范围。