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】数据加工概述
【4】SPL 句法
点击阅读原文，体验日志服务 SLS StoreView 功能
阅读原文：链接
