StoreView SQL,让数据分析不受地域限制

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
可观测监控 Prometheus 版,每月50GB免费额度
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
简介: 日志服务SLS是云原生观测与分析平台,支持Log、Metric、Trace等数据的大规模、低成本实时处理。为解决跨地域数据联合分析问题,SLS推出StoreView功能,可将多地域、多项目的Logstore组合成虚拟Logstore,简化查询分析流程。相比传统ETL方式,StoreView无需同步数据,减少存储成本和延迟,同时支持数据可见性控制、查询式ETL处理及异构数据Schema对齐等功能,提升跨域数据分析效率。通过__project__和__logstore__两个Meta字段,用户还能识别数据来源,实现精细化分析。

1.gif


1. 引言


日志服务 SLS 是云原生观测和分析平台,为 Log、Metric、Trace 等数据提供大规模、低成本、实时的平台化服务。SLS 提供了多地域支持【1】,方便用户可以根据数据源就近接入 SLS 服务,减少不必要网络延迟以及公网费用。然而,如果需要将不同地域的数据进行联合统筹分析时,该怎么办呢?


SLS 近期推出的 StoreView 功能,可以协助用户便捷地进行跨域、跨 project 的查询和统计分析。StoreView 允许将多个 project 下(支持跨域)的 logstore 数据组合成一个虚拟的 logstore 使用,用户可以像使用一个 logstore 那样,使用 StoreView 进行各种查询分析。


2. 数据准备


下面以 4 个 demo projects 对几个常遇到的场景进行说明,这 4 个 projects 来自不同的地域,信息如下:



其中,每个 project 都包含一个名为 user-queries 的 logstore,包含的核心字段如下:


字段名称

类型

含义
requestId 字符串

请求的唯一ID

status 整数

请求状态,200,400, 500等

latencyMs 整数 请求延迟
resultRows 整数 返回的结果行数
prcessedBytes 整数 处理的原始数据量(字节)
prcessedRows

整数

处理的原始数据量(行数)

query

字符串

SQL的具体内容


3. 如何进行全域分析?


3.1 主要问题


在支持 StoreView 之前,如果需要对多个地域的 logstore 数据进行整体分析,则需要通过 ETL 任务先将各个地域的 logstore 数据同步到中心化的 logstore下,即需要为上面 4 个 demo project 下的 logstore 按照如下步骤创建同步 logstore 数据的加工任务(具体参考数据加工概述【2】)。




所有加工任务创建成功后,就可以使用中心化的 logstore centralized-user-queries 进行统计分析了。



可以看到,上面的操作非常繁琐,需要为每个 logstore 创建加工任务。另外,这种方式会导致数据存储量放大,即每个 logstore 的存储量会增加一倍,而且还有公网流量,从而导致产生额外费用。因此,通过加工任务的方式将多个地域的数据同步到一个 project 下,不仅费时费力,还费钱。


3.2 现在的做法


鉴于通过 ETL 任务将多地域的数据同步到一个 project 下的缺点,SLS 推出了 StoreView 功能,允许将不同地域、不同 project 下的多个 logstore 进行组合,形成一个虚拟的 logstore。用户基于 StoreView 对跨域、跨 project 的多个 logstore 数据进行统筹分析下时,就像对单个 logstore 进行分析一样简单。进入任意一个 project,参考文档数据集(StoreView)概述【3】 ,创建如下 StoreView 定义。



创建好上面的 StoreView 定义后,就可以进入对应的查询分析页面进行操作了。通过下面 SQL 语句,可以在 StoreView 下实现和加工中心化 logstore 查询分析一样的效果。



可以看到,相比于为每个 logstore 创建加工任务,创建 StoreView 非常简单。同时,使用 StoreView 进行数据分析时,不会存在 ETL 任务同步数据延迟的问题,因为它是实时地读取底层每个 logstore 的数据。


4. StoreView SPL 特性


StoreView 除了能够高效地解决数据因地域隔离导致查询分析不方便的问题外,它还集成了 SPL 句法加工数据的能力(参看 SPL 句法【4】,当前 StoreView 仅支持 extend、project 以及 where 三种指令)。基于 SPL 丰富的函数以及算子,StoreView 可以实现诸多 logstore 本身不具备的能力,下面将从数据可见性控制查询式 ETL 处理以及异构数据 schema 对齐等方面展开介绍。


4.1 数据可见性控制


对于 logstore 中的数据,有时我们想控制数据行级别的可见性,比如对于运维人员,我们想让他们只有权限看到报错的 queries 信息(方便他们监控系统的异常情况),但无权限查看正常的 queries。对于普通 logstore 而言,目前无法做到行级别的可见性控制(当前授权仅支持以 logstore 为粒度),但采用 StoreView 后,却非常容易实现这一点,比如我们可以创建如下图所示的 StoreView。



上面的 StoreView 中额外定义了一个查询过滤,它限定了返回没有匹配 status 为 200 的数据。通过下的 SQL 结果,可以清楚地看到,从 failed_user_queries 这个 StoreView 中只能看到错误的 queries 统计结果,而成功 queries(status 为 200)全部被过滤掉了。



因此,如果有行级别的数据可见性管理需求,StoreView 正好可以派上用场。


4.2 查询式 ETL 处理


有时候,logstore 中可能会包含一些敏感信息,我们并不想让团队中普通组员看到(但允许他们查看其他非敏感的字段信息)。比如,对于 user-queries 这个 logstore,我不想让所有人看到 sourceIp 以及 userId 这两个用户敏感信息,那该怎么处理呢?



