什么网站可以做简历模板,手机对比平台,平面设计公司电话,潮汕美食网站怎么做作者#xff1a;观测云 CEO 蒋烁淼 飞轮科技技术团队
在云计算逐渐成熟的当下#xff0c;越来越多的企业开始将业务迁移到云端#xff0c;传统的监控和故障排查方法已经无法满足企业的需求。而观测云可提供整体数据的分析、洞察、可视化、自动化、监测告警、智能巡查…作者观测云 CEO 蒋烁淼 飞轮科技技术团队
在云计算逐渐成熟的当下越来越多的企业开始将业务迁移到云端传统的监控和故障排查方法已经无法满足企业的需求。而观测云可提供整体数据的分析、洞察、可视化、自动化、监测告警、智能巡查、安全巡查等服务。为更好提供上述服务要求观测云能够统一整合来自多个场景和多种结构的海量数据并提供全面的日志检索分析能力快速实现数据查询、筛选和分析。
因此飞轮科技与观测云进行了全面合作。通过 SelectDB 的倒排索引能力、Variant 数据类型、冷热数据分层存储等特性为观测云日志存储和分析场景服务注入强大的动力实现存储成本降低 70% 的同时查询性能提升 2-4 倍最终实现整体性价比 10 倍提升
GuanceDB 原有架构 观测云具备强大的数据接入能力通过自研的 All In One 采集工具 DataKit 可以从不同端侧、业务层、中间件、基础设施等不同层获取数据同时进行预处理和元信息关联。除了广泛支持日志数据以外Datakit 还支持采集和处理基础设施的时序指标、链路追踪、安全事件以及在 APP 端或浏览器端的用户行为数据等。为了满足多元化的多场景需求DataKit 不仅对开源探针和采集器进行了全面兼容还支持对自定义格式的数据源接入。
DataKit 采集的数据经过核心计算层处理后会统一存储到 GuanceDB 中。GuanceDB 是一个观测云自主研发的由多种数据库技术组成的多模态数据库。 GuanceDB 的内部架构如上图所示主要包含查询引擎 Query Engine 和存储引擎 Storage Engine 两层。在逻辑结构上查询引擎与存储引擎通过抽象解耦整体架构上实现了可拔插可替换。
观测云基于 VictoriaMetrics 存储模块研发了时序存储引擎 Metric Store同时在泛日志场景集成了 Elasticsearch/OpenSearch。这样的设计使 GuanceDB 对外有统一的写入和查询接口能适应不同类型的数据格式和业务需求。在当前的实现中MetricStore 已经具备卓越的性能。然而对于日志类和用户行为类数据的处理来说Elasticsearch 却有诸多不足具体表现如下
写入占用资源多Elasticsearch 在处理高频写入大量的数据时会占用较高的 CPU 和内存资源这不仅会显著增加集群成本还会挤占查询所占用的资源。对无模式表支持差Elasticsearch 对于 Schemaless 支持有限当前的 Dynamic Mapping 在面对大量的用户自定义字段时会频繁造成字段类型冲突导致数据丢失需要人工介入进行手动处理。聚合查询性能差Elasticsearch 在面对海量数据时聚合性能表现较差。例如对亿级数据计算分位数、错误率时极易出现超时很难满足大规模数据下的业务分析需求。
选型目标及调研
原有架构中 Elasticsearch 存在的问题推动我们对架构进行升级在升级之前我们调研了包括 SelectDB 在内的多款数据库。结合实际可观测性场景我们选型目标如下
高吞吐高性能在可观测场景下业务数据的规模会随着业务复杂度和业务规模线性递增。为满足这一需求我们需要一种既能支持高吞吐实时写入又能支持高性能数据分析同时集群本身易于运维、支持横向拓展的存储方案。全文倒排索引全文倒排索引能够显著提升检索性能并降低查询的资源开销是实现高效日志分析的必备能力。在调研中我们也注意到了像 Loki 这样的无索引方案 这类方案虽然简单但当请求 QPS 稍高时全盘扫描时磁盘 IO 和 CPU 资源开销争抢就会非常激烈无法承载日志图表展示、聚类筛选分析、实时告警等业务需求。支持多种业务写入和查询场景观测云采集的业务场景丰富多样包括海量吞吐的追加写、进程和主机等对象数据的整体周期性更新、 RUM 场景下 Session 会话部分更新等同时覆盖高频点查、列表查询、大范围聚合查询等多种查询场景这就需要新方案能够支持多种业务写入和多样化场景查询。支持无模式表可观测业务场景中有大量的字段元信息是业务工程师根据业务需求手工维护的为了更好的适配这种场景存储层就需要支持 SchemaLess无需上层业务维护数据表的 Schema 信息并且能够自动处理类型冲突。支持大规模租户隔离在 SaaS 场景中我们有大量的租户和分表这些元数据本身会给系统造成较大管理压力。在使用 Elasticsearch 时其单个集群能支持的索引数有限一旦达到某个索引数量性能就会急剧下降因此需要将数据分散到不同的集群中这给集群管理造成了诸多困扰降低长期存储成本可观测类的数据价值会随时间迁移而递减我们希望能通过冷热分离、存算分离等技术手段将长期存储的数据保存到对象存储中以降低数据的总体存储成本。
综合来看SelectDB 能够满足观测云的大部分需求并且在与同类产品的对比中表现出色我们也会在后面的章节中详细介绍基于 SelectDB 的改造实践。特别值得一提的是在前期调研中以下特性是吸引我们的重要特性
SelectDB 倒排索引可使得存储空间节约超 80% 、写入速度是 Elasticsearch 的 5 倍、查询性能是 Elasticsearch 的 2.3 倍。SelectDB 针对 JSON 等半结构化数据设计了 Variant 数据类型可以将任意结构的 JSON 存入 Variant 类型中可以对 JSON 内部的字段和类型自动分析、对频繁出现的字段采用列式存储提升存储和分析的效SelectDB 可以支持上千个数据库和上万个数据表能够实现一个租户独立使用一个数据库实现多租户数据隔离的需求满足数据的隔离和安全性。
基于 SelectDB 的存储架构升级
因此我们引入 SelectDB 对 GuanceDB 内部架构进行升级为了更好地介绍 SelectDB 如何在 GunaceDB 中作为存储引擎发挥作用我们首先介绍一下 DQL 查询语言。
在可观测性场景中几乎所有的查询都涉及时间的筛选同时大部分的聚合也需要按照时间窗口来进行并且针对时间序列还需要支持按单个序列在时间窗口前后进行 Rollup。在这些场景中使用 SQL 来表达相同的语义就需要嵌套多层子查询导致表达过程和编写都异常复杂。
因此我们尝试简化语法元素在此基础上设计出了新的查询语言 DQL并且增强了在可观测场景下的常见计算函数通过 DQL 即可查询指标、日志、链路追踪、对象等所有的可观测数据。
从 GuanceDB 内部结构来看本次升级我们使用 SelectDB 替换了 Elasticsearch/OpenSearch原有的查询架构保持不变。 接下来我们介绍在引入 SelectDB 之后DQL 查询是如何工作的 如上图所示Guance-Insert 是数据写入组件Guance-Select 是 DQL 查询引擎。
在 Guance-Insert 中实现了分租户的数据攒批逻辑均衡了写入吞吐量和写入延迟两大指标尽量高效地将数据通过 Stream Load 接口写给 SelectDB Doris BE 组件。当海量日志产生时该方式攒批速度很快平均日志入库延迟在 2-3 秒。在 Guance-Select 中 Guance-Select 会根据当前查询 SelectDB 的 SQL 支持情况选择是否将查询下推给 FE 计算。通常情况下常见的聚合查询都可以下推给 FE 计算但当遇到 FE 不支持的 SQL 语义或函数时我们就会选择 Fallback 到仅下推谓词到 BE通过 Thrift RPC 接口获取 Arrow 格式的列存数据再在 Guance-Select 中计算。由于此方案无法将计算逻辑下推 BE 因此实际性能会略差于在 FE 中的查询。不过在大部分场景下这种方案是可以满足需求的。
当前的查询架构是综合 FE 和 BE 能力的混合计算架构DQL 即可以利用 SelectDB 已经充分优化的查询能力也可以让语法拓展不受 SelectDB 本身 SQL 能力的限制。
架构升级的收益
01 存储成本降低约 70%、查询性能提升 3 倍
SelectDB 的引入实现了综合成本的大幅降低。之前我们在云上某可用区使用的是由 20 台 16C 64G 云主机组成的 Elasticsearch 集群提供查询服务同时采用了独立的索引写入服务相当于使用 20 台云主机。在替换成 SelectDB 之后只需要 13 台同配置的云主机总成本下降了 67%。成本的大幅降低主要得益于两个因素
SelectDB 写入性能高于 Elasticsearch 在应对 1GB/s 的持续高吞吐写入时SelectDB 所占用 CPU 保持在 20% 以下折合约占 2.6 台云主机的成本仅为 Elasticsearch 索引写入服务成本的 13%。这一优势可以在降低写入成本的同时应对更大的突发流量保障系统的稳定性。 SelectDB 数据和索引压缩率高于 ElasticsearchSelectDB 数据和索引采用列式存储和 ZSTD 压缩技术使得线上集群整体压缩比可达 1:8 而 Elasticsearch 压缩比只有 1:1.5因此使用 SelectDB 时所占用存储空间仅是 Elasticsearch 的 20% 左右。SelectDB 支持冷热数据分层存储我们可以将近期较频繁查询的热数据存储在本地盘长时间不使用的冷数据自动上传至对象存储中这样可大幅降低数据存储成本。同时SelectDB 支持根据存储策略的配置自动进行冷热数据迁移并且数据生命周期管理和查询对上层应用透明使用起来更加灵活方便。此外SelectDB 还可通过本地 Cache 加速对冷数据的访问从而提升用户查询冷数据的使用体验。
SelectDB 的引入实现了查询性能显著提升。在减少机器数量以后我们对比了相同的查询在两个集群下的性能实践表明 SelectDB 的点查和列表查询速度比 Elasticsearch 快近 2 倍在聚合查询不进行采样的情况下SelectDB 相比 Elasticsearch 快将近 4 倍。
综上采用 SelectDB 替换 Elasticsearch 后仅使用 Elasticsearch 的 1/3 成本、获得 24 倍的性能提升整体性价比提升了近 10 倍
02 倒排索引满足日志场景全文检索需求
倒排索引能够显著提升全文检索的性能并降低查询的资源开销是实现高效日志分析的必备能力。SelectDB 支持倒排索引以下是我们从 Elasticsearch 迁移到 SelectDB 过程中关键能力的介绍
支持字符串全文检索包括可同时匹配多个关键字 MATCH_ALL、匹配任意一个关键字 MATCH_ANY 、匹配短语词组 MATCH_PHRASE 的查询方式。我们对日志文本内容创建倒排索引时使用 MATCH_PHRASE 进行查询能够完整覆盖原来在 Elasticsearch 上的功能。支持英文、中文及 Unicode 多语言分词中文分词还支持自定义词库、自定义停用词。我们将原先在 Elasticsearch 上使用的中文词库和停用词配置到 SelectDB 上完成了用户体验平滑迁移。加速普通的等值 IN、范围查询 同时支持数字、日期、字符串类型。
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 中设计了如下的采样逻辑
估算查询时间范围内的原始数据行数当需要查询的原始数据行数大于 1000 万时开启采样并固定采样行数为 1000 万反推计算采样率。在存储层利用 SelectDB 的 TableSample 能力进行实际数据采样配合一定的表写入均衡策略保证聚合结果不产生严重偏差。在查询引擎层根据不同的聚合算子适配采样结果大部分的分位数、平均值之类计算无需处理仅需要处理 Sum 和 Count 函数等比例放大。当 Count 聚合查询在采样后命中结果过少时我们会关闭采样重新查询避免大的误差出现。此外我们会在响应结果中标注采样率当用户怀疑采样结果有偏差时可以关闭采样重新发起请求。
在这样的采样逻辑下可以显著减少超大规模计算所需的计算开销和用户等待时间相比之前有数十倍的性能提升极大的提升了用户的使用体验。
结束语
SelectDB 的引入满足了我们 Schema Free 的要求解决了数据 Schema 频繁变化痛点提高了数据写入的性能保证了数据写入的时效性和查询的实时性提升了全文检索的性能并降低查询的资源开销… 总而言之SelectDB 的应用使观测云最终实现存储成本降低 70% 的同时查询性能提升 2-4 倍最终实现整体性价比 10 倍提升未来我们还将持续与飞轮科技协作打造更受用户欢迎的解决方案同时也将共同推动 Apache Doris 社区的发展和壮大
