TLDR; A funkciótároló a gépi tanuláshoz (ML) szolgáló funkciók adattárháza. Építészetileg abban különbözik a hagyományos adattárháztól, hogy egy kettős adatbázis, az egyik adatbázis (sororientált) alacsony késleltetéssel szolgálja ki a funkciókat az online alkalmazások számára, a másik pedig (oszlop-orientált) nagy mennyiségű szolgáltatást tárol. a Data Scientists által betanítási/tesztelési adatkészletek létrehozásához és kötegelt alkalmazásokhoz, amelyek offline modellpontozást végeznek.

Szolgáltatások Áruház: Data Warehouse Déjà Vu

Az adattárházak demokratizálták a vállalati adatokhoz való hozzáférést azáltal, hogy egyetlen platformon központosították az adatokat, majd vizuális eszközökkel, például a Tableau-val és a Power BI-val felhatalmazták az üzleti elemzőket. Többé nem kellett tudniuk, hogy milyen adatok hol találhatók, és hogyan kérdezzék le ezeket az adatokat az adott platformon. BI-eszközök segítségével történelmi betekintést nyerhettek az üzletbe.

Ezzel szemben az adattudósok prediktív modelleket építenek, hogy üzleti betekintést nyerjenek. A szolgáltatástároló a Data Science adattárháza – ez egy központi tároló a dokumentált, kurált és hozzáférés-vezérelt szolgáltatások tárolására, amelyek számos különböző modellen használhatók. A szolgáltatástároló az adatok átalakítása, összesítése és érvényesítése után a Vállalat számos különböző forrásából feldolgozza az adatokat.

A szolgáltatásfolyamatokat meg kell írni annak biztosítására, hogy az adatok megbízhatóan áramlanak a meglévő forrásokból, és olyan formátumban állnak rendelkezésre, amely készen áll az ML oktatási folyamatok és modellek általi felhasználásra.

A legtöbb Data Scientist jelenleg nem rendelkezik szolgáltatástárolóval. Idejük nagy részét adatok keresésével, tisztításával és megjelenítésével töltik. Innen ered az a (nagyon valóságos) közhely, hogy az adattudomány 80%-a adatcsavarás. A szolgáltatástároló nélküli adatkutatók egy olyan korszakban dolgoznak, mint az üzleti elemzők az adattárházak megjelenése előtt, alacsony egyéni és szervezeti termelékenység mellett.

Az Adattárház a Feature Store egyik bemenete

Mindkét platform a kurált adatok központi tárolója, amelyek segítségével betekintést nyerhet az adatokba. Mindkét platform rendelkezik csővezetékekkel (ETL és szolgáltatási csővezetékek), hogy egy vagy több különböző forrásból (működési adatbázisok, adatforrások stb.) nyerjenek adatokat.

Mindkettő számára előnyös a metaadat-katalógus az adatkészletek rendszerezéséhez, valamint a hozzáférés-szabályozás az adatok megosztásához csak arra jogosult szereplőkkel.

Mindkét platformot meg lehet tervezni úgy, hogy kibővítsék az árucikkek hardverét, és nagy mennyiségű adatot tároljanak, bár az adattárházak általában csak az elemzés szempontjából relevánsakat tárolják (a modern „adatbázisokat” úgy tervezték, hogy nagy mennyiségű adatot tároljanak költséghatékonyabban).‍

A funkciók tárolása kettős adatbázisként

A fő építészeti különbség az adattárház és a szolgáltatástároló között az, hogy az adattárház jellemzően egyetlen oszlopos adatbázis, míg a szolgáltatástároló jellemzően két adatbázisként valósul meg:

  • egy offline szolgáltatástároló a szolgáltatások nagy kötegeinek kiszolgálásához (1) képzési/tesztelési adatkészletek létrehozásához és (2) kötegelt alkalmazásokhoz, amelyek pontozzák a modelleket ezen kötegek használatával, és
  • egy online szolgáltatásbolt a szolgáltatások egyetlen sorának (egy szolgáltatás vektorának) kiszolgálásához, amelyet egy online modell bemeneti funkciójaként használnak egy egyedi előrejelzéshez.

Az az offline szolgáltatástárolóra általában nagy mennyiségű funkcióadat hatékony kiszolgálásához és tárolásához van szükség, míg az online szolgáltatástárolónak nagyon alacsony késleltetési idő alatt kell visszaadnia a funkcióvektorokat (pl. ‹ 10 ms). Az offline szolgáltatástárolóhoz használt adatbázisok például az Apache Hive és a BigQuery, az online szolgáltatástárolókra pedig a MySQL Cluster, a Redis és a DynamoDB.

