本部分主要介绍 Inceptor 数据库的概况，以及作为一款国产化的自研数据库，使用 Inceptor 数据库执行用户数据库业务时所具备的技术优势。

本部分包含以下章节：

产品定位

随着大数据技术在企业数字化平台中深度应用，用户业务的分析需求变得越来越复杂。数据分析相关的业务逐步呈现为：离线业务与在线业务并存，分析型业务与检索型业务并存，结构化数据与非结构化数据并存。传统的、单一的数据平台架构已经很难满足用户业务对数据处理的低时延、高性能的使用诉求。

Transwarp Inceptor（简称 Inceptor）是星环科技自主研发的关系型分析引擎，可以对数百万张结构化数据表、PB 级的海量数据进行存储和加工，帮助企业快速开发数据湖以及其他结构化数据的分析应用等。Inceptor 是全球首个通过分析决策系统国际基准测试 TPC-DS 的产品；支持完整的SQL标准语法，兼容 Oracle、IBM Db2、TeraData 方言，兼容 Oracle 和 Db2 的存储过程，帮助企业平滑地迁移应用；支持分布式事务处理，保障数据强一致性。

产品优势

使用星环分布式分析型数据库 Inceptor 构建用户的数据业务，具备以下优势：

高扩展
- Inceptor 数据可以按需进行水平扩展，且作业任务能够均匀调度，不存在木桶效应；
- 存储和计算模块相互解耦，用户可以按需分配或者扩展集群资源；
- 自主研发的作业调度技术，可以支持企业级混合负载业务的运行；
- 底层利用容器技术实现资源调度和资源隔离，支持资源的弹性扩/缩容，可以为多租户弹性提供稳定可靠的数据库服务。
高性能
- 特有的向量化计算引擎，加速用户的查询分析性能；
- 高性能的 OLAP 分析引擎，底层计算算子全向量化实现，高并发复杂分析在百毫秒内完成；
- 匹配实时流，强化批流融合
  
  与星环自研的实时流引擎 Slipstream 无缝衔接，数据落地即可分析，提供了高吞吐（百万记录/秒）数据入库，实时业务秒级响应。
- 深度适配新兴硬件，单服务器资源最大化利用。
高可靠
- 基于 Raft 一致性协议的存储引擎，具备自动故障迁移、自动数据修复的能力；
易开发
- 标准 SQL 支持
  
  支持 SQL 99/2003 标准语法，兼容 Teradata，Oracle，DB2 等方言；
- 多模态数据支持
  
  支持 11 种数据模型的存储与计算，覆盖业务全场景；
- 联邦能力
  
  支持 Inceptor 数据库与自身或者其他第三方数据库进行跨库的 SQL 联邦计算。
自主可靠
- 纯国产化数据库，帮助用户实现自主可控
  
  数据库的核心代码 100% 自研，且拥有第三方机构权威认证。
- 对国产生态的支持
  
  全面适配国产 CPU、操作系统、ETL 工具、BI 分析报表等底层生态。
- 成熟可靠
  
  数据库团队多年的技术积累，且 Inceptor 数据库在全行业都有落地实施案例。

软件架构

产品定位

Transwarp Inceptor 是一款创新型分布式架构，可提供超大规模、高效性能、稳定运行、极简使用的能力供用户数据库业务使用。其产品架构请参见下图：

图 1. Inceptor 产品架构图

核心组件

Inceptor 的产品功能模块清单及功能介绍如下：

