前言

日志数据有以下的特点，种类繁多，缺乏 schema 规划，而且写多读少，最常使用的功能是OLAP和搜索用作运维。但是随着时代发展，我们发现一些在场景需求上的变化：一是日益严格的合规要求，日志数据要求留存时间变长，二是日志的价值被进一步挖掘，机器学习、离线分析、数据发现等。总结来看，日志的生命周期中，除了基本的OLAP和搜索能力做DevOps，还有用于数据洞察，合规审计，规则告警，和DevOps下一形态AIOps等，数据湖的优势是能够在低存储成本下很好满足长期存储、查询、分析、读取，并在此基础上做数据发现，BI，ML等。

阿里云提供的企业级数据湖解决方案，存储层基于阿里云对象存储 OSS 构建。日志服务（SLS）是云原生观测分析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、分析、告警可视化与投递功能，全面提升研发、运维、运营和安全等场景数字化能力。SLS支持开箱即用的OSS投递入湖功能，实现日志数据端到端的入湖，SLS 在2017年推出了开箱即用，按量付费的投递 OSS 功能，面对新的需求场景下，今天我们对投递 OSS 功能进行了全新升级，本文会介绍日志数据投递 OSS 新版特性，并以一个案例实践做展开。下面我介绍下SLS的日志数据入湖方案和实践。

架构设计

原始方案在日志增量产生时，满足用户设置的投递条件时生成投递任务，执行器会执行投递任务。

编辑搜图

但原有的方案只支持增量投递，对于以下场景难以覆盖：

1. 只能从当前时间开始投递，对于在创建LogStore之初就规划好冷存/审计/数据洞察等需求的用户能即时开启投递还好，但无法满足那些对于历史数据有归档、投递需求的用户。

2. 无法启停，由于任务的产生依赖日志收集过程，在用户发现参数的配置不合理时，一阵验证修改重启折腾后却只能对新数据才能生效

历史方案的架构存在着一些历史原因，初始投递功能简单，技术实现的方案也是基于增量的数据而集成在日志的主处理流程中，开发和验证的成本很低。而随着用户需求的升级，我们针对性地支持了以下新的feature：

支持对历史数据归档投递

某客户日志存储的历史数据有需求不能删除，其设置的TTL（可以理解为存储的时间，超过则会过期）为永久，想转储历史数据进行分析和归档，原有投递方案只支持增量数据而无法满足。而客户评估如果通过自建来实现，开发维护成本很高，而且对于大文件处理、压缩和投递，内存、计算资源的消耗也是比较大的。

针对客户的需求，我们升级后的方案去除了对数据增量过程的依赖，每个投递任务自行记录checkpoint，用户可以选择任务的任意开始时间（TTL - Now）范围，可以对历史数据回溯投递。而且支持用户随时启动停止任务，在调试好后可从停止时的checkpoint继续运行。

编辑搜图

同一日志库多种投递需求

某客户对投递的数据有多种需求，一份用来压缩归档，一份用来分析计算，由于之前只能对单个logstore绑定一个投递任务，用户需要数据采集到两个logstore或者通过logstore拷贝到另一个logstore，用户需要额外付一份logstore的存储费用。

针对客户的需求，升级后的方案中一个logstore可绑定多个投递任务，用户额外的投递任务不会产生多余的logstore费用，只需要按照总投递量付费。

编辑搜图

支持数据链路的可观测性和监控告警

数据投递功能开箱即用，但用户在原有方案中只能看到增量数据产生的多个任务和执行结果，整体数据链路和处理过程是个黑盒。用户希望能够提供更强的可观测性，能观测到投递的质量（是否能达到近实时性、参数是否配置错误比如角色权限配置不正确导致投递不成功等等），如果遇到数据有异常或者后端抖动，用户可以及时观测到，而且最好能够实时被触达到。

编辑搜图

针对这个需求，升级后的方案中，对于后端处理的整个流程会产生详细的诊断日志，并基于诊断日志为每个投递任务自动生成功能丰富的诊断仪表盘，包含读/写数据量，处理速率，处理延时，运行异常，运行信息等等。并配置了相对应的报警规则模版，用户可以根据其使用的数据量和速率等的阈值配置自己的报警规则和行动策略（支持钉钉等多自定义渠道及时报警）。

编辑搜图

编辑搜图

整体方案如下：多个投递任务的执行不再依赖用户biz log的增量日志产生，可以选择从不同的时间点开始。而且可以指定不同参数指定不同的目标bucket（或者相同bucket不同的目录），分别用来压缩归档和计算。而且执行过程中会存储详细的诊断日志，同时提供了详细的仪表盘和报警。而且初次之外我们还优化了一些细节，比如有的客户希望指定不同的时区来生成分区路径，有的客户希望自行制定文件后缀等等。另一个重要的点是，在升级后我们仍然保证投递可以按照日志数据流量的变化做到Auto Scaling，弹性的处理能力。

编辑搜图

下面我将进行一次SLS投递到OSS中的实践。

实践步骤

前提条件

• SLS日志项目(project)和日志库(logstore)

• OSS Bucket

日志投递

下方我们选择logstore中的数据处理 - 导出 - OSS（对象存储）来创建OSS投递功能。

编辑搜图编辑搜图

Step1：填写基本目标信息

• OSS Bucket：填写目标的OSS Bucket。

• 文件投递目录：数据将会放置在目标Bucket的文件目录下，也可以理解是一个文件路径的前缀。

• 文件后缀（可选）：以此为后缀或由存储格式和压缩类型自动生成。

• 分区格式：对于计算引擎Spark、Flink等了解的同学对数据分区(partition)的概念不会陌生。目前SLS的OSS投递功能支持用户使用自定义的时间格式来按照时间生成分区（业务时间或者其他自定义字段规划中）。

