一、日志与数据湖的联系

日志是大数据的重要载体，包括：工业传感器数据、日志文件、Prometheus 采集的云原生应用指标、Syslog、网络流日志、点击日志、stdout、移动端埋点等等。近十年来，日志数据的规模、种类在快速增长。

围绕企业的生产、运营，大量的 IT 系统依赖日志数据作为生产资料。在日志的生命周期中，会涉及很多技术：

• 实时摄入：采集、集中化。
• ETL：预处理。
• OLAP：交互式分析。
• Map-Reduce：大规模离线数仓分析。
• 流计算：实时业务大屏等。
• 搜索：DevOps 场景必须品。
• 数据湖：低成本、可扩展的存储底座，多样化的分析生态。
• 可视化：数据洞察。
• 告警：包括传统的规则告警、AIOps 智能巡检。

在这其中，数据湖技术兴起已有十年，在日志数据生态中已然不可或缺，有以下切入点：

• 日志数据种类繁多，缺乏 schema 规划，湖提供了包容性。
• 大量的日志具有写多读少的特性，schema-on-read 相比 schema-on-write 牺牲一些性能，但保留了 raw-text 的灵活性。
• 伴随着日益严格的合规要求、业务日志数据精细化分析需求，一些日志数据未来可能是十年留存，极低成本的存储底座是湖的强项。
• 过去研发、运维才关心的日志，现在分析师、运营等新角色也加入到使用者行列，对计算提出更多样化的需求。湖上的生态广泛，覆盖：机器学习、实时计算、离线分析、数据下载、搜索等。
• 存、算分离在大规模数据集上获得成功，做大池子规模释放成本红利，可以匹配日志的急速增长趋势。当前云端算力不断扩张，结合湖加速器、缓存的应用，让过去面向 Locality 的设计技巧不再是刚需。

数据湖是一种逻辑上的存储系统，本文要介绍的是逻辑存储的 Input 部分。即如何做到端到端（End-to-End）的数据入湖。包括：

• 从企业的各个地方采集、摄取数据，包括程序运行日志、app 埋点、Trace 数据、设备指标、数据库业务数据、SaaS 服务数据等。
• 清理、丰富源数据并将其转换为可满足不同业务方需求的高价值数据。
• Serverless 服务提升交付效率，提供多样化的入湖模板匹配数据湖存储、分析需求。

阿里云提供的企业级数据湖解决方案，存储层基于阿里云对象存储 OSS 构建，本文的入湖内容即围绕着 OSS 展开。

二、日志入湖方案

采集器直接入湖

在日志产生的地方将数据直传 OSS，常见的方式有：

• 自建程序：基于云厂商提供的 Open API（SDK），业务方在自己程序里定制数据处理与上报逻辑，需要处理好异常重试（QuotaExceed、UnAuthorized、InvalidObjectName 等错误码），有一定代码适配代价。
• 开源软件：日志领域里流行的有 Flume/Logstash/Beats 等，插件多、生态广泛，缺点是可靠性、性能上的背书。

计算引擎入湖

利用计算引擎的 connector 能力，读取源数据后写到对象存储：

• 开源：例如 Flink CDC 方案，支持实时摄入数据库数据，在错误容忍、数据重放上有局限。
• AWS Lake Formation：用 Glue（底层是 Spark）做数据入湖，可以搞定 PasS/IaaS 类型（Kinesis、DynamoDB 等）的数据源。
• 阿里云 DLA：支持 DBaaS（MySQL、AnalyticDB、Lindorm 等数据库）数据编排入湖。

队列存储入湖

借助持久化的 Queue，解决了数据入湖的的可扩展性、容错性、集中化需求，方便构建统一的数据接入中台：

• 开源：Kafka/Pulsar/RocketMQ，凭借其多年构建的丰富生态，有比较多的生产者可以使用，配合 Kafka 的 OSS sink 插件完成入湖过程。
• 云厂商：阿里云 SLS、AWS Kinesis Firehose 为代表的企业级 Hub，为用户提供 Serverless 方式入湖支持。

迁移工具

满足自建或混合云场景数据上云、迁移需求：

• 对象存储工具：例如 ossimport 可以部署在服务器上将其它云存储的数据迁移到 OSS。
• Hadoop 生态：有较多成熟开源工具，可以在 EMR 上平滑地做 Hive/HDFS 等数据迁移。

三、日志入湖的挑战

类型众多，分布在异构数据源

• 程序日志在服务器上落盘存储，如何以低耦合的方式采集，降低数据接入成本。
• 基础设施从 IDC 迁移到云上之后，计算、存储、网络负载所在的云产品（IaaS、SaaS）产生日志、监控如何采集。
• 云原生大发展浪潮，on K8s 应用的 stdout/log/metric 采集方式有别于传统服务器场景。
• 线下、混合云下的 Hadoop 生态数据存储，大规模迁移与业务平滑过渡。
• 数据库（MySQL、PG、Redis）中的业务数据，包括开源和云厂商托管的服务。
• 摄入在开源软件（Elasticsearch、Kakfa）等软件服务中的数据。
• 摄入在云厂商托管存储系统（例如 S3）中的数据。

日志数据产生的环境复杂、多样

• 例如手机 app 数据采集场景，在复杂环境（弱网、机器时钟错误等）下如何提升采集覆盖率。
• Trace 数据埋点怎样实现自动化。
• 嵌入式设备的设计功耗低、内存小，需要低资源占用的采集方案。
• 非服务端（手机、H5 页面、IoT 设备）产生的数据是易失的，采集端要简单可靠，把数据送上来。

流量大、呈现周期性波动

• 日志流量特征与业务是强关联的，峰、谷相差 5 倍以上，入湖链路需应对流量高峰，保障数据完整接入。
• 高峰期写进来的数据，如何弹性、低成本地存储、处理，在辅助入湖的同时也能完成一些高频场景（日志搜索、交互式分析、告警等）。
• 大规模（百 TB/day）数据下会放大开源软件的性能、可靠性不足，也对运维人力、硬件供应链提出更苛刻要求。

数据不规整，需要预处理

• 日志前期缺乏规划，导致多个版本的格式定义，如何在以统一的数据模型入湖做分析。
• 多种类型日志混在一起，如何清理、丰富再分门别类入湖。
• 一些终端上的日志数据是易失的，预处理引入了复杂性，如何以可重放的方式来兼顾采集可靠性、个性化预处理需求。
• 数据入湖有格式化诉求，例如：计算引擎偏好 parquet 列存，低成本存储喜欢 zstd/gzip 压缩格式，OSS Select 下推要求日志结构化为 csv 格式。

四、SLS 入湖设计

阿里云 SLS 为Log/Metric/Trace 等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、分析、告警可视化与投递功能，全面提升研发、运维、运营和安全等场景数字化能力。

SLS 的队列功能及上下游生态可以为日志入湖提供端到端的支持，要修高速公路（PaaS/SaaS 数据源），也要去做“村村通”（端、开源软件）。

SLS 入湖支持包括四个部分：

• 可靠的采集能力覆盖
• 弹性的写入与存储能力
• 日志 ETL 与入湖准备工作
• 围绕湖生态的模板支持与一键入湖

统一接入

采集是 SLS 的传统强项，覆盖以下场景：

• API、移动端：以 API 为基础，衍生出 Producer（帮助处理异常重试、支持数据缓冲机制）、Logger Appender（可以在 Logback/Log4j 上直接配置使用）、Web Tracking（适合不鉴权场景，网页上直接埋点使用）。

下图是为 IoT 设备优化的 Producer（Lite 版本），最小化硬件资源消耗：

• 服务器与应用：SLS Logtail 是一款在阿里集团内使用了近十年的日志、指标采集客户端，装机量百万级，具有高性能、可靠的特点。在公共云环境下也做了改良，例如 Logtail 适配网络加速（复用 CDN节点）支持出海游戏客户日志采集回流到阿里云国内 region。

从传统服务器一路走来，Logtail 近年来在云原生应用上也稳定服务了数千个客户，支持全链路实时收集 K8s 应用数据：

• 阿里云产品日志：企业深度使用云产品后，可能会有多种观测需求，例如：通过 VPC FlowLog 分析流量模式、识别错配的带宽、不安全的访问；通过 SLB AccessLog 分析出 UV/PV、客户端地理分布、用户画像。通过 OSS AccessLog 分析出冷热 Object，指导配置冷、温、热存储层。

SLS 提供的阿里云 Lens App 对阿里云上 IaaS/PaaS/SaaS 核心产品提供可观测性，支持主动发现元数据变化、自动数据抓取，以下是一些典型接入产品，可以帮助企业破除黑盒：

• 自建日志存储：提到日志，开源社区的 Kafka、Elasticsearch 在业内有很好的口碑，企业决定上云（出于免运维、省掉预留实例等因素考虑）需要解决存量业务数据搬迁的问题。SLS 支持托管的导入服务，免费地从这些系统中持续复制数据到 SLS。
• 标准协议：SLS 除了标准 HTTP API 以外，也支持 Kafka/Syslog Protocol 数据直接写入，免去了一些老的客户端上协议适配的成本，可以节省掉一组转发数据的 broker 机器。
• 开源软件：Flume/Logstash/Beats 积累下了大量社区用户，在这些软件上插上 SLS-output 插件，就可以用习惯了的开源方式推送日志到 SLS。

弹性、低成本存储

第一个问题：引入队列存储，对于成本有多大影响？

以 10 TB/day（中大型规模）日志写入量计算，设置存储 TTL 为 1 天（可以容忍异常，赢得一天解决问题的缓冲时间），日志采集后即入湖。一天花费 281 元（list price，可再购买资源包、使用大客户折扣）：

• 写入流量：网络上会做压缩（平均为 1/7），264 元。
• 存储费用：存储（压缩后）一天 17 元。

第二个问题：自建成本怎么样？

自建要付出的成本如下：

• ECS 机器：CPU 性能需满足生产者写入序列化、消费者读取反序列化、数据拷贝落盘等开销。如下图的一个日志数据源，峰值流量是低谷时 5 倍，则需要按照峰值预留写入资源，否则会阻塞数据生产者。

• 云盘：3 TB（考虑压缩后再预留一倍余量，防止写满后无法动态存储 re-balance）。
• 运维人力：稳定性、存储负载不均等运维项。

从入湖的角度看，SLS 存储提供了哪些支持？

1. 高可用、高可靠：99.9% SLA；QoS 机制做到 Logstore 级别的流量控制；分布式存储冗余。
2. 高吞吐：单 Logstore 写入能力可以水平扩展，从 0 到 500+ GB/min。
3. 低成本：按量收费，无任何预留成本，不写入数据即不产生费用。
4. 免运维：不操心开源自建的集群热点、broker GC、恶意攻击等工作投入。

SLS 数据转储 OSS 时，OSS 支持小时级申请的高性能 （读、写高带宽）满足 burst 流量需求。

Serverless 预处理

对于归档需求，非结构化数据做个压缩就可以入湖，简单直接。

结构化数据入湖，则要严格遵循：二维表的格式、字段定义，做好入湖需求评估、管理。否则，数据可用性差、没有规范就可能变成数据沼泽。

在大数据领域，为了数据最终可以被发现、查询和分析，一般来说，在使用数据湖架构实现数据分析解决方案时，通常有 75% 的时间花在数据集成上，这里面包括了数据采集和数据预处理。

SLS 提供全托管、免运维的 ETL 基础设施简化数据预处理操作：

1. 与数据写入流量洪峰相对应的，ETL 计算也需要考虑峰值资源规划，SLS 数据加工功能实现了基于流量的并发度控制，shard 数目作为一个参考指标，结合当前整体的资源指标（CPU 使用率等）动态扩、缩容 worker 数量，水平扩展支持每天百 TB 级数据预处理。

例如直播应用的 CDN AccessLog，21:00 ~ 23:00 是业务访问高峰期产生几百 GB 日志，到了凌晨 1:00 ~ 7:00 日志流量跌至高峰时的 20%。SLS 数据加工按真实日志流量收费，不因业务高峰产生预留计算实例费用。

1. 数据加工抽象了一层 DSL，相比 SQL 而言更适合处理弱 schema 日志，同时对于典型场景直接提供算子，有效缩短分析项目中 ETL 阶段的时间。

SLS 服务数万客户积累了许多日志数据预处理的场景，用 DSL 可以方便地实现：

• 复杂的数据规整：在一些旧的软件系统或是业务快速发展但缺乏日志规划的系统里，同一个日志文件内数据格式可能多达 10 种，需要将它们识别出来并分门别类提取字段。
• 数据的分发与汇集：在一个集中管理的数据总线上，运维（日志管理、使用者）、研发（日志打印、使用者）等角色对于对日志有不同需求，将数据做汇集或按条件分发到多个下游再使用，是刚需。
• 数据富化：除了运维、研发外，日志数据正在被越来越多的角色（例如运营、决策者）所依赖。例如将资产表的信息映射到日志内容上，对于后续的数据分析具有重要意义。
• 日志高频处理需求：例如对于 AccessLog 的 request_uri 字段提取资源路径、参数 K-V 对；对 IP 计算 geo 信息；对日志内容中密码、邮箱做脱敏处理等。

DSL 编排组合可以用于解决较为复杂的问题，灵活度高：

1. 数据加工基于 SLS 持久化存储做计算，存、算分离架构。在发生了业务变更（导致加工规则与日志内容不匹配）时，数据加工可以方便地修改 DSL 做任务重跑。在分布式计算节点失效时也能保证 at-least-once 数据处理语义。这种模式对于重要数据的处理更加友好，为异常发生预留了充足的缓冲措施。

一键入湖

以 SLS Logstore（日志库）为统一的数据接入抽象层，屏蔽了数据源复杂性，Logstore 数据以统一的方式入湖：

1. 入湖使用的数据投递功能是全托管的，提供 wizard 方便创建投递任务。

1. 按量付费，且相比于开源软件（例如 Flink 消费 SLS 数据写 OSS），投递不收取读取 SLS 流量费用。
2. 多个入湖模板（持续增强中），目前已支持 json/csv/parquet 格式，也可以开启压缩，让存储更好地匹配计算（湖分析）。
3. 投递出去的对象文件支持 Hive-style 目录设置，数据有效组织起来更方便后续数据引擎的高效扫描。

五、SLS 入湖实践

归档场景

• 背景

某点播服务有客户端和服务端：客户端支持三种操作系统（iOS/Android/Windows），记录应用埋点数据；服务端以 Nginx AccessLog 为主，记录用操作日志（点击、登录、购买等行为）。

需要搭建统一的日志分析平台，支持最近 30 天的数据搜索（问题调查）、SQL 统计与报表查看，其日志量大，最近一年的数据需要归档存储（审计需要）。

• 需求分析

有许多这样的日志冷、热分层场景，近一段时间内的热数据会经常被使用到，伴随日志量的不断增长，访问频度较低的数据可以归档以降低成本。

• 方案实践

服务端日志通过 Logtail 采集，客户端日志通过 C Producer 上报数据到 SLS Logstore。

Logstore 存储周期设置 TTL 30 天，开启索引，实现关键词搜索、交互式 SQL 分析与可视化：

Logstore 开启投递 OSS，启用 snappy 压缩降低 OSS 存储空间：

计算场景

• 背景

某游戏公司，游戏客户端（iOS/Android）因为多个历史版本，上报的事件日志格式也产生了多个版本，记录了游戏 ID、事件类型（登录、登出、购买、金币流转、流量监控等）等信息。

数据中台需要根据游戏 ID 实现日志路由到多个下游存储，并进行日志字段的结构化，结构化之后的数据会进行 Flink 实时计算以及 OSS 数据湖构建，后续也需要在数据湖上建仓分析。

• 需求分析

移动端版本不易对齐，例如多版本日志统一分析需要依赖 ETL 做预处理，加工后的结构化数据可以支持多种下游去消费，包括流计算集成、OSS 投递入湖。

结构化后的数据，可以按列做好压缩，通过 parquet 投递可以节省 80% 存储空间，数据扫描量大大减少，平均分析效率提升 30 倍。

• 方案实践

使用 C Producer 上报数据到 SLS Logstore 存储，之后用数据加工作业做 ETL，实现数据按照游戏 ID 分发到多个下游 Logstore：

预处理后 Logstore 的数据投递 OSS 时，入湖模板设置 parquet 列存格式，按照游戏 ID、日期分区存储：my-app 为 OSS bucket，my-dw 定义为数仓的项目名，my-table 设置为游戏 ID，date = 20210330 为日期分区。

六、SLS 入湖新特性展望

SLS 将持续完善日志数据湖的构建体验，最后，预告一些后续会推出的特性：

• 更多的格式：入湖模板扩展 zstd/gzip/avro/orc 等新格式支持，优化 parquet 构建模式，提升湖分析效率、降低湖存储成本。
• 增强的可观测性：为数据采集、投递提供统一的管理视图、数据行数同比、诊断日志、异常告警等。
• 更灵活的投递调度：例如每天凌晨 1 点，定时投递[now-31day, now-30day)的数据到 OSS，实现无缝的冷（OSS）、热（SLS）存储。
• 强化数据自动发现：实现元数据的自动发现，提升采集覆盖率。

您可以通过以下方式联系我们：

• 钉钉（SLS 用户交流群）

• 微信、B 站