阿里云数据库服务_阿里十年技术沉淀｜深度解析百PB级数据总线技术

作者 | 徐可嘉（叶默）

本文是阿里云SLS徐可嘉在GIAC 2022全球互联网架构大会上分享的话题内容。

云原生场景下数据总线的要求和挑战

数据总线简介

数据总线作为大数据架构中的流量枢纽，起到了不同大数据组件间数据桥梁的作用。通过数据总线可以实时接入服务器、K8s、APP、Web、IoT/移动端等产生的数据，各类异构数据可以统一管理，从而实现与下游系统的解耦；进而异步实现数据清洗、数据分发、实时计算、离线计算等计算过程，将结构化数据投递给下游的分析与归档系统，达到构建清晰数据流的目的。广义上，数据的采集与接入、传输链路、存储队列、消费计算、投递都属于数据总线的范畴，分为入口层、管道层、计算层。

通过数据总线可以轻松实现以下目的：

比如在计算广告检索系统中，广告点数据至关重要。一个点数据往往被多方订阅和消费，应用场景多种多样，有精度达到秒级的实时计算服务，也有类似小时级、日级的批处理任务。如果数据直连，需要考虑各种异常场景，系统会变得异常复杂。但通过数据总线，可以大大降低系统复杂度，提高系统可靠性。这保证了任何一个数据订阅系统，即使之前已经下线维护或者宕机，重新上线后都可以继续从上次断点开始处理数据。

云原生场景的技术挑战

当面对每天数百亿次读写、近百PB数据流量、数万用户的场景时，构建一条高可用的数据总线将是一个非常有挑战性的任务。下面是一些简单的流量场景：

经过几十年的高速发展，整个开发模式、系统架构、部署模式、基础设施等也经历了几次颠覆性的变化，带来了更快的开发和部署效率。整个系统和网络环境更加复杂，部署方式和运行环境更加动态和不确定，访问的数据源和数据量大幅增加，流量波动等不确定性增加，访问难度也不同于原来的架构。这些都是云原生时代也给数据总线带来的新要求。

综上所述，云原生时代数据总线的技术挑战可以从三个方面展开：采集接入层、管道层、计算层。采集接入层重点关注数据源的接入丰富度、访问易用性、资源开销以及数据采集可靠性；管道层重点关注网络质量、带宽与水平扩展性、安全与隔离性、生态丰富度等；计算层重点关注计算语法能力、流量处理带宽与扩展性等。

开源解决方案的选择与比较

目前业界主流的大数据架构大致可以分为五个部分，其中前三部分构成了数据总线。

用户可以利用以上采集端、消息队列、计算三部分提供的开源组件来构建数据总线，虽然基于开源组件构建数据总线在技术上是可行的，但整体实现非常复杂，需要维护多套系统，另外也无法完全满足前文提到的网络质量、区域规划等云原生场景面临的难以攻克的技术挑战。

数据总线总体架构

可观测平台不仅需要解决如何获取和查询数据的问题，还应该提供针对具体业务场景的应用能力，帮助客户从碎片化、低信息量的数据中挖掘出更大的数据价值。平台从下到上可以分为四个层级：数据总线、存储分析、工具、应用。其中数据总线是整个可观测平台的数据基础，为数据分析和上层业务应用提供数据保障。因此在企业数字化过程中，必须足够可靠、足够稳定，保证数据畅通，能够灵活应对流量变化的需求。接下来我们将重点分享阿里云SLS数据总线的架构与实践。

在本文的第一部分我们介绍了典型的数据总线可以分为三层：采集访问层、流水线层、计算层，对应的SLS数据总线架构也可以类似地划分。

以上我们对SLS数据总线有了大致的了解，接下来我们将从数据接入、交通枢纽、数据处理三个维度进行详细介绍。

数据访问技术架构与实践

数据访问功能概述

作为数据总线的核心流量枢纽，默认提供HTTP/HTTPS协议API编写能力，同时还提供多种语言的SDK，简化接入场景，增强可靠性，SDK覆盖Java、Go、C++等从服务端应用到iOS等移动端场景甚至前端场景。

自研开源可观测数据采集器承载着服务器场景和容器场景的可观测数据采集能力，覆盖Linux操作系统及X86、ARM等架构，借助阿里云的优势，无缝支持各类主流云服务的日志、指标、安全审计数据的采集。

