サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
engineering.atspotify.com
Introducing Voyager: Spotify’s New Nearest-Neighbor Search Library For the past decade, Spotify has used approximate nearest-neighbor search technology to power our personalization, recommendation, and search systems. These technologies allow engineers and researchers to build systems that recommend similar items (like similar tracks, artists, or albums) without needing to run slow and expensive m
Choosing a Sequential Testing Framework — Comparisons and Discussions March 21, 2023 Published by Mårten Schultzberg (Staff Data Scientist) and Sebastian Ankargren (Sr. Data Scientist) TL;DR Sequential tests are the bread and butter for any company conducting online experiments. The literature on sequential testing has developed quickly over the last 10 years, and it’s not always easy to determine
February 1, 2023 Published by Divita Vohra, Sr. Product Manager, Keshi Dai, Sr. ML Engineer, David Xia, Sr. ML Engineer, & Praveen Ravichandran, Staff Research Scientist As the field of machine learning (ML) continues to evolve and its impact on society and various aspects of our lives grows, it is becoming increasingly important for practitioners and innovators to consider a broader range of pers
March 17, 2022 Published by Alexandre Tamborrino, Machine Learning Engineer Beyond term-based Search Until recently, Search at Spotify relied mostly on term matching. For example, if you type the query “electric cars climate impact”, Elasticsearch will return search results that contain everything that has each of those query words in its indexed metadata (like in the title of a podcast episode).
The Rise (and Lessons Learned) of ML Models to Personalize Content on Home (Part I) At Spotify, our goal is to connect listeners with creators, and one way we do that is by recommending quality music and podcasts on the Home page. In this two-part blog series, we will talk about the ML models we build and use to recommend diverse and fulfilling content to our listeners, and the lessons we’ve learn
Introducing Pedalboard: Spotify’s Audio Effects Library for Python September 7, 2021 Published by Peter Sobot, Staff Machine Learning Engineer - Spotify Audio Intelligence Lab We’ve just open sourced Pedalboard, Spotify’s framework for adding effects to audio in Python. Pedalboard makes it easy to use studio-quality audio effects in your code, rather than just in your digital audio workstation (DA
TL;DR Have you made a significant decision that impacts how engineers write software? Write an ADR! An Architecture Decision Record (ADR) is a document that captures a decision, including the context of how the decision was made and the consequences of adopting the decision. At Spotify, a handful of teams use ADRs to document their decisions. One of these teams, The Creator Team, focuses on provi
March 10, 2021 Published by Mårten Schultzberg, Oskar Kjellin, and Johan Rydberg At Spotify we run hundreds of experiments at any given time. Coordinating these experiments, i.e., making sure the right user is receiving the right “treatment” with a population of hundreds of millions of users, poses technical challenges. Adding to the complexity, some of these experiments must be coordinated in the
It’s All Just Wiggly Air: Building Infrastructure to Support Audio Research TL;DR We just open sourced Klio — our framework for building smarter data pipelines for audio and other media processing. Based on Python and Apache Beam, Klio helps our teams process Spotify’s massive catalog of music and podcasts, faster and more efficiently. We think Klio’s ease of use — and its ability to let anyone le
Yesterday, we released the open source version of Backstage, our homegrown developer portal. And we learned a thing or two via the feedback we received. So, I wanted to take this opportunity to further explain what we’re trying to do with Backstage — and more importantly, what we want to give to the greater engineering community beyond Spotify. What’s the big infrastructure problem? As companies g
How We Improved Data Discovery for Data Scientists at Spotify At Spotify, we believe strongly in data-informed decision making. Whether we’re considering a big shift in our product strategy or we’re making a relatively quick decision about which track to add to one of our editorially-programmed playlists, data provides a foundation for sound decision making. An insight is a conclusion drawn from d
The Winding Road to Better Machine Learning Infrastructure Through Tensorflow Extended and Kubeflow When Spotify launched in 2008 in Sweden, and in 2011 in the United States, people were amazed that they could access almost the world’s entire music catalog instantaneously. The experience felt like magic and as a result, music aficionados dug in and organized that content into millions of unique pl
The purpose of this post is to tell the story of the new Spotify web player. How and why it came to be. We will focus on what the steps were that led to a complete rewrite and how the lessons learned influenced the experience and the tech decisions of the new web player for desktop browsers. Using the Web to implement Spotify applications at Spotify Spotify has been using web technologies for a lo
August 31, 2018 Published by Erik Carlsson, Eirini Kakogianni We flipped one server flag and got more download bandwidth for Spotify users. That is the TL;DR of this A/B experiment with BBR, a new TCP option. Background BBR is a TCP congestion control algorithm developed by Google. It aims to make Internet data transfers faster, which is no small feat! How Spotify Streams Music The basic principle
For more recent information on Spotify’s Health Check model, check out this blog post. What is a squad health check model? A lot of companies experiment with ways of measuring and visualizing how their teams are doing. They’re usually called “maturity models”, and involve some sort of progression through different levels. The intent of these types of models is usually benign – for example managers
Why do we write tests? Most people would say that we write tests to verify that things work as we expect them to. While that is true, it’s not the whole truth. After all, that can be verified through manual tests as well. So there has to be something more to it. Anyone who has ever done manual testing knows that it’s slow, boring and error-prone. By writing automated tests we are trying to remove
TL;DR: We have created the Retro Kit. It can be downloaded by following this link. Retro Kit… but why? Historically at Spotify there has been an Agile Coach attached to each team. That coach has, among other things, helped the team to improve their processes. A central piece to that improvement are regular retrospectives where teams reflect on their way of working to continuously become better in
Spotify’s Event Delivery system is responsible for delivering hundreds of billions of events every day. Most of the events are generated as a response to a user action, such as playing a song, following an artist or clicking on an ad. All in all, more than 300 different types of events are being collected from Spotify clients. The Event Delivery system is one of the core pillars of Spotify’s data
In this part we’ll take a closer look at Scio, including basic concepts, its unique features, and concrete use cases here at Spotify. Basic Concepts Scio is a Scala API for Apache Beam and Google Cloud Dataflow. It was designed as a thin wrapper on top of Beam’s Java SDK, while offering an easy way to build data pipelines in idiomatic Scala style. We drew most of our inspiration for the API from S
Whenever a user performs an action in the Spotify client—such as listening to a song or searching for an artist—a small piece of information, an event, is sent to our servers. Event delivery, the process of making sure that all events gets transported safely from clients all over the world to our central processing system, is an interesting problem. In this series of blog posts, we are going to lo
Introduction When you log into Spotify, browse through your Discover Weekly playlist, and play a track, you’re interacting with some of our fleet of around 12,000 servers. Spotify has historically opted to run our core infrastructure on our own private fleet of physical servers (aka machines) rather than leveraging a public cloud such as Amazon Web Services (AWS). Our fleet consists of a minimal s
This is part two of a three part series on how we created a technical career path for individuals at Spotify and what we learned in the process. This post contains the actual version one of our Technical Career Steps. This is the complete document, so it is a bit long. In the next and final post, I will talk about the mistakes we made along the way and the good and bad lessons we learned. If you h
Spotify launched a career path framework for individuals last year. Since then, I’ve spoken to leaders at several other companies about it. This seems to be a bit of a hot topic, so I’ve decided to write about our model and how we arrived at it. Hopefully, this may be useful to your company. This will be a three part series. In this, the first part, I will talk about how we created our framework.
“You just talk to them for half an hour.” That’s the guideline I got when I first joined Spotify for how to run my 1:1s — a recurring half hour meeting between a manager and their team members. It didn’t leave me with much to work with. I was admittedly clueless about the practice. I spent ten years in an entirely different culture, where managers managed people and teams, assigning tasks, trackin
Load Balancing Most Spotify clients connect to our back-end via accesspoint which forwards client requests to other servers. In the picture below, the accesspoint has a choice of sending each metadataproxy request to one of 4 metadataproxy machines on behalf of the end user. Load balancer with 4 clients The client should get a quick reply from our servers, so if one machine becomes too slow, it sh
This is the first in a two-part series about Monitoring at Spotify. In this, I’ll be discussing our history, the challenges we faced, and how they were approached. Operational monitoring at Spotify started its life as a combination of two systems. Zabbix and a homegrown RRD-backed graphing system named “sitemon”, which used Munin for collection. Zabbix was owned by our SRE team, while sitemon was
All of our lovely Spotify users generate many terabytes of data every day. All the songs that are listened to, all the playlists you make, all the people you follow, and all the music you share. Somehow we need to organise, process and aggregate all of this into meaningful information out the other side. Here are just a few of the things we need to get out of the data: Reporting to record labels a
次のページ
このページを最初にブックマークしてみませんか?
『Spotify Engineering』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く