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

日志大数据下的鱼和熊掌

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

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

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

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

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

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

数据系统架构

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