В днешно време все повече и повече организации биха искали да имат унифициран инструмент, за да се справят с тоновете си функции. За един прост POC продукт управлението на функциите и родословието изглеждат пресилени, но когато става дума за големи, сложни и непрекъснато развиващи се проекти, те наистина подтикват високо качество на функциите и ефективност на изпълнение в следните проекти за наука за данни.

За да обобщим, защо се нуждаем от магазин за функции?

  • Стандартизиране на дефинициите на характеристиките. Това трябва да бъде отворена, разширяема, унифицирана платформа за съхранение на функции.
  • Насърчаване на функцията повторна употреба. Улеснява откриването и повторното използване на функции в проекти за машинно обучение.
  • Осигуряване на точност до точка във времето за извличане на функции. Важно е за възпроизводимостта.
  • Функция за проверка на качествоната. Специалистите по данни/инженерите по машинно обучение определят критериите за приемане на стойностите на функциите и тези правила ще се използват за проверка на стойността на характеристиките по време на поглъщане на данни.
  • Премахнете изкривеността на данните за влак/прогноза. Учените по данни не трябва да се тревожат за функции за прогнозиране и обучение на модели, които идват от различни дистрибуции или преминават през различен процес на трансформация.

Понякога магазинът за функции означава различни неща за различните хора или компании, защото те имат свои собствени уникални изисквания и искат тези изисквания да станат част от изпълнението на магазина за функции.

В тази статия ще разделя изискванията за общ магазин за функции на групи, така че да можете да изберете някои или всички от тях в пътната карта за внедряване на магазина за функции.

Група 1: Магазин за функции Vanilla

  • Потекло на функцията: версия, описание, собственик, време, произход. Помага да се отговори на следните въпроси на учените по данни. Откъде идват тези функции? Как са изчислени? кой е собственикът на тези функции? Валидни ли са още?
  • Извличане на характеристики в даден момент. Това се използва за предотвратяване на изтичане на данни. Когато тренирате модели, някои функции са достъпни само след определено време, потребителите трябва да вземат това предвид.
  • Поглъщане на данни с висока пропускателна способност. Производителността на партидното зареждане на данни е един от критичните показатели за хранилището на функции.
  • Онлайн обработка на функции с ниска латентност. За онлайн прогнозиране функциите трябва да бъдат подготвени своевременно, това допринася за ефективността на прогнозирането от край до край.
  • SDK. Най-общо казано, инженерите по данни, инженерите по машинно обучение и учените по данни са основните потребители на магазина за функции. Те може да имат свои собствени езикови предпочитания за комуникация с магазина за функции. Python и java може да са най-популярните избори за SDK.
  • Функции за откриване на характеристики. Помогнете на потребителите да изследват магазина за функции, това е за повторна употреба на функции.

Група 2: Единен офлайн и онлайн процес

  • Офлайн и онлайн споделяне на логика. Въпреки че почти всички смятаме, че е лошо да имаме отделен софтуер за работа с офлайн и онлайн данни, ние трябва да го внедрим по този начин, за да отговорим на собствените онлайн и офлайн изисквания. Изключително полезно е да споделяте една и съща логика за онлайн и офлайн процесите и да се превръщате в различен процес само когато е необходимо.
  • Онлайн и офлайн синхронизиране на данни. Понякога използваме хранилище за данни като офлайн хранилище на данни (за uber Hive, за feast Bigquery) и използваме база данни с ключ-стойност като онлайн хранилище (за uber Cassandra, за feast Redis), трябва ли да синхронизираме данни в тези хранилища на данни ? Някои функции може да са налични само в офлайн хранилище, как бихме могли да позволим на онлайн прогнозирането да използва функцията. „Ламбда архитектурата“ може да е една от възможностите, можем ли да го направим по по-елегантен начин?

Група 2: Автоматично генериране на характеристики

  • DSL за генериране на функции. Някои магазини за функции считат генерирането на функции за част от тяхната функция, те използват `yaml` или други конфигурационни файлове, за да определят как се генерират функции. Един добър пример е „циплайн“.
  • График за генериране на функции. Планирането на задачи за генериране на функции също може да бъде част от магазина за функции, Airflow изглежда е изборът по подразбиране за внедряване.
  • Обратно насипване. Когато се създават нови правила за генериране на функции, историческите данни ще се използват за изчисляване на новата функция.

Група 3: Изисквания за напреднали

  • Без заключване на хранилището. За онлайн и офлайн съхранение на данни ще бъде чудесно, ако можем да мигрираме от едно към друго, за да предотвратим блокиране на доставчика.
  • Еднообразен партиден и поточен процес. Използвайте същата рамка, за да се справите с онлайн или офлайн процес на данни.

Справка: