日志数据入湖的设计与实践

一、日志与数据湖的联系


日志是大数据的重要载体,包括:工业传感器数据、日志文件、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 站

日志数据入湖的设计与实践

上一篇:重拾Java(0)-基础知识点


下一篇:Java刷题知识点之内存溢出和内存泄漏的概念、区别、内存泄露产生原因、内存溢出产生原因、内存泄露解决方案、内存溢出解决方案