当前位置：
  1. 首页
  2. 互联网
  3. 正文
本文介绍: SelectDB 助力观测云完成日志数据存储和分析架构升级，实现整体性价比 10 倍提升，为日志存储和分析场景服务提供强大动力。

作者：观测云 CEO 蒋烁淼 & 飞轮科技技术团队

在云计算逐渐成熟的当下，越来越多的企业开始将业务迁移到云端，传统的监控和故障排查方法已经无法满足企业的需求。而观测云可提供整体数据的分析、洞察、可视化、自动化、监测告警、智能巡查、安全巡查等服务。为更好提供上述服务，要求观测云能够统一整合来自多个场景和多种结构的海量数据，并提供全面的日志检索分析能力，快速实现数据查询、筛选和分析。

因此，飞轮科技与观测云进行了全面合作。通过 SelectDB 的倒排索引能力、Variant 数据类型、冷热数据分层存储等特性，为观测云日志存储和分析场景服务注入强大的动力，实现存储成本降低 70% 的同时，查询性能提升 2-4 倍，最终实现整体性价比 10 倍提升！

GuanceDB 原有架构

观测云-原有架构.PNG

观测云具备强大的数据接入能力，通过自研的 All In One 采集工具 DataKit 可以从不同端侧、业务层、中间件、基础设施等不同层获取数据，同时进行预处理和元信息关联。除了广泛支持日志数据以外，Datakit 还支持采集和处理基础设施的时序指标、链路追踪、安全事件以及在 APP 端或浏览器端的用户行为数据等。为了满足多元化的多场景需求，DataKit 不仅对开源探针和采集器进行了全面兼容，还支持对自定义格式的数据源接入。

DataKit 采集的数据，经过核心计算层处理后，会统一存储到 GuanceDB 中。GuanceDB 是一个观测云自主研发的由多种数据库技术组成的多模态数据库。

观测云-原有架构2.png

GuanceDB 的内部架构如上图所示，主要包含查询引擎 Query Engine 和存储引擎 Storage Engine 两层。在逻辑结构上查询引擎与存储引擎通过抽象解耦，整体架构上实现了可拔插可替换。

观测云基于 VictoriaMetrics 存储模块研发了时序存储引擎 Metric Store，同时在泛日志场景集成了 Elasticsearch/OpenSearch。这样的设计使 GuanceDB 对外有统一的写入和查询接口，能适应不同类型的数据格式和业务需求。在当前的实现中，MetricStore 已经具备卓越的性能。然而，对于日志类和用户行为类数据的处理来说，Elasticsearch 却有诸多不足，具体表现如下：

选型目标及调研

原有架构中 Elasticsearch 存在的问题推动我们对架构进行升级，在升级之前，我们调研了包括 SelectDB 在内的多款数据库。结合实际可观测性场景，我们选型目标如下：

综合来看，SelectDB 能够满足观测云的大部分需求，并且在与同类产品的对比中表现出色，我们也会在后面的章节中详细介绍基于 SelectDB 的改造实践。特别值得一提的是，在前期调研中，以下特性是吸引我们的重要特性：

基于 SelectDB 的存储架构升级

因此我们引入 SelectDB 对 GuanceDB 内部架构进行升级，为了更好地介绍 SelectDB 如何在 GunaceDB 中作为存储引擎发挥作用，我们首先介绍一下 DQL 查询语言。

在可观测性场景中，几乎所有的查询都涉及时间的筛选，同时大部分的聚合也需要按照时间窗口来进行，并且针对时间序列，还需要支持按单个序列在时间窗口前后进行 Rollup。在这些场景中，使用 SQL 来表达相同的语义就需要嵌套多层子查询，导致表达过程和编写都异常复杂。

因此我们尝试简化语法元素，在此基础上设计出了新的查询语言 DQL，并且增强了在可观测场景下的常见计算函数，通过 DQL 即可查询指标、日志、链路追踪、对象等所有的可观测数据。

从 GuanceDB 内部结构来看，本次升级我们使用 SelectDB 替换了 Elasticsearch/OpenSearch，原有的查询架构保持不变。

观测云-架构升级.png

接下来我们介绍在引入 SelectDB 之后，DQL 查询是如何工作的：

观测云-架构升级2.png

如上图所示，Guance-Insert 是数据写入组件，Guance-Select 是 DQL 查询引擎。

当前的查询架构是综合 FE 和 BE 能力的混合计算架构，DQL 即可以利用 SelectDB 已经充分优化的查询能力，也可以让语法拓展不受 SelectDB 本身 SQL 能力的限制。

架构升级的收益

01 存储成本降低约 70%、查询性能提升 3 倍

SelectDB 的引入，实现了综合成本的大幅降低。之前我们在云上某可用区使用的是由 20 台 16C 64G 云主机组成的 Elasticsearch 集群提供查询服务，同时采用了独立的索引写入服务（相当于使用 20 台云主机）。在替换成 SelectDB 之后，只需要 13 台同配置的云主机，总成本下降了 67%。成本的大幅降低主要得益于两个因素：

观测云-写入速度.png

观测云- BE占用CPU.png

SelectDB 的引入，实现了查询性能显著提升。在减少机器数量以后，我们对比了相同的查询在两个集群下的性能，实践表明 SelectDB 的点查和列表查询速度比 Elasticsearch 快近 2 倍，在聚合查询不进行采样的情况下，SelectDB 相比 Elasticsearch 快将近 4 倍。

综上，采用 SelectDB 替换 Elasticsearch 后，仅使用 Elasticsearch 的 1/3 成本、获得 2～4 倍的性能提升，整体性价比提升了近 10 倍！

02 倒排索引满足日志场景全文检索需求

倒排索引能够显著提升全文检索的性能并降低查询的资源开销，是实现高效日志分析的必备能力。SelectDB 支持倒排索引，以下是我们从 Elasticsearch 迁移到 SelectDB 过程中关键能力的介绍：

CREATE TABLE httplog
(
  `ts` DATETIME,
  `clientip` VARCHAR(20),
  `request` TEXT,
  INDEX idx_ip (`clientip`) USING INVERTED, --不分词
  INDEX idx_req (`request`) USING INVERTED PROPERTIES("parser" = "chinese") --中文分词
)
DUPLICATE KEY(`ts`)
...

-- 查询clientip为'8.8.8.8'的最新10条数据
SELECT * FROM httplog WHERE clientip = '8.8.8.8' ORDER BY ts DESC LIMIT 10;
-- 检索request字段中有error或者404的最新10条数据
SELECT * FROM httplog WHERE request MATCH_ANY 'error 404' ORDER BY ts DESC LIMIT 10;
-- 检索request字段中有image和faq的最新10条数据
SELECT * FROM httplog WHERE request MATCH_ALL 'image faq' ORDER BY ts DESC LIMIT 10;
-- 检索request字段中有'查询错误'词组的最新10条数据
SELECT * FROM httplog WHERE request MATCH_PHRASE '查询错误' ORDER BY ts DESC LIMIT 10;

除了在功能上能够满足日志全文检索的需求，SelectDB 倒排索引还支持在线按需增减索引。Elasticsearch 索引在创建时是固定的，后续无法新增索引字段，这就需要提前规划哪些字段需要建立索引，后续如需变更索引则需要重写，变更成本非常高。SelectDB 支持在运行过程中按需增加索引，新写入的数据索引立即生效。同时 SelectDB 可以控制对哪些分区创建索引，使用起来非常灵活。

03 Variant 数据类型，解决数据 Schema 频繁变化痛点

在可观测场景中，数据的种类繁多且变化频繁。例如我们在收集用户在网页上的每一次点击、每一次导入等行为时，都可能会追加新的业务指标，这样的场景对数据库的 Schema 变更实时性提出了更高的要求。

在常见的数据库中，大部分数据表的 Schema 是静态的，也有一些数据库如 Elasticsearch 可以通过 Mapping 实现动态 Schema。然而，动态 Schema 可能会遇到字段类型冲突或因历史字段不失效而导致字段数量达到上限的问题。在引入 SelectDB 之后，我们使用最新特性 Variant 动态数据类型（该特性将在 Apache Doris 2.1 版本中正式发布）可以很好地支持这类场景。

