简介：本文总结了大规模日志全局剖析的需要，探讨 SLS 上现有的典型剖析计划，并延长到 SLS 原生数据处理计划，介绍 Schedueld SQL 性能与最佳实际。
大规模日志全局剖析的需要
数据大规模与时效性
基于工夫的数据（日志、指标）在与日俱增后的数量是惊人的。以 SLB 七层拜访日志为例，每一个 HTTP/HTTPS 拜访申请会记录一条 access log，假如每天产生 1000 万条数据，则一年为 36 亿条数据。一方面，长时间的数据存储须要微小的存储空间，而通过缩小存储周期的形式升高存储空间，尽管管制了存储老本，但也失落了有价值的历史数据。另一方面，大量的数据将造成剖析上的性能压力。
大部分时序数据具备时效性特色。历史数据能够承受分钟或小时级别的精度，而新产生的数据须要更高的精度（例如监控、线上问题考察）。数据经营、分析师须要存储全量的数据以备剖析，历史数据间接 TTL 删除是可能最差的抉择。
例如 Elasticsearch rollup、时序数据库的降精度用于解决这部分问题。
一份数据在多种场景应用
对于同一份日志，可能被多种用户角色在多种场景下应用到：
• 实时的数据，须要反对关键词告警、时序数据 ML 巡检、日志上下文查问。
• 亚秒级提早粒度上，有全文关键词的查问、交互式 SQL 统计分析的需要。
• 以天为单位，须要对日志做经营剖析，计算转化率、设计经营策略。
• 一周前的产生的数据，大部分时候不再会被触碰到，在反对偶然的历史指标查看以外，审计场景下对全量日志的存储也是必须项。
一份数据，多处应用，既要满足业务需要，老本也是须要关怀的。
自定义业务剖析
云上日志设施面对的客户群出现多样化，自定义的业务需要举例如下：
• 电商：计算七日留存率，业务拜访 SQL 审计日志对用户信息脱敏，等等。
• 在线教育：多平台终端（android、ios、PC）埋点数据的规整，直播课堂生命周期内的异样诊断，等等。
• 游戏：按游戏的数据散发存储，全文搜寻反对工单考察，等等。
阿里云 SLS 是云原生观测剖析平台，为 Log/Metric/Trace 等数据提供大规模、低成本、实时平台化服务，一站式提供数据采集、加工、剖析、告警可视化与投递性能。咱们将以业务为指标的数据处理演绎为两类需要：
• ETL：将非结构化的日志做预处理，为日志信息增加业务字段，数据脱敏与散发等。
• 剖析：全局数据大表上的查问和 SQL 剖析，反对布尔搜寻、window、aggregate 操作等。
SLS 上的典型剖析计划
对于 ETL、剖析这两类计算工作，除了交互式剖析以外，还须要常驻作业模式来处理结果落盘。
依据不同的业务需要，这里总结了几种常见的 SLS 数据分析计划。
数仓 “T+1”
对于后果实时性不敏感的业务，有较多采纳数仓计划：
- 数据通过 SLS 实时入库，集中化存储。
- 全托管数据投递到 MaxCompute。
- 业务布局小时级或天级的计算工作，生成上游表，产出业务报表等后果。
流计算
以 Flink、Spark Streaming（continuous mode）、Kafka Streams 为代表的实时计算零碎，在数据处理语义（exactly-once）、计算结果修改上的能力弱小。该计划会用到 SLS 百 ms 秒级端到端提早的 pub/sub 能力：
- 数据实时推送到 SLS 日志库。
- 启动流计算工作，从多个 shard 实时生产数据。
- 流计算工作依据算子组合状况（stateless、statefull、groupby 等）切分多个拓扑执行，可能波及到数据 shuffle、watermark、state store 等机制。
这个计划在算子丰盛度、实时能力、性能上综合体现全面，是一把牛刀，例如在电商实时大屏场景上是十分好的抉择。
如果抱着挑刺的眼光来看：
• 计算引擎层面做得平衡，但不足存储层的优化。例如：一个 logstore 上运行 10 个流计算作业，无论理论须要纳入计算范畴的数据有多少，最终须要 10 遍全副数据流量的订阅，从业务角度上看存在网络、计算资源上的节约。
• 对于日志用户来说，在参数配置、性能调优、问题 Debug 有复杂性（简单经常是通用、弱小的另一面）。在简单场景下，DevOps-er 了解业务需要后，须要设置好高级参数、抉择好 state store 等。
• 计算集群部署形式，尤其对于自建集群、数据稠密的利用，其老本上有影响，例如 JobManager/TaskManager 等角色资源须要摊销。
自建程序做流式生产
还是围绕 SLS 的 pub/sub 能力，以 SLS SDK 形式调用 PullData API，例如：
• 通过 Logstash/Flume 等开源软件，加载 SLS source connector。
• 通过函数计算（SLS 提供 FC 触发器），益处是 Serverless 的 runtime，极致弹性计费。
• 通过 SLS 的 consumer group library 解决数据，主动负载平衡、failover。
以上对于行解决场景是实用的，实用面上则须要关注：
• 该计划在绝大部分状况下都不波及全局计算（窗口、汇集），即便能实现也很简单。
• 自建程序、开源软件须要运维人力以及固定机器投入的老本。
自建程序做查问、剖析
在 SLS 的流式存储之上，开启了索引剖析性能，带来了全文索引、列式下推、SQL 计算能力加持。
该计划调用 SLS GetLogs API，部署一个常驻程序，设置定时触发器，周期调度工作执行：
- 调用 API 读取 SLS 索引并计算数据。
- 读取计算结果写出到指标做存储。
用户除了须要运维程序，还须要思考以下需要：
• SQL 运行可能因计算量微小而超时，失败时需调度层的重试反对。
• 执行提早时告警反对。
• 调度元信息（schedule_time 等）长久化。
• web console 治理的需要。
• 如何将 SQL 计算结果 exactly-once 入库。
本文后续重点介绍的 Scheduled SQL，从实质上来讲，是对该计划的服务化，对以上问题有更全面的思考。
SLS 告警
对，你没看错。有多数用户用 SLS 告警曲线救国，图的是一个全托管、免运维。
SLS 告警性能反对设置定时策略，执行多个 SQL 获取后果，并将后果编排后发送到内置 logstore（internal-alert-history）或自定义的网关 /webhook。
须要阐明的是，告警的次要设计场景是面向小的计算结果，按触发策略、值班表，将事件传播给接收者。对于严苛的业务，不举荐这种做法（能够关注 Scheduled SQL 性能做迁徙）：
• 告警的后果写出可能呈现写出数据大小截断（1 MB 内）、exactly-once 等问题。
• 告警 1.0 是串行调度，某一次计算产生提早后，屡次执行实例的 SQL 工夫窗口会呈现空洞。
SLS 原生数据处理计划
用一张图形容 SLS 原生数据处理性能如下，接下来别离按存储模型开展介绍：
stream 模型
例如通过 Flink、自建生产组程序进行 SLS 数据分析，都基于 stream 模型。这是 SLS 最根底的存储模式（也称 LogHub），能够了解为 append-only 的 log 构造，通过 多个 shard 组合实现 IO 和存储的程度扩大。
LogHub 与开源软件 Kafka 是相似的性能状态，SLS 底层是共享分布式存储（盘古），这防止了 Kafka 在机器磁盘空间 re-balance、机器替换、存储规模的一些缺点。
stream 存储模型在机器数据场景下有多重劣势：
• 写入模型简略，不须要 commit 机制，天生反对流式写入，客户端（挪动端设施、Agent）敌对。
• append-only 保障了写入吞吐的设计下限，满足业务高并发、高吞吐需要。
• FIFO 的 changelog 模式，满足大多数日志、指标类数据的生成与应用场景。
针对流式数据 ETL 场景，SLS 反对数据加工性能，能够实现按量付费、全托管的行解决需要，本文不多介绍，能够参考 SLS 数据加工的设计与实际。
table 模型
当 stream 数据写入后，对于 shard 内的数据，能够同时构建一份包含倒排、列存、bitmap 等信息的索引数据。shard 内 stream 数据相当于是注释，索引到明天有两种模式：
• Logstore (with index)：实用于日志模型，模式上是表构造，一条数据由多组 key-value pair 组成。
• Metricstore：对于指标类型数据有针对性优化，有序排列存储反对疾速指标计算，高压缩率低存储老本。
例如 Logstore，在计算时称为 append-only Table 模型。在 SLS 场景下有以下劣势：
• 计算效率高，工夫（一级索引）过滤、计算下推都能够间接利用 index 进行，节俭网络、计算的性能开销与计算成本。当然，index 会有构建费用，SLS 的一份 index 数据能够服务于多个业务场景（告警、仪表盘、全文搜寻、监控）来摊销老本。
• OLAP 解决确定性问题，依照条件过滤取到数据后，间接进行计算即可，不须要思考流计算中 watermark、trigger 与 window 配合、state store 数据收缩（特定场景）等简单问题。
Scheduled SQL 让 SQL 可调度
SLS 的每一次 SQL 计算针对预约的一片数据做解决，因而，对全副工夫区间（从当初开始始终到将来）数据的 SQL 剖析依赖于下层调度，也就是将要介绍的新性能 Scheduled SQL，它反对规范 SQL、SLS 查问和剖析语句，依照调度规定周期性执行，并将运行后果写入到指标库中。可用于以下场景：
• 定时剖析数据：依据业务需要设置剖析语句，定时执行，并将剖析后果存储到指标库中。
• 全局聚合：对全量、细粒度的数据进行聚合存储，汇总为存储大小、精度适宜的数据，相当于肯定水平的有损压缩数据。例如依照秒级别对 36 亿条数据进行聚合存储，存储后果为 3150 万条数据，存储大小为全量数据的 0.875%。
• 投影与过滤：对原始数据的字段进行筛选，依照肯定条件过滤数据并存储到指标 Logstore 中。该性能还能够通过数据加工实现，数据加工的 DSL 语法比 SQL 语法具备更强的 ETL 表达能力，更多信息请参见加工原理。
Scheduled SQL 相比于自建程序调用 SLS API 而言，有以下劣势：
• SQL 运行 timeout 晋升至 600 秒，单次最大解决百亿级数据。
• 计算资源池可选：收费（project 级 15 并发）、付费（弹性扩大，参考 SQL 独享实例）。
• 最小 1 分钟周期执行，反对常驻或固定工夫区间内调度运行。
• 反对灵便的查问工夫窗口参数配置，满足多样化需要。
• exactly-once 写入指标库。
• 欠缺的作业实例查看、重试反对（控制台、API）。
• 全托管运行，主动解决多种异样，调度不免费。
• 实例执行失败集成 SLS 告警告诉。
Scheduled SQL 性能介绍
工作机制
Scheduled SQL 波及以下几个重要概念：
• 作业：一个 Scheduled SQL 工作对应一个作业，包含调度策略、计算规定等信息。
• 实例：一个 Scheduled SQL 作业依照调度配置按时生成执行实例。每一个实例对原始数据进行 SQL 计算并将计算结果写入指标库。实例 ID 是其惟一标识。
• 创立工夫：实例的创立工夫。个别是依照您配置的调度规定生成，在补运行或追赶提早时会立刻生成实例。
• 调度工夫：由调度规定生成，不会受到上一个实例执行超时、提早、补运行等状况的影响。大部分场景下，间断生成的实例的调度工夫是间断的，可解决残缺的数据集。
流计算里有大量篇幅用于解决数据计算的一致性、完整性问题，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)。
• SQL 计算的后果在插入指标时，须要思考数据反复可能带来的业务影响。对于 append 模式写，例如 Scheduled SQL 后果写 Logstore，写入客户端与 SLS 服务端实现了 exactly-once 协定。对于 overwrite 模式写，更容易做到原子性，将来会布局 Scheduled SQL 写数据库的反对。
- 数据的完整性
• 作业上设置提早执行参数从业务上给与领导，在实例的调度工夫点上，往后提早 N 秒才真正开始触发实例运行，而实例查问的工夫范畴不受提早参数影响。例如设置调度距离为每小时、提早执行为 30 秒，那么一天生成 24 个实例，其中某实例的调度工夫为 2021/4/6 12:00:00，执行工夫为 2021/4/6 12:00:30。这个设计在大部分场景下能够解决数据早退问题，但对于写 logstore 存储（数据写入后将无奈更新）来说，完全避免提早问题是难以实现的。极其状况下，数据早退问题可通过预先的实例重试来补后果。
• 将 SQL 查问的工夫窗口按分钟对齐（例如整分钟），以保障在 SLS 索引模型优化（batch log-group 组成倒排 doc）时仍然能保障相对的计算精确。
调度场景
Scheduled SQL 作业顺次调度多个实例执行，无论是失常被调度还是被动异样实例重试的状况，同时只有一个实例处于运行中，不存在多个实例并发执行的状况。
在 SLS 数据场景下，次要的几种调度场景如下：
• 场景一：实例提早执行
无论实例是否提早执行，实例的调度工夫都是依据调度规定事后生成的。尽管后面的实例产生提早时，可能导致前面的实例也提早执行，但通过追赶执行进度，可逐步缩小提早，直到复原准时运行。
• 场景二：从某个历史工夫点开始执行 Scheduled SQL 作业
在以后工夫点创立 Scheduled SQL 作业后，依照调度规定对历史数据进行解决，从调度的开始工夫创立补运行的实例，补运行的实例顺次执行直到追上数据处理进度后，再依照预约打算执行新实例。
• 场景三：固定工夫内执行 Scheduled SQL 作业
如果须要对指定时间段的日志做调度，则可设置调度的工夫范畴。如果设置了调度的完结工夫，则最初一个实例（调度工夫小于调度完结工夫）执行实现后，不再产生新的实例。
• 场景四：批改调度配置对生成实例的影响
批改调度配置后，下一个实例依照新配置生成。个别倡议同步批改 SQL 工夫窗口、调度频率等配置，使得实例之间的 SQL 工夫范畴能够间断。
• 场景五：重试失败的实例
失常状况下，一个 Scheduled SQL 作业依照调度工夫的递增程序生成执行实例。如果实例执行失败（例如权限有余、源库不存在、指标库不存在、SQL 语法不非法），零碎反对主动重试，当重试次数超过您配置的最大重试次数或重试工夫超过您配置的最大运行工夫时，重试完结，该实例状态被置为失败，而后零碎继续执行下一个实例。
您能够对失败的实例设置告警告诉并进行手动重试。您能够对最近 7 天内创立的实例进行查看、重试操作。调度执行实现后，零碎会依据理论执行状况变更实例状态为胜利或失败。
Scheduled SQL 在拜访日志上的利用
场景需要
在阿里云上，SLB/OSS 的被用到很多的根底计算、存储服务。在应用过程中如果要失去细粒度可察看性，都绕不过拜访日志，在深度应用后您可能会有体感：
- 拜访日志与 request 数一比一关系，数据量很大，造成存储成本增加并拖慢计算。
- 拜访日志有时效性，近 15 天日志须要交互式查问剖析反对，历史数据须要具备降精度的指标查问能力。
- 拜访日志有留存的需要，须要长期存储以备审计。
整体计划
以 SLB 七层拜访日志为例，这里介绍一种实际：
- 基于 Scheduled SQL 性能，将历史原文数据压缩为低精度数据，反对长期的索引存储并大大晋升剖析效率。
- 依据业务须要，原文数据反对全局搜寻和无损的 SQL 剖析，能够设置存储周期为 15 天。
- 历史数据原文投递到 OSS，反对极低成本存储，低频的审计捞数据操作也是不便的。
整体计划图如下：
OSS 投递操作步骤参考将日志服务数据投递到 OSS。
Scheduled SQL 配置应用增强型资源池，默认 STS 角色受权，最终计算结果写同区域 Logstore：
应用 Scheduled SQL 时，倡议依据业务状况，同时兼顾数据实时性和准确性。
• 思考数据上传日志服务存在提早状况，您能够联合数据采集提早以及业务可能容忍的最大后果可见提早，设置执行提早和 SQL 工夫窗口（完结工夫往前一点），防止实例执行时 SQL 工夫窗口内的数据未全副达到。
• 倡议 SQL 工夫窗口按分钟对齐（例如整分钟、整小时），以保障上传部分乱序数据时的数据准确度。
在这里每分钟调度一次 SQL 计算最近一分钟窗口的数据，并设置提早执行（如果对于实时性要求不高，倡议这个值设置大一些）：
Scheduled SQL 写出到指标 Logstore 数据的后果如下图，其中 tag 字段是零碎默认增加的信息，用于数据的搠源。
Scheduled SQL 调度生成的实例信息在工作治理页面能够查看，对于失败的工作能够做重试。
计划成果
• 性能体验上：
• 热、温数据存储、剖析，反对交互式查问、剖析的能力，保留了灵活性。
• 冷数据分析，反对分钟粒度的自定义指标查问（例如本文是 host、method、status 维度统计），能够疾速实现问题剖析，同样查问范畴提早升高两个数量级。
• 冷数据存储，以压缩格局投递到 OSS 存储，保留了审计能力。
• 存储老本上：在永恒存储的背景下，存储量升高到之前的 1/1000，OSS 上的压缩格局存储且做到极低的单价。
原文链接
本文为阿里云原创内容，未经容许不得转载。