大规模日志全局分析需求大规模、时效性强的数据随着时间的推移积累的时态数据（日志、指标）数量惊人.以负载均衡七层访问日志为例，每个HTTP/HTTPS访问请求都会记录一个访问日志。假设每天产生1000万条数据，那么一年就是36亿条数据。一方面，长期的数据存储需要巨大的存储空间，通过减少存储周期来降低存储空间会控制存储成本，但也会丢失宝贵的历史数据。另一方面，大量的数据会造成分析性能压力。大多数时间序列数据都具有时间敏感的特性。历史数据可以接受分钟或小时的精度，而新生成的数据需要更高的精度（例如监控、在线问题调查）。数据运营和分析师需要存储全量数据进行分析，直接TTL删除历史数据是最糟糕的选择。比如Elasticsearchrollup和时序数据库的降准就是用来解决这部分问题的。一份数据用于多种场景。同一份日志可能在多种场景下被多个用户角色使用：实时数据需要支持关键字告警、时序数据ML检查、日志上下文查询等。在亚秒级延迟粒度上，有全文关键词查询和交互式SQL统计分析的要求。日常需要对日志进行运营分析，计算转化率，设计运营策略。一周前产生的数据，大部分时间是不会被触及的。除了支持偶尔查看历史指标外，审计场景下全量日志的存储也是必须的。一份数据可以在多个地方使用，既能满足业务需求，又能节省成本。定制化的业务分析云日志设施面向多种客户群体。自定义业务需求示例如下：电商：计算七日留存率，业务访问SQL审计日志用户信息脱敏等。在线教育：多平台终端（android、ios、PC）埋点数据正则化、直播课堂生命周期异常诊断等游戏：游戏数据按游戏数据分布存储，全文检索支持工单排查等。阿里云SLS是一个云原生的观察分析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时的平台服务，提供一站式的数据采集、处理、分析、报警可视化和传递功能。我们将面向业务的数据处理归纳为两类需求：ETL：预处理非结构化日志、为日志信息添加业务字段、数据脱敏分发等。分析：对全局大数据表的查询和SQL分析，支持布尔查找、窗口、聚合操作等。在SLS上的典型分析方案中，针对ETL和分析两类计算任务，除了交互分析，还增加了一个还需要常驻作业模式来处理结果。根据不同的业务需求，这里总结了几种常见的SLS数据分析方案。数据仓库“T+1”对于对实时结果不敏感的业务，采用了很多数据仓库方案：数据通过SLS实时存储，集中存储。完全托管的数据交付给MaxCompute。业务规划小时级或天级计算任务，生成下游表，输出业务报表等结果。流计算是以Flink、SparkStreaming（连续模式）、KafkaStreams为代表的实时计算系统。它在数据处理语义（exactly-once）和计算结果校正方面具有强大的能力。该方案将利用SLS的pub/sub能力，端到端延迟数百毫秒：数据实时推送到SLS日志库。启动流计算任务，实时消费多个分片的数据。流计算任务基于算子组合（stateless、statefull、groupby等）在多种拓扑中执行，其中可能涉及数据shuffle、watermark、statestore等机制。该解决方案在算子丰富性、实时能力和性能方面非常全面。这是一把大锤。比如电商实时大屏场景是非常好的选择。如果用挑剔的眼光来看：计算引擎层面平衡的很好，但是存储层缺乏优化。比如一个logstore上运行了10个流计算作业，不管计算范围内实际需要包含多少数据，最终都会需要10个订阅所有的数据流。从业务的角度来看，存在网络和计算资源的浪费。对于日志用户来说，在参数配置、性能调优、问题调试等方面存在复杂性（复杂性往往是通用性和强大性的另一面）。在复杂场景下，DevOps-er需要在了解业务需求后设置高级参数，选择statestore等。计算集群的部署方式，特别是自建集群和数据稀疏的应用，对成本有影响。比如JobManager/TaskManager等角色资源需要摊销。流媒体消费的自建程序仍然围绕SLS的pub/sub能力，使用SLSSDK调用PullDataAPI。例如通过Logstash/Flume等开源软件加载SLS源连接器。使用函数计算（SLS提供FC触发器）的好处是无服务器运行时和极其灵活的计费。数据通过SLS的消费者组库处理，自动负载均衡和故障转移。以上适用于行处理场景，但需要注意适用的方面：该方案大部分情况下不涉及全局计算（窗口、聚合），即使能实现也非常复杂。自建程序和开源软件需要运维人力和固定机器投资成本。自建程序基于SLS的流式存储进行查询分析，开启索引分析功能，带来全文索引、列式下推、SQL算力加持。本方案调用SLSGetLogsAPI，部署常驻程序，设置定时触发器，定时调度任务执行：调用API读取SLS索引，计算数据。读取计算结果并将其写出到目标进行存储。除了运维方案，用户还需要考虑以下需求：SQL操作可能因为计算量巨大而超时，失败时需要调度层的重试支持。延迟执行时提醒支持。调度元数据（schedule_time等）被保留。需要web控制台管理。如何将SQL计算结果exactly-once存入数据库。本文后面要重点介绍的ScheduledSQL，本质上是针对这个方案的一个面向服务的方案，它对上述问题有更全面的考虑。SLS警告是的，您没有看错。少部分用户使用SLS报警曲线救国，图为全程托管，免运维。SLS告警功能支持设置定时策略，执行多条SQL获取结果，并将结果整理发送到内置logstore（internal-alert-history）或自定义gateway/webhook。需要注意的是，告警的主要设计场景是针对小的计算结果，根据触发策略和值班时间表将事件传达给接收者。对于要求高的业务，不推荐这种方式（可以关注迁移的ScheduledSQL功能）：告警结果写入时，可能会出现写入数据大小（1MB以内）截断等问题，恰好一次等。警告1.0是串行调度。一个计算延迟后，多个执行实例的SQL时间窗口就会出现空洞。SLS原生数据处理方案用图来描述SLS原生数据处理功能如下，然后根据存储模型分别介绍：流模型，比如通过Flink和自建消费者组程序进行SLS数据分析，是基于流模型。这是SLS（也叫LogHub）最基本的存储形式。可以理解为append-only日志结构，通过多个shard的组合实现IO和存储的横向扩展。LogHub和开源软件Kafka具有相似的功能形态。SLS底层是共享分布式存储（盘古），避免了Kafka在机器磁盘空间再平衡、机器更换、存储规模等方面的一些缺陷。流式存储模型在机器数据场景中具有多重优势：写入模型简单，不需要commit机制，天然支持流式写入，客户端友好（移动设备，代理）。append-only保证写吞吐量的设计上限，满足业务的高并发、高吞吐需求。FIFO的changelog模式满足了大部分日志和指标数据的生成和使用场景。针对流式数据ETL场景，SLS支持数据处理功能，可以实现按量付费、完全托管的线路处理需求。本文介绍不多，大家可以参考SLS数据处理的设计与实践。表模型写入流数据后，对于分片中的数据，可以同时构建包含倒排、列存、位图等信息的索引数据。分片中的流数据相当于文本，索引在今天有两种形式：值对。Metricstore：针对指标类型数据进行针对性优化，有序存储支持指标计算速度快，压缩率高，存储成本低。比如Logstore在计算的时候就叫一个append-onlyTable模型。在SLS场景下，具有以下优势：计算效率高，时间（一级索引）过滤，计算下推可以直接使用索引进行，节省网络和计算性能开销和计算成本。当然，索引会有建设成本，SLS的一个索引数据可以服务于多个业务场景（告警、仪表盘、全文搜索、监控）来分摊成本。OLAP解决了确定性问题。根据条件过滤得到数据后，可以直接进行计算。无需考虑流计算中watermark、trigger和window协同、statestore数据扩展（具体场景）等复杂问题。ScheduledSQL允许SQL是可调度的。SLS的每一次SQL计算都是针对预定的一条数据进行处理的。因此，整个时间段（从现在到未来）数据的SQL分析依赖于上层调度，这是即将推出的新功能ScheduledSQL，支持标准SQL、SLS查询分析语句，执行定期按照调度规则，将运行结果写入目标数据库。可用于以下场景：数据定时分析：根据业务需要设置分析语句，定时执行，并将分析结果存入目标库。全局聚合：将全量的细粒度数据聚合存储，聚合成存储大小和精度合适的数据，相当于一定程度的有损压缩数据。例如，秒级聚合存储36亿条数据，存储结果为3150万条数据，存储规模为总数据的0.875%。投影过滤：对原始数据的字段进行过滤，将数据按照一定的条件过滤后存储到目标Logstore中。这个功能也可以通过数据处理来实现。数据处理的DSL语法比SQL语法具有更强的ETL表达能力。有关详细信息，请参阅处理原则。与调用SLSAPI的自建程序相比，ScheduledSQL具有以下优势：SQL运行超时时间提升至600秒，最大单次处理百亿级数据。计算资源池可选：免费（项目级15并发）、付费（弹性扩容，参考SQL专用实例）。最小1分钟循环执行，支持固定时间间隔内常驻或定时运行。支持灵活的查询时间窗口参数配置，满足多样化需求。exactly-once写入目标库。完整的作业实例查看和重试支持（控制台、API）。全托管运营，自动处理各种异常，排班不收费。实例执行失败集成SLS告警通知。ScheduledSQL功能介绍工作机制ScheduledSQL涉及以下重要概念：Job：一个ScheduledSQL任务对应一个作业，包括调度策略、计算规则等信息。实例：ScheduledSQL作业根据调度配置按时生成执行实例。每个实例对原始数据进行SQL计算，并将计算结果写入目标数据库。InstanceID是它的唯一标识。创建时间：实例的创建时间。一般是根据你配置的调度规则生成，当实例正在运行或者赶上延迟时会立即生成。调度时间：由调度规则生成，不会受到上一个实例执行超时、延迟、补充操作的影响。在大多数场景下，连续生成实例的调度时间是连续的，可以处理完整的数据集。流计算中有很多空间来处理数据计算的一致性和完整性。ScheduledSQL是驻留计算的小批量模拟。针对这两个问题的设计是：1.计算一致性每一次SQL的执行都会对应一定的时间窗口，然后在得到一定的数据集后，再调度SQL计算。ScheduledSQL实例运行时，SQL查询的时间窗口根据调度时间呈现，左闭右开，与实例的创建时间和执行时间无关。例如调度时间为2021/01/0110:00:00，SQL时间窗口表达式为[@m-10m,@m)，则实际SQL时间窗口为[2021/01/0109:50:00，2021/01/0110:00:00）。SQL计算的结果插入目标时，需要考虑数据重复可能对业务造成的影响。对于append方式的写入，比如将ScheduledSQL的结果写入Logstore，写入客户端和SLS服务器实现了exactly-once协议。对于overwrite方式写入，更容易实现原子性，未来计划支持ScheduledSQL写入数据库。2、在数据完整性作业上设置延迟执行参数，以业务为指导。在实例的调度时间，延迟N秒后触发实例运行，实例查询的时间范围不受delay参数影响。.例如设置调度间隔为每小时，延迟执行30秒，则一天生成24个实例，一个实例的调度时间为2021/4/612:00:00，执行时间现在是2021/4/612:00:30。这种设计可以解决大部分场景下数据迟到的问题，但是对于写入logstore存储（写入后数据无法更新），很难完全避免延迟问题。在极端情况下，可以通过事后重试实例来纠正数据延迟到达的问题。按分钟（例如整分钟）对齐SQL查询的时间窗口，保证SLS索引模型优化时（batchlog-group组成倒排doc）的绝对计算精度。调度场景ScheduledSQL作业调度多个实例依次执行。无论是正常调度还是异常实例被动重试，同一时刻都只有一个实例在运行，不存在多个实例并发执行的情况。SLS数据场景下，主要调度场景如下：场景一：实例延迟执行无论实例是否延迟执行，实例的调度时间都是根据调度规则预先生成的。虽然前面的实例延迟可能会导致后面的实例延迟执行，但是通过跟上执行进度，可以逐渐减少延迟，直到恢复按时运行。场景二：从某个历史时间点开始执行一个ScheduledSQL作业。在当前时间点创建ScheduledSQL作业后，根据调度规则处理历史数据，从预定开始时间开始创建补充运行实例，依次执行补充运行实例，追上数据处理进度后，根据预定计划执行新实例。场景三：在固定时间内执行定时SQL作业如果您需要将日志在指定时间段内进行调度，您可以设置调度的时间范围。如果设置了计划结束时间，则在上一个实例（计划时间小于计划结束时间）执行完毕后，不会再产生新的实例。场景四：修改调度配置对生成实例的影响修改调度配置后，下一个实例会按照新的配置生成。一般建议同步修改SQL时间窗口、调度频率等配置，使实例间的SQL时间区间连续。场景五：重试失败的实例一般情况下，ScheduledSQL作业会按照调度时间的递增顺序生成执行实例。如果实例执行失败（如权限不足、源库不存在、目标库不存在、SQL语法无效），系统支持自动重试，当重试次数超过您配置的最大重试次数或retrytimeexceedsyourconfiguration当最大运行时间为时，重试结束，实例状态设置为失败，然后系统继续执行下一个实例。您可以为失败的实例设置警报通知并执行手动重试。您可以查看和重试最近7天内创建的实例的操作。定时执行完成后，系统会根据实际执行情况将实例状态更改为成功或失败。ScheduledSQL在访问日志中的应用场景，要求在阿里云上，很多基础计算和存储服务都使用了SLB/OSS。如果想在使用过程中获得细粒度的可观察性，就绕不开访问日志。深入使用后，你可能会觉得访问日志和请求数是一对一的关系，数据量大，导致存储成本增加和延迟。缓慢的计算。访问日志是时间敏感的。近15天的日志需要交互式查询分析支持，历史数据需要具备降低精度查询指标的能力。访问日志需要保留，需要长期保存以备审计。整体方案以SLB的七层访问日志为例。这里有一个实践：基于ScheduledSQL功能，将历史原始数据压缩成低精度数据，支持长期索引存储，大大提高分析效率。根据业务需要，原始数据支持全局搜索和无损SQL分析，存储期限可设置为15天。历史数据原文交付OSS，支持极低成本存储，低频审计数据挖掘操??作也方便。整体方案图如下：OSS下发操作步骤参考下发日志服务数据到OSS。ScheduledSQL配置使用增强型资源池，默认STS角色授权，最终计算结果写入同区域Logstore：使用ScheduledSQL时，建议根据数据的实时性和准确性考虑到业务情况。考虑到数据上传日志服务的延迟，可以结合数据采集的延迟和业务所能容忍的最大可见延迟，设置执行延迟和SQL时间窗口（结束时间早一点），从而避免实例执行时SQL时间窗口内的数据未全部到达。SQL时间窗口建议按分钟对齐（如整分钟、整小时），保证上传部分乱序数据时的数据准确性。这里每分钟调度一次SQL，计算最后一分钟窗口内的数据，并设置延迟执行（如果对实时性要求不高，建议将这个值设置大一点）：结果ScheduledSQL写入目标Logstore数据如下图所示，其中tag字段是系统默认添加的信息，用于数据的来源。ScheduledSQL调度生成的实例信息可以在任务管理页面查看，失败的任务可以重试。在程序效果和功能体验方面：保留了热温数据存储和分析，支持交互式查询和分析的能力，以及灵活性。冷数据分析支持分钟粒度的自定义索引查询（如本文中的host、method、status维度统计），可以快速实现问题分析，也可以将查询范围延迟降低两个数量级。冷数据存储，以压缩格式交付到OSS存储，保留可审计性。存储成本：在永久存储的场景下，存储容量降低到之前的1/1000，以极低的单价存储在OSS上的压缩格式。
