阿里云实时数据加工服务的设计及实践

云布道师

于 2021-06-30 19:20:26 发布

阅读量1.1k

点赞数

文章标签：大数据数据库 java 人工智能编程语言

本文链接：https://blog.csdn.net/bjchenxu/article/details/118383957

版权

凌云时刻

编者按：作者王彬（花名蓝雁），技术专家，现供职于阿里巴巴云智能事业群日志存储团队，负责阿里巴巴集团、蚂蚁金服、阿里云和外部客户等全站日志的数据加工服务的性能优化及功能开发工作，每日处理 PB 级别的数据。目前主要关注流式计算、编译优化、异常检测等技术，发表专利30余项。本文根据作者出席QCon全球软件开发大会的演讲整理而成。

本次分享主要介绍阿里云超大规模下实时数据加工服务的应用场景、架构设计、性能优化等全方位技术设计，以及多个最佳实践方案。

问题

优秀程序员都有一个共同的习惯，打日志！一方面，日志可以供自身使用，比如排查程序错误、跟踪数据链路等等；另一方面，日志还可以供数据分析师等其他人使用。

通常，各个数据分析师的关注点不同，对原始日志的格式和内容需求往往不同。针对上述场景，根据数据分析师的不同需求，修改打印日志的程序代码，线上运行环境可靠性风险高，程序员工作量大。为保证日志的一致性，所有线上机器均需升级到最新程序，实时性较差。

除了上面提到的程序员打印的日志外，还包含硬件设备运行监控消息、网络流量包、数据库操作记录和nginx转发日志等等，日志来源的多样性引发了日志样式的多样性。最为常见的日志格式是字符串，字符串具有非结构和无schema的特征。也就是说，数据分析师通常无法直接使用原始日志。

业务场景

收集大量客户的数据加工需求得知95%都是行处理场景，包含数据规整、数据分派、数据富化三大类。

数据规整。数据规整是数据分析的前提，对混乱格式的原始日志进行字段提取、格式转换，获取结构化数据以支持后续的流处理、数仓计算。
数据分派。通常各类日志的重要性不同，不同类型日志的存储时长不同，数据分派能够将全量日志按转发规则分别提取到多个下游存储供不同业务使用。
数据富化。原始日志信息有限，为打通关联业务数据，数据富化可以将日志（例如业务订单）与维表（例如用户信息MySQL表）进行字段join，为日志添加更多维度信息供分析。

现有方案

采集端系统、数据库系统、批量计算系统、流式计算系统是常见的数据加工实现方式。

采集端系统。在采集阶段利用机器资源完成一定程度的预处理，不需要专用计算集群做预处理。复杂处理逻辑会造成数据源采集延时，延时过大可能会丢失原始数据。不保存原始日志，会影响错误回溯的准确性，由于配置散落在众多机器上，加工逻辑变更或作业运维大多依赖机器上操作，维护较为复杂。
数据库系统。多用于存储清洗后的数据，用于在线服务场景。存储结构化数据，内置函数有限，复杂场景扩展内置函数难度较大。
批量计算系统。以可扩展的计算和海量存储能力，解决了大数据分析难题。在延迟敏感型业务占比越来越大的背景下，离线系统的延迟高、交互性差。
流式计算系统。让数据加工变得实时化，定位于通用场景。需要编写较多的程序代码实现自身业务逻辑，且维护集群成本较高。

设计目标

易用性。为实现上述数据规整、数据分派和数据富化三大业务场景，设计了一种特定领域语言DSL。客户仅仅编写简洁的DSL，即可实现复杂业务需求。
云原生。多租户，弹性伸缩，免运维，按量收费，成本较低。
高性能。采用语义编译优化和较优的运行时数据结构，增强了执行效率，缩短了数据加工延时，提升了实时性。

利他

日志生命周期包含数据摄取、日志集中化、多元存储和业务分析。多种业务分析需求，需采用不同的存储单元，进而也对数据加工提出了多种需求。数据加工使下游的多元存储空间和业务分析均带来了帮助，不完全统计，数据加工使对象存储OSS存储节省了80%，而且列分析效率提升了30倍，数据扫描较少了95%。

整体架构

数据加工采用了主从架构，master负载调度和检查点协调，worker包含日志服务客户端、DSL优化器和DSL执行器，采用了k8s技术的资源管理器能够根据资源利用率自动伸缩，工具库提供了调试环境、告警和API。并且，master和worker之间采用了心跳机制以保证worker的高可用，当worker出现异常时，master会自动重启此worker。

易用性设计-DSL

