在本期《openGemini兼容普罗生态，云原生可观测性新势力》的主题直播中，华为云开源DTSE技术布道师&openGemini内核研发工程师寒雪，通过介绍openGemini的整体框架和计算性能的关键技术，让大家了解了openGemini兼容Prometheus API和算子的同时如何实现更优的性能和更低的存储成本，希望通过本次直播能使开发者们获益良多。

什么是云原生可观测性？

2017年，Matt Stine 将云原生特征归纳为六大点：

• 模块化 Modularity

• 可观测性 Observability

• 可部署性 Deployability

• 可测试性 Testability

• 可处理性 Disposability

• 可替换性 Replaceability

什么是可观测性呢？它是从传统监控发展而来的概念，指系统可以由其外部输出推断其内部状态的程度，这里有两个方面的关键词，一个是系统有哪些外部输出，另一个是需要推断什么程度的内部状态。那么上面这幅图就是将外部输出归纳为三个方向，这个图也是可观测性三大支柱的经典图。包括指标metric、日志logging以及调用链tracing。metric主要是对系统底层基础资源运行状态的监控指标的统计，通过多维的聚合分析来帮助在某些指标达到风险阈值时发出预警，监控和可视化系统健康状态等。Logging是应用运行时持续输出的日志数据，通过这些日志可以帮助分析系统的关键事件，梳理系统行为。Tracing是记录系统中某个事件生命周期内的调用链路，帮助根因定位，分析系统故障点。并且这三个维度的数据并不是相互独立的，往往会有一定的重叠，并且可以互相组合的方式来提供丰富的可观测性能力。
那么基于上述这三个维度发展可观测性有什么意义呢？它为云原生系统带来什么好处呢？

云原生可观测性的意义：

• 提升系统稳定性：快速发现和解决系统问题

• 优化性能：可观测性深入的洞察力帮助识别性能瓶颈

• 降低运维成本：通过自动化和智能化的监控，减少人工干预

• 支持快速迭代：云原生应用的快速迭代需要快速响应和处理问题

• 提高安全性：可观测性通过监控和分析安全日志，帮助识别和响应安全威胁

云原生时代来临，可观测性数据的存储和分析成为挑战

接下来我们针对指标数据来具体分析业务数据特征，在存储和分析层面会具有什么样的挑战。

首先一条简单的指标数据一般由几个最重要的部分组成，比如这样一条设备监控指标，它包括多个监控指标，也就是这里的field字段列包括信号路线状态、设备运行状态、错误码、总运行时间等，还有指标采集时间time时间列，以及采集对象的一些属性比如这里tag列包括设备编码、产品编码。可以认为field列是随时间变化的，tag是不随时间变化的。监控数据从云端采集到可观测性平台，包括指标，日志和调用链。

可以看到单独针对指标进行存储和分析的产品是比较多的，其中使用最广泛的就是普罗。采集到的指标一般存储模型为典型的时序数据模型，在云原生场景下容器多，监控对象多，写入的并发大，并且单个指标具有明显的时间属性，某些分析业务可能会要求保存较久的数据，因此数据量也比较大，比如华为云上某个业务可能每天就会产生20TB的指标数据，80TB的日志数据，这些数据往往具备一个时效性，数据往往可以周期性地过期淘汰，并且在生成环境中数据是持续不断的产生的。

那么针对这些数据我们可以用于哪些分析场景呢，比如我们需要利用系统的资源指标来做监控告警和异常检测，帮助运维人员早点发现问题，还有就是为快速分析问题、根因定位提供方向。这些业务场景具有的一些共同特点，主要是以下几点：

• 它不会对数据进行更新和删除

• 对于近期数据更关注，对于历史数据关注较低

• 以时间范围的聚合查询为主

• 对查询响应速度要求较高，需提供灵敏的监控能力

Prometheus技术生态活跃，它的优势与劣势是什么？

目前Prometheus在企业实际的监控平台中应用最广泛。它具备这几点优势：

• 完整的指标数据模型：每一条时间序列由指标名(metrics name)以及一组标签(labels)组成

