【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

《Spotify 的入云之旅》系列之一——事件传输系统

  • 2016-05-02
  • 本文字数:3259 字

    阅读完需:约 11 分钟

写在之前

当 Spotify 的用户打开客户端听歌或者搜索音乐人,用户的任何一个触发的事件都会传送回 Spotify 的服务器。事件传输系统(也即,日志收集系统)是个有趣的项目,确保全球用户使用 Spotify 客户端所产生的事件都完全、安全的发送到数据中心。在本系列文章中,将讲述 Spotify 在这方面所做过的工作,而且会详细解说 Spotify 新的事件传输系统架构,并回答“为什么 Spotify 会基于 Google 云平台管理建立自己的新系统?”。

在本文章中,首先会阐述当前事件传输系统是如何工作,并分享一些在此架构下的实践经验;在下篇文章里,将描述新事件传输系统的架构设计,更进一步的,解释 Spotify 为什么会选择 Google 云平台的 Cloud Pub/Sub 服务作为所有事件的传输机制;在第三篇,将展示 Spotify 公司如何消费从 Google 的 DataFlow 订阅的事件数据,并分享 Spotify 技术团队采用这一方案的经验总结。

Spotify 的事件传输系统有很多用途,Spotify 大部分产品的设计策略是基于 A/B test 的结果,而这些 A/B test 得依赖于海量、精确的用户数据。Spotify 2015 年发布最受欢迎的特色功能之一是“Discover Weekly”播放列表,它是基于 Spotify 用户播放数据。“Year in music”、“Spotify Party”等其他特色的模块都是对用户播放数据进行数据分析的结果,同时 Soptify 的用户数据也是 Billboard 榜单的数据源。

事件传输系统是 Spotify 公司数据基础设施,它能保证数据以预期的延迟时间完整的传输,并且通过事先定义好的接口发送数据给开发者。用户数据是开发者事先埋点用户点击后产生的结构化数据。
Spotify 大部分事件都是响应用户在 Spotify 客户端的行为而触发的事件,事件在客户端发生后通过日志收集系统 syslog 发送到 Spotify 网关,这些数据通过事件传输系统时都会记录时间戳。为了能监测事件传输和事件传输的完整性,事件记录采用 syslog 时间戳而不是事件在客户端发生的时间戳,因为在事件传到 Spotify 服务器前是无法控制事件。

在 Spotify 公司,所有的用户数据需要发送到中心的 Hadoop 集群。Spotify 收集数据的服务器位于两个州的多个数据中心,但是数据中心之间的带宽是紧缺的资源,因此需要时刻监控带宽的占用情况。
数据接口是根据存储数据的 Hadoop 的位置和存储的格式来定义的,Soptify 所有通过事件传输服务传输的数据都是以 Avro 格式存储在 HDFS 上。传输的数据都是以小时来分桶,这么做的原因是系统遗留问题:Spotify 公司第一个事件传输系统是简单的用 scp 命令,然后按小时从所有的服务器上把 syslog 文件复制到 Hadoop 集群。现在 Spotify 公司所有的数据任务还是按小时分片的,这种接口形式预期将来一段时间还是不会变。

Spotify 的大部分数据读取任务是从小时桶里读取一次。一个 job 的输出会作为另外一个 job 的输入,这样形成一个长的转运 job 链。中间传输的 job 每小时传输一次,并且不做任何数据检查,即使在数据操作的过程中数据源发生了变化。一般出现小时桶里的数据发生变化需要手动去强制启动整个 job 链,相应的下游 job 就会按指定的时间运行。显然地,这是一个耗时耗力的处理过程,并且没有数据回滚的机制,因此需要一个事件传输服务来解决这个问题。数据完整性问题同时也带来的数据传输的延迟,你可以从 Google 的 Dataflow 论文里看到对数据完整性问题的有意思的看法。

当前使用的事件传输系统

系统设计

现在 Spotify 公司生产环境上使用的系统是基于 Kafka 0.7 版本。

(点击放大图像)

图1: 基于Kafka 0.7 点事件传输系统架构图

Spotify 线上运行的事件传输系统是按每小时文件抽象所设计的,它支持从服务器到 HDFS 的流式日志文件,包含事件数据。当所有的日志文件按小时传输到 HDFS 上的过程中会做一个日志格式转化,将原始的 Tab 键分隔的文本转化成 Avro 格式。

