By Duitse Osin, Senior Solutions Architect bij Provectus.

Afbeelding door Yurchanka Siarhei oppompen van Shutterstock.

Kunstmatige intelligentie en machine learning hebben een keerpunt bereikt. In 2020 begonnen organisaties in verschillende industrieën van verschillende groottes hun ML-projecten te ontwikkelen van experimenten naar productie op industriële schaal. Terwijl ze dit deden, realiseerden ze zich dat ze veel tijd en moeite verspilden aan het definiëren en extraheren van functies.

Feature store is een fundamenteel onderdeel van de ML-stack en van elke robuuste data-infrastructuur omdat het efficiënte feature engineering en beheer mogelijk maakt. Het maakt ook eenvoudig hergebruik van functies mogelijk, standaardisatie van functies in het hele bedrijf en consistentie van functies tussen offline en online modellen. Een gecentraliseerde, schaalbare feature store stelt organisaties in staat sneller te innoveren en ML-processen op schaal aan te sturen.

Het team van Provectus heeft verschillende feature stores gebouwd en we willen graag onze ervaringen en geleerde lessen delen. In dit artikel zullen we onderzoeken hoe feature stores kunnen helpen bij het elimineren van herwerk en de traceerbaarheid van gegevens van bron tot model tussen teams kunnen afdwingen. We zullen de specifieke kenmerken van het bouwen van een schaalbare feature store onderzoeken en bespreken hoe we consistentie kunnen bereiken tussen real-time en trainingsfuncties, en hoe we de reproduceerbaarheid kunnen verbeteren met tijdreizen voor data.

Wat is een Feature Store?

Een Feature Store is een gegevensbeheerlaag voor functies voor machine learning. ML-functies zijn meetbare eigenschappen van verschijnselen die worden waargenomen, zoals onbewerkte woorden, pixels, sensorwaarden, rijen met gegevens in een gegevensopslag, velden in een CSV-bestand, aggregaten (min, max, som, gemiddelde) of afgeleide representaties (insluiten of TROS).

Vanuit zakelijk oogpunt bieden feature stores twee grote voordelen:

1. Betere ROI door feature-engineering door verlaging van de kosten per model, die samenwerking, delen en hergebruik van functies vergemakkelijkt
2. Snellere time-to-market voor nieuwe modellen, aangedreven door verhoogde productiviteit van ML Engineers​ Dit stelt organisaties in staat om storage-implementatie en API-functionaliteit los te koppelen van ML-engineers, waardoor ze aan modellen kunnen werken, niet aan latentieproblemen, voor een efficiëntere online weergave.

Sommige use-cases vereisen geen gecentraliseerde, schaalbare feature store. Feature stores werken voor projecten waar modellen een stateful, steeds veranderende weergave van het systeem nodig hebben. Voorbeelden van dergelijke use-cases zijn onder meer vraagvoorspelling, personalisatie en aanbevelingsengines, dynamische prijsoptimalisatie, supply chain-optimalisatie, logistiek en transportoptimalisatie, fraudedetectie en voorspellend onderhoud.

Concepten van een Feature Store

Een gestandaardiseerde feature store heeft bepaalde sleutelconcepten die eromheen draaien. Die concepten zijn:

1. Online functiewinkel​ Onlinetoepassingen zoeken naar een kenmerkvector die voor voorspellingen naar een ML-model wordt gestuurd.
2. ML-specifieke metagegevens​ Maakt het mogelijk om functies te ontdekken en opnieuw te gebruiken.
3. ML-specifieke API en SDK​ Bewerkingen op hoog niveau voor het ophalen van trainingsfunctiesets en online toegang.
4. Gematerialiseerde datasets met versiebeheer​ Onderhoudt versies van functiesets die worden gebruikt om ML-modellen te trainen.

Afbeelding door auteur.

Alle concepten zijn weergegeven in de bovenstaande afbeelding. Analytische gegevens worden uit een datameer gehaald en door de feature engineering-pijplijn gepusht, waar de uitvoer wordt opgeslagen in de feature store. Van daaruit kunnen ML-ingenieurs de functies ontdekken, ze gebruiken voor het trainen van nieuwe modellen en de functies vervolgens opnieuw gebruiken om te serveren.