通用语言（Python）实现方式，需要自己编写代码实现输入函数、业务逻辑、输出函数三部分，一个简单通用的过滤字段需求往往需要100行以上的代码量，运维较为复杂，对数据分析师而言写代码几乎是不现实的。

SQL只能处理结构化数据，采用嵌套查询的方式实现复杂业务逻辑，实现一个过滤正则模糊字段需求的存储过程难度较大。

数据加工DSL提供了30多种场景方案、200多个内置函数、400多项GROK模式，内置函数包含转换、分发、分裂、复制、富化五大类，并且内置函数之间没有前后强依赖关系，可以自由编排，由此客户只需以函数调用的方式编写DSL即可实现复杂业务需求。

云原生设计

数据加工采用了云原生设计方案，具有多租户、弹性、Serverless特性。

多租户。用户数量大，隔离性好，数据量大，每天处理PB级数据。
弹性。日志服务Logstore具有Append Only写入的特性，可以满足业务高并发、高吞吐需求，此功能类比kafka。由于业务特征，日志流量也呈现周期性波动，比如上下班时间某些业务用户访问量大，凌晨几乎没有用户访问，上班时间访问量适中。适中时采用两个shard存储，高峰时存储自动扩大为5个shard，低谷时只需采用1个shard存储。数据加工的work会根据存储动态伸缩，适中时采用两个worker计算，高峰时存储自动扩大为3个worker计算，低谷时只需采用1个worker计算。如果采用自建方案，通常需按照峰值购买硬件设备，相比而然，数据加工服务成本较低，业务流量增长也能自动应对。
Serverless。服务化、全托管、免运维、按量付费，客户无需投入运维成本，使用较为简单。

高性能设计-DSL编译期优化

数据加工服务客户多，各个客户的业务需求较为复杂，DSL灵活性强，由此导致数据加工作业数量较多，且数据加工作业内容差异较大。

由于数据加工采用了按量收费，优化门槛较高，客户性能优化积极性不高。客户往往只关心正确性的问题，而不会关心性能，出现了问题再去解决，后知后觉，客户体验较差。如果采用研发人员手动优化的方式提升数据加工作业的执行效率，工作量巨大，成本极高。由此，采用编译技术将“优化意识”自动化是一种较优的DSL优化解决方案。

上面数据加工作业的原始DSL包含大量的重复函数，比如v(“content”)和其包装函数json_select(v(“content”), “Content”),经过优化后会把这些公共子表达式抽出为临时变量，依次消除部分冗余函数计算。此优化的步骤包含词法语法分析、函数影响识别、字段版本同步、唯一标识生成、公共变量替换和优化代码反馈。上面的例子相对比较简单，真正实现时会涉及到作用域的相互覆盖的场景。

高性能设计-DSL运行时优化

编译器优化往往只能解决一部分性能问题，而较好的运行时数据结构通常能够得到10倍以上的性能提升。子串搜索是极为常见的字符串操作函数，当子串较多时，AC算法效率较高容易已发内存爆炸，上面的内存保护的AC是较好的解决方案。

高性能设计-性能优化

除了上面的两个优化点，从具体函数和全局语义还做了其他优化：

具体函数：静态模式初始化、常量抽取、内存保护的AC、复杂逻辑触发、op_and/op_or短路、e_search语义优化、e_json/e_split优化、字段操作函数优化。
全局语义：公共子表达式删除、if转switch、资源函数主键自动推导、e_split下移、e_keep/e_drop上移。

数据分派实践

不同的日志类别往往具有不同的业务分析需求，不同的业务分析需求对日志的存储周期和有无索引通常也不相同，例如：登录日志存储周期为30天且需要建立索引，订单日志存储周期为14天且需要建立索引，而鼠标点击日志存储周期为7天且不需要建立索引。

复杂场景实践–方案对比

下面是一个数据加工优化的真实案例。“设备元信息”周期性上报，“用户操作日志”实时上报，客户的需求是将上述两种日志进行关联得到“带详细信息的操作日志”。

开源自建方案。上面是基于开源软件以前的实现方案，首先将两种日志统一传输到服务器，然后采用Logstash的拉去落盘日志到Kafka，然后采用Flink编写程序实现业务逻辑，最后将结果输出到ElasticSearch。使用组件多、数据链路复杂、调试极为困难、运维工作重、开发代码量大。
日志服务方案。日志服务SLS提供了统一的解决方案，包含了：日志采集、日志存储、数据加工、日志查询分析（日志服务SLS实现了索引功能）等功能，一直在日志服务中流转，只需要一个服务SLS。全托管、免运维、自动扩容缩容、两行DSL语句搞定。