Vegye figyelembe, hogy ha a különböző modellekhez tartozó különböző betanítási/tesztadatkészletekben lévő funkciókat szeretné újra felhasználni, az adatbázisnak vagy alkalmazásnak egyesítenie kell a szolgáltatásokat. Ez mind az offline, mind az online szolgáltatásboltokra igaz. Ha a szolgáltatástárolója nem támogatja a funkciók összekapcsolását, vagyis nem használja fel újra a funkciókat különböző modelleken, akkor Önnek (vagy bizonyos rendszernek) új feldolgozási folyamatot kell létrehoznia minden új modellhez, amelyet a termelésben támogat.

Részletes összehasonlítás

Az alábbi táblázatban áttekintést kapunk a funkciótárolók és adattárházak közötti főbb felépítési különbségekről.Az adattárházakat elsősorban az üzleti elemzők használják interaktív lekérdezésre, valamint előzményjelentések/irányítópultok létrehozására a vállalkozásról. A A szolgáltatástárolókat az adatkutatók és az online/kötegelt alkalmazások egyaránt használják, és jellemzően Python vagy Scala/Java nyelven írt szolgáltatásfolyamatok táplálják őket.

Az adattudósok általában Python programokat használnak betanítási/tesztelési adatkészletek létrehozására oly módon, hogy összekapcsolják a szolgáltatástárban meglévő szolgáltatásokat, és a betanítási/tesztelési adatkészleteket „a keretrendszernek leginkább megfelelő fájlformátumban” valósítják meg, amelyben modelljüket betanítani kívánják (pl. TFRecord a TensorFlow-hoz, NPY a PyTorch-hoz). Az adattárházakból és az SQL-ből jelenleg hiányzik ez a képesség a betanítási/tesztelési adatkészletek létrehozására ML fájlformátumokban.

A szolgáltatás adatait a lenyelés előtt ellenőrizni kell

A táblázat bemutatja a tárolt adatok típusai közötti különbségeket, valamint az adatok tárolásának, érvényesítésének és lekérdezésének módját is. Az adattárház táblákban tárolja az adatokat az adattípusok és az oszlopokra vonatkozó megszorítások leírására szolgáló sémákkal együtt. Hasonlóképpen a jellemzőtároló tárolja a beírt adatokat (jellemzően táblázatokban), de mivel a jellemzőket jellemzően fogyasztásra kész numerikus értékekként vagy vektorokként (beágyazások) vagy tenzorokként tárolják, kevésbé van szükség gazdagabb oszloptípus-készletre, mint egy adattárház. Az idegen kulcsok megszorításai általában nem támogatottak a szolgáltatásboltokban, mivel az ilyen megszorításokat nehéz betartani az online és offline üzletek között.

Mivel a modelltanítás nagyon érzékeny a rossz adatokra (null értékek, kiugró értékek numerikus instabilitást okoznak, hiányzó értékek), a jellemzőadatokat a feldolgozás előtt ellenőrizni kell. Az olyan adatellenőrzési keretrendszerek, mint a „Great Expectations” és a „Deequ”, úgy tűnt, hogy segítik azokat a szolgáltatásfolyamatokat, amelyek predikátumokat (adatellenőrzési szabályokat) alkalmaznak a szolgáltatástárolóba bevitt összes szolgáltatásra, így biztosítva a szolgáltatástárban a magas adatminőséget.

Időnként tartományspecifikus nyelveket (DSL) használnak a jellemző transzformációk, összesítések és adatellenőrzési szabályok meghatározására a szolgáltatásfolyamatokban, de általános célú nyelveket (Python, Scala) gyakran használnak, ha nem triviális szolgáltatástervezésre van szükség.

A funkciótár használata vonat-/tesztadatok létrehozására

Az adattudósok a funkciótár egyik fő felhasználói. Szolgáltatástárat használnak feltáró adatelemzés (EDA) végrehajtására – az elérhető szolgáltatások keresése/böngészése, valamint a szolgáltatásértékek/séma/statisztika ellenőrzése. Az adatkutatók főként a Python segítségével választanak ki funkciókat a betanítási/tesztelési adatkészletek létrehozásához. Ez általában azt jelenti, hogy összekapcsolják a szolgáltatásokat, és létrehoznak egy vonat/teszt adatkészletet a választott fájlformátumukban (.tfrecord, .csv, .npy, .petastorm stb.). Néha a szolgáltatásboltok támogatják a DSL-t (tartományspecifikus nyelv) képzési/teszt adatkészletek vagy más nyelvek, például a Scala/Java létrehozásához.

Online szolgáltatás áruház

Az online alkalmazások az online szolgáltatásboltot használják alacsony késleltetésű jellemzőértékek lekérésére, hogy olyan jellemzővektorokat építsenek, amelyeket előrejelzés céljából elküldenek a modelleknek. A magasabb késleltetésű adattárházakkal ellentétben előfordulhat, hogy a szolgáltatástárolóknak egyetlen ezredmásodperces késleltetéssel kell visszaadniuk a jellemzővektorokat – ez csak a sororientált vagy kulcsérték-tárolókban érhető el.

A jellemzők lekérésének tipikus hozzáférési mintája a kulcsérték-keresés, de ha a szolgáltatásokat újra fel kívánja használni az online szolgáltatástárolóban, akkor ismét össze kell kapcsolni (akár az adatbázisban, akár az alkalmazásban). Egyes adatbázisokban (mint például a MySQL Cluster) kis számú összekapcsolás hajtható végre nagyon alacsony késleltetéssel.

Funkcióstatisztikák a funkciók
eltolódásának és adatsodródásának figyeléséhez

A jellemzők leíró statisztikái (pl. átlag, szórás) szintén hasznosak az adatsodródás azonosításakor az online modellekben. Monitoring infrastruktúrája képes kiszámítani az élő előrejelzési forgalom statisztikáit, és összehasonlítani ezeket a statisztikákat a szolgáltatástárolóban található értékekkel, hogy „azonosítsa az adatsodródást” az élő forgalomhoz, ami a modell esetlegesen szükséges átképzését.

Időutazás

Az időbeli adatbázisok támogatják az időutazást: az adatok lekérdezésének lehetőségét úgy, ahogyan azok egy adott időpontban voltak, vagy az adatok változásait egy adott időintervallumban. Az „AS OF SYSTEM TIME” szintaxist az „SQL 2011”-ben vezették be a pont-időben történő lekérdezések szabványosítására, míg a „VERSIONS BETWEEN SYSTEM TIME … AND …” szintaxist az adatok időintervallumon belüli verziószámú változásainak azonosítására vezették be. Az időutazást egyes adattárházak támogatják, de nem minden szállítónál van egyetemes támogatása.

Egy szolgáltatástároló esetében az időutazásnak számos fontos felhasználása van: vonat-/tesztadatok létrehozásakor (pl. a képzési adatok a 2010–2018-as évekből, míg a tesztadatok a 2019–2020-as tartományból származnak). Az időutazás akkor is hasznos, ha módosítani akar egy adatkészletet (például visszaállítja az adatok rossz véglegesítését az adatkészletben), vagy összehasonlítja a metaadatokat (statisztikáit) a szolgáltatásokhoz és azok időbeli változásához. Ritkán igényelünk időutazást a kiszolgálás során használt funkciókhoz. Az időutazás akkor is fontos, amikor pont-időben való összekapcsolásokat hajtunk végre, ahol biztosítjuk, hogy ne szivárogjon adat a jövőből, amikor előzményadatokból vonatozási/tesztelési adatkészleteket hozunk létre.

Feature Pipeline

Az adattárházak jellemzően időzített triggerekkel rendelkeznek az ETL-feladatok (vagy adatfolyamok) futtatásához, hogy a legfrissebb adatokat feldolgozzák a működő adatbázisokból, üzenetsorokból és adattókokból. Hasonlóképpen, a szolgáltatásfolyamatok időzített triggereket képesek átalakítani és összesíteni a különböző forrásokból származó legfrissebb adatokat, mielőtt az online és offline szolgáltatástárolóban tárolnák azokat online és offline alkalmazások általi pontozáshoz. Azonban további folyamatok is betáplálhatnak funkciókat a szolgáltatástárolóba.

A modellek által készített előrejelzések az előrejelzések eredményeivel együtt a funkciótárban tárolhatók. Hosszú, akár napok, hónapok vagy évek telhet el, mire az eredmények elérhetővé válnak – például előrejelzés arra vonatkozóan, hogy a kölcsönt visszafizetik-e vagy sem), de amint megérkeznek, új képzési adatok válnak elérhetővé, amelyek felhasználhatók az újraképzés kiváltására. modellek közül.

Következtetések

Az adattárházak használhatók előre kiszámított szolgáltatások tárolására, de az ML-folyamatoknál nem nyújtanak sokkal több funkciót. Ha a Data Scientistnek Python használatával képzési/tesztelési adatokat kell létrehoznia, vagy ha online szolgáltatásokra van szükség (a szolgáltatások online modellekhez való kiszolgálásához) alacsony késleltetés mellett, akkor szolgáltatástárolóra van szüksége. Hasonlóképpen, ha a funkciók eltolódását vagy adatsodródását szeretné észlelni, támogatásra van szüksége a szolgáltatásstatisztikák kiszámításához és az elsodródás azonosításához.

„Csillagozzon meg minket a GitHubon!”