按照之前的做法,可以通过数据加工任务对原始的 logstore 数据进行脱敏后,保存到另外一个 logstore 中,然后再将这个新的 logstore 开放给普通成员。虽然这样操作也能满足需求,但这不仅操作复杂,而且会增加额外的存储成本。基于 StoreView 的 SPL 能力,很容易满足这个需求,我们可以创建如下一个 StoreView。



通过下面的执行结果可以看到,无论是查询还是 SQL 分析,都看不到 sourceIp 和 userId 的原始内容。




可以看到,通过 StoreView 集成的 SPL 能力,可以非常便捷地对原始数据进行各种加工处理。相对于传统的 ETL 加工任务,StoreView SPL 定义更新更为灵活,修改后立刻对查询分析可见,而加工任务更新后,仅仅会作用于新写入源 logstore 中的数据。


4.3 异构数据 schema 对齐


在 SQL 场景下,StoreView 这个虚拟表支持的字段是所有底层 logstore 开启了统计分析字段的超集。对于多个 logstore 中同名但类型不同的分析字段,会归一化到 varchar 类型。但对于名称不同、含义相同的字段,怎么进行统一分析呢?比如,下面的场景中,统计每个 project 下 query 的平均延迟,结果发现 sls-cn-guangzhou-queries 对应的结果为 null,这是为什么呢?



经过分析发现,原来 sls-cn-guangzhou-queries 中的 query 数据并不包含 latencyMs 这个字段,它的数据中对应的字段名称实际上为 latency。针对这种情况,我们仍然可以通过 SPL 的 extend 算子解决这种问题,即为 latency 字段增加一个 alias 字段(当前 SPL 会默认将所有字段作为 varchar 处理,下面 SPL 中进行了类型转换)。



经过上面的操作后,SQL 的执行结果就符合预期了,具体如下所示。



5. StoreView meta 字段


StoreView SQL 提供了 __project__ 以及 __logstore__ 两个 meta 字段,它们分别表示数据原始所对应的 project 以及 logstore 名称。用户可以基于这两个 meta 字段来识别 StoreView 中结果的来源。比如,我们可以通过以下 SQL 来对比分析每个 project 下一天的处理数据量。



6. 结语


通过上面的实例分析可以看到,SLS StoreView 功能为用户提供了极为便捷的跨 project 查询和分析能力,用户不再需要通过创建加工任务来汇聚数据,节省了用户的使用成本。当前,控制台直接 SQL 分析以及大盘展示已经支持 StoreView(告警目前还不支持,后续也会考虑放开)。当然,因为跨 project 进行查询和分析,会涉及到跨域读取数据,整个处理链路受网络影响可能较大。后期我们会不断完善 StoreView 的易用性、稳定性和性能,让用户基于 StoreView 就能轻松愉悦地查询分析全地域的数据,真正做到数据分析不受地域边界的限制。


【1】多地域支持


【2】数据加工概述


【3】数据集(StoreView)概述


【4】SPL 句法


点击阅读原文,体验日志服务 SLS StoreView 功能


阅读原文:链接

相关文章
|
弹性计算 Kubernetes 数据处理
KubeRay on ACK:更高效、更安全
阿里云 ACK 以托管组件化的方式给客户提供快速搭建Ray集群的能力,并通过结合使用阿里云的调度,存储,日志与监控,给用户提供更佳使用体验。
|
3月前
|
机器学习/深度学习 人工智能 搜索推荐
Deep Search 如何理解业务仓库代码?
本文系统地介绍了 Deep Search 和 Deep Research 的概念、与传统 RAG 的区别、当前主流的商业产品与开源方案、在代码领域的应用(如 Deep Search for 仓库问答)以及未来的发展规划。
389 21
Deep Search 如何理解业务仓库代码?
|
4月前
|
存储 SQL 大数据
从 o11y 2.0 说起,大数据 Pipeline 的「多快好省」之道
SLS 是阿里云可观测家族的核心产品之一,提供全托管的可观测数据服务。本文以 o11y 2.0 为引子,整理了可观测数据 Pipeline 的演进和一些思考。
318 35
|
4月前
|
人工智能 Kubernetes Java
回归开源,两位 Java 和 Go 程序员分享的开源贡献指引
Higress是一个基于Istio和Envoy的云原生API网关,支持AI功能扩展。它通过Go/Rust/JS编写的Wasm插件提供可扩展架构,并包含Node和Java的console模块。Higress起源于阿里巴巴,解决了Tengine配置重载及gRPC/Dubbo负载均衡问题,现已成为阿里云API网关的基础。本文介绍Higress的基本架构、功能(如AI网关、API管理、Ingress流量网关等)、部署方式以及如何参与开源贡献。此外,还提供了有效的开源贡献指南和社区交流信息。
522 33
|
2月前
|
人工智能 大数据 开发者
让AI时代的卓越架构触手可及,阿里云技术解决方案开放免费试用
阿里云推出基于场景的解决方案免费试用活动,新老用户均可领取100点试用点,完成部署还可再领最高100点,相当于一年可获得最高200元云资源。覆盖AI、大数据、互联网应用开发等多个领域,支持热门场景如DeepSeek部署、模型微调等,助力企业和开发者快速验证方案并上云。
4264 145
让AI时代的卓越架构触手可及,阿里云技术解决方案开放免费试用
|
4月前
|
SQL JSON API
什么!我把SQL编辑器装进了大模型?
本文旨在通过约束解码技术,赋予大型语言模型在生成SQL等结构化内容时更高的准确性、可控性与可解释性,从而满足企业级场景对“精准生成”的严苛要求。
728 125
什么!我把SQL编辑器装进了大模型?
|
2月前
|
人工智能 算法 关系型数据库
AI编码不是梦:手把手教你指挥Agent开发需求
AI编码不是梦:手把手教你指挥Agent开发需求
1184 24