Spotify on kehittänyt Random Access Parquet eli RAP -nimisen tallennusarkkitehtuurin, jonka avulla yksittäisiä tietueita voidaan hakea pienellä viiveellä suoraan yhtiön datajärvestä. Ratkaisun keskeinen ajatus on lisätä Apache Parquet -tiedostojen päälle erillinen indeksi, jolloin verkkopalvelujen ja tekoälysovellusten tarvitsemaa dataa ei tarvitse ensin kopioida erillisiin operatiivisiin tietokantoihin.
Muutos on merkittävä erityisesti Spotifyn kaltaisessa ympäristössä, jossa datamäärät ovat valtavia. Yhtiö säilyttää petatavujen verran verkkopalveluissa käytettävää dataa Bigtablessa, mutta sen Google Cloud Storageen rakennetussa datajärvessä dataa on jo eksatavujen verran. Saman aineiston kopioiminen eri käyttötarkoituksia varten erillisiin järjestelmiin muuttuu tällaisessa mittakaavassa nopeasti kalliiksi.
RAP pyrkii ratkaisemaan ongelman niin, että sama data voidaan säilyttää datajärvessä ja sitä voidaan käyttää sekä laajoihin analyyseihin että yksittäisten tietueiden nopeisiin hakuihin.
Datajärvet eivät ole perinteisesti sopineet yksittäisiin hakuihin
Datajärvet on rakennettu ennen kaikkea suurten tietomäärien käsittelyyn. Esimerkiksi Trino ja BigQuery pystyvät tehokkaasti analysoimaan valtavia aineistoja, mutta ne eivät ole samalla tavalla optimoituja tilanteeseen, jossa sovellus haluaa löytää yhden tietyn käyttäjän tai tapahtuman tiedot mahdollisimman nopeasti.
Ongelma ei Spotifyn mukaan enää välttämättä ole itse pilvitallennuksen nopeus. Google Cloud Storagen kaltaisista objektitallennuspalveluista dataa voidaan saada millisekuntien viiveellä, mutta ennen varsinaista lukemista järjestelmän täytyy selvittää, missä haluttu tieto sijaitsee.
Kyselyn suunnittelu, metatietojen läpikäynti ja oikeiden tiedostojen löytäminen voivat muodostaa suuren osan kokonaisviiveestä. Jos yhden käyttäjätunnuksen löytämiseksi täytyy ensin selvittää, missä tuhansista Parquet-tiedostoista kyseisen käyttäjän tiedot sijaitsevat, nopeasta objektitallennuksesta ei saada kaikkea hyötyä irti.
RAP siirtää tämän työn erillisen indeksin tehtäväksi.
RAP kertoo suoraan, mistä haluttu tietue löytyy
Random Access Parquet ohjelmisto rakentaa Parquet-tiedostojen päälle ulkoisen indeksin. Indeksi yhdistää hakemiseen käytettävän avaimen, kuten käyttäjätunnuksen, suoraan tiedostoon ja sen sisällä sijaitsevaan tietueeseen.
Kun sovellus tekee haun, sen ei tarvitse käydä läpi suurta määrää tiedostoja. Hakutunnus tarkistetaan ensin indeksistä, minkä jälkeen objektitallennuksesta voidaan tehdä kohdistettu ranged read eli lukea vain tarvittava osa tiedostosta. Joissakin tapauksissa kyse voi olla vain muutamasta kilotavusta.
Spotify rakentaa indeksin erillään varsinaisesta datasta. Kun Apache Iceberg -tauluihin kirjoitetaan uutta dataa, indeksin rakentaja muodostaa uusia vain lisättäviä indeksiosia. Olemassa olevia muuttumattomia Parquet-tiedostoja ei tarvitse muokata.
Tämä on arkkitehtuurin kannalta tärkeää, sillä Spotify voi säilyttää nykyisen datajärvensä rakenteen ja lisätä nopeamman hakukerroksen sen päälle sen sijaan, että koko aineisto pitäisi siirtää uuteen järjestelmään.
Sama data voi palvella analytiikkaa, tekoälyä ja verkkopalveluja
Spotifyn tavoitteena on vähentää tarvetta ylläpitää samasta datasta useita kopioita eri käyttötarkoituksia varten. Datajärvessä sijaitsevaa aineistoa voidaan edelleen käyttää esimerkiksi analytiikkaan, koneoppimiseen ja notebook-ympäristöissä tehtävään tutkimiseen.
RAP lisää saman aineiston käyttötarkoituksiin myös viiveherkät verkkopalvelut ja tekoälyagentit.
Perinteisesti näiden tarpeet ovat olleet varsin erilaisia. Analytiikassa voidaan esimerkiksi käsitellä miljoonia tai miljardeja tietueita yhdellä kyselyllä, jolloin suuren aineiston tehokas skannaaminen on tärkeämpää kuin yksittäisen rivin löytyminen muutamassa millisekunnissa. Verkkopalvelussa tilanne voi olla päinvastainen: tarvitaan yhden käyttäjän tiedot nopeasti, eikä miljoonien muiden tietueiden käsittelystä ole mitään hyötyä.
RAP yrittää tuoda molemmat käyttötavat saman tallennuskerroksen päälle.
Tämä voi olla erityisen kiinnostavaa tekoälysovelluksissa. Agentti tai muu AI-järjestelmä voi tarvita jatkuvasti pieniä määriä tarkasti rajattua tietoa suuresta yrityksen tietovarannosta. Jos jokainen tällainen haku pitäisi tehdä perinteisen analyyttisen kyselymoottorin kautta tai data pitäisi kopioida erilliseen tietokantaan, järjestelmästä tulisi helposti sekä monimutkaisempi että kalliimpi.
Spotify optimoi myös Parquet-tiedostojen rakennetta
Ulkoinen indeksi ei ole RAP:n ainoa keino pienentää hakujen viivettä. Spotify on kehittänyt samalla tapoja järjestää data niin, että tarvittavien tallennusoperaatioiden määrä voidaan pitää mahdollisimman pienenä.
Data voidaan esimerkiksi järjestää hakuavaimen mukaan. Tällöin samaan avaimeen liittyvät tiedot sijaitsevat lähellä toisiaan eikä yhden haun suorittaminen vaadi suuren tiedostomäärän käsittelemistä. Myös toisiinsa liittyviä tietueita voidaan ryhmitellä yhteen.
Yksi kiinnostavista ratkaisuista on arvosarakkeiden lomittaminen. Sen avulla useiden eri sarakkeiden tietoja voidaan sijoittaa siten, että tarvittavat arvot voidaan hakea yhdellä yhtenäisellä lukuoperaatiolla sen sijaan, että objektitallennukseen tehtäisiin useita erillisiä pyyntöjä.
Spotify hyväksyy samalla kompromissin tallennustilan ja nopeuden välillä. Tiedostojen tai indeksien koko voi kasvaa hieman, jos sillä voidaan merkittävästi vähentää yksittäisen kyselyn vaatimia tallennusoperaatioita.
Joihinkin kyselyihin ei tarvitse avata Parquet-tiedostoa lainkaan
RAP tukee myös niin sanottuja covering index -indeksejä. Niissä itse indeksi sisältää tarpeeksi tietoa kyselyn ratkaisemiseen, jolloin varsinaista Parquet-tiedostoa ei tarvitse lukea lainkaan.
Tällainen ratkaisu voi pienentää viivettä entisestään tilanteissa, joissa sovellus tarvitsee vain pienen määrän usein käytettyjä tietoja. Indeksin kasvava koko muodostaa jälleen kompromissin, mutta erittäin usein tehtävissä hauissa ylimääräinen tallennustila voi olla pieni hinta vähentyneistä lukuoperaatioista.
Tämä tekee RAP:sta enemmän kuin pelkän tiedostoluettelon. Indeksikerros voi käytännössä osallistua itse kyselyn palvelemiseen eikä ainoastaan kertoa, mistä tiedostosta vastaus pitäisi etsiä.
Toissijaiset indeksit mahdollistavat useita hakutapoja
Yksi suuren datamäärän ongelmista on se, ettei tietoa välttämättä haeta aina samalla tunnisteella. Sama aineisto voidaan esimerkiksi joutua hakemaan toisessa tilanteessa ostajan ja toisessa myyjän tunnuksen perusteella.
Spotify tukee RAP:ssa sekundaarisia eli toissijaisia indeksejä. Niiden avulla samalle Parquet-aineistolle voidaan rakentaa useita erilaisia hakupolkuja ilman, että alkuperäisiä tiedostoja kirjoitetaan uudelleen.
Hash-pohjaiset indeksit soveltuvat tarkkoihin avainhakuihin, joissa etsitään yhtä tiettyä arvoa. Järjestetyt indeksit puolestaan mahdollistavat myös aluehaut.
Toissijaisten indeksien hallinta tapahtuu serving-kerroksessa, joten uusia hakutapoja voidaan lisätä muuttamatta varsinaista dataputkea. Sama Parquet-aineisto pysyy edelleen käytettävissä tavallisiin analyyttisiin kyselyihin.
Spotify nostaa lisäksi esille Z-orderingin ja Hilbert-käyrien kaltaiset tekniikat, joilla dataa voidaan sijoittaa fyysisesti niin, että myös useampien hakudimensioiden paikallisuus paranee.
Objektitallennuksen nopeutuminen muuttaa datajärvien käyttöä
RAP liittyy laajempaan muutokseen siinä, mihin datajärviä voidaan käyttää. Objektitallennusta on perinteisesti pidetty edullisena ja skaalautuvana mutta operatiivisiin tietokantoihin verrattuna hitaana tallennusratkaisuna.
Pilvipalvelujen objektitallennuksen viiveiden pienentyessä itse datan lukeminen ei kuitenkaan välttämättä enää ole suurin ongelma. Pullonkaulaksi voivat nousta sitä edeltävät vaiheet, kuten kyselyn suunnittelu, metatietojen käsittely ja oikeiden tiedostojen paikantaminen.
RAP:n ulkoinen indeksi pyrkii poistamaan juuri tätä ylimääräistä työtä. Jos järjestelmä tietää jo kyselyn alussa tarkasti, mistä tiedostosta ja mistä kohdasta tarvittava tieto löytyy, objektitallennusta voidaan käyttää huomattavasti lähempänä perinteisen avain-arvotietokannan toimintamallia.
Google Cloud on tuonut esille samankaltaista kehityssuuntaa Apache Icebergiin perustuvissa lakehouse-ratkaisuissa, joissa datajärviä pyritään käyttämään entistä laajemmin myös tekoälysovellusten taustalla. Spotifyn lähestymistavan erityispiirre on erillinen ulkoinen indeksikerros, joka on suunniteltu nimenomaan yksittäisten tietueiden nopeisiin hakuihin.
Erillisten tietokantakopioiden tarve voi vähentyä
RAP:n kiinnostavin vaikutus ei välttämättä ole yksittäisen kyselyn nopeutuminen vaan mahdollisuus yksinkertaistaa koko data-arkkitehtuuria.
Jos analyyttisessä datajärvessä oleva aineisto tarvitaan myös verkkopalvelussa, tavallinen ratkaisu on ollut kopioida tarvittava data esimerkiksi Bigtableen tai muuhun matalan viiveen tietokantaan. Tämän jälkeen järjestelmän täytyy huolehtia paitsi kahdesta tallennusjärjestelmästä myös datan siirtämisestä ja synkronoimisesta niiden välillä.
Mitä suuremmaksi aineisto kasvaa, sitä kalliimmaksi tämä malli muuttuu. Spotifyn tapauksessa mittakaavaero on huomattava: yhtiön operatiivisessa Bigtable-tallennuksessa puhutaan petatavuista, kun datajärven kokonaisuus on jo eksatavuluokassa.
RAP:n avulla kaikkea verkkopalvelujen tarvitsemaa aineistoa ei välttämättä tarvitse kopioida erilliseen serving-tietokantaan. Sen sijaan ainakin osa kyselyistä voidaan ohjata suoraan datajärveen indeksin kautta.
Ratkaisu ei tarkoita, että perinteiset operatiiviset tietokannat muuttuisivat tarpeettomiksi. Datajärven päälle rakennettu indeksikerros tarjoaa kuitenkin uuden vaihtoehdon tilanteisiin, joissa data on jo Parquet- ja Iceberg-muodossa ja sitä tarvitaan sekä analyyttisesti että yksittäisinä nopeasti haettavina tietueina.
Spotifyn RAP osoittaa samalla, kuinka datajärvien rooli on laajenemassa. Ne eivät ole enää pelkästään paikka, johon valtavia aineistoja kerätään myöhempää analysointia varten. Nopeamman objektitallennuksen, avoimien taulukkomuotojen ja erillisten indeksien yhdistelmä voi tehdä samasta datasta käyttökelpoista myös verkkopalveluille ja AI-agenteille ilman, että jokaiselle käyttötarkoitukselle rakennetaan kokonaan oma tallennusratkaisu.