Step2 配置权限

使用RAM角色来配置好LogStore的读取权限和OSS的写权限，用户还可以通过自定义角色配置粒度更细（如特定Bucket的写权限，特定Logstore的读权限等）。

对写OSS的RAM角色增加相关配置后可以支持做跨账号的投递

编辑搜图

Step3 配置输出格式

• 投递大小：代表着会收集投递大小的日志数据量进行投递，用户可根据实际情况选择所需大小(5-256MB)，对于一些计算引擎或者数据湖上层的数据管理系统，过大的文件会影响读写的延时，而投递大小设置偏小会导致文件数过多，会导致对元数据管理或对象存储的List等接口压力过大。

• 压缩方式：压缩可以降低用户的存储成本，目前仅支持snappy（压缩速度较快，适合计算引擎，未来会支持gzip/zstd等，有进一步提高压缩率降成本的选择）。

编辑搜图

• 具体格式

• JSON格式：应用广泛，可读性好，是非常好的原始数据格式。用户可以选择不投递日志中的tag字段减少日志大小。

编辑搜图

• CSV格式：结构相对于JSON更加紧凑，几乎大部分的数据相关软件或者系统都能处理，虽然无法存储太复杂的数据结构，但总体非常适合日志场景。用户可以配置具体的字段名和分隔符转义符等定制所需格式。

编辑搜图

• Parquet格式：是一种列式的存储格式，列存带来许多好处如读取速度快，IO小，压缩比高，支持谓词下推等；被许多计算引擎和数据湖的数据管理系统所支持。用户可自定义日志需要投递的字段和每个字段所需要的字段类型（string/int64/int32/double/float等）。

编辑搜图

• 之后更多的格式orc/avro 已在规划中...

Step4 配置时间选项

• 投递时间：决定任务的生成间隔，投递大小或者投递时间满足任一条件会完成一次投递，所以用户可以根据自己使用场景配置合理的投递时间，比如在用户流量较小的情况下，可选择偏长的投递时间，防止出现过多小文件。

• 开始时间：为开始投递的起始日志收集的时间，可选择ttl-now任意的时间。

• 时区选择：时区选择会影响到最后具体的分区partition路径。

编辑搜图

最后点击确定启动

Step5 投递概览和任务管理

在配置结束后会跳转到数据投递概览页面，也可以在 作业 - 数据投递(新版)中找到创建的任务。

编辑搜图

我们可以在基础信息中预览基础的配置，如选择的日志库和OSS bucket等。在这个界面我们可以停止任务和启动任务，当然也可以点击修改投递配置，来直接一键重启任务。

点击修改好投递的配置后，点击 修改配置并重启作业 即可，此时状态会进入重启中，可点击刷新确认是否重启完成。编辑搜图

统计报表

数据投递作业内基础信息下方是统计报表内容，包含了以下内容。

编辑搜图

读取日志监控overview，监控了一定时间段内数据读取的数据条数和公网流量。

投递数据overview，监控了一定时间段内数据投递成功的条数和公网流量

注意：目前尚未支持跨region的投递，所以目前公网流量都为0。

处理速率观测，监控了一定时间段内的处理速率，可用来观测日志流量和处理能力的变化。

编辑搜图

任务进度观测，监控了一段时间内每个处理实例的延时，可用来观测数据投递的近实时性。

编辑搜图

运行细节：包含运行状态与运行异常。我们可以通过运行状态来查看数据读取和投递的实例、数量、耗时和额外信息等，比如OSS投递的额外信息还会展示投递的名称和大小等。运行异常包含了处理的异常信息，用户可以根据异常信息来判断是否是参数配置错误或是运行过程异常等问题。

编辑搜图

配置报警

用户可以在告警中心中找到SLS数据投递预置规则中添加和开启报警。目前SLS内置了五条数据投递的监控报警规则，分别是：

• 数据投递延迟监控：根据每个投递实例的延迟，超过一定阈值进行报警。可以通过这个判断是否数据投递的近实时性变差，方便监控问题产生。

• 数据投递流量（绝对值）监控：对一段时间内的投递数据量进行监控，低于一定数据量的时候报警。

• 数据投递异常报错监控：对一段时间内的出现的异常报错进行监控，超过一定阈值时报警。

• 数据投递失败条数监控：对一段时间内出现的投递失败条数进行监控，超过一定阈值时报警。

• 数据投递流量（日同比）监控：对一段时间内的数据流量与前一日进行比较，超过一定阈值时会报警。

编辑搜图

这五个报警监控包含了运行中可能出现的大部分异常情况：运行异常、有部分数据失败、处理延迟、流量异常（过低或者波动过大）。用户还可以配置具体的行动策略，可以通过钉钉或者其他渠道实时地通知触达。

编辑搜图

总结

SLS提供了开箱即用的OSS数据投递入湖功能，而且，我们在收集到用户一些需求痛点后对原有投递功能进行了升级，也方便未来拓展更丰富的格式和功能支持；在可观测性方面，增加了整个数据链路的仪表盘和告警，即使此功能是数据链路无需用户搭建、开箱即用的，对用户来说也绝不是一个黑盒。SLS也将继续完善日志投递入湖的体验，增强增强更多的格式：入湖模板扩展 zstd/gzip/avro/orc 等新压缩方式/格式支持，优化 parquet 构建模式，提升湖分析效率、降低湖存储成本；更灵活的投递调度：例如每天凌晨 1 点，定时投递[now-31day, now-30day)的数据到 OSS，实现无缝的冷（OSS）、热（SLS）存储。希望能够帮助用户使用SLS发掘日志价值，助力业务发展。