对常见协议支持也比较丰富，兼容Kafka、JDBC、等开源协议；支持、、等众多开源采集工具。

针对大数据、高并发场景如Java、Go，我们基于SDK提供了Java[1]和Go[2]；针对物联网/嵌入式设备，我们推出了C[3]。

与直接通过API或者SDK发送数据相比，它提供了更高层次的封装，大大提高了性能和可靠性。

可观察数据收集器

是数据总线数据访问的重要流量源，具有轻量、高性能、自动化配置等生产级特性，可部署在物理机、虚拟机等环境采集遥测数据，是一款可观察数据采集器，帮助开发者构建统一的数据采集层，助力可观察平台打造各类上层应用场景，解决数据总线数据访问问题。

得益于阿里/蚂蚁集团及公有云场景的不断细化，相比开源代理（如、、Beats）在性能、资源消耗、可靠性、多租户隔离、K8s支持等硬性指标上更加先进，并且能够满足2022年6月29日全面开源，受到众多开发者的关注，2022年11月7日star数突破1K。

高性能低成本采集是核心优势之一，在Linux下作为文件监控的主要手段，提供毫秒级延时的数据发现能力。同时，为了兼顾不同操作系统，支持各种特殊的采集场景，采用轮询作为数据发现方式，通过使用轮询和事件的混合方式，打造兼具性能优势和健壮性的文件发现机制。另外，采用无锁的事件处理模型，不同于业界其他开源代理为每个配置/数据读取分配独立线程，数据读取只配置一个线程，由于数据读取的瓶颈不是计算而是磁盘，所以单线程足以完成所有配置，使用单线程可以让事件处理和数据读取运行在无锁的环境中，使数据结构更加轻量，从而达到比多线程处理更好的性价比。

在生产环境中，一个服务有上百个采集配置是常态，各个配置的优先级、日志生成速度、处理方式、上传目标地址等都可能不一样，因此需要有效解决如何隔离各种自定义配置，保证采集配置的QoS不因某些部分配置异常而受到影响。采用基于时间片的采集调度、多级高低水位反馈队列、事件非阻塞处理、流控/停止采集策略、动态配置更新等多项关键技术，融合隔离性、公平性、可靠性、可控性、性价比五大特点的多租户隔离方案，经过双11流量高峰期多年考验，该方案已被证明比其他开源方案有更大的稳定性和性价比优势。

毫不夸张地说，数据源的多样性可以成为数据总线的生命线，否则好厨子难无米之炊。通过插件化的设计，突破了单纯文件采集的范畴，有效拓展了上下游生态，成为真正的 。目前支持很多数据源的接入，包括 Log、Trace、等数据源。数据源除了文件采集，还支持标准协议，比如 HTTP、MySQL 等，eBPF 支持实现了非侵入式的网络数据采集能力。数据产出生态也从 SLS 逐渐拓展到 Kafka、gPRC 等，未来也会通过开源社区共建的方式支持、等。

面对众多异构数据的接入，数据总线的职责之一就是通过数据处理构建统一的数据格式。它还提供强大的数据处理能力，可以完成数据格式正则化、数据过滤、上下文关联等。采用的设计是先通过Input插件采集数据，然后经过采集配置中设置的处理，再通过插件进行打包，最后发送到存储系统，数据处理环境包括数据切分、字段提取、过滤、数据增强等环节，所有插件都可以自由组合。

随着云原生的落地，已经得到全面支持，目前支持两种主流的容器运行时，通过实时监控容器列表并维护容器与日志采集路径的映射，结合高效的文件采集能力，提供极致的容器数据采集体验。支持使用容器标签、环境变量、K8s标签、Pod名称、命名空间等方式进行容器筛选，为用户提供便捷的采集源配置能力，支持、、CRD等多种部署方式，应对不同的使用场景，提供灵活的部署能力。另外，对于对CICD自动化部署和运维要求高的用户，也提供了K8s原生支持，支持通过CRD进行采集配置管理，扩展名为.log。同时开发了-log-来监控事件，自动创建采集配置，完成日志采集工作。

交通枢纽技术架构与实践