模块名称	模块功能	模块介绍
Quark Gateway	引擎协调器	Quark Gateway 是星环自主研发的弱状态分布式计算引擎调配模块，可以将客户的负载均匀按需调度到不同的 Quark Server 服务上，同时还会负责监测 Quark Server 服务的健康状态，任务发送自动避开有故障的 Quark Server 服务达到系统整体高可用的目的。
Quark Server	SQL 引擎	Quark Server 是星环自主研发的分布式 SQL 查询引擎模块，兼容多种方言的 SQL 编译器，包括 HiveQL，Oracle，DB2，Teradata 等方言，也包括了算子和类型系统。
Gluon	多模型数据库优化器	Gluon 是星环自主研发的多模型数据库优化器，对 SQL 编译结果进行优化，通过基于规则优化、基于成本优化、物化视图等技术手段，自动判断选择合理高效的模型，拆分、分发计算任务。
Transaction Manager	事务管理器	Transaction Manager 是星环自主研发的分布式事务管理系统，是 Inceptor 中用于实现分布式事务的核心组件。
Nucleon	分布式执行引擎	Nucleon 是星环自主研发的分布式计算引擎。拥有高性能，高扩展性，高稳定性的特点。
Metastore	分布式元数据管理系统	Metastore 是星环自主研发的分布式元数据管理系统，可以支持上百万张表的元信息管理。
TDDMS	分布式数据管理系统	TDDMS（Transwarp Distributed Data Management System ）是星环自主研发的分布式数据管理系统，管理数据多副本间的强一致或最终一致；管理数据在存储介质上的合理分片分布，扩缩存储容量时，自动管理数据重分布，充分利用存储资源；保障数据高可用，在存储硬件故障时，保持数据存储服务不中断。
TDFS	星环分布式文件系统	TDFS（Transwarp Distributed File System）是星环研发的分布式文件系统，提供文件目录结构及有关服务；主要用于数据批量导入和导出的时候以文件形式进行数据交换的功能。

模块名称

模块功能

模块介绍

Quark Gateway

引擎协调器

Quark Gateway 是星环自主研发的弱状态分布式计算引擎调配模块，可以将客户的负载均匀按需调度到不同的 Quark Server 服务上，同时还会负责监测 Quark Server 服务的健康状态，任务发送自动避开有故障的 Quark Server 服务达到系统整体高可用的目的。

Quark Server

SQL 引擎

Quark Server 是星环自主研发的分布式 SQL 查询引擎模块，兼容多种方言的 SQL 编译器，包括 HiveQL，Oracle，DB2，Teradata 等方言，也包括了算子和类型系统。

Gluon

多模型数据库优化器

Gluon 是星环自主研发的多模型数据库优化器，对 SQL 编译结果进行优化，通过基于规则优化、基于成本优化、物化视图等技术手段，自动判断选择合理高效的模型，拆分、分发计算任务。

Transaction Manager

事务管理器

Transaction Manager 是星环自主研发的分布式事务管理系统，是 Inceptor 中用于实现分布式事务的核心组件。

Nucleon

分布式执行引擎

Nucleon 是星环自主研发的分布式计算引擎。拥有高性能，高扩展性，高稳定性的特点。

Metastore

分布式元数据管理系统

Metastore 是星环自主研发的分布式元数据管理系统，可以支持上百万张表的元信息管理。

TDDMS

分布式数据管理系统

TDDMS（Transwarp Distributed Data Management System ）是星环自主研发的分布式数据管理系统，管理数据多副本间的强一致或最终一致；管理数据在存储介质上的合理分片分布，扩缩存储容量时，自动管理数据重分布，充分利用存储资源；保障数据高可用，在存储硬件故障时，保持数据存储服务不中断。

TDFS

星环分布式文件系统

TDFS（Transwarp Distributed File System）是星环研发的分布式文件系统，提供文件目录结构及有关服务；主要用于数据批量导入和导出的时候以文件形式进行数据交换的功能。

核心技术

分布式系统中多层次计算任务线性扩展技术

为了让分布式系统在复杂的场景中可以根据集群资源规模进行线性扩展，需要在以下几个关键技术上取得突破：

查询任务调度，能够做到线性扩展

查询任务在接入分布式数据库时需要设计一个路由系统，该系统负责将查询任务分发到后端分布式数据库的编译层进行后续分布式编译执行端执行。通过该系统架构，每个分布式编译执行端可以得到充分利用，并且不会出现一个编译器负载过重的情况。该路由系统的路由规则可以自动化分发或者自定义规则分发。当集群扩展时，可以合理配置路由系统部署新的分布式编译器；通过路由系统将任务调度上去完成线性扩展。
分布式子任务执行调度能够做到线性扩展

