基于时间的数据 日志、指标 在日积月累后的数量是惊人的。以 SLB 七层访问日志为例 每一个HTTP/HTTPS 访问请求会记录一条 access log 假设每天产生1000万条数据 则一年为36亿条数据。一方面 长时间的数据存储需要巨大的存储空间 而通过减少存储周期的方式降低存储空间 虽然控制了存储成本 但也丢失了有价值的历史数据。另一方面 大量的数据将造成分析上的性能压力。
大部分时序数据具有时效性特征。历史数据可以接受分钟或小时级别的精度 而新产生的数据需要更高的精度 例如监控、线上问题调查 。数据运营、分析师需要存储全量的数据以备分析 历史数据直接 TTL 删除是可能最差的选择。
例如 Elasticsearch rollup、时序数据库的降精度用于解决这部分问题。
一份数据在多种场景使用对于同一份日志 可能被多种用户角色在多种场景下使用到
实时的数据 需要支持关键词告警、时序数据 ML 巡检、日志上下文查询。一份数据 多处使用 既要满足业务需求 成本也是需要关心的。
自定义业务分析云上日志设施面对的客户群呈现多样化 自定义的业务需求举例如下
电商 计算七日留存率 业务访问 SQL 审计日志对用户信息脱敏 等等。阿里云 SLS 是云原生观测分析平台 为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务 一站式提供数据采集、加工、分析、告警可视化与投递功能。我们将以业务为目标的数据处理归纳为两类需求
ETL 将非结构化的日志做预处理 为日志信息添加业务字段 数据脱敏与分发等。对于 ETL、分析这两类计算任务 除了交互式分析以外 还需要常驻作业模式来处理结果落盘。
根据不同的业务需求 这里总结了几种常见的 SLS 数据分析方案。
数仓 T 1对于结果实时性不敏感的业务 有较多采用数仓方案
数据通过 SLS 实时入库 集中化存储。以 Flink、Spark Streaming continuous mode 、Kafka Streams 为代表的实时计算系统 在数据处理语义 exactly-once 、计算结果修正上的能力强大。该方案会用到 SLS 百 ms 秒级端到端延迟的 pub/sub 能力
数据实时推送到 SLS 日志库。这个方案在算子丰富度、实时能力、性能上综合表现全面 是一把牛刀 例如在电商实时大屏场景上是非常好的选择。
如果抱着挑刺的眼光来看
计算引擎层面做得均衡 但缺乏存储层的优化。例如 一个 logstore 上运行 10 个流计算作业 无论实际需要纳入计算范围的数据有多少 最终需要 10 遍全部数据流量的订阅 从业务角度上看存在网络、计算资源上的浪费。还是围绕 SLS 的 pub/sub 能力 以 SLS SDK 方式调用 PullData API 例如
通过 Logstash/Flume 等开源软件 加载 SLS source connector。以上对于行处理场景是适用的 适用面上则需要关注
该方案在绝大部分情况下都不涉及全局计算 窗口、聚集 即使能实现也很复杂。在 SLS 的流式存储之上 开启了索引分析功能 带来了全文索引、列式下推、SQL 计算能力加持。
该方案调用 SLS GetLogs API 部署一个常驻程序 设置定时触发器 周期调度任务执行
调用 API 读取 SLS 索引并计算数据。用户除了需要运维程序 还需要考虑以下需求
SQL 运行可能因计算量巨大而超时 失败时需调度层的重试支持。本文后续重点介绍的 Scheduled SQL 从本质上来讲 是对该方案的服务化 对以上问题有更全面的考虑。
SLS 告警对 你没看错。有少数用户用 SLS 告警曲线救国 图的是一个全托管、免运维。
SLS 告警功能支持设置定时策略 执行多个 SQL 获取结果 并将结果编排后发送到内置 logstore internal-alert-history 或自定义的网关/webhook。
需要说明的是 告警的主要设计场景是面向小的计算结果 按触发策略、值班表 将事件传达给接收者。对于严苛的业务 不推荐这种做法 可以关注 Scheduled SQL 功能做迁移
告警的结果写出可能出现写出数据大小截断 1 MB 内 、 exactly-once 等问题。用一张图描述 SLS 原生数据处理功能如下 接下来分别按存储模型展开介绍
stream 模型例如通过 Flink、自建消费组程序进行 SLS 数据分析 都基于 stream 模型。这是 SLS 最基础的存储形式 也称 LogHub 可以理解为 append-only 的 log 结构 通过 多个 shard 组合实现 IO 和存储的水平扩展。
LogHub 与开源软件 Kafka 是类似的功能形态 SLS 底层是共享分布式存储 盘古 这避免了 Kafka 在机器磁盘空间 re-balance、机器替换、存储规模的一些缺陷。
stream 存储模型在机器数据场景下有多重优势
写入模型简单 不需要 commit 机制 天生支持流式写入 客户端 移动端设备、Agent 友好。针对流式数据 ETL 场景 SLS 支持数据加工功能 可以实现按量付费、全托管的行处理需求 本文不多介绍 可以参考SLS 数据加工的设计与实践。
table 模型当 stream 数据写入后 对于 shard 内的数据 可以同时构建一份包括倒排、列存、bitmap 等信息的索引数据。shard 内 stream 数据相当于是正文 索引到今天有两种形式
Logstore (with index) 适用于日志模型 形式上是表结构 一条数据由多组 key-value pair 组成。例如 Logstore 在计算时称为 append-only Table 模型。在 SLS 场景下有以下优势
计算效率高 时间 一级索引 过滤、计算下推都可以直接利用 index 进行 节省网络、计算的性能开销与计算成本。当然 index 会有构建费用 SLS 的一份 index 数据可以服务于多个业务场景 告警、仪表盘、全文搜索、监控 来摊销成本。SLS 的每一次 SQL 计算针对预定的一片数据做处理 因此 对全部时间区间 从现在开始一直到未来 数据的 SQL 分析依赖于上层调度 也就是将要介绍的新功能 Scheduled SQL 它支持标准SQL、SLS 查询和分析语句 按照调度规则周期性执行 并将运行结果写入到目标库中。可用于以下场景
定时分析数据 根据业务需求设置分析语句 定时执行 并将分析结果存储到目标库中。Scheduled SQL 相比于自建程序调用 SLS API 而言 有以下优势
SQL 运行 timeout 提升至 600 秒 单次最大处理百亿级数据。Scheduled SQL 涉及以下几个重要概念
作业 一个 Scheduled SQL 任务对应一个作业 包括调度策略、计算规则等信息。流计算里有大量篇幅用于处理数据计算的一致性、完整性问题 Scheduled SQL 则是一种以 small-batch 模拟常驻计算的方案 针对这两个问题的设计是
计算一致性SQL 每次执行会对应到确定的时间窗口 由此得到确定数据集再调度 SQL 计算。Scheduled SQL 实例运行时 SQL 查询的时间窗口是基于调度时间渲染得到 左闭右开格式 与实例的创建时间、执行时间无关。例如调度时间为2021/01/01 10:00:00 SQL时间窗口的表达式为[ m - 10m, m) 则实际的SQL时间窗口为[2021/01/01 09:50:00, 2021/01/01 10:00:00)。Scheduled SQL 作业依次调度多个实例执行 无论是正常被调度还是被动异常实例重试的情况 同时只有一个实例处于运行中 不存在多个实例并发执行的情况。
在 SLS 数据场景下 主要的几种调度场景如下
场景一 实例延迟执行无论实例是否延迟执行 实例的调度时间都是根据调度规则预先生成的。虽然前面的实例发生延迟时 可能导致后面的实例也延迟执行 但通过追赶执行进度 可逐渐减少延迟 直到恢复准时运行。
场景二 从某个历史时间点开始执行Scheduled SQL作业在当前时间点创建Scheduled SQL作业后 按照调度规则对历史数据进行处理 从调度的开始时间创建补运行的实例 补运行的实例依次执行直到追上数据处理进度后 再按照预定计划执行新实例。
场景三 固定时间内执行Scheduled SQL作业如果需要对指定时间段的日志做调度 则可设置调度的时间范围。如果设置了调度的结束时间 则最后一个实例 调度时间小于调度结束时间 执行完成后 不再产生新的实例。
场景四 修改调度配置对生成实例的影响修改调度配置后 下一个实例按照新配置生成。一般建议同步修改SQL时间窗口、调度频率等配置 使得实例之间的SQL时间范围可以连续。
场景五 重试失败的实例正常情况下 一个Scheduled SQL作业按照调度时间的递增顺序生成执行实例。如果实例执行失败 例如权限不足、源库不存在、目标库不存在、SQL语法不合法 系统支持自动重试 当重试次数超过您配置的最大重试次数或重试时间超过您配置的最大运行时间时 重试结束 该实例状态被置为失败 然后系统继续执行下一个实例。
您可以对失败的实例设置告警通知并进行手动重试。您可以对最近7天内创建的实例进行查看、重试操作。调度执行完成后 系统会根据实际执行情况变更实例状态为成功或失败。
Scheduled SQL 在访问日志上的应用场景需求在阿里云上 SLB/OSS 的被用到很多的基础计算、存储服务。在使用过程中如果要得到细粒度可观察性 都绕不过访问日志 在深度使用后您可能会有体感
访问日志与 request 数一比一关系 数据量很大 造成存储成本增加并拖慢计算。以 SLB 七层访问日志为例 这里介绍一种实践
基于 Scheduled SQL 功能 将历史原文数据压缩为低精度数据 支持长期的索引存储并大大提升分析效率。整体方案图如下
OSS投递操作步骤参考将日志服务数据投递到OSS。
Scheduled SQL 配置使用增强型资源池 默认 STS 角色授权 最终计算结果写同区域 Logstore
使用Scheduled SQL时 建议根据业务情况 同时兼顾数据实时性和准确性。
考虑数据上传日志服务存在延迟情况 您可以结合数据采集延迟以及业务能够容忍的最大结果可见延迟 设置执行延迟和SQL时间窗口 结束时间往前一点 避免实例执行时SQL时间窗口内的数据未全部到达。在这里每分钟调度一次 SQL 计算最近一分钟窗口的数据 并设置延迟执行 如果对于实时性要求不高 建议这个值设置大一些
Scheduled SQL 写出到目标 Logstore 数据的结果如下图 其中 tag 字段是系统默认添加的信息 用于数据的搠源。
Scheduled SQL 调度生成的实例信息在任务管理页面可以查看 对于失败的任务可以做重试。
方案效果功能体验上 热、温数据存储、分析 支持交互式查询、分析的能力 保留了灵活性。注 目前 Scheduled SQL 已发布部分区域 参考快速开始使用 Scheduled SQL 其它区域正在逐个开放中 如有问题或需求可以工单或钉钉群联系 SLS 团队。
我们平时使用地图的时候要么到高德或者百度等开发平台去使用,要么去可视化站点...
标签用于标记云资源,如实例、镜像和磁盘等。如果您的帐户下有多种云资源,并且...
引言 kubeflow 是 google 开源的一个基于 kubernetes 的 ML workflow 平台,其集...
操作场景 安全组类似防火墙功能,是一个逻辑上的分组,用于设置网络访问控制。用...
本文转载自公众号读芯术(ID:AI_Discovery)。 如果你一直关注Kaggle新闻,那对Me...
1.一旦我发现数学有题目不会做了我就跳过,这一跳我发现根本停不下来。 2.慢点...
大家好,我是站长 polarisxu。 有些朋友应该知道,我最近在看 Rust,在朋友圈我...
图片来自 Pexels 前者对性能有极高的要求,而后者又正好拉低了性能,本文谈谈秒...
本文介绍了阿里云资源编排服务ROS如何帮助OA实现自动化部署,大大提升效率。 公...
互联网时代,如果没有很好地对品牌进行塑造、宣传、推广,几乎可以说是寸步难行...