Deze vier concepten worden ondersteund door meerdere producten. De leiders van de markt zijn Feast, Tecton, Hopsworks en AWS SageMaker-functiewinkel​ We zullen ons concentreren op open source-producten: Feast en Hopsworks.

# 1 Feest

Feest is een ML-service die teams helpt de kloof tussen data en machine learning-modellen te overbruggen. Hiermee kunnen teams functies in productie registreren, opnemen, bedienen en bewaken.

Deze service bevindt zich in de actieve ontwikkelingsfase, maar is al beproefd met GoJek, Farfetch, Postmates en Zulily. Het kan worden geïntegreerd met Kubeflow en wordt ondersteund door de sterke community van Kubeflow.

Vanaf 2020 is Feast een GCP-service. Het is een beetje infrastructuur-zwaar, mist composability en biedt geen gegevensversies. Merk op dat het bedrijf van plan is om deze uitdagingen aan te pakken in zijn routekaart voor 2021. En vanaf november 2020 is Feast beschikbaar als een open source-versie van Tecton.

Afbeelding door auteur.

# 2 Hopsworks

Hopswerken is een Enterprise Platform voor het ontwikkelen en exploiteren van AI-toepassingen. Hiermee kunnen teams ML-functies snel en efficiënt beheren. Het team achter Hopsworks zijn feature store-evangelisten en ze bieden veel geweldige educatieve inhoud.

De feature store van Hopsworks kan worden geïntegreerd met de meeste Python-bibliotheken voor opname en training. Het ondersteunt ook offline winkels met tijdreizen. Het belangrijkste is dat het AWS-, GCP-, Azure- en on-premise gereed is.

Wat Hopsworks tot een uitdaging maakt om te gebruiken, is de grote afhankelijkheid van de HopsML-infrastructuur. Ook voldoet de online winkel van Hopsworks mogelijk niet aan alle latentievereisten.

Afbeelding door auteur.

Uitdagingen van moderne dataplatforms

Voordat we ingaan op de specifieke kenmerken van het bouwen van feature stores, moeten de uitdagingen van moderne dataplatforms worden overwogen. Feature-archieven kunnen niet afzonderlijk van de rest van de gegevens en het ML-infrastructuur.

Traditioneel ziet een canonieke data lake-architectuur er als volgt uit:

Afbeelding door auteur.

Deze architectuur op hoog niveau heeft componenten voor sourcing, opname, verwerking, persisting, query's en een consumentencomponent. Hoewel het voor de meeste taken prima werkt, is het niet ideaal.

Gegevenstoegang en vindbaarheid kan een probleem zijn. Gegevens zijn verspreid over meerdere gegevensbronnen en services. Dit hielp ooit bij het beschermen van gegevens, maar nu voegt het alleen een nieuwe laag van complexiteit toe en creëert het gegevenssilo's. Een dergelijke architectuur brengt het moeizame proces met zich mee van het beheren van AWS IAM-rollen, Amazon S3-beleid, API-gateways en databasemachtigingen. Dit wordt nog ingewikkelder bij het opzetten van meerdere accounts. Als gevolg hiervan zijn ingenieurs in de war over welke gegevens er bestaan ​​en welke daadwerkelijk voor hen toegankelijk zijn, aangezien metadata niet standaard detecteerbaar zijn. Dit creëert een omgeving waarin investeringen in data en machine learning worden beperkt vanwege problemen met gegevenstoegang.

Monolithische datateams zijn een ander probleem om te overwegen. Omdat data- en machine learning-teams extreem gespecialiseerd zijn, moeten ze vaak buiten hun context opereren. Gebrek aan eigendom en domeincontext creëert silo's tussen dataproducenten en dataconsumenten, waardoor het aanzienlijk moeilijker wordt voor een datateam met achterstand in de zakelijke behoeften. Data- en ML-engineering worden het slachtoffer van complexe afhankelijkheden, waardoor hun activiteiten niet kunnen worden gesynchroniseerd. Elke snelle, end-to-end-experiment is in dergelijke omstandigheden niet mogelijk.

Infrastructuur voor experimenten met machine learning is onbekend terrein. Traditionele architectuur mist een experimentele component, wat niet alleen leidt tot problemen met gegevensdetectie en gegevenstoegang, maar het ook complexer maakt om de reproduceerbaarheid van datasets, ML-pijplijnen, ML-omgevingen en offline experimenten te behouden. Hoewel Amazon SageMaker en Kubeflow hier enige vooruitgang hebben geboekt, is reproduceerbaarheid problematisch. Kaders voor productie-experimenten zijn onvolwassen en kunnen niet volledig worden vertrouwd. Als gevolg hiervan kan het drie tot zes maanden duren om één end-to-end-experiment van data naar productie-ML te pushen.

ML in productie opschalen is complex en kost veel tijd en moeite. Hoewel machine learning meestal wordt besproken als een offline activiteit (bijv. Gegevensverzameling, verwerking, modeltraining, evaluatie van resultaten, enz.), Zijn de manieren waarop modellen online in de echte wereld worden gebruikt en bediend, wat er werkelijk toe doet. Met een traditionele architectuur hebt u tijdens het presenteren van modellen op een uniforme en consistente manier geen toegang tot functies. U kunt functies tussen meerdere trainingspijplijnen en ML-toepassingen ook niet hergebruiken. Het bewaken en onderhouden van ML-toepassingen is ook ingewikkelder. Als gevolg hiervan groeien de tijd en kosten die nodig zijn om van 1 naar 100 modellen in productie te schalen exponentieel, wat het vermogen van organisaties om in het gewenste tempo te innoveren, beperkt.

Opkomende architecturale verschuivingen

Om deze uitdagingen het hoofd te bieden, zijn er verschillende architecturale verschuivingen ontstaan:

1. Van Data Lakes tot Hudi / Delta meren​ Een datameer is niet alleen een map in Amazon S3. Het is een functierijke, volledig beheerde laag voor gegevensopname, incrementele verwerking en serveren met ACID-transacties en point-in-time queries.
2. Van datameren tot datamesh​ Het eigendom van datadomeinen, datapijplijnen, metadata en API's verschuift van gecentraliseerde teams naar productteams. Een ander belangrijk voordeel is het behandelen en bezitten van gegevens als een compleet product in plaats van een bijwerking waar niemand om geeft.
3. Van datameren tot data-infrastructuur als platform​ Als het eigendom van data gedecentraliseerd is, moeten platformcomponenten worden verenigd en verpakt in een herbruikbaar dataplatform.
4. Van Endpoint Protection tot Global Data Governance​ Als onderdeel van de verschuiving naar gecentraliseerde dataplatforms, stappen organisaties over van Endpoint Protection naar Global Data Governance, een controleplan op een hoger niveau voor het beheren van beveiligings- en gegevenstoegangsbeleid voor beschikbare gegevensbronnen.
5. Van metadatastore tot globale datacatalogus​ Metagegevensopslag zoals Hive-metastore kan niet veel gegevensbronnen samenvoegen. De branche heeft een wereldwijde gegevenscatalogus nodig om de gebruikerservaring te ondersteunen op het gebied van gegevensdetectie, afkomst en versiebeheer.
6. Functie winkel​ Feature store is een nieuw opkomend onderdeel van de ML-stack dat schaalvergroting van ML-experimenten en -bewerkingen mogelijk maakt door een afzonderlijke gegevensbeheerlaag voor ML-functies toe te voegen.

Al deze transformaties vinden parallel plaats en moeten als holistisch worden beschouwd. U kunt niet beginnen met het ontwerpen van een feature store en uiteindelijk aparte datacatalogi hebben voor features en voor andere datatoepassingen. Bij het bouwen van een feature store moet u vertrouwen op data versioning features, die gemakkelijk deel kunnen uitmaken van andere parallelle projecten.

Voordat we verder gaan, slechts een paar woorden over vier belangrijke componenten die de bovengenoemde transformaties van onsamenhangende ML-taken naar MLOps aandrijven, om een ​​bredere context te bieden voor het belang van feature stores.

