标签

数据

给数据湖加一层索引:让在线点查询不再扫描海量文件

来源: engineering.atspotify.com 15
数据湖擅长以较低成本保存海量历史数据,却不天然适合在线服务中的点查询:当请求只需要某个用户、歌曲或订单的一条记录时,扫描大量对象存储文件的延迟和成本都难以接受。Spotify 这类需要同时处理庞大数据规模与低延迟在线请求的公司,面临的核心问题就是:如何在保留数据湖存储优势的同时,快速定位一条具体记录。 一种实用思路是在数据湖与在线服务之间增加索引层。索...

从内容摄取到视频播放:播客可靠性事故该如何拆解

来源: engineering.atspotify.com 34
过去两个月,Spotify 的播客创作者连续遭遇可靠性问题,涉及内容摄取与播客视频。来源摘要没有披露具体故障时间线、根因或修复细节,因此不能据此判断是哪一个服务失效。不过,这类事故暴露了一个普遍难题:创作者看到的是“节目没有正常上线”,平台内部经历的却可能是接收、解析、转码、发布和播放等多个阶段的局部失败。 内容摄取系统通常不是一次请求完成全部工作。一...

Spotify 如何用 Kong AI Gateway 支撑规模化生成式 AI

来源: engineering.atspotify.com 44
Spotify 希望让 AI 像电子邮件一样直观,并成为员工日常工作中不可缺少的工具。要实现这个目标,难点不只是接入一个大模型,而是让大量团队能够稳定、安全、可观测地使用不同模型。Spotify Engineering 介绍的方向,是通过 Kong AI Gateway 为生成式 AI 流量建立统一入口。 由于公开摘要没有披露 Spotify 的完整拓...

把领域专家的知识编码进系统:Spotify 数据助手背后的上下文层

来源: engineering.atspotify.com 38
在 Spotify,数据问题曾经有一个固定模式:先翻找相关仪表盘,再确认指标口径,然后找人核对——整个过程可能要跨 Slack、内部文档和好几个工具来回折腾。问题不是没有答案,而是答案散落在各处,需要一位"懂行的人"才能拼起来。 Spotify 的解法不是雇更多懂行的人,而是把这位领域专家的知识编码成一层上下文,喂给他们的数据助手(Data Assis...

写代码不再是瓶颈:Spotify 如何把开发者体验扩展到团队与 AI Agent

来源: engineering.atspotify.com 52
Spotify 首席架构师在 Code with Claude 大会上抛出一个判断:写代码本身已经不再是约束了。真正卡住交付速度的,是团队协作摩擦、重复的基建搭建、以及工具链对 AI Agent 的不友好。他们的应对方式是——用平台工程把开发者体验(DevEx)从"个人写代码"的维度,拉升到"团队+Agent 高效运转"的维度。 这个判断值得认真对待。...

用 LLM Eval 做实验:漏斗而非一刀切

来源: engineering.atspotify.com 48
Spotify 工程团队最近分享了一个关于 LLM Eval 实验设计的核心观点:把 LLM 评估当成漏斗,而不是一刀切的闸门。 这句话看似简单,但背后指向的是很多团队在用 LLM 做自动评估时踩的坑——把 eval 当成 binary pass/fail 的裁判,结果要么放过了坏输出,要么误杀了好输出。 很多团队拿到 LLM eval 的第一反应是:...