日志大数据下的鱼和熊掌

咱们正处于大数据、多样化数据（非结构化）的时代，实时的机器数据快速产生，作一家数据公司的核心之一是如何充分利用好大量日志数据。
由此背景，对日志的采集、存储、分析、管理也提出了更高的挑战，其中包括鱼和熊掌的选择问题：html

鱼：成本高昂可能致使数据被删除，由此错过了价值发现。在数据量快速增加的同时，客户要保留更长时间的日志，还但愿在相应场景降低低存储成本一半或更多。
熊掌：实时数据占机器数据的比例逐步增长，在实时价值愈来愈受重视的今天，客户但愿继续获得交互式、一站式的体验。

鱼和熊掌如何得兼？这里讨论成本与体验的平衡。
阿里云日志服务（SLS）是针对机器数据的一站式服务，为用户提供快捷的数据采集、消费、投递以及查询分析等功能，提高运维、运营效率。
咱们在服务众多客户的时候，观察到在不少场景下，伴随日志量的不断增加，数据呈现出访问热度的差别。例如：正则表达式

机器指标不断地追加更新，但在监控指标仪表盘上，新数据的访问频率远超过一天前的数据。
排查异常时，研发人员经过 tail 和 grep 关注 ERROR/WARN 日志的变化，定位问题每每不须要几天前的程序日志。
数据按业务属性有重要程度之分，大量非生产环境日志数据在7天后被访问几率很低，而最近的生产日志须要被灵活访问到。

本文将为你们介绍在 SLS 上兼顾日志数据灵活性、经济性的存储策略与实践。json

基于数据加工与投递的业务分层

数据系统架构

以 SLB 访问日志处理为例，一个区域下的多个实例数据一般存放在一个全量 Logstore 下（10 秒级延迟）。在该 Logstore 上配置数据加工做业实现数据预处理、按业务标签作数据流转。
错误、高延时的请求，需保证明时查询、快速统计能力，能够规划到一个带 SLS 索引的 Logstore。
其它的全部生产域名请求日志，须要长期存储以备审计、合规，能够转储临时 Logstore（充当桥梁）并投递到更经济的存储。后端

运维数据管道每每比较复杂，SLS 提供的 Serverless 的加工、投递服务，开箱即用。让如上方案实现起来更容易，且具备成本优点。api

数据加工实现预处理

对于 SLB 七层监听的访问日志，URI 字段包含高价值的业务 key-value 字段，UserAgent 字段能够辅助监控各个端上的服务质量、稳定性。
加工前原日志部分字段：服务器

request_uri: /api/get.convert.v2?fn=callback&url=https%3A%2F%2Fmini.yyrtv.com%2Fr%2F80ba436b763b747d.html%3Ffrom%3D320101%26site%3D1
http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3947.100 Safari/537.36

加工 DSL 针对日志规整、抽取场景作处理：架构

经过 e_kv 抽取 URI 中的业务 key-value 对。
经过 ua_parse_all 对 http_user_agent 字符串作自动抽取。

e_kv('request_uri', prefix = 'uri.')
e_set('ua', ua_parse_all(v('http_user_agent')))
e_json("ua", depth = 1, fmt = 'root')
e_drop_fields('ua', '__tag__:__receive_time__')

URI 抽取获得 fn、url 两个业务 key-value 对，使用 e_json 函数对 ua_parse_all 的结果作进一步抽取获得设备、OS、UA 结构化信息。
加工后结果字段以下：less

uri.fn:  callback
uri.url:  https%3A%2F%2Fmini.yyrtv.com%2Fr%2F80ba436b763b747d.html%3Ffrom%3D320101%26site%3D1
ua.device:  {"family": "Other"}
ua.os:  {"family": "Windows", "major": "7"}
ua.user_agent:  {"family": "Chrome", "major": "69", "minor": "0", "patch": "3947"}

数据加工实现数据分流

加工提供算子快速实现多源的数据聚集、同源数据的多目标分发，支持攒批发送（增长吞吐、利于压缩存储）、数据写入异常自动重试。
以下加工 DSL 实现了：运维

若是 RS 处理延迟有值且大于5.0秒，或者状态码非200，这部分数据写入目标 debug。
符合正则表达式的线上域名产生的访问日志，所有写入到目标 product-host。

e_if(op_or(
        op_and(op_ne(v('upstream_response_time'), '-'), op_ge(ct_float(v('upstream_response_time')), 5.0)), 
        op_ne(v('status'), '200')),
    e_coutput(name = 'debug'))
e_if(e_search('host ~= ".*-prod\.com"'), e_output(name = 'product-host'))
e_drop()

源 Logstore 不开启索引并缩短存储周期到 1 天，将上述两段 DSL 保存到一个加工做业运行，数据实时处理后流向两个下游 Logstore：函数

debug：存储周期设置为 30 天，开启索引。
product-host：存储周期设置为 1 天，开启 OSS 投递。

索引计算实如今线分析

SLS 开启 Logstore 索引大大提升了数据分析的灵活性，适合热的数据存储与处理场景。能够完成实时的查询、同步的 SQL 交互、丰富的可视化、基于业务日志的告警。

经过 UserAgent 统计设备厂商、设备 OS 分布

计算后端服务器处理延迟超过 60 秒的请求来源 IP 地理分布

数据投递实现OSS数据湖

SLS 投递服务帮助实现数据在阿里云生态、开源软件上自由流转，破除数据孤岛，提高客户上云的灵活性，下降系统适配成本。
按下图配置，对全量生产域名的访问日志（product-host），在 Logstore 开启 OSS 投递，将数据以分钟级延迟同步到 OSS 存储桶。

SLS 数据投递到 OSS 数据湖上，常见有两种场景：

1.极低成本存储

投递时配置开启压缩以下降对象文件大小（日志通常为5~15倍压缩比），数据长期冷存储甚至能够选择归档存储类型或低频访问存储类型 OSS bucket。

2.数据湖存储，兼顾中低频分析

SLS 投递 OSS 提供行存（json/csv）格式、列存（parquet）格式选择，能够根据自定义 key 列表来构建文件。
根据计算引擎（Spark、DLA 等）的特性，选择适当文件格式，能够在计算效率和成本之间取得一个平衡。
例如，使用 OSS select 指定对象文件作简单的数据查询，基于 OSS 的多种存储、计算分离实践均可以经过 Select 作加速。

总结

随着业务场景支持的逐步深刻，在 SLS 目前有如下存储实体：

LogHub：流式存储，提供实时 pub/sub 能力。
Index：倒排索引、列存等，支撑交互式查询体验。
Metric：针对指标数据特征，作到高效存储、读取效率。
外部存储：OSS、RDS、MaxCompute 等，能够做为投递目标或是富化日志的源头。

多个存储实体之间，经过连线能够实现数据的流动分层。
在日志数据融合、价值释放、高效利用的道路上，SLS 数据加工、投递持续作好管道服务，知足更多样化的场景需求。

原文连接

本文为阿里云原创内容，未经容许不得转载。

基于实时ETL的日志存储与分析实践