SelectDB 针对半结构化数据设计了 Variant 数据类型，具备以下特色能力：

  • 支持任何合法的 JSON 数据存储在 Variant 类型的列中，并且能够自动识别 JSON 中的子字段和类型。
  • Variant 数据类型可以避免字段过多导致的 Schema 爆炸问题。对于频繁出现的子字段，Variant 类型采用列式存储方式，以提高数据存储和分析的效率。而对于不频繁出现的子字段，Variant 类型则会将其合并为一列进行存储，以避免列的数量过大。
  • Variant 数据类型可以避免业务变更字段类型冲突无法写入的问题。Variant 允许一个字段存在不同的类型，并采用不同的存储方式，对新老数据采用不同的类型存储，对于新老交替的混合部分采用最小公共类型存储。

Variant 类型与 Elasticsearch Dynamic Mapping 最显著区别在于，Dynamic Mapping 的作用域是当前表的完整生命周期，而 Variant 的作用域只在当前的动态分区内。这个差异化的设计使得 Variant 列可以随着业务数据写入的变化而周期性失效，从而降低类型冲突的概率。例如，当我们今天变更了业务逻辑代码，并对部分业务字段进行了重命名，那么旧的字段名将不会出现在明天的 Variant 列中。因此，我们可以认为 Variant 只维护了最新数据的类型数据。

另外当单个分区内的字段类型冲突时会升级到 JSON 数据类型，从而避免出现数据错误和数据丢失的问题。例如业务系统中有两处都用到了 status 字段，其中一处为字符串，一处为数字，那么我们在查询时可以根据实际的语义来选择当前查询需要的是字符串、数字或二者都要。（假设在筛选条件中写 status = "ok"，此时就只会筛选 status 类型为字符串的数据。)

使用 Variant 数据类型后，在实际的写入和查询中，用户都无需感知 Variant 的存在。用户可以根据自身的业务需求增删字段，就如同使用普通列一样。在进行查询时，也无需额外的语法或注解，只需要将其当成普通列进行运算即可。

在当前版本中，Variant 数据类型在使用时还需要额外的类型断言，自动的类型断言将在后续版本中更新。而当前在 DQL 的查询中，我们已经实现 Variant 列的自动类型断言。大部分情况下可直接根据 Variant 的实际数据类型来直接进行断言，只有极少数类型冲突的情况下 Variant 列会升级到 JSON 数据类型，此时我们会根据 DQL 查询中的聚合算子或操作符关联语义来进行实际断言。

04 设计采样逻辑，加速聚合查询性能

在适配过程中我们发现，尽管 SelectDB 性能强大，但在需要对超大数据集进行聚合计算时，仍然会占用较多的系统资源，计算的开销相对很高。而在可观测场景中，大部分的计算都是定性分析，而不是定量的绝对值精确分析。

基于这样的业务背景，我们在 GunaceDB 中设计了如下的采样逻辑：

在这样的采样逻辑下，可以显著减少超大规模计算所需的计算开销和用户等待时间，相比之前有数十倍的性能提升，极大的提升了用户的使用体验。

结束语

SelectDB 的引入满足了我们 Schema Free 的要求，解决了数据 Schema 频繁变化痛点；提高了数据写入的性能，保证了数据写入的时效性和查询的实时性；提升了全文检索的性能并降低查询的资源开销… 总而言之，SelectDB 的应用，使观测云最终实现存储成本降低 70% 的同时，查询性能提升 2-4 倍，最终实现整体性价比 10 倍提升！未来，我们还将持续与飞轮科技协作，打造更受用户欢迎的解决方案，同时也将共同推动 Apache Doris 社区的发展和壮大！

原文地址:https://blog.csdn.net/SelectDB_Fly/article/details/134696952

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_#ID#.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

上一篇 使用极限网关助力 ES 集群无缝升级、迁移上/下云
下一篇 Es条件查询

相关文章

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

插入图片
浏览器会保存昵称、邮箱和网站cookies信息，下次评论时使用。