当线上正运行的事件传输系统上线时,Kafka 0.7 版本的 Kafka Broker 集群还未能实现稳定的持久化,这导致数据生产者、Kafka Syslog 生产者和 Hadoop 集群之间不能进行持久化。所以等到事件数据写入文件或者 HDFS 才能认为数据已经持久化了。

事件数据到达 Hadoop 集群并不能达到可靠的持久化,这里又面临一个问题:事件传输系统中 Hadoop 集群的单点问题,如果 Hadoop 集群宕机则事件传输系统即挂掉。为了解决这一问题,Spotify 公司确保所有收集事件数据的服务器上有足够多的磁盘空间,当 Hadoop 集群挂掉了,事件数据先缓存到服务器上,等 Hadoop 集群恢复后立即传输所有数据,这种传输策略到恢复时间主要受限于两个数据中心的带宽。

每个服务主机上都有一个 Producer 守护进程,它监控这日志文件并按行批量发送日志数据到 Kafka Syslog 消费者。Producer 并不会关注事件类型或者事件属性,它仅仅把区分日志文件的行数据,并且把所有数据发送到相同的 channel。这意味着所有的事件类型都包含在相同的日志文件里,并且发到同一个 channel 里。Producer 发送日志到 Consumer 后,需要等到 Consumer 成功的把日志持久化到 HDFS,并返回 ACK 给 Producer。当 Producer 收到成功的 ACK 后继续发送后面的日志。

Producer 上的事件数据传到 Consumer 需要经过 Kafka Brokers 和 Kafka Groupers。Kafka Brokers 是 Kafka 的标准组件,而 Kafka Groupers 是由 Spotify 工程师开发的,Grouper 消费本地数据中心的所有事件数据,并进行压缩、批量的发送到 Consumer 的单个 topic。

接下来是数据清洗(ETL)的过程,将 Tab 分隔的文本文件转化成 Avro 格式。这个 job 只是一个常规的 Hadoop MapReduce 任务,采用 Crunch 框架开发。
所有的 Producer 都会持续发送文件结束标记的检查点信息(checkpoint),当一个文件全部持久化到 Hadoop 集群后,Producer 会有且仅有发送一次文件结束标记。生命周期监控持续不断的去查询各数据中心的服务发现系统,探测在某个小时内服务器是否在线。为了确定某个小时的数据是否全部传送到数据中心,ETL 任务会去校验服务器文件的结束标记,如果 ETL 的 job 探测到数据未全部收到,它会延迟处理当前小时到数据。

为了最大化利用 mapper 和 reducer,ETL 的 job 需要知道如何共享输入数据,并且基于Consumer 传过来的事件数来优化共享。

总结

上述事件传输系统的设计主要缺点之一:本地Producer 需要确认发送的数据被持久化存储的数据中心位置。在美国西海岸的服务器,Producer 需要知道数据什么时间写入到London 数据中心。大部分情况下系统工作正常,一旦传输变慢将引起传输延迟并很难恢复。

对比这个问题,需要将转移点放在本地数据中心,这简化里Producer 的设计,只要数据中心的网络正常即可。

暂且放下这些问题,接下来计划构件一个事件传输系统能够可靠的每秒钟推送70 万个事件。重新设计这个事件传输系统同时给Spotify 团队一个机会提高软件的开发过程。

所有的事件一起发送到相同的channel,这会失去对不同QoS 的事件流的灵活管理。同时也会限制实时数据使用,因为任何实时的消费者需要过滤数据,仅仅获取有用的信息。

发送非结构化数据会带来不必要的延迟,因为清洗任务会带来额外的数据转移,当前运行的事件传输系统,清洗任务在处理非结构化数据会多好使大概30 分钟。如果发送的数据是结构化的Avro 格式,当被写入HDFS 会立即处理完。

跟踪处理的数据要按小时完整的数据会引起问题,例如,当机器挂掉,不能发送文件结束的标记。如果有一个缺失的文件结束标记,其他任务需要等到人为的处理才会继续工作。当机器的数量增长时,这个问题变得更明显。

下一步要做的

在Spotify 公司,传输的事件数据在不断的增长。同时系统的负载也在不断的增加,开始经历机器掉电,掉电掉数目开始警告大家,并且意识到系统在负载不断增加的情况下不能维持太久,见图2。

(点击放大图像)

图2

不幸的是,当前线上的事件传输系统已不能再通过迭代开发的方式得到提高了。留在前面唯一能解决问题的方法是重写事件传输系统。