一个查询任务在分布式系统中将被切分成多个阶段，而每个阶段又会有许多子任务。当集群规模扩展时，需要做到子任务变多的同时系统持续保持稳定及性能保持同步扩展。这里的关键技术在于分布式子任务调度任务分发在集群扩展时可以利用扩展节点进行计算，同时单节点的整体计算性能保持。

主要技术途径如下：

统一查询任务路由系统

在设计的路由系统中，用户客户端通过指定IP地址与端口以标准化的方式连接路由系统，而不需要具体指定后端需要连接的分布式编译执行端。该路由系统将根据规则将用户后续提交的任务按策略分配到整个集群的编译执行端。用户可以根据业务需求执行规则，当集群有新计算资源（分布式编译执行端）加入后，可以自动地将查询的负载传导到对应资源上，整个集群资源得到充分利用，达到线性扩展的目标。此处列出几种常用的分配规则（下文假定集群有N个分布式编译执行端，命名是Driver0, Driver1, …, DriverN）：
1. 轮询调度分配：在这种分配机制上，用户的任务会按照集群的执行端配置。那么用户任务会按顺序在Driver上分配。比如上一个任务如果在Driver0上执行，那么下一个任务会在Driver1上执行。
2. 随机调度分配：在这种机制下，用户的任务会被随机地分配到N个Driver之一上执行。
3. 自定义任务规则分配：在某些场景下，一些查询业务更适合在特定的Driver端执行，那么运维人员可以根据规则配置这些业务。路由系统在分发时会优先根据这些规则分发。
4. 自适应规则分配：分布式系统根据自适应机制通过任务的类型及执行时间等统计信息自动地将任务分发到合适的Driver上执行。
路由系统自适应规则技术

静态的任务分配规则可以适用一部分场景，在复杂场景下静态的策略往往不能很好地根据集群状态及特点将任务负载到不同的编译执行端上。我们需要设计一种自适应的任务调度机制，这个机制主要分为两个阶段：任务信息特征采集阶段、动态信息特征维护及自适应任务分发阶段。

在第一个阶段里，路由系统依然会根据静态或自定义规则进行任务分发，但同时会采集一些诸如任务执行时间、任务使用存储特点、任务切分机制、任务资源占用特点等信息特征并保存在系统里；在有了这些信息后路由系统会建立一个任务特点分类到路由端的映射。

在第二个阶段，路由系统对来源的查询任务会先用这些信息进行一些分类，将任务归类在一个具体的类别里。而每一个特点类别会有一个较优的执行端列表，路由系统会先从这个列表中选择对应的路由端。系统在持续地运行过程中，特点分类会像第一阶段一样动态采样获取特点，并更新特点分类映射。同时每个特点的对应执行端列表也会根据负载以及对应特点进行持续更新。
分布式子任务存储局部性识别技术

在性能线性扩展的目标下，使分布式子任务在集群中执行时可以达到优化的执行性能是一个关键指标。子任务需要能充分利用存储的信息。假定子任务A需要读取分布式文件F，同时F位于集群的h1, h2, h3节点上。那么当子任务分配在这三个节点时，能最大化存储读取性能，最终可以使子任务达到最好的IO性能。为了实现这个机制，存储系统需要将文件访问或资源访问的运行时局部性信息（分布式资源可能根据集群规模动态调整位置）传递给分布式计算系统，分布式计算信息再获取这些信息后统筹地对所有分布式子任务进行局域性计算，从而尽可能地使所有任务都在局部性较好的节点进行任务执行从而保证了整体任务的性能。
分布式子任务增量分发机制

