概述
过去一年，SLS团队持续对数据加工服务进行了各方面迭代升级，本文总结了相关功能与技术上的进展。
SLS数据处理链路
上图是从数据处理链路的角度对SLS的描述，其中包含两个方面。
一方面SLS本身是一个开放的日志数据平台。用户可以通过开放API，把其存储在 SLS 的数据与已有的大数据平台连接起来，这一点与阿里云上很多大数据产品也有紧密合作。另外今年 iLogtail 开源（GitHub库）、阿里云Terrform集成、阿里云统一CLI等等都在推动SLS越来越开放化。
另一方面SLS为客户提供一站式数据处理链路服务，支持客户快速完成非结构化数据实时加工处理。如上图所示，整个数据处理链路包含四个功能点：
- 数据导入：打通阿里云上客户自建服务、外部开放服务与SLS的无缝对接
- 数据加工：对数据进行实时行处理、以及链路编排
- Scheduled SQL：对数据进行定时分析、聚合加工
- 数据导出：围绕“数据入湖”等场景给出相应的技术实现与解决方案
本文重点将放在数据加工上。
数据加工
应用场景
这里我们总结下数据加工的常见场景（具体场景很多，这里仅列出典型、常见的场景）：
规整：这是使用频率最高的场景，比如从文本日志数据中提取出关键信息，将其转为规范化的数据
富化：比如用户的点击数据中只包含商品ID，在分析时需要从数据库关联起详细信息
脱敏：随着我国信息安全相关法律的完善，对于敏感数据（比如个人信息）的处理要求越来越高
分裂：在数据写出时，出于性能、便捷性考虑会将多条数据合并输出，在分析前则需要拆分出独立数据条目
分发：将不同类型的数据分别写到不同的特定目标中，以供下游定制化使用
用户接口
SLS数据加工语法DSL (Domain Specific Language)是一个基于Python语法的子集，提供了完善的内置函数。详情请参考 SLS数据加工语法简介
2021年改进详情
架构升级，免除同地域下数据读写费用
SLS数据加工正在逐步进行架构升级，充分发挥SLS一站式数据平台的优势，数据加工功能从同地域内Logstore读取及写入数据将不再需要在不同服务模块间数据流转。
本次架构升级正在内侧中，即将发布。发布完成后，SLS团队将通过官网等渠道向用户公告。
加工引擎性能增强
随着客户日趋增长的数据量、复杂多变的数据加工计算，数据加工服务引擎在一些场景下需要更加灵活和弹性，例如：
- 复杂的需求场景导致计算复杂度不可控，要求更强的单点计算能力
- 原始数据流的模式不可预知，要求作业的算力伸缩过程极其灵敏
SLS数据加工作业执行性能依赖多方面因素，详情请参考SLS数据加工性能指南。例如在游戏业务场景中，面对开新服活动时的流量高峰，数据加工作业运行需要更高敏感度的自动弹性扩容，保持高效实时性的处理高峰流量的游戏日志。
以下总结过去一年对数据加工性能相关的几个核心迭代。
1. 数据协议层
数据协议层的优化分为两个部分：
- 序列化、反序列化算法实现优化
数据协议层，也就是从SLS消费的原始数据是Protobuf协议的LogGroup，需要反序列化为单条原始事件；加工后的数据需要根据Protobuf协议进行序列化才能写入SLS。数据协议层作为基础公共代码模块，对所有作业的执行效率有关键作用。通过对一些核心模块用C++重写，在特定场景下性能提升了5倍。 - 新增小包合并发送协议
在数据发送阶段，序列化操作是基于数据的元信息（比如 time、source、topic、tags）组装数据包独立发送，当遇到原始数据的元信息无规则的场景时（比如WebTracking采集数据），就会出现大量小包发送数据，导致网络传输效率不足。数据加工合并处理因元信息不同而无法合并的大量小数据包，这种场景下单次上传提升网络传输效率10+倍。
2. DSL 执行层
DSL执行层是数据加工作业运行的计算核心，过去一年我们通过多个方面对DSL执行层进行了优化，以下列出一些重点的优化项：
- DSL解析器，”预编译”加工脚本
- 编译优化
- 逻辑短路
- 数据模式Lazy-Parse
- 多级缓存
- 公共子表达式提取等
3. 内置函数层
针对客户场景中高频使用的内置函数进行深入优化，这里不做赘述，部分优化请参考技术博文。
数据加工DSL编译优化：搜索算子语义等价转换
数据加工DSL编译优化：公共子表达式删除
系统稳定性保障
1. 集群迭代升级，集群内作业无感知
SLS数据加工是构建在阿里云容器服务ACK之上，得益于其部署简单高效、安全可靠的优势，数据加工的技术架构非常直接。由于集群中运行大量线上作业，集群升级过程对于作业有潜在影响，所以集群升级需要一个确保线上作业稳定性的方案。这一点也导致了集群的升级无法频繁操作。
为了能够应用到集群最新版本的新功能，集群的升级就势在必行。集群升级有以下两个方案。
一个方案是使用ACK的集群热升级功能，其提供升级、暂停、取消等能力。不过对于数据加工的业务场景，此方案存在几个缺点：
- 升级时集群中所有作业都可能受到影响，所以总体来说达不到“可灰度”的稳定性要求；
- 升级过程中一旦出现问题就需要回滚，作业在整个回滚过程中可能都无法正常运行，客户的数据链路将会被阻塞；
- 每次升级只能升级到相邻版本，所以需要多次升级操作，这不仅增加了工作量，而且几何级的提高了升级风险。
另一个方案是在调度层实现多集群负载均衡的能力，需要升级集群时，将新建作业创建至新集群，逐步地将旧版本集群汰换掉。此方规避了集群热升级潜在的风险，但是新旧版本集群会同时存在很长一段时间，这使得运维工作也不小，这也驱动我们进一步完善运维自动化。综前所述，最终选择的是此方案进行升级。
2. 近百个集群统一化监控运维、告警
如上所述，SLS数据加工是区域化部署，同时单区域内存在多集群负载均衡，目前已经有近百个集群在线上运行。
为了保障所有集群的稳定运行，我们通过SLS全栈监控应用的指标统一采集与存储方案，实现所有集群的统一监控。
结合SLS告警功能，任何一个集群在任何时间点出现异常事件，都可以及时通知到运维人员进行排查。
3. 自定义伸缩计算指标，满足不同场景的计算需求
原生的K8S HPA内置支持CPU和内存两个指标，这对于绝大多数数据密集型作业来说已经足够了。但是在数据加工中，某些客户会对数据编排，进行跨地域数据流转，面对这类网络/IO敏感场景，内置的HPA指标就无法满足。所以我们需要引入更全面的HPA指标，以支撑多种多样业务场景下的作业需求。
除此之外，我们还将使用智能算法对HPA指标进行续升级优化， 比如基于作业的历史运行特性，提前做资源分配，更进一步提升作业运行的稳定性。
4. 内置告警规则，客户一键开启作业监控
数据加工与SLS监控告警能力整合，用户可一键开启加工作业异常告警，接收到告警后可通过手册排错处理。
- 在控制台上配置加工作业后，默认引导用户开启告警通知，模板化、一键开启。
- 支持加工流量同环比、错误日志信息、数据处理延迟等多个维度通知，覆盖全部异常场景
具体使用请参考 为数据加工任务开启监控告警
用户体验提升
1. DSL语法简化，开放Python字典、列表和元组常量
SLS数据加工在保证安全性的同时，也在持续增强DSL的语法能力，使其更加Pythonic、更加简洁易用。最新的语法可参考 SLS数据加工语法简介，以下就以Python字典常量使用作为例子。
模拟HTTP访问日志：
method: 101.37.0.0
request: GET /product/8396812?from=source-2 HTTP/1.1
http_status: 200
我们需要HTTP状态码的具体描述信息，详情如下：
method: 101.37.0.0
request: GET /product/8396812?from=source-2 HTTP/1.1
http_status: 200
http_description: OK
可以直接在代码中嵌入完整的HTTP状态码表，用于字段映射：
e_dict_map(
{
"100": "Continue",
"200": "OK",
"300": "Multiple Choices",
"400": "Bad Request",
"500": "Internal Server Error",
},
"http_status",
"http_description",
)
2. IP地理解析库精准度进一步提升，更大程度挖掘数据价值
IP是日志数据中重要的信息，比如访问客户端的IP就可以用于完成用户画像的分析。
SLS数据加工支持开放式的对IP地址数据的地理位置（GeoIP）进行解析，并内置了GeoIP库方便客户使用。通过调用数据加工预定义函数geo_parse即可实现，参考以下例子。
某系统的模拟访问日志样例：
client_ip: 101.37.0.0
request: GET /product/8396812?from=source-2 HTTP/1.1
http_status: 200
通过以下数据加工代码获取client_ip字段的IP地理位置信息：
e_set("_geo_", geo_parse(v("client_ip")))
加工后的结果：
client_ip: 101.37.0.0
request: GET /product/8396812?from=source-2 HTTP/1.1
http_status: 200
_geo_: {
"country_en": "CN",
"province_en": "330000",
"city_en": "330100",
"country": "中国",
"province": "浙江省",
"city": "杭州市",
"isp": "阿里云",
"lat": 30.294,
"lon": 120.162
}
客户通过geo_parse函数也可以使用自定义的GeoIP库，参考文档 IP解析函数
3. Terraform集成，作业编排自动化
使用Terraform可以对云上资源进行编码，利用代码来进行增删查改。阿里云已经集成Terraform，便于客户安全高效地预览，配置和管理云基础架构和资源。通过Terraform，客户也可以 方便的管理 SLS 数据加工任务配置。
详情请参考：
场景深化、最佳实践总结
SLS数据加工从客户场景角度出发，对一些典型场景的解决方案进行深度总结，这里进行完整汇总。
应用场景 |
实践总结 |
简要说明 |
信息脱敏 |
随着数字化的推进，个人敏感信息保护显得越来越重要，通过数据加工可实现敏感信息的脱敏处理 |
|
数据流编排 |
数据加工支持跨区域数据复制，客户可选择通过公网传输，也可以针对SLS Project开启全球加速服务，确保更稳定的传输效率 |
|
数据编码、解码 |
数据加工提供完善的内置函数，支持各类数据转化场景：编码与解码、压缩与解压缩、加密与解密、哈希摘要 |
|
阿里云威胁情报服务集成 |
数据加工提供内置函数扫描数据内容是否存在威胁情报，比如检查访问 IP 是否存在攻击行为 |
|
Log转Metric |
某种程度上来说，Metric是一种特殊的Log，数据加工提供内置函数将Log中的指标信息转化为Metric |
其他参考
过去一年里，SLS也多次参与开放社区、大会的专题分享与讨论SLS加工服务的技术原理与实践。以下是最近几次与数据加工相关的专题分享。
- 2021 QCon（北京站）
- 2021 K+峰会（上海站）
- 2021 Python Meetup（杭州站）
总结
在过去一年里，SLS数据加工在系统性能、稳定性保障和用户体验提升多个角度持续投入，获得一定的结果。另一方面，在与客户深入沟通需求场景后，也总结出多个最佳实践，以供用户参考。
接下来的工作中，我们依然会在以上几个方面持续深入，为云上客户提供更稳定、更便捷的数据加工服务，同时也将会致力于建设更开放的平台。