• 强大的查询能力：灵活的查询语言PromQL帮助用户查询指标数据

• 易于集成：基于golang开发，多平台兼容，使用起来快速、友好

• 对云原生友好：对Kubernetes的深度支持，灵活的服务发现机制帮助有效地监控大规模kubernets集群

• 多样的客户端库：多种编程语言的客户端库，方便开发者在应用程序中嵌入监控代码

• 可视化和集成：可与Grafana等数据可视化工具集成，提供丰富的图表和仪表盘，帮助用户直观地理解监控数据

• 高可用性解决方案：Cortex和Thanos等社区高可用解决方案，助力大规模监控数据

然而Prometheus受限其技术架构设计，处理海量数据存在性能瓶颈，可能会出现以下的问题：

• 单线程处理：PromQL 的计算是单线程的，这在高负载情况下可能导致性能瓶颈，特别是在所有block都被覆盖的时间范围查询时。

• 数据持久性问题：TSDB存储层避免长时间运行后数据量过大的情况会在一定时间后删除部分就block的数据，数据长期持久性无法保证。

Prometheus和openGemini如何达成1+1>2

openGemini作为一款可观测性底座，兼容Prometheus API和算子，可以充分发挥其技术优势，在海量指标数据分析的场景下进一步带来更加高效、低成本的产品。它拥有诸多技术优势比如说：

1. 弹性可扩展，支持数百节点规模和PB级数据存储

2. 列式存储，不同数据类型采用专用压缩算法

3. 灵活部署，编译无需外部依赖

4. 亚秒级数据查询响应，向量化执行引擎，多种计算优化

5. 绝大部分应用可实现无缝对接

在介绍openGemini执行promql的关键优化技术之前，我们先了解一下openGemini的整体框架和数据分区方式。

openGemini的整体框架主要分为四个部分，包括支持的接口协议，绿色部分是已经支持的协议，比如数据行写入协议，influxql查询。黄色部分是新版本增加和优化的部分，接口层就包括新兼容的prom写入api和查询的promql。计算层主要对解析查询语句，生成执行计划，包括之前就有的解析和优化器，向量化执行引擎、各种物理算子的实现等。

最近新增了一个语法转换器将promql语法转化为influxql语法，从而后续可以基于influxql的语法结构使用解析与优化器、执行引擎等模块。这些模块一定程度上增加了适配prom的修改，比如物理执行算子增加了一些prom查询专用的算子。存储引擎我们目前一共有时序和列存两种存储引擎，prom数据现在只能使用时序引擎，后续社区会考虑是否适配列存引擎来支持普罗指标数据的高基数场景。

上图是openGemini数据的分区方式，考虑到指标数据的时序特点和数据打散均匀性，所以采用两个维度对数据进行分区，一个是基于时间的范围分区，一个是基于分区键的hash分区，在不指定分区键的情况下默认采用指标表和标签时间线来做为分区键。时间维度得到的所有分区也就是shard称为一个shardgroup，这里一共产生了两个shardgroup，按照分区键维度得到的所有shard称为一个partition，这里一共产生6个parttition。假设集群一共有三个节点，每个节点上为两个partition，那么每个节点上就有了4个shard分区，在数据查询和写入时可能会使用到这些概念。

openGemini的计算性能关键技术

接下来重点介绍一下openGemini计算执行中的一些关键技术，它能够给promql带来的计算优势。

• 联合计算下推：将计算任务尽可能地推送到数据源端进行处理，减少网络传输，利用数据源端的计算资源平衡计算负载

• 分层并行计算：查询在顶层被分解为多个并行执行的子任务，每个子任务独立地执行部分查询，最终收集汇总形成查询结果

• 向量化批量计算：将数据组织成有序的向量或数组，发挥SIMD（单执行多数据）的优势批量处理数据，提高数据处理效率

AOM云原生监控业务测试模型

接下来通过一个真实的业务场景，构造大量的测试数据来验证openGemini相对于普罗一些开源分布式方案的性能优势，这里选用的是华为云原生监控业务的部分场景。本测试旨在针对该业务场景做充分的性能验证，并与Cortex进行对比。