系统在将子任务调度到具体节点执行时需要把子任务的上下文信息序列化的二进制状态通过网络传递到执行器中。当任务内容较为复杂时，该上下文信息的二进制大小将达到较大规模。随着集群规模扩展，也许该上下文信息的传递将对整个任务的执行带来较大的性能影响，阻碍系统的线性扩展。因此，我们需要设计一种增量任务分发机制。该机制将充分利用了任务相似性的特征，针对相似的任务，该机制可以将不同任务的相同上下文部分提取出来，并在集群中进行一次性的基础内容传播；在此之后的子任务只需要传播基于这个基础内容的增量内容，而增量内容一般是极小的。这样可以有效地将子任务大小限制在合理区间内，当集群规模扩展时传播子任务的上下文信息将是短暂地，不会对真正的任务执行带来实质的性能影响。
分布式子任务自适应切分机制

分布式子任务的切分对于性能扩展是一个关键因素。当任务切分过大时，会使得单个任务执行时间过长；而当任务切分过小时，查询任务的子任务总数将达到过大的数量，任务传播开销，任务调度开销等分布式系统性开销将成为执行时间的重要部分，导致最终的任务资源使用超过预期。我们需要设计一种自适应的分布式子任务切分机制。在该机制下，主要分为两种切分机制：1. 直接读取存储任务的自适应机制， 2. 中间计算任务的自适应机制。第一种自适应机制主要针对直接从存储读取数据的任务，在这种任务的子任务切分过程中，将充分利用存储的能力，把查询分析任务的过滤信息精确地翻译给存储开销模型，然后该模型给出较为准确的存储资源开销；在获得这个开销信息后，分布式系统可以集群规模以及集群负载，并综合考虑存储的访问粒度再进行子任务切分。第二种自适应机制时针对计算的中间阶段的子任务。这些子任务读取中间临时数据，并将数据直接写成下一阶段的临时数据或者直接写成临时结果。在这个阶段，分布式系统可以获得每个阶段所有执行任务的准确的输出大小以及需要的其它统计信息；分布式编译执行端在获得这些信息将动态地对下一阶段子任务进行切分分配。在这两种机制的保证下，每一阶段的子任务分配都可以尽可能地利用所有系统运行时信息，做出优质的子任务分配促成最后的总任务性能。

主要创新点如下：
- 多层次的分布式计算线性扩展技术
- 充分利用运行时计算系统、存储系统信息进行分布式任务分发
多模态数据分布式计算优化技术

针对海量数据分布式计算需求，通过堆外内存技术关键技术解决了大规模数据计算稳定性问题，通过算子下推方法将分布式计算任务下推到各分布式服务节点中做本地的数据预处理计算，避免大量网络数据传输（shuffle）带来的性能损耗，实现了数据批量计算的高性能，采用堆外内存技术，解决了大规模数据计算稳定性问题，满足分布式计算引擎海量存储计算的要求。
- 优化信息下压机制
  
  在对不同存储进行查询时，除了最基本的读接口，根据不同存储特点，存储自身有很多优势特点需要充分利用起来。因此，在多引擎实现过程中，对于优化信息的反馈机制也非常关键。
  
  首先，在SQL编译之后，我们可以将SQL中的查询信息尽量多的解析出来下压给存储进行分析。例如HBase底层支持按照Rowkey的快速检索，则需要将SQL中的Filter条件识别为HBase的Rowkey条件，下压到存储中进行按照Rowkey的快速检索。再比如Elastic Search底层支持快速聚合，其底层存储的聚合操作效率比上层计算执行引擎执行效率高，这时候则可以将SQL中的聚合（GroupBy）信息下压到ElasticSearch中，生成出对应的聚合操作，在读取时提前进行聚合操作。
  
  另一方面，对于上述从SQL中解析出来的信息，并不一定所有存储都能识别，例如ElasticSearch中支持地理信息类型，但是HBase中并不支持。在这种情形下，存储必须将自己能否使用某些优化的信息反馈给计算执行引擎，这样，计算执行引擎可以根据存储的优化信息反馈调整自己的执行计划。只有有效的实现了优化信息下压机制，才能保证同一个多引擎能够充分利用各个存储的优势功能。
- 堆外内存技术
  
  内存计算默认将内存数据集存储在JVM的堆存储空间中，这样可以避免Java对象序列化或输出JVM堆的性能开销。然而，当分布式计算数据量巨大，计算占用的堆存储太大时，JVM的垃圾回收机制（GC）在扫描整个JVM堆存储中的Java对象并频繁回收空间时，会对系统整体的搜索性能产生很大影响。本方案采用堆外内存技术提高系统的健壮性，避免了GC问题对系统的影响，从而提升了海量数据的计算稳定性和单机的数据存储能力。