作为SLS数据总线的流量枢纽，是支持海量可观察数据实时访问和消费的高吞吐量数据通道，在可观察数据场景下可以使用Kafka等消息队列产品，在性能、易用性方面具有更高的效率和更好的稳定性。

可以理解为一个只支持IO和通过多个shard组合来扩展存储的日志队列结构，另外基于队列创建了多层索引，可以快速定位每一条数据在队列中的位置，赋予队列模型随机查询的能力。

/ 是SLS中可观察数据采集、存储和查询的单元，作为/的队列模型，提供实时写入数据和流式消费的能力，同时在此基础上对模型进行扩展，构建统一的可观察性分析引擎。

全球支持和智能加速

它是阿里云上的基础设施，借助阿里云等全球部署优势，与阿里云保持同步，这是其他开源数据总线无法比拟的优势，可以保证全球业务就近选择，也可以满足一些国家或组织对数据不能出境的法定要求。

联合CDN基于阿里云CDN硬件资源（覆盖2800+节点，70+国家）推出全球自动上传加速解决方案，全球数据就近接入边缘节点，通过内部高速通道路由，大幅降低网络时延和抖动。

弹性和保序处理

在生产中我们经常会面临流量的高峰和低值，也会遇到由于业务层不均衡导致某个分区（shard）流量非常大的场景，（Merge/Split）就是解决这个问题的机制。

分片分裂原理

Shard 分裂是扩展流量的一个重要手段，将一个 Shard 分裂成两个 Shard，同时原来的 Shard 变成一个状态，其上的数据可以继续被消费和读取。

合并操作与分裂操作相反，它将两个相邻的 Shard 合并为一个 Shard，而原来的两个 Shard 则变为状态。

负载均衡：根据峰值、谷值弹性扩容，控制成本。

下图中，最初只提供服务，后来随着晚间流量高峰，单个Shard不足以支撑业务流量，所以拆分成两个Shard提供服务，当流量再次稳定后，出于成本考虑，将两个Shard合并成一个新的Shard提供服务。

日志保序处理：将不同的实例映射到不同的分区，并调整分区处理能力。

对于某些业务场景，需要保证数据的有序性，在写入数据时，经常会使用hash规则将不同业务的数据映射到固定的分片上。

下图中的业务场景，三个DB的流量都超负荷了，此时可以通过Shard 来均衡流量，拆分之后原来的变成只读的，数据还是可以被消费的，但是不会再接受新的数据写入，新拆分出来的数据会对外提供服务。

如何保证Shard调整前后边界数据的顺序性呢？提供了Shard顺序消费能力，即Shard分裂后，先消费原有的Shard数据（即数据），再同时消费从该Shard分裂出来的Shard数据（Hash策略保证同一业务落在同一个Shard上）。同样，在Shard合并场景下，也是先消费原有的Shard数据，再消费原Shard合并后新的Shard数据。当然，对于不严格保持顺序的场景，为了提高消费速率，可以关闭Shard顺序消费功能，达到同时消费所有Shard的目的。

建立稳定

粗粒度流量控制：级别

全局流控的主要目的是限制用户整体的资源使用量，拒绝前端的请求，防止流量穿透后端，导致整个集群不堪重负。

细粒度流控：分片级别

分片级别的流控更加精细，语义（错误码）更加清晰，可控性更强。

数据处理技术架构与实践

从上面数据接入部分我们可以看出，数据总线作为交通枢纽，承载着各类异构数据的接入，虽然其具有强大的前期数据处理能力，但是往往由于历史原因或者接入方式的差异，导致数据格式五花八门，难以做到统一的格式规范，给后续的分析带来很大困难，因此数据总线往往还需要一个数据处理环节，为此我们提供了数据处理服务和基于调度SQL（SQL）的数据处理能力。

另外为了更好的支持开源生态，还支持自定义消费或者Flink流式消费的能力。

数据处理

数据处理服务可以有效解决大多数处理和编排场景：

总体架构

数据处理服务基于实时消费者组实现对源的数据进行负载均衡消费，源中的 shard 数量决定了数据处理任务的并发上限，数据处理调度器在启动新作业时，会自动创建并绑定到源的一个消费者组，消费者组内的多个消费者独立负责处理不同 shard 中的数据，随着数据量的增大，源需要拆分成更多的 shard，数据处理作业可以拓展更多的消费者，独立工作。

当作业需要关联外部资源时，每个消费者都独立维护一份资源副本，实现高性能的关联计算。

弹性机制

除了数据量巨大之外，日志数据的另一个特点是数据量呈现周期性波动，且波动峰值极高且窄。例如，对于某直播平台而言，其每日流量的90%来自于21:00至23:00之间的休闲时段。这就导致这一时段的数据量是平时的数十倍。面对这样的极端场景，数据处理需要能够实现算力的弹性伸缩，在保证用户操作高性能的同时，尽量减少资源浪费。

任务调度中数据处理的弹性伸缩基于K8s的 和HPA机制，通过系统内部存储与计算分离，实现数据处理算力的自由伸缩，用户看到的是一个服务化的计算平台，按需付费，无需担心繁琐的细节。

原生的 K8S HPA 仅支持 CPU、内存两个指标，对于大部分数据密集型作业来说已经足够。但是在数据处理中，部分客户会进行数据编排、跨地域传输数据，对于此类网络/IO 敏感场景，内置的 HPA 指标无法满足要求。因此我们引入了更加完善的 HPA 指标，以支撑各类业务场景下的运行需求。此外，我们还将利用智能算法不断升级优化 HPA 指标，比如根据作业历史运行特征提前分配资源等，进一步提高作业运行的稳定性。

云数据 (DPL)

数据处理服务基于语法设计了用户侧接口，并提供了完善的内置数据处理功能，我们称之为云数据（DPL），通过DPL，只需要很少的代码就可以完成非常复杂的数据处理逻辑。

以下是一个信息丰富的例子：在一个http请求中，通过RDS维表的关联，在原始数据中添加了对请求状态码（字段）的详细描述（字段）。

SQL

基于时间的数据（日志、指标）随着时间的流逝累积起来的数量是惊人的。以 Nginx 访问日志为例，每个 HTTP/HTTPS 访问请求都会记录一条日志，假设每天产生 1000 万条数据，一年下来就是 3600 万条。大量数据长期保存不仅会占用大量存储空间，还会对数据分析处理造成很大的性能压力。

SQL可以对数据进行定时聚合分析（支持标准SQL、SLS查询分析语句），按照调度规则定期执行，并将操作结果写入目标数据库，相比自建API调用方式有以下优势：

云服务数据分发技术应用与实践

数据调度技术概述

云服务（如OSS、SLB等）往往托管在云厂商的服务器上，用户无法直接登录服务器查看日志。数据调度技术是基于SLS数据总线技术的关键服务模块，达到将可观察的数据从云服务端传递到各个用户端的目的。其实现机制是云产品服务端经过预收集和清洗（处理）流程将日志存储到集中式数据中心（），然后再分发到用户端。服务端以多租户形式将数据分发给用户端。它有以下优点：

云镜头架构

数据分发技术只是解决了可观测数据从云产品服务端到用户端的流转问题。但要实现云服务日志的采集、云资产归属、多账户体系认证等仍然需要一些上层服务来维护。为此，我们构建了包括资产同步、自动化采集服务、多账户体系等多项基础服务，统称为统一接入服务。后续在统一接入服务的基础上，我们进一步为各个云产品提供统一的交互和功能组件，构建更高层的APP能力——云镜头。

Cloud Lens基于SLS构建统一的云产品可观测性，提供阿里云产品使用分析、性能监控、安全分析、数据保护、异常检测、访问分析等服务，从接入和分析六个维度，为云产品运维提供辅助分析能力，有效降低云产品可观测性的门槛。

动态数据发现和收集

采集链路的自动编排是Cloud Lens的一大特色，通过图形化的方式，实现一键式的自动化资产发现和自动化数据采集（到用户侧），这其实就是通过DSL代码来编排采集逻辑。

对未来方向的思考和展望

未来已来，SLS数据总线技术将在采集访问、管道、计算三个层面持续发展，为可观测平台持续提供稳定可靠的数据基础。

附录：

SLS：构建统一的可观察性引擎

双11五周年：SLS数据管道的发展

数字 IT 基础 - 数据采集总线：

使用日志服务替换Kafka：

日志服务（原SLS）新特性发布（一）—支持保序写入和消费：

日志服务（原SLS）新功能发布（二）-弹性伸缩（Merge/Split）：

[1]

[2]

[3]