AOM（Application Operations Management）：华为云一站式应用运维管理平台，实时监控用户应用和相关云资源。
测试工具：
Inch：Influxdb开源测试工具，使用Inch生成符合业务模型的千万级时间线数据
Jmeter：使用开源压力测试工具Jmeter测试读写性能
如AOM仪表盘查询语句测试用例可以分为如下几类：

这里挑选了部分用例的结果来进行展示，一共有5类查询，包括全量聚合、部分时间线的分组聚合、分组聚合后求topk、短时间区间的分组聚合和长时间区间的分组聚合。

从测试结果来看，openGemini的qps在绝大部分场景都优于cortex，特别是随着查询时间范围的增加，openGemini的性能增长非常显著。在1天的范围下，综合查询性能更是比cortex提升近1000倍。

• 1h区间综合查询性能比cortex提升20%-100%

• 6h区间综合查询性能比cortex提升250%-350%

• 1d区间综合查询性能比cortex提升900%-1000%

版本新特性抢先了解

最后，简单为大家介绍一下openGemini新版本的两个重要特性，数据多副本和备份恢复。

1、 数据多副本

数据多副本提供了openGemini原生的高可用性，使用多副本功能需要先修改集群配置为replication，副本模式。根据业务和资源情况调整单节点的dbpt数，默认推荐设置为2。配置完成之后重启集群就可创建副本db，创建db时在后边加上副本关键字和希望创建的副本数。副本数据分布的粒度是partition，比如之前两级分区的架构，一共三个节点每个节点上分布两个partition，如果db是创建的三副本，那么为了保证副本分布尽量均衡，patition1 3 5会称为一个副本组，partition2 4 6为一个副本组。

2、 数据备份恢复

接下来介绍一下数据的备份恢复，包括备份和恢复两个阶段。

1) 数据备份向计算引擎发起备份命令

Http POST debug/ctrl?mod=backup

重要参数说明：

isInc=<bool>：false表示全量备份；true表示增量备份

backupPath=<string>：备份路径

isNode=<bool>：设置是否只备份当前节点数据

2) openGemini提供独立的数据恢复工具用于将备份数据恢复到之前的状态。在恢复时，在每个节点上都需要单独执行ts-recover命令恢复数据。
>ts-recover [flags]

重要参数说明：
config： openGemini配置文件路径
recoverMode：数据恢复策略，1表示全量+增量的数据恢复，2表示全量数据恢复
fullBackupDataPath：全量备份目录地址
incBackupDataPath：增量备份目录地址

社区合作&共建计划：开放合作、携手创新、共同发展

社区已开启共建计划，欢迎高校、研究机构、开源社区、企业以及个人参与到openGemini社区共建中来。共建的方式十分开放，开发者可以在社区的协助下完成特性开发，也能向社区提出解决方案，或者联合社区做一些技术创新，社区十分鼓励跨领域跨行业的项目合作，包括但不限于分布式系统、软硬件协同、数据压缩、aifordb/dbforai等等。最终，社区希望建立一个开放治理的社区，联合伙伴成立社区技术委员会，负责社区技术线路和重大事件的决策。

社区人才培养计划：助力个人成长，培养新一代数据库人才

在人才培养方面，社区也在执行切实有效的培养计划。社区会为开发者提供技术培训，导师制度等为成员赋能。

人才培养目标：

• 培养对数据库技术有深刻理解的专业人才

• 为社区成员提供成长和发展的机会

如感兴趣可下载申请表并提交：从社区 Community 仓库下载申请表 openGemini-Application.docx

本次分享已结束，欢迎大家试用openGemini时序数据库，加入社区共建计划。

openGemini开源地址：https://github.com/openGemini

openGemini官网地址：https://opengemini.org

openGemini是一款开源分布式时序数据库，主要聚焦于海量时序数据的存储和分析，通过技术创新，简化业务系统架构，降低存储成本，提升时序数据的存储和分析效率。