- 基于SSD的计算加速技术
  
  SSD硬件的读写性能比普通SATA磁盘高一个量级，设计存储格式充分使用硬件IO提升加速数据的读写性能,并基于该优势专门设计了块索引，当过滤数据时，可以快速跳过未命中的数据块，极大地提升访问效率，并且大大减少磁盘IO,实现批量数据计算加速。

技术解决途径如下：

① 算子下推技术

为满足用户对于不同数据高性能计算的需求，需要对于计算引擎的计算任务信息进行完整表达给底层不同的存储，以提供更大的可优化空间。

谓词逻辑优化信息下推

谓词逻辑下推是非常重要的一块，合理以及完整的谓词逻辑下推，可以使得存储能够充分利用自己的存储特点，如hbase的kv索引，elasticsearch的倒排索引，这样可以大大提升检索的效率。中间层需要对中间的谓词逻辑实现统一、清晰的表达，这样有利于底层不同存储对于其能够简单完整的进行识别并翻译成自身可实现的谓词逻辑。同时，中间层还会给计算引擎提供合适的谓词条件下推反馈。如存储是否支持当前的谓词逻辑下推，谓词逻辑是否能由存储完整且无误地完成。这些信息有助于计算引擎根据存储行为来调整自身的执行计划以及逻辑，从而进一步优化整体执行。谓词逻辑下推以及相关反馈的设计如下：

中间层将计算引擎的谓词逻辑表达转换成更简单且清晰的逻辑表示。

中间层针对第一次转换过后的过滤条件进行第一次优化，并完整保留原先语义，主要包含以下两点：将可以合并的谓词逻辑进行合并，简化表述；识别确认会产生冲突的谓词逻辑，优化数据读取，即返回空集。

中间层在数据读取的时候将生成的对应谓词逻辑下推给对应存储进行识别。

存储判断是否可以处理对应的谓词逻辑，这里接口设计为两种语义：可以完整处理、可以部分处理。存储将对每个谓词逻辑进行判断，并返回自己可实现的下推逻辑。

中间层根据存储反馈结果决定真正下推给存储的谓词逻辑，这里保证存储只会得到自己能够处理的谓词逻辑。

中间层在将存储可实现的谓词逻辑下推给存储的同时，还会收集一下信息返回给计算层，用以优化计算逻辑：
1. 存储是否能完整实现所有谓词逻辑，是否可在计算引擎直接跳过过滤计算；
2. 存储是否能完整实现所有谓词逻辑，上层计算是否能够将聚合计算下压，由存储实现聚合信息的计算；
3. 存储可根据自身实际情况结合下压的谓词逻辑，实现中间层过滤率计算相关的接口。这样计算层可以获取真实的过滤率相关数据。用以CBO（基于代价的优化模型）计算以及优化。
聚合优化信息下推设计

聚合逻辑下推以及相关的反馈设计如下：
- 中间层识别计算引擎聚合相关逻辑，判断是否可分布式处理。
- 中间层将聚合相关逻辑翻译成通用且清晰表示（如分别表示聚合的列信息，需要实现的聚合逻辑）。
- 中间层在底层存储能够完整实现所有谓词逻辑时，将相关的聚合逻辑下压给存储（可参考前一段对于谓词逻辑下压的描述，这里只有当所有的谓词逻辑都能被正确计算时，聚合逻辑的下压才能保证正确性）。
- 底层存储通过实现相应接口，返回是否能够处理聚合下压逻辑。
- 中间层根据存储的反馈决定是否将聚合逻辑下压至存储。
- 最后当聚合逻辑下压时，中间层将存储反馈告知计算层，计算引擎则以此决定是否进行自身执行计划的修改（跳过shuffle前的聚合步骤）。
其他优化信息下推设计