# 1 Delta / Hudi-meren

ACID-datameren maken beheerde opname mogelijk, efficiënte versiebeheer van gegevenssets voor ML-training, goedkope "verwijderingen" om het GDPR / CCPA-compatibel te maken en "upserts" voor gegevensopname. Ze bieden ook een auditlogboek om wijzigingen in de dataset en ACID-transacties bij te houden, terwijl de datakwaliteit door middel van schema's wordt afgedwongen. De meren van Delta en Hudi brengen stroomverwerking naar Big Data, waardoor nieuwe gegevens veel efficiënter worden geleverd dan traditionele batchverwerking.

# 2 Wereldwijd gegevensbeheer

Omdat het niet langer een standaard is om AWS IAM-rollen, Amazon S3-beleid, API Gateways en databasemachtigingen op gebruikersniveau te beheren, moet een bedrijfsbrede gegevensbeheerstructuur worden gebruikt om:

1. Versnel privacyactiviteiten met gegevens die u al hebt. Automatiseer bedrijfsprocessen, gegevenstoewijzing en PI-detectie en classificatie voor privacyworkflows.
2. Operationaliseer beleid op een centrale locatie. Beheer het privacybeleid om ervoor te zorgen dat het beleid effectief wordt beheerd in de hele onderneming. Definieer en documenteer workflows, traceerbaarheidsweergaven en bedrijfsprocesregisters.
3. Schaal compliance over meerdere regelgeving heen. Gebruik een platform dat is ontworpen en gebouwd met het oog op privacy dat gemakkelijk kan worden uitgebreid om nieuwe regelgeving te ondersteunen.

# 3 Globale gegevenscatalogus

Hoewel er hier geen enkele marktleider is, zijn Marquez, Amundsen, Apache Atlas, Collibra, Alation en Data Hub het vermelden waard.

Een globale datacatalogus is uitermate handig voor het beantwoorden van vragen als bestaan ​​deze gegevens? Waar is het? Wat is de waarheid van deze gegevens? Heb ik toegang? Wie is de eigenaar? Wie zijn de gebruikers van deze gegevens? Zijn er bestaande activa die ik kan hergebruiken? Kan ik deze gegevens vertrouwen? In feite fungeert het als een soort metagegevensopslag.

# 4 Reproduceerbare ML-pijplijnen

Het laatste onderdeel zijn reproduceerbare ML-pijplijnen voor experimenten.

Afbeelding door auteur.

De bovenstaande grafiek geeft de architectuur weer voor MLOps en reproduceerbare experimenteerpijplijnen. Het begint met vier ingangen: ML-modelcode, ML-pijplijncode, Infrastructuur als een code en Versie-dataset. De dataset met versiebeheer - een invoer voor uw machine learning-pijplijn - moet afkomstig zijn uit de feature store.

Moderne data-infrastructuur

Laten we nu eens kijken naar de moderne data-infrastructuur.

Afbeelding door auteur.

We hebben batchverwerking voor onbewerkte gegevens en streamverwerking voor gebeurtenisgegevens. We slaan verwerkte artefacten op in koude opslag voor zakelijke rapporten en in een bijna realtime, stapsgewijs bijgewerkte hotindex voor onze API. Dezelfde gegevens kunnen in beide scenario's worden gebruikt en om het consistent te maken, gebruiken we verschillende pub / subsystemen.

Dit is de traditionele architectuur voor dataplatforms. Het doel is om consistentie te bieden tussen koude en warme opslag en om vindbaarheid vanuit de datacatalogus, datakwaliteit en wereldwijde beveiliging mogelijk te maken met een fijnmazige controle erop.

Afbeelding door auteur.

Als we kijken naar het ontwerp van een feature store, zullen we features en infrastructuurcomponenten zien die vrijwel identiek zijn aan wat we hebben in het dataplatform. In dit geval is de feature store geen aparte silo die weer een ander innamesysteem, opslag, catalogus en kwaliteitspoorten biedt. Het dient als een lichtgewicht API tussen ons dataplatform en ML-tools. Het kan mooi worden geïntegreerd met alles wat al in uw data-infrastructuur is gedaan. Het moet composable en lichtgewicht zijn en zonder een eigenzinnig ontwerp.

Afbeelding door auteur.

Wanneer u begint met het ontwerpen en bouwen van uw gegevensinfrastructuur, moet u rekening houden met de volgende "geleerde lessen" tot nu toe:

1. Begin met het ontwerpen van een consistent ACID Data Lake voordat u investeert in een Feature Store.
2. De waarde van bestaande open-sourceproducten rechtvaardigt investeringen in integratie en de afhankelijkheden die ze met zich meebrengen niet.
3. Een feature store is geen nieuwe infrastructuur en data-opslagoplossing, maar een lichtgewicht API en SDK geïntegreerd in uw bestaande data-infrastructuur.
4. De componenten Data Catalog, Data Governance en Data Quality zijn horizontaal voor de gehele data-infrastructuur, inclusief de feature store.
5. Er zijn geen volwassen open source- of cloudoplossingen voor monitoring van Global Data Catalog en Data Quality.

Referentiearchitectuur

Afbeelding door auteur.

Deze grafiek geeft de referentiearchitectuur weer die we voor onze klanten hebben gebruikt. Het bevat de services die we hebben gekozen om te gebruiken, maar u mag niet worden beperkt door onze keuzes. Het idee hier is dat je voor koud moet kiezen en hot storage op basis van uw gegevensworkloads en op basis van uw zakelijke behoeften.

Voor hot storage kunt u kiezen uit DynamoDB, Cassandra, Hbase of traditionele RDBMS zoals Mysql, PostgreSQL of zelfs Redis. Het is belangrijk dat uw hot storage composable, pluggable en in lijn is met uw data-infrastructuurstrategie

Voor koude opslag zijn Apache Hudi en Delta Lake onze favorieten. Ze bieden functies als tijdreizen, incrementele opname en gematerialiseerde weergaven.

Er zijn enkele lege ruimtes in het diagram, die we binnenkort hopen te vullen. Tot nu toe is er bijvoorbeeld geen over-the-shelf leider voor de datacatalogus. Datakwaliteitstools bevinden zich ook in de beginfase. Voor nu kun je kiezen uit Great Expectations of Apache Deequ, geweldige tools, maar ze bieden geen complete oplossing.

Afbeelding door auteur.

In de bovenstaande afbeelding bezetten de vraagtekens ruimtes waar u kunt kiezen uit oplossingen die zijn gebouwd door open source-gemeenschappen, uw eigen oplossing intern kunt bouwen of kunt samenwerken met cloudproviders (bijv. De nieuwste toevoeging van AWS - Amazon SageMaker Feature Store voor machine learning).

Vooruitgaan met Feature Store

Hoewel het nog vroeg in de game is voor feature stores, hebben organisaties die niet alleen experimenteren, maar ook machine learning-projecten actief naar productie verplaatsen, zich al gerealiseerd dat er behoefte is aan een gecentraliseerde opslagplaats om functies op te slaan, bij te werken, op te halen en te delen.

In dit artikel hebben we laten zien hoe je zo'n repository kunt ontwerpen en bouwen. Hoewel sommige van de hier besproken punten discutabel zijn en openstaan ​​voor feedback van de gemeenschap, is het duidelijk dat:

1. Uw bestaande data-infrastructuur moet ten minste 90% van de feature store-vereisten dekken, inclusief streaming-opname, consistentie, datacatalogus en versiebeheer, om het gewenste resultaat te bereiken.
2. Het is logisch om een ​​lichtgewicht Feature Store API te bouwen om te integreren met uw bestaande interne opslagoplossingen.
3. U moet samenwerken met community- en cloudleveranciers om de compatibiliteit met standaarden en geavanceerde ecosystemen te behouden.
4. U moet klaar zijn om te migreren naar een beheerde service of naar een open-sourcealternatief naarmate de markt ouder wordt.

ORIGINELE. Met toestemming opnieuw gepost.

Zie ook:

• Feature Store versus Data Warehouse
• Een belangrijk ontbrekend onderdeel van de machine learning-stack
• The Hitchhiker's Guide to Feature Extraction