从 Elasticsearch 到 SelectDB,观测云实现日志存储与分析的 10 倍性价比提升
在云计算逐渐成熟的当下,越来越多的企业开始将业务迁移到云端,传统的监控和故障排查方法已经无法满足企业的需求。观测云可以实现对云、云原生、应用及业务的统一监测,提供整体数据的分析、洞察、可视化、自动化、监测告警、智能巡查、安全巡查等服务。本文将分享 SelectDB 如何助力观测云完成日志数据存储和分析架构升级,实现在存储成本降低 70% 的同时、查询性能提升 2-4 倍,最终实现整体性价比 10 倍提升,为日志存储和分析场景服务提供强大动力。
上海观测未来信息技术有限公司是一家国内领先的具备可观测性实时数据检测平台的公司,其自研产品「观测云」首批通过中国信通院颁发的「可观测性平台技术能力」先进级认证,可实现对云、云原生应用及业务系统的统一观测需求,为互联网、零售、金融等行业用户提供统一高效的数字化可观测服务。
在云计算逐渐成熟的当下,越来越多的企业开始将业务迁移到云端,传统的监控和故障排查方法已经无法满足企业的需求。在可观测理念逐渐深入人心的当下,人们越来越意识到通过多层次、多维度、多视角的数据去观测应用系统来提升故障的定位效率以及业务分析能力。而观测云本质上是一个全面性的、可观测性的解决方案,可提供整体数据的分析、洞察、可视化、自动化、监测告警、智能巡查、安全巡查等服务。
为更好提供上述服务,要求观测云具备对基础对象、网络性能、日志、应用性能、用户体验、可用性甚至 CI 进行观测的能力。这些能力要求观测云能够统一整合来自多个场景和多种结构的海量数据,并提供全面的日志检索分析能力,快速实现数据查询、筛选和分析。
为解决观测云在日志存储和分析场景所面临的挑战,飞轮科技与观测云进行了全面合作。通过 SelectDB 的倒排索引能力、Variant 数据类型、冷热数据分层存储等特性,为观测云日志存储和分析场景服务注入强大的动力,实现存储成本降低 70% 的同时,查询性能提升 2-4 倍,最终实现整体性价比 10 倍提升!
GuanceDB 原有架构
写入占用资源多:Elasticsearch 在处理高频写入大量的数据时,会占用较高的 CPU 和内存资源,这不仅会显著增加集群成本,还会挤占查询所占用的资源。 对无模式表支持差:Elasticsearch 对于 Schemaless 支持有限,当前的 Dynamic Mapping 在面对大量的用户自定义字段时,会频繁造成字段类型冲突,导致数据丢失,需要人工介入进行手动处理。 聚合查询性能差:Elasticsearch 在面对海量数据时,聚合性能表现较差。例如对亿级数据计算分位数、错误率时,极易出现超时,很难满足大规模数据下的业务分析需求。
选型目标及调研
原有架构中 Elasticsearch 存在的问题推动我们对架构进行升级,在升级之前,我们调研了包括 SelectDB 在内的多款数据库。结合实际可观测性场景,我们选型目标如下:
高吞吐高性能:在可观测场景下,业务数据的规模会随着业务复杂度和业务规模线性递增。为满足这一需求,我们需要一种既能支持高吞吐实时写入,又能支持高性能数据分析,同时集群本身易于运维、支持横向拓展的存储方案。 全文倒排索引:全文倒排索引能够显著提升检索性能并降低查询的资源开销,是实现高效日志分析的必备能力。在调研中,我们也注意到了像 Loki 这样的无索引方案, 这类方案虽然简单,但当请求 QPS 稍高时,全盘扫描时磁盘 IO 和 CPU 资源开销争抢就会非常激烈,无法承载日志图表展示、聚类筛选分析、实时告警等业务需求。 支持多种业务写入和查询场景:观测云采集的业务场景丰富多样,包括海量吞吐的追加写、进程和主机等对象数据的整体周期性更新、 RUM 场景下 Session 会话部分更新等,同时覆盖高频点查、列表查询、大范围聚合查询等多种查询场景,这就需要新方案能够支持多种业务写入和多样化场景查询。 支持无模式表:可观测业务场景中有大量的字段元信息是业务工程师根据业务需求手工维护的,为了更好的适配这种场景,存储层就需要支持 SchemaLess,无需上层业务维护数据表的 Schema 信息,并且能够自动处理类型冲突。 支持大规模租户隔离:在 SaaS 场景中,我们有大量的租户和分表,这些元数据本身会给系统造成较大管理压力。在使用 Elasticsearch 时,其单个集群能支持的索引数有限,一旦达到某个索引数量,性能就会急剧下降,因此需要将数据分散到不同的集群中,这给集群管理造成了诸多困扰。 降低长期存储成本:可观测类的数据价值会随时间迁移而递减,我们希望能通过冷热分离、存算分离等技术手段,将长期存储的数据保存到对象存储中,以降低数据的总体存储成本。
SelectDB 倒排索引可使得存储空间节约超 80% 、写入速度是 Elasticsearch 的 5 倍、查询性能是 Elasticsearch 的 2.3 倍。 SelectDB 针对 JSON 等半结构化数据设计了 Variant 数据类型,可以将任意结构的 JSON 存入 Variant 类型中,可以对 JSON 内部的字段和类型自动分析、对频繁出现的字段采用列式存储,提升存储和分析的效率。 SelectDB 可以支持上千个数据库和上万个数据表,能够实现一个租户独立使用一个数据库,实现多租户数据隔离的需求,满足数据的隔离和安全性。
基于 SelectDB 的存储架构升级
接下来我们介绍在引入 SelectDB 之后,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 中的查询。不过在大部分场景下,这种方案是可以满足需求的。
架构升级的收益
01 存储成本降低约 70%、查询性能提升 3 倍
SelectDB 写入性能高于 Elasticsearch :在应对 1GB/s 的持续高吞吐写入时,SelectDB 所占用 CPU 保持在 20% 以下,折合约占 2.6 台云主机的成本,仅为 Elasticsearch 索引写入服务成本的 13%。这一优势可以在降低写入成本的同时应对更大的突发流量,保障系统的稳定性。
SelectDB 数据和索引压缩率高于 Elasticsearch:SelectDB 数据和索引采用列式存储和 ZSTD 压缩技术,使得线上集群整体压缩比可达 1:8 ,而 Elasticsearch 压缩比只有 1:1.5,因此使用 SelectDB 时,所占用存储空间仅是 Elasticsearch 的 20% 左右。 SelectDB 支持冷热数据分层存储:我们可以将近期较频繁查询的热数据存储在本地盘,长时间不使用的冷数据自动上传至对象存储中,这样可大幅降低数据存储成本。同时,SelectDB 支持根据存储策略的配置自动进行冷热数据迁移,并且数据生命周期管理和查询对上层应用透明,使用起来更加灵活方便。此外,SelectDB 还可通过本地 Cache 加速对冷数据的访问,从而提升用户查询冷数据的使用体验。
02 倒排索引满足日志场景全文检索需求
支持字符串全文检索,包括可同时匹配多个关键字 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;
支持任何合法的 JSON 数据存储在 Variant 类型的列中,并且能够自动识别 JSON 中的子字段和类型。 Variant 数据类型可以避免字段过多导致的 Schema 爆炸问题。对于频繁出现的子字段,Variant 类型采用列式存储方式,以提高数据存储和分析的效率。而对于不频繁出现的子字段,Variant 类型则会将其合并为一列进行存储,以避免列的数量过大。 Variant 数据类型可以避免业务变更字段类型冲突无法写入的问题。Variant 允许一个字段存在不同的类型,并采用不同的存储方式,对新老数据采用不同的类型存储,对于新老交替的混合部分采用最小公共类型存储。
status
类型为字符串的数据。)04 设计采样逻辑,加速聚合查询性能
估算查询时间范围内的原始数据行数,当需要查询的原始数据行数大于 1000 万时开启采样,并固定采样行数为 1000 万反推计算采样率。 在存储层利用 SelectDB 的 TableSample 能力进行实际数据采样,配合一定的表写入均衡策略,保证聚合结果不产生严重偏差。 在查询引擎层,根据不同的聚合算子适配采样结果,大部分的分位数、平均值之类计算无需处理,仅需要处理 Sum 和 Count 函数等比例放大。 当 Count 聚合查询在采样后命中结果过少时,我们会关闭采样重新查询,避免大的误差出现。此外,我们会在响应结果中标注采样率,当用户怀疑采样结果有偏差时可以关闭采样重新发起请求。
观测云联合飞轮科技打造新一代可观测性解决方案
使用场景广泛:我们将 SelectDB 实时数仓的能力扩展到了监控日志及更广泛的可观测性场景,除监控应用开发场景外,基于该方案可以构建更多面向业务场景的实时观测监控场景。 降本提效:与传统监控方案相比,该方案存储成本显著降低,同时通过对采样效率的提升和多租户功能的优化,整体性价比提高至少 20 倍,我们也强化了日志查看功能,使其效率提高了 100 倍甚至 1000 倍。值得一提的是,通过观测云的产品力,用户无需对 SelectDB 二次开发即可获得完整的监控观测能力。 数据高效整合:SelectDB 可以将可观测性数据与业务数据进行整合,以发挥更大的价值。当前底层大量数据已存储在 SelectDB 中,当引入新的业务数据后,利用 SelectDB Catalog 或 Join 能力对可观测性数据与业务数据进行高线整合,缩短了数据处理流程。 挖掘数据价值:借助于 SelectDB 的强大实时分析能力,使得 Metrics、Logs、Traces 等可观测性数据的计算变得更加容易,用户可以更充分地挖掘和利用这些数据。
未来,我们还将持续与飞轮科技协作,打造更受用户欢迎的解决方案,同时也将共同推动 Apache Doris 社区的发展和壮大!
更多行业实践
智慧金融与政企:杭银消金|河北幸福消费金融|金融壹账通|平安人寿|同程数科|星云零售信贷|招商信诺人寿|360数科
互联网与文娱:斗鱼|叮咚买菜|货拉拉|荔枝微课|票务平台|奇安信|腾讯音乐|天眼查|网易互娱|网易严选|小米|小鹅通|约苗|字节跳动|知乎|360商业化
企业服务与新经济:橙联|度言|慧策|领健|领创|Moka BI|美联物业|拈花云科|思必驰|物易云通|云积互动|有赞|纵腾集团