排序相关的反馈信息。由于不同存储的特性（如不同设计的索引），部分存储可以以较小的代价，在返回数据时，直接将排序/部分排序完成的数据返回给上层计算。而上层计算则可以根据存储返回的这些信息来选择更加合适的排序策略和算法。

索引相关信息。由于不同存储的索引设计不同（如hbase的kv，elasticsearch的倒排，全局/部分索引）这些索引的使用场景以及相应的代价也会存在差别。底层存储可通过中间层的相关接口返回自身的索引信息（如哪些列存在索引，每一列索引的搜索代价等），这些反馈的信息可以有效地帮助计算引擎优化执行的逻辑（如在CBO中可以根据不同索引的代价，决定读表的先后顺序即join的顺序等）。

表级以及列级的统计信息。不同存储在自身的元信息或者数据文件中可能会存储一些统计信息（如单个文件的行数，单列的最大最小值等）。而这些统计信息，可以经由中间层的统计信息获取接口返回给上层计算引擎，上层计算引擎则可以根据这些信息调整执行计划，提升执行效率。（如在CBO中，优化器可以根据这些不同的统计信息，调整多个表join的先后顺序）相比于传统的由计算引擎预先统计来获取统计信息的方式，存储通过中间层反馈给计算引擎的方式更能有效地利用存储的特性。并且相较于传统的统计算法，由各个存储直接返回的方式提升了数据的准确性。

② 堆外内存技术

内存计算管理模块基于分布式内存计算设计，内存计算默认将内存数据集存储在JVM的堆存储空间中，这样可以避免Java对象序列化或输出JVM堆的性能开销。然而，当搜索计算数据量大，搜索计算占用的堆存储太大时，JVM的垃圾回收机制（GC）在扫描整个JVM堆存储中的Java对象并频繁回收空间时，会对系统整体的搜索性能产生很大影响。主要原因是Java为了给新对象挪出空间而剔除旧的对象之前，需要跟踪扫描所有的Java对象找到那些不再被使用的对象。这可能会造成扫描和释放大量的内存数据集对象，甚至好几十GB的存储空间。这种GC问题在多个任务共同运行的干扰之下影响更严重。这种长时间的GC过程是应用开发程序员层面难以控制和解决的，这对于使用计算引擎进行大规模数据计算不利，而且会大大降低计算引擎的运行性能。

采用堆外内存优化技术能够有效避免上述问题，如上图所示。堆外内存优化技术是把内存对象分配在Java虚拟机的堆以外的内存，这些内存直接受操作系统管理（而不是虚拟机），这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。使用堆外内存拥有以下优势：

减少了垃圾回收
加快了复制的速度
通过堆外缓存引擎提升单机数据存储能力

③ 基于SSD计算加速技术

数据计算的IO 有4种类型：连续读，随机读，随机写和连续写，连续读写的IO size 通常比较大（128KB-1MB），主要衡量吞吐量，而随机读写的IO size比较小(小于 8KB)，主要衡量 IOPS 和响应时间。数据库中的全表扫描是连续读 IO，索引访问则是典型的随机读 IO，日志文件是连续写 IO，而数据文件则是随机写 IO。

SSD 的 IO 特点分析：

随机读能力非常好，连续读性能一般，但比普通 SAS 磁盘好；
不存在磁盘寻道的延迟时间，随机写和连续写响应延迟差异不大；
erase-before-write 特性，造成写入放大，影响写入的性能；
写磨损特性，采用 wear leveling 算法延长寿命，但同时会影响读的性能；
读和写的 IO 响应延迟不对等（读要大大好于写），而普通磁盘读和写的 IO 响应延迟差异很小；
连续写比随机写性能好，比如 1M 顺序写比 128 个 8K 的随机写要好很多，因为随即写会带来大量的擦除。

基于SSD上述特性，如果将数据全部放在SSD 上，可能会有以下的问题：

日志文件 sequential logging 会反复擦写同一位置，虽然有损耗均衡算法，但是长时间写入依然会导致性能下降；
数据文件in place update 会产生大量的随机写入，erase-before-write 会产生写入放大；
数据库读写混合型应用，存在大量的随机写入，同时会影响读的性能，产生大量的 IO 延迟。