感谢杜小芳对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-05-02 17:451515
用户头像

发布了 43 篇内容, 共 27.6 次阅读, 收获喜欢 7 次。

关注

评论

发布
暂无评论
发现更多内容

测试角色在项目各阶段的项目管理tips

京东科技开发者

项目管理 测试 测试 单元测试 企业号 2 月 PK 榜

颜色的认识与使用(大屏颜色/仪表板报告设计)

Data 探险实验室

大屏配色 颜色 可视化颜色 配色搭配

行云管家属于高新企业吗?安全吗?

行云管家

云计算 网络安全 高新企业 云管理 高新技术

TiDB x Aliyun 免费试用,竟还有这般福利?

TiDB 社区干货传送门

社区活动 版本测评 6.x 实践

在字节跳动,造赛博古籍

字节跳动技术范儿

后端 nlp 搜索 OCR 多模态

云小课|MRS基础原理之Hue组件介绍

华为云开发者联盟

大数据 华为云 企业号 2 月 PK 榜 华为云开发者联盟

LeetCode题解:2357. 使数组中所有元素都等于零,哈希表,详细注释

Lee Chen

JavaScript 算法 LeetCode 哈希表

瓴羊Quick BI率先提供移动端自助分析整体解决方案,成为行业的领导者!

流量猫猫头

ZBC通证月内已翻倍,Nautilus Chain 上线前夕的“开门红”

股市老人

LeetCode题解:2357. 使数组中所有元素都等于零,排序,详细注释

Lee Chen

JavaScript 算法 LeetCode

中冶赛迪:基于鲲鹏DevKit开发智慧城市基础设施管理平台,性能提升47%

Geek_2d6073

C++中const和constexpr关键字解析:常量、函数和指针

小万哥

程序员 后端 开发 C/C++ const

Wallys/QSDK IPQ6010/wifi mesh function supports qcn9074/qcn6024 M.2 E Key Interface

Cindy-wallys

IPQ6010 ipq6018 IPQ6000

这周末,StarRocks 邀请开发者们一起来上海 GAIDC 开源集市,各种任务等你来挑战!

StarRocks

数据库

深入浅出玩转监控宝|网站监控之创建网站监控任务

云智慧AIOps社区

监控宝 监控工具 监控指标 #监控 网站监控

华为云CodeArts Artifact,5大特性守护制品质量与安全

华为云开发者联盟

云计算 开发 华为云 企业号 2 月 PK 榜 华为云开发者联盟

DevEco Studio端云协同开发之云函数

白晓明

HarmonyOS 端云协同 云函数

云数据库TiDB免费试用初体验

TiDB 社区干货传送门

社区活动 6.x 实践

云数据库 TiDB 初使用

TiDB 社区干货传送门

版本测评 安装 & 部署 性能测评 扩/缩容 6.x 实践

Fine BI、Smart BI怎么办,瓴羊Quick BI已经可以提供移动端自助分析整体解决方案!

对不起该用户已成仙‖

不要 ChatGPT,我们要你!2023 涛思招聘季重磅来袭~

TDengine

数据库 tdengine 时序数据库

揭穿数据分析的六大谎言

葡萄城技术团队

爆肝!《Java权威面试指南(阿里版)》,冲击“金三银四”有望了

程序知音

Java java面试 java架构 后端技术 Java面试八股文

云数据库TiDB-试用

TiDB 社区干货传送门

管理与运维 版本测评 安装 & 部署

ZBC通证月内已翻倍,Nautilus Chain 上线前夕的“开门红”

EOSdreamer111

云数据库 TiDB 入门级别的体验

TiDB 社区干货传送门

6.x 实践

ZBC通证月内已翻倍,Nautilus Chain 上线前夕的“开门红”

鳄鱼视界

数据库审计有什么用?过等保三级需要吗?

行云管家

数据库 等保 等级保护 数据库审计

在流媒体时代,如何看待音乐版权?

HIFIVE音加加

知识产权 音乐 版权

多模并起,万向融合 | 2023年2月《中国数据库行业分析报告》精彩抢先看

墨天轮

数据库 HTAP MatrixDB 多模数据库 超融合数据库

平时报表很复杂吗?瓴羊Quick BI智能报表轻松解决!

夏日星河

《Spotify的入云之旅》系列之一——事件传输系统_语言 & 开发_侠天_InfoQ精选文章