成喆 2019-06-10 05:47:16 浏览 33 评论 0
etl
函数
SQL
日志
Image
钉钉
索引
数据加工
数据规整
摘要: 日志服务新功能: 数据加工上线!, 提供一站式免运维的数据加工服务, 具备行业中的数据加工的大部分能力, 并具备灵活的扩展能力, 内测阶段免费, 欢迎试用.
概述
日志服务的数据加工功能上线了! 目前内测阶段, 欢迎试用.
条件
区域: 北京, 上海, 英国
目前在内测阶段, 申请内测, 可请提工单, 或者通过加钉钉群 11775223 @成喆 @唐恺 申请
解决问题
行业上数据加工的痛点
行业上 80% 的数据分析花费在数据规整上, 数据在接入, 分析, 投递, 对接时存在各种数据加工的需求与痛点
数据源混合各种格式, 难以简单提取, 如交换机, 服务器, 容器, 程序 Logging 模块等, 通过文件, stdout,syslog, 网络等途径收集的数据, 混合了程序的各种格式的日志; 如日志中的 message 字段, 需要根据各种情况的正则匹配后提取;
单一场景, 字段动态且不确定, 例如 NGNIX, 的 QueryString,HttpCookie,HttpBody 信息中的字段, 需要用自动 KV 或者多种正则提取;
源数据包含动态 JSON 格式的数据(如 CVE 数据, O365 Audit 日志等), 需要动态计算, 提取合并字段, 甚至分裂为多条日志进行处理;
某些常规日志包含了敏感信息(例如秘钥的密码, 用户手机号, 内部数据库连接字符串等), 很难在提取时过滤掉或者做脱敏.
使用简单表格, CSV,OSS 文件, RDS, 外部 API 等进行数据富化.
数据量过大, 需要做聚集(如将 5 分钟的多条网络连接数据, 根据机器聚集成几条)
日志服务中数据处理的痛点
在数据加工上线之前, 我们发现, 日志服务的用户在各个阶段存在如下痛点:
1. 数据接入时
单一源包含多种格式, 难以提取分发:
交换机, 服务器, 容器, Logging 模块等, 通过文件, 标准输出, syslog, 网络等途径收集时, 里面是各种日志格式的混合, 只能做部分提取, 例如使用 logtail 先提取某些基础字段, 例如时间, log level,IP 等, 但是日志主体 message 中很多有价值的信息因为混合了各种日志, 无法在导入时提取
期望根据特定格式接入到不通目标时, 难以实现
特定格式内容复杂多变, 难以提取:
例如 NGNIX, 的 QueryString 中的字符串, 或者 HttpCookie, 甚至 HttpBody 信息等, 里面字段内容变化巨大, 格式信息复杂度也很高, 难以在提取的时候一次性使用正则表达式完成提取.
某些复杂 JSON 递归深度
某些常规日志包含了敏感信息(例如秘钥的密码, 用户手机号, 内部数据库连接字符串等), 很难在提取时过滤掉或者做脱敏.
某些 JSON 日志信息包含多条日志, 需要分裂为多条日志进行处理等, 但无法操作
其他方法例如使用 SDK 规则后再上传, 通过 Logstash channel 转换后导入等方法试图解决时, 事情变得复杂, 数据收集的性能也变得更慢
2. 查询分析时
接入后的数据, 用户普遍使用 SQL 进行数据加工, 存在以下痛点:
常规数据加工用 SQL 实现复杂冗长, 难以编写, 脆弱与维护:
常规简单的字段梳理, 正则提取, 富化等难以编写
源日志稍有变化即出现执行错误
过长的 SQL 难以理解, 修改与维护
性能慢, 数据量大或 SQL 复杂时, 很容易超时:
经过字段计算的 SQL 失去索引优势
大量 Metrics 数据在 groupby 后跨长时间范围比较耗时
字段长度超过 2KB 时不支持计算
SQL 单个字段索引在 2KB 内, 超过部分不支持, 但超长字段普遍存在
无高级函数支持下, 高级规则处理需求无法实现:
各种格式混合, 动态字段等无法用 SQL 实现
日志分裂, 特定逻辑计算 (如 UserAgent/SQL Pattern) 无法实现
自定义聚集计算不支持
3. 归档时
投递到 OSS,MaxCompute 等并不支持内容上的过滤或者格式转换
4. 对接外部系统时
可以在其他系统 (例如 DataWorks,FunctionCompute) 等中将日志导入进行规整后再导回日志服务, 但在整个过程中因为要解决编程, 配置, 调试等方面的工作, 相对要耗费不少功夫.
主要支持场景
场景 1 - 数据规整(一对一)
场景 2 - 数据分派(一对多)
场景 3 - 多源汇集(多对一)
场景 4 - 常规数据数据加工场景
提供了 150 多个内置函数, 不需要写代码即可完成主要加工任务, 同时提供灵活自定义函数 (UDF) 的能力, 满足各种场景:
过滤(filter): 将特定的日志去掉
分裂(split): 将一条日志变成多条
转换(transform): 字段操作, 内容转换等
富化(enrich): 关联外部资源, 丰富字段信息等
聚合(Rollup)(待上线): 特定维度做聚集, 减少日志量
自定义操作(待上线): 以上自定义操作, 如 SQL 模式解析, 自定义 Agg 操作等
优势
更快速简单的接入: 通过 logtail 等各种渠道, 只需要用最简单的方式接入一个无索引, 短期存储的 logstore 即可.
更快的查询与更灵活的分析: 通过开箱机用的规则与简单的语法, 即可完成复杂的加工, 并使得加工好的数据基于索引可以跟快的分析; 分析的 SQL 不再冗长, 低效与难以调整.
更多业务场景的可能: 通过数据加工的富化, 自定义加工等, 可以进一步挖掘数据的价值, 构建更高级的业务
更灵活的投递与生态对接: 可以更简单的配置符合生态需要的规则
一站式托管的数据加工方案, 免运维, 自动扩展
其他常见问题
费用问题
加工服务本身消耗的机器与网络资源目前免费, 但读取源 logstore 与写入目标 logstore 按照日志服务的标准正常收取.
根据情况, 可以关闭源 logstore 的索引, 并设置较短的保存时间.
参考
欢迎扫码加入官方钉钉群 (11775223)获得实时更新与阿里云工程师的及时直接的支持:
来源: https://yq.aliyun.com/articles/704935