基于SSD优化就是解决 erase-before-write 产生的写入放大的问题，不同类型的 IO 分离，减少写操作带来的性能影响。

将 sequential logging 修改为 In-page logging，避免对相同位置的反复擦写；通过缓存写入的方式将大量的 in-place update 随机写入合并为少量顺序写入；利用 SSD 随机读写能力高的特点，减少写增加读，从而达到整体性能的提升。主要创新点如下：

（1）建立基于多存储引擎的连接器StarGate 针对多存储引擎的差异性问题，提出StarGate多存储引擎连接器，能够屏蔽底层存储引擎的差异对计算引擎的影响，提高计算引擎的通用性，同时提高数据库对新存储引擎的兼容性，即只需要开发相应连接驱动就可接入新存储引擎。

（2）建立基于多存储引擎的统一SQL编译模型针对多存储引擎对接单一SQL编译器时，编译器稳定性低、维护性差的问题，重新改写SQL编译器，实现多存储引擎的统一SQL编译。

（3）提出面向多存储引擎的信息下压反馈算法针对异构存储引擎操作数据时，因查询、索引、算子执行规则不同而导致使用壁垒的问题，研究并提出面向多存储引擎的信息下压反馈算法，在融合各存储引擎优势基础上，实现多存储引擎统一管理。算子下压技术通过本地预处理减少参与引擎层计算的数据，减少IO从而提升整体性能。

（4）建立统一的计算调度框架，支撑混合负载调度面向大数据的多存储引擎数据库在支撑多种存储负载的同时，也意味着面对不同的作业类型的混合负载，如轻量级的短查询作业、重量级的全量数据跑批计算等。建立统一的多任务执行、多层次调度计算框架，实现整体资源利用率的优化，提升数据库整体作业吞吐量。

管理组件

Transwarp Audit，大数据平台安全审计软件

Transwarp Audit 面向 Inceptor 中对数据的操作和权限进行合理布控和监测，整合大数据平台各节点中的监控信息，实现对数据访问和操作的集中监控、查看和管理的智能化、可视化审计。 Audit 支持对各类审计事件做出快速、准确的定位，并进行过滤和归并，实现集中、综合的展现。

Transwarp Guardian，大数据安全管理软件

星环科技提供的安全管理组件 Transwarp Guardian ，从用户认证、服务资源授权以及配额管理三方面为客户的业务逻辑、数据资产提供了全面的安全保障。用户认证使用 LDAP，Kerberos 等协议保证只有经过身份甄别的用户才能访问系统，授权保证只有被赋予权限的用户才可以访问服务资源，而配额管理控制用户允许使用的资源大小，三个部分一同保证了平台大数据的安全。

Transwarp Aquila，智能运维分析平台软件

Transwarp Aquila 作为一站式综合运维平台, 提供监控仪表盘、告警通知、日志生命周期管理、日志检索、审计日志等功能。同时，Aquila 还预置了基础监控、大数据监控、PaaS 层监控等多维度的监控资源，能做到整个 Inceptor 产品各个维度的开箱即用的一键运维。

Transwarp Manager，大数据管理软件

Transwarp Manager 是负责配置、管理和运维 Inceptor 集群的图形化工具。用户只需通过几个手动步骤，就可以在 x86、ARM、MIPS 等各架构服务器或基于 Docker 的云端平台上完成集群部署，并且提供告警、健康检测、监控和度量等运维服务。用户可以实时的浏览各服务的状态，并且在告警出现时采取恰当的措施以处理应对。此外， Manager 还提供了一些便捷的运维功能，例如磁盘管理、软件升级和服务迁移等。

Transwarp Cloud Operating System，云原生操作系统

TCOS 是星环自主研发的云原生操作系统，提供统一的资源调度框架，通过容器化编排，能够统一调度计算、存储、网络等各基础资源，TCOS 支持主流国产操作系统、国产服务器，并且支持混合部署，满足国产化部署需求。