Wstępne przetwarzanie danych dla ML: opcje i rekomendacje

Ten dokument jest pierwszym z dwuczęściowej serii eksplorującej temat inżynierii danych i inżynierii funkcji na potrzeby uczenia maszynowego (ML), ze szczególnym uwzględnieniem zadań uczenia się nadzorowanego. W pierwszej części omówiono najlepsze praktyki wstępnego przetwarzania danych w potoku uczenia maszynowego w Google Cloud. Dokument koncentruje się na użyciu TensorFlow i biblioteki TensorFlow Transform ( tf.Transform ) o otwartym kodzie źródłowym do przygotowywania danych, uczenia modelu i obsługi modelu do przewidywania. W tym dokumencie podkreślono wyzwania związane z wstępnym przetwarzaniem danych na potrzeby ML oraz opisano opcje i scenariusze skutecznego przeprowadzania transformacji danych w Google Cloud.

W tym dokumencie założono, że znasz BigQuery , Dataflow , Vertex AI i interfejs API TensorFlow Keras .

Drugi dokument, Wstępne przetwarzanie danych dla uczenia maszynowego za pomocą Google Cloud , zawiera samouczek krok po kroku dotyczący wdrażania potoku tf.Transform .

Wstęp

ML pomaga automatycznie znajdować złożone i potencjalnie przydatne wzorce w danych. Wzorce te są kondensowane w modelu uczenia maszynowego, który można następnie wykorzystać w nowych punktach danych — jest to proces nazywany tworzeniem przewidywań lub wnioskowaniem .

Budowa modelu ML to proces wieloetapowy. Każdy etap wiąże się z własnymi wyzwaniami technicznymi i koncepcyjnymi. Ta dwuczęściowa seria koncentruje się na zadaniach uczenia się pod nadzorem oraz procesie selekcji, przekształcania i rozszerzania danych źródłowych w celu wytworzenia potężnych sygnałów predykcyjnych dla zmiennej docelowej. Operacje te łączą wiedzę dziedzinową z technikami analityki danych. Operacje są istotą inżynierii cech .

Rozmiar zestawów danych szkoleniowych dla rzeczywistych modeli uczenia maszynowego może z łatwością być równy lub większy niż jeden terabajt (TB). Dlatego potrzebne są struktury przetwarzania danych na dużą skalę, aby przetwarzać te zbiory danych wydajnie i rozproszonie. Jeśli używasz modelu uczenia maszynowego do tworzenia prognoz, musisz zastosować te same przekształcenia, które zostały użyte w przypadku danych szkoleniowych w nowych punktach danych. Stosując te same przekształcenia, prezentujesz aktywny zestaw danych w modelu ML w sposób zgodny z oczekiwaniami modelu.

W tym dokumencie omówiono te wyzwania dla różnych poziomów szczegółowości operacji inżynierii funkcji: agregacji na poziomie instancji, pełnego przebiegu i agregacji okien czasowych. W tym dokumencie opisano również opcje i scenariusze przeprowadzania transformacji danych dla ML w Google Cloud.

Ten dokument zawiera także omówienie TensorFlow Transform ( tf.Transform ), biblioteki dla TensorFlow, która umożliwia definiowanie transformacji danych zarówno na poziomie instancji, jak i w trybie pełnego przejścia za pomocą potoków wstępnego przetwarzania danych. Te potoki są wykonywane za pomocą Apache Beam i tworzą artefakty, które umożliwiają zastosowanie tych samych transformacji podczas prognozowania, co podczas udostępniania modelu.

Wstępne przetwarzanie danych dla ML

W tej sekcji przedstawiono operacje wstępnego przetwarzania danych i etapy gotowości danych. Omówiono także rodzaje operacji wstępnego przetwarzania i ich szczegółowość.

Inżynieria danych w porównaniu z inżynierią cech

Wstępne przetwarzanie danych na potrzeby uczenia maszynowego obejmuje zarówno inżynierię danych, jak i inżynierię funkcji. Inżynieria danych to proces przekształcania surowych danych w przygotowane dane . Następnie inżynieria funkcji dostraja przygotowane dane, aby utworzyć funkcje oczekiwane przez model ML. Terminy te mają następujące znaczenie:

Surowe dane (lub po prostu dane )
Dane w formie źródłowej, bez wcześniejszego przygotowania do ML. W tym kontekście dane mogą występować w postaci surowej (w jeziorze danych) lub w formie przekształconej (w hurtowni danych). Przekształcone dane znajdujące się w hurtowni danych mogły zostać przekonwertowane z oryginalnej, surowej postaci w celu wykorzystania ich do celów analitycznych. Jednak w tym kontekście surowe dane oznaczają, że nie zostały przygotowane specjalnie na potrzeby zadania ML. Dane są również uważane za dane surowe, jeśli są wysyłane z systemów przesyłania strumieniowego, które ostatecznie wywołują modele uczenia maszynowego w celu uzyskania prognoz.
Przygotowane dane
Zbiór danych w formie gotowy do zadania ML: źródła danych zostały przeanalizowane, połączone i umieszczone w formie tabelarycznej. Przygotowane dane są agregowane i podsumowywane z odpowiednią szczegółowością — na przykład każdy wiersz w zbiorze danych reprezentuje unikalnego klienta, a każda kolumna przedstawia podsumowanie informacji o kliencie, np. sumę wydatków w ciągu ostatnich sześciu tygodni. W przygotowanej tabeli danych usunięto nieistotne kolumny i odfiltrowano nieprawidłowe rekordy. W przypadku zadań uczenia się pod nadzorem występuje funkcja docelowa.
Zaprojektowane funkcje
Zbiór danych ze dostrojonymi funkcjami, których oczekuje model — to znaczy funkcjami, które są tworzone poprzez wykonanie pewnych operacji specyficznych dla uczenia maszynowego na kolumnach w przygotowanym zbiorze danych oraz utworzenie nowych funkcji dla modelu podczas uczenia i przewidywania, jak opisano w dalszej części w operacjach wstępnego przetwarzania . Przykłady tych operacji obejmują skalowanie kolumn numerycznych do wartości z zakresu od 0 do 1, wartości obcinające i funkcje kategoryczne z jednym kodowaniem na gorąco .

Poniższy diagram, rysunek 1, przedstawia etapy przygotowania wstępnie przetworzonych danych:

Diagram przepływu przedstawiający przenoszenie surowych danych do przygotowanych danych przenoszenie do funkcji inżynieryjnych.
Rysunek 1. Przepływ danych od danych surowych do danych przygotowanych, do funkcji inżynieryjnych i do uczenia maszynowego.

W praktyce dane z tego samego źródła często znajdują się na różnych etapach gotowości. Na przykład pole z tabeli w hurtowni danych może zostać użyte bezpośrednio jako funkcja inżynieryjna. Jednocześnie inne pole w tej samej tabeli może wymagać przekształcenia, zanim stanie się funkcją inżynieryjną. Podobnie operacje inżynierii danych i inżynierii cech można połączyć w tym samym etapie wstępnego przetwarzania danych.

Operacje wstępnego przetwarzania

Wstępne przetwarzanie danych obejmuje kilka operacji. Każda operacja ma na celu pomóc ML w tworzeniu lepszych modeli predykcyjnych. Szczegóły tych operacji wstępnego przetwarzania wykraczają poza zakres tego dokumentu, ale niektóre operacje zostały pokrótce opisane w tej sekcji.

W przypadku danych strukturalnych operacje wstępnego przetwarzania danych obejmują:

  • Czyszczenie danych: usuwanie lub poprawianie rekordów, które mają uszkodzone lub nieprawidłowe wartości z nieprzetworzonych danych oraz usuwanie rekordów, w których brakuje dużej liczby kolumn.
  • Wybór i partycjonowanie instancji: wybieranie punktów danych z wejściowego zbioru danych w celu utworzenia zbiorów szkoleniowych, ewaluacyjnych (walidacyjnych) i testowych . Proces ten obejmuje techniki powtarzalnego próbkowania losowego, nadpróbkowania klas mniejszościowych i podziału warstwowego.
  • Dostrajanie funkcji: poprawianie jakości funkcji dla ML, co obejmuje skalowanie i normalizowanie wartości liczbowych, przypisywanie brakujących wartości, obcinanie wartości odstających i dostosowywanie wartości, które mają skośne rozkłady.
  • Transformacja funkcji: konwersja funkcji numerycznej na cechę jakościową (poprzez segmentację ) i konwersja cech kategorycznych na reprezentację numeryczną (poprzez kodowanie typu one-hot, uczenie się za pomocą zliczeń , osadzanie rzadkich funkcji itp.). Niektóre modele działają tylko z funkcjami numerycznymi lub kategorialnymi, podczas gdy inne obsługują funkcje typu mieszanego. Nawet jeśli modele obsługują oba typy, mogą skorzystać z różnych reprezentacji (numerycznej i jakościowej) tej samej cechy.
  • Ekstrakcja cech: redukcja liczby funkcji poprzez tworzenie mniejszych, bardziej wydajnych reprezentacji danych przy użyciu technik takich jak PCA , ekstrakcja osadzająca i hashowanie .
  • Wybór cech: wybór podzbioru cech wejściowych do szkolenia modelu i ignorowanie tych nieistotnych lub zbędnych, przy użyciu metod filtrowania lub opakowania . Wybór funkcji może również polegać na prostym usuwaniu funkcji, jeśli brakuje im dużej liczby wartości.
  • Konstrukcja cech: tworzenie nowych cech przy użyciu typowych technik, takich jak rozwinięcie wielomianu (przy użyciu jednowymiarowych funkcji matematycznych) lub krzyżowanie cech (w celu uchwycenia interakcji cech). Funkcje można również konstruować przy użyciu logiki biznesowej z domeny przypadku użycia ML.

Kiedy pracujesz z danymi nieustrukturyzowanymi (na przykład obrazami, plikami audio lub dokumentami tekstowymi), głębokie uczenie się zastępuje inżynierię funkcji opartą na wiedzy domeny, włączając ją do architektury modelu. Warstwa splotowa to automatyczny preprocesor funkcji. Skonstruowanie właściwej architektury modelu wymaga pewnej empirycznej wiedzy na temat danych. Ponadto wymagana jest pewna ilość wstępnego przetwarzania, na przykład:

  • W przypadku dokumentów tekstowych: stemming i lematyzacja , obliczenia TF-IDF i ekstrakcja n-gramów , wyszukiwanie osadzania.
  • W przypadku obrazów: przycinanie, zmiana rozmiaru, kadrowanie, rozmycie gaussowskie i filtry kanaryjskie.
  • Dla wszystkich typów danych (w tym tekstu i obrazów): uczenie transferowe , które traktuje wszystkie warstwy w pełni wyszkolonego modelu jako krok inżynierii funkcji.

Szczegółowość wstępnego przetwarzania

W tej sekcji omówiono szczegółowość typów transformacji danych. Pokazuje, dlaczego ta perspektywa jest kluczowa podczas przygotowywania nowych punktów danych do prognoz przy użyciu transformacji stosowanych na danych szkoleniowych.

Operacje przetwarzania wstępnego i transformacji można podzielić na następujące kategorie w zależności od szczegółowości operacji:

  • Transformacje na poziomie instancji podczas uczenia i przewidywania . Są to proste transformacje, w których do transformacji potrzebne są tylko wartości z tej samej instancji. Na przykład transformacje na poziomie instancji mogą obejmować obcięcie wartości cechy do pewnego progu, wielomianowe rozwinięcie innej cechy, pomnożenie dwóch cech lub porównanie dwóch cech w celu utworzenia flagi logicznej.

    Transformacje te muszą być stosowane identycznie podczas uczenia i przewidywania, ponieważ model będzie szkolony na przekształconych cechach, a nie na surowych wartościach wejściowych. Jeśli dane nie zostaną przekształcone identycznie, model będzie zachowywał się słabo, ponieważ zostaną mu przedstawione dane o rozkładzie wartości, z którym nie został przeszkolony. Aby uzyskać więcej informacji, zobacz omówienie pochylenia w zakresie obsługi szkolenia w sekcji Wyzwania związane z przetwarzaniem wstępnym .

  • Transformacje pełnoprzepustowe podczas uczenia, ale transformacje na poziomie instancji podczas przewidywania . W tym scenariuszu transformacje są stanowe, ponieważ do przeprowadzenia transformacji korzystają z wstępnie obliczonych statystyk. Podczas uczenia analizujesz cały zbiór danych szkoleniowych, aby obliczyć wielkości takie jak minimum, maksimum, średnia i wariancja w celu przekształcenia danych szkoleniowych, danych ewaluacyjnych i nowych danych w momencie przewidywania.

    Na przykład, aby znormalizować cechę liczbową na potrzeby uczenia, oblicza się jej średnią (μ) i odchylenie standardowe (σ) dla wszystkich danych uczących. To obliczenie nazywa się operacją pełnego przejścia (lub analizą ). Gdy model jest udostępniany do przewidywania, wartość nowego punktu danych jest normalizowana, aby uniknąć odchylenia w zakresie uczenia. Dlatego wartości μ i σ obliczane podczas uczenia służą do dostosowywania wartości cechy, co jest następującą prostą operacją na poziomie instancji :

    $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

    Transformacje pełnoprzepustowe obejmują:

    • MinMax skaluje funkcje numeryczne przy użyciu wartości min i max obliczonych na podstawie zbioru danych szkoleniowych.
    • Standardowe skalowanie (normalizacja wyniku Z) funkcji numerycznych przy użyciu μ i σ obliczonych na zbiorze danych szkoleniowych.
    • Bucketyzacja cech numerycznych za pomocą kwantyli.
    • Podpisywanie brakujących wartości za pomocą mediany (cechy liczbowe) lub trybu (cechy kategoryczne).
    • Konwertowanie ciągów znaków (wartości nominalnych) na liczby całkowite (indeksy) poprzez wyodrębnienie wszystkich odrębnych wartości (słownictwa) wejściowej cechy kategorycznej.
    • Zliczanie występowania terminu (wartości cechy) we wszystkich dokumentach (instancjach) w celu obliczenia dla TF-IDF.
    • Obliczanie PCA cech wejściowych w celu rzutowania danych na przestrzeń o niższych wymiarach (z cechami liniowo zależnymi).

    Do obliczania statystyk takich jak μ, σ, min i max należy używać wyłącznie danych uczących. Jeśli dodasz dane testowe i ewaluacyjne dla tych operacji, nastąpi wyciek informacji z danych ewaluacyjnych i testowych w celu uczenia modelu. Ma to wpływ na wiarygodność wyników testu i oceny. Aby mieć pewność, że zastosujesz spójną transformację do wszystkich zestawów danych, do transformacji danych testowych i ewaluacyjnych używasz tych samych statystyk obliczonych na podstawie danych szkoleniowych.

  • Agregacje historyczne podczas uczenia i przewidywania . Obejmuje to tworzenie agregacji biznesowych, wyprowadzeń i flag jako sygnałów wejściowych do zadania prognozowania — na przykład tworzenie wskaźników aktualności, częstotliwości i wskaźników pieniężnych (RFM) dla klientów w celu zbudowania modeli skłonności. Tego typu funkcje można wstępnie obliczyć i przechowywać w magazynie funkcji w celu wykorzystania podczas uczenia modeli, oceniania wsadowego i udostępniania prognoz online. Przed uczeniem i prognozowaniem można także przeprowadzić dodatkową inżynierię funkcji (na przykład transformację i dostrajanie) tych agregacji.

  • Agregacje historyczne podczas uczenia, ale agregacje w czasie rzeczywistym podczas przewidywania . Podejście to polega na utworzeniu funkcji poprzez podsumowanie wartości w czasie rzeczywistym w czasie. W tym podejściu instancje, które mają być agregowane, są definiowane poprzez klauzule tymczasowego okna. Można na przykład zastosować to podejście, jeśli chcesz wytrenować model, który szacuje czas podróży taksówką na podstawie wskaźników ruchu na trasie w ciągu ostatnich 5 minut, w ciągu ostatnich 10 minut, w ciągu ostatnich 30 minut i w innych interwały. Można również zastosować to podejście do przewidywania awarii części silnika na podstawie średniej ruchomej wartości temperatury i wibracji obliczonych w ciągu ostatnich 3 minut. Chociaż te agregacje można przygotować w trybie offline na potrzeby szkolenia, są one obliczane w czasie rzeczywistym na podstawie strumienia danych podczas udostępniania.

    Mówiąc dokładniej, podczas przygotowywania danych szkoleniowych, jeśli zagregowana wartość nie znajduje się w danych surowych, wartość jest tworzona w fazie inżynierii danych. Surowe dane są zwykle przechowywane w bazie danych w formacie (entity, timestamp, value) . W poprzednich przykładach entity jest identyfikatorem odcinka trasy dla tras kołowania i identyfikatorem części silnika w przypadku awarii silnika. Do obliczeń można używać operacji okienkowych (entity, time_index, aggregated_value_over_time_window) i używać funkcji agregacji jako danych wejściowych do uczenia modelu.

    Gdy używany jest model przewidywania w czasie rzeczywistym (online), model oczekuje jako danych wejściowych cech pochodzących z zagregowanych wartości. Dlatego możesz użyć technologii przetwarzania strumieniowego, takiej jak Apache Beam, do obliczenia agregacji na podstawie punktów danych w czasie rzeczywistym przesyłanych strumieniowo do systemu. Technologia przetwarzania strumieniowego agreguje dane w czasie rzeczywistym w oparciu o okna czasowe w miarę pojawiania się nowych punktów danych. Przed uczeniem i prognozowaniem można także przeprowadzić dodatkową inżynierię funkcji (na przykład transformację i dostrajanie) tych agregacji.

Potok uczenia maszynowego w Google Cloud

W tej sekcji omówiono podstawowe elementy typowego kompleksowego potoku służącego do uczenia i obsługi modeli TensorFlow ML w Google Cloud przy użyciu usług zarządzanych. Omówiono także, gdzie można wdrożyć różne kategorie operacji wstępnego przetwarzania danych oraz typowe wyzwania, jakie możesz napotkać podczas wdrażania takich transformacji. Sekcja Jak działa tf.Transform pokazuje, jak biblioteka TensorFlow Transform pomaga sprostać tym wyzwaniom.

Architektura na wysokim poziomie

Poniższy diagram (rysunek 2) przedstawia architekturę wysokiego poziomu typowego potoku uczenia maszynowego do szkolenia i obsługi modeli TensorFlow. Etykiety A, B i C na diagramie odnoszą się do różnych miejsc w potoku, w których może odbywać się wstępne przetwarzanie danych. Szczegółowe informacje na temat tych kroków znajdują się w poniższej sekcji.

Diagram architektury przedstawiający etapy przetwarzania danych.
Rysunek 2. Architektura wysokiego poziomu do szkolenia i obsługi ML w Google Cloud.

Rurociąg składa się z następujących etapów:

  1. Po zaimportowaniu nieprzetworzonych danych dane tabelaryczne są przechowywane w BigQuery, a inne dane, takie jak obrazy, dźwięk i wideo, są przechowywane w Cloud Storage. Druga część tej serii wykorzystuje jako przykład dane tabelaryczne przechowywane w BigQuery.
  2. Inżynieria danych (przygotowanie) i inżynieria funkcji są wykonywane na dużą skalę przy użyciu Dataflow. To wykonanie generuje zestawy szkoleniowe, ewaluacyjne i testowe gotowe do obsługi uczenia maszynowego, które są przechowywane w Cloud Storage. W idealnym przypadku te zestawy danych są przechowywane jako pliki TFRecord , co jest formatem zoptymalizowanym do obliczeń TensorFlow.
  3. Pakiet trenera modelu TensorFlow jest przesyłany do szkolenia Vertex AI, które wykorzystuje wstępnie przetworzone dane z poprzednich kroków do szkolenia modelu. Dane wyjściowe tego kroku to przeszkolony model TensorFlow SavedModel , który jest eksportowany do Cloud Storage.
  4. Wyszkolony model TensorFlow jest wdrażany w Vertex AI Prediction jako usługa posiadająca interfejs API REST, dzięki czemu można go używać do przewidywań online. Ten sam model można również wykorzystać do zadań przewidywania wsadowego.
  5. Po wdrożeniu modelu jako interfejsu API REST aplikacje klienckie i systemy wewnętrzne mogą wywoływać interfejs API, wysyłając żądania z pewnymi punktami danych i otrzymując odpowiedzi od modelu z przewidywaniami.
  6. Do organizowania i automatyzowania tego potoku można użyć Vertex AI Pipelines jako harmonogramu do wywoływania etapów przygotowania danych, uczenia modelu i wdrażania modelu.

Możesz także użyć magazynu funkcji Vertex AI do przechowywania funkcji wejściowych w celu tworzenia prognoz. Można na przykład okresowo tworzyć funkcje inżynieryjne na podstawie najnowszych nieprzetworzonych danych i przechowywać je w magazynie funkcji Vertex AI. Aplikacje klienckie pobierają wymagane funkcje wejściowe z magazynu funkcji Vertex AI i wysyłają je do modelu w celu otrzymania prognoz.

Gdzie przeprowadzić obróbkę wstępną

Na rysunku 2 etykiety A, B i C pokazują, że operacje wstępnego przetwarzania danych mogą odbywać się w BigQuery, Dataflow lub TensorFlow. W poniższych sekcjach opisano działanie każdej z tych opcji.

Opcja A: BigQuery

Zazwyczaj w BigQuery implementowana jest logika umożliwiająca wykonanie następujących operacji:

  • Próbkowanie: losowe wybieranie podzbioru danych.
  • Filtrowanie: usuwanie nieistotnych lub nieprawidłowych instancji.
  • Partycjonowanie: dzielenie danych w celu utworzenia zbiorów szkoleniowych, ewaluacyjnych i testowych.

Skryptów SQL BigQuery można używać jako zapytania źródłowego dla potoku wstępnego przetwarzania Dataflow, czyli etapu przetwarzania danych przedstawionego na rysunku 2. Jeśli na przykład system jest używany w Kanadzie, a hurtownia danych zawiera transakcje z całego świata, filtrowanie dane szkoleniowe dotyczące tylko Kanady najlepiej wykonać w BigQuery. Inżynieria funkcji w BigQuery jest prosta i skalowalna oraz umożliwia wdrażanie transformacji funkcji na poziomie instancji i agregacji historycznych.

Zalecamy jednak używanie BigQuery do inżynierii funkcji tylko wtedy, gdy używasz modelu do przewidywania zbiorczego (oceny) lub jeśli funkcje są wstępnie obliczane w BigQuery, ale przechowywane w magazynie funkcji Vertex AI do wykorzystania podczas przewidywania online. Jeśli planujesz wdrożyć model do prognoz online i nie masz zaprojektowanej funkcji w magazynie funkcji online, musisz zreplikować operacje wstępnego przetwarzania SQL, aby przekształcić surowe punkty danych generowane przez inne systemy. Innymi słowy, musisz zaimplementować tę logikę dwukrotnie: raz w SQL, aby wstępnie przetworzyć dane szkoleniowe w BigQuery, a drugi raz w logice aplikacji, która wykorzystuje model do wstępnego przetwarzania punktów danych online na potrzeby prognozowania.

Na przykład, jeśli aplikacja kliencka jest napisana w Javie, musisz ponownie zaimplementować logikę w Javie. Może to powodować błędy wynikające z rozbieżności w implementacji, jak opisano w sekcji dotyczącej przekrzywienia w obsłudze szkolenia w części Wyzwania związane z przetwarzaniem wstępnym w dalszej części tego dokumentu. Utrzymanie dwóch różnych implementacji jest również dodatkowym obciążeniem. Za każdym razem, gdy zmieniasz logikę w SQL w celu wstępnego przetwarzania danych szkoleniowych, musisz odpowiednio zmienić implementację Java, aby wstępnie przetwarzać dane w czasie udostępniania.

Jeśli używasz modelu tylko do przewidywania wsadowego (na przykład używasz przewidywania wsadowego Vertex AI) i jeśli dane do oceniania pochodzą z BigQuery, możesz zaimplementować te operacje przetwarzania wstępnego w ramach skryptu SQL BigQuery. W takim przypadku możesz użyć tego samego skryptu SQL do wstępnego przetwarzania, aby przygotować dane uczące i oceniające.

Pełnoprzepustowe transformacje stanowe nie nadają się do implementacji w BigQuery. Jeśli używasz BigQuery do transformacji pełnoprzepustowych, potrzebujesz tabel pomocniczych do przechowywania ilości potrzebnych do transformacji stanowych, takich jak średnie i wariancje do skalowania funkcji numerycznych. Co więcej, implementacja transformacji pełnoprzepustowych przy użyciu języka SQL w BigQuery zwiększa złożoność skryptów SQL i tworzy skomplikowaną zależność między uczącymi a oceniającymi skryptami SQL.

Opcja B: przepływ danych

Jak pokazano na rysunku 2, w Apache Beam można wdrożyć kosztowne obliczeniowo operacje wstępnego przetwarzania i uruchamiać je na dużą skalę za pomocą Dataflow. Dataflow to w pełni zarządzana usługa automatycznego skalowania do przetwarzania danych wsadowych i strumieniowych. Korzystając z Dataflow, możesz także używać zewnętrznych wyspecjalizowanych bibliotek do przetwarzania danych, w przeciwieństwie do BigQuery.

Dataflow może wykonywać przekształcenia na poziomie instancji oraz przekształcenia funkcji agregacji historycznej i agregacji w czasie rzeczywistym. W szczególności, jeśli modele uczenia maszynowego oczekują funkcji wejściowej, takiej jak total_number_of_clicks_last_90sec , funkcje okienkowe Apache Beam mogą obliczyć te funkcje w oparciu o agregację wartości okien czasowych danych zdarzeń w czasie rzeczywistym (strumieniowych) (na przykład zdarzeń kliknięć). We wcześniejszej dyskusji na temat szczegółowości transformacji nazywano to „agregacjami historycznymi podczas uczenia, ale agregacjami w czasie rzeczywistym podczas przewidywania”.

Poniższy diagram, rysunek 3, przedstawia rolę Dataflow w przetwarzaniu danych strumieniowych w celu uzyskania przewidywań w czasie zbliżonym do rzeczywistego.

Architektura wykorzystania danych strumieniowych do przewidywania.
Rysunek 3. Architektura wysokiego poziomu wykorzystująca dane strumieniowe do predykcji w Dataflow.

Jak pokazano na rysunku 3, podczas przetwarzania zdarzenia zwane punktami danych są pobierane do Pub/Sub . Dataflow wykorzystuje te punkty danych, oblicza funkcje na podstawie agregacji w czasie, a następnie wywołuje wdrożony interfejs API modelu ML w celu uzyskania prognoz. Prognozy są następnie wysyłane do wychodzącej kolejki Pub/Sub. Z Pub/Sub prognozy mogą być wykorzystywane przez systemy niższego szczebla, takie jak monitorowanie lub kontrola, lub mogą być przekazywane z powrotem (na przykład jako powiadomienia) do pierwotnego klienta wysyłającego żądanie. Prognozy można również przechowywać w magazynie danych o niskim opóźnieniu, takim jak Cloud Bigtable, w celu pobierania w czasie rzeczywistym. Cloud Bigtable może być również używany do gromadzenia i przechowywania agregacji w czasie rzeczywistym, dzięki czemu można je wyszukiwać w razie potrzeby w celu przewidywania.

Tę samą implementację Apache Beam można wykorzystać do przetwarzania wsadowego danych szkoleniowych pochodzących z magazynu danych offline, takiego jak BigQuery, oraz do przetwarzania strumieniowego danych w czasie rzeczywistym na potrzeby udostępniania prognoz online.

W innych typowych architekturach, takich jak architektura pokazana na rysunku 2, aplikacja kliencka bezpośrednio wywołuje interfejs API wdrożonego modelu w celu prognozowania online. W takim przypadku, jeśli w Dataflow zaimplementowano operacje przetwarzania wstępnego w celu przygotowania danych szkoleniowych, operacje te nie są stosowane do danych predykcyjnych, które trafiają bezpośrednio do modelu. Dlatego tego typu transformacje powinny zostać zintegrowane z modelem podczas udostępniania predykcji online.

Przepływu danych można używać do przeprowadzania transformacji pełnoprzepustowej poprzez obliczanie wymaganych statystyk na dużą skalę. Jednakże statystyki te muszą być gdzieś przechowywane, aby można je było wykorzystać podczas prognozowania w celu przekształcenia punktów danych prognozy. Korzystając z biblioteki TensorFlow Transform ( tf.Transform ), możesz bezpośrednio osadzić te statystyki w modelu, zamiast przechowywać je w innym miejscu. Podejście to wyjaśniono w dalszej części Jak działa tf.Transform .

Opcja C: TensorFlow

Jak pokazano na rysunku 2, możesz zaimplementować operacje wstępnego przetwarzania i transformacji danych w samym modelu TensorFlow. Jak pokazano na rysunku, przetwarzanie wstępne zaimplementowane na potrzeby uczenia modelu TensorFlow staje się integralną częścią modelu, gdy model jest eksportowany i wdrażany na potrzeby prognoz. Transformacje w modelu TensorFlow można zrealizować na jeden z poniższych sposobów:

Kod logiki transformacji w funkcji serving_fn definiuje interfejs obsługujący Twój SavedModel na potrzeby przewidywania online. Jeśli zaimplementujesz te same przekształcenia, które zostały użyte do przygotowania danych szkoleniowych w kodzie logiki transformacji funkcji serving_fn , zapewni to, że te same przekształcenia zostaną zastosowane do nowych punktów danych przewidywania podczas ich udostępniania.

Ponieważ jednak model TensorFlow przetwarza każdy punkt danych niezależnie lub w małej partii, nie można obliczyć agregacji ze wszystkich punktów danych. W rezultacie w modelu TensorFlow nie można zaimplementować transformacji pełnoprzepustowych.

Wyzwania związane z przetwarzaniem wstępnym

Poniżej przedstawiono główne wyzwania związane z wdrażaniem wstępnego przetwarzania danych:

  • Skok treningowo-służący . Skok trening-serw odnosi się do różnicy pomiędzy efektywnością (wydajnością przewidywaną) podczas treningu i podczas serwowania. To zniekształcenie może być spowodowane rozbieżnością między sposobem obsługi danych w potokach szkoleniowych i obsługujących. Na przykład, jeśli model jest szkolony na funkcji przekształconej logarytmicznie, ale podczas udostępniania jest prezentowany z surową funkcją, dane wyjściowe prognozy mogą nie być dokładne.

    Jeśli transformacje staną się częścią samego modelu, obsługa transformacji na poziomie instancji może być prosta, jak opisano wcześniej w opcji C: TensorFlow . W takim przypadku interfejs obsługujący model (funkcja serving_fn ) oczekuje surowych danych, podczas gdy model wewnętrznie przekształca te dane przed obliczeniem wyniku. Transformacje są takie same, jak te, które zastosowano w przypadku surowych punktów danych szkoleniowych i predykcyjnych.

  • Transformacje pełnoprzepustowe . W modelu TensorFlow nie można zaimplementować przekształceń pełnoprzepustowych, takich jak przekształcenia skalujące i normalizacyjne. W przypadku transformacji pełnoprzepustowych niektóre statystyki (na przykład wartości max i min w celu skalowania funkcji numerycznych) muszą zostać wcześniej obliczone na danych szkoleniowych, jak opisano w opcji B: Przepływ danych . Następnie wartości muszą być gdzieś zapisane, aby można je było wykorzystać podczas udostępniania modelu do przewidywania w celu przekształcenia nowych nieprzetworzonych punktów danych w postaci przekształceń na poziomie instancji, co pozwala uniknąć zniekształceń podczas szkolenia. Możesz użyć biblioteki TensorFlow Transform ( tf.Transform ), aby bezpośrednio osadzić statystyki w modelu TensorFlow. Podejście to wyjaśniono w dalszej części Jak działa tf.Transform .

  • Przygotowanie danych z góry w celu zwiększenia efektywności treningu . Implementowanie przekształceń na poziomie instancji w ramach modelu może obniżyć efektywność procesu uczenia. Ta degradacja występuje, ponieważ te same transformacje są wielokrotnie stosowane do tych samych danych szkoleniowych w każdej epoce. Wyobraź sobie, że masz surowe dane szkoleniowe zawierające 1000 funkcji i stosujesz kombinację transformacji na poziomie instancji, aby wygenerować 10 000 funkcji. Jeśli zaimplementujesz te transformacje jako część swojego modelu, a następnie przekażesz modelowi surowe dane szkoleniowe, te 10 000 operacji zostanie zastosowanych N razy w każdym wystąpieniu, gdzie N to liczba epok. Ponadto, jeśli używasz akceleratorów (GPU lub TPU), pozostają one bezczynne, podczas gdy procesor wykonuje te transformacje, co nie jest efektywnym wykorzystaniem kosztownych akceleratorów.

    W idealnym przypadku dane szkoleniowe są przekształcane przed szkoleniem przy użyciu techniki opisanej w opcji B: przepływ danych , gdzie 10 000 operacji transformacji jest stosowanych tylko raz w każdym wystąpieniu szkoleniowym. Przekształcone dane uczące są następnie prezentowane modelowi. Nie są stosowane żadne dalsze przekształcenia, a akceleratory są cały czas zajęte. Ponadto korzystanie z Dataflow ułatwia wstępne przetwarzanie dużych ilości danych na dużą skalę przy użyciu w pełni zarządzanej usługi.

    Przygotowanie danych treningowych z wyprzedzeniem może poprawić efektywność treningu. Jednak wdrożenie logiki transformacji poza modelem (podejścia opisane w Opcja A: BigQuery lub Opcja B: Przepływ danych ) nie rozwiązuje problemu odchylenia w obsłudze szkoleń. Jeśli nie przechowujesz zaprojektowanej funkcji w magazynie funkcji, która będzie używana zarówno do uczenia, jak i przewidywania, logika transformacji musi zostać gdzieś zaimplementowana, aby można ją było zastosować do nowych punktów danych przychodzących do przewidywania, ponieważ interfejs modelu oczekuje przekształconych danych. Biblioteka TensorFlow Transform ( tf.Transform ) może pomóc w rozwiązaniu tego problemu, jak opisano w poniższej sekcji.

Jak działa tf.Transform

Biblioteka tf.Transform jest przydatna w przypadku transformacji wymagających pełnego przejścia. Dane wyjściowe biblioteki tf.Transform są eksportowane jako wykres TensorFlow, który reprezentuje logikę transformacji na poziomie instancji oraz statystyki obliczone na podstawie transformacji pełnoprzepustowych, które mają być używane do uczenia i udostępniania. Używanie tego samego wykresu do treningu i serwowania może zapobiec zniekształceniom, ponieważ na obu etapach stosowane są te same przekształcenia. Ponadto bibliotekę tf.Transform można uruchomić na dużą skalę w potoku przetwarzania wsadowego w Dataflow, aby od razu przygotować dane szkoleniowe i poprawić efektywność szkolenia.

Poniższy diagram, rysunek 4, pokazuje, jak biblioteka tf.Transform wstępnie przetwarza i przekształca dane na potrzeby uczenia i przewidywania. Proces opisano w poniższych sekcjach.

Diagram przedstawiający przepływ od surowych danych przez tf.Transform do prognoz.
Rysunek 4. Zachowanie tf.Transform przy wstępnym przetwarzaniu i przekształcaniu danych.

Przekształcaj dane dotyczące szkoleń i ocen

Wstępnie przetwarzasz surowe dane szkoleniowe za pomocą transformacji zaimplementowanej w interfejsach API tf.Transform Apache Beam i uruchamiasz je na dużą skalę w Dataflow. Przetwarzanie wstępne przebiega w następujących fazach:

  • Faza analizy: Podczas fazy analizy wymagane statystyki (takie jak średnie, wariancje i kwantyle) dla transformacji stanowych są obliczane na danych szkoleniowych za pomocą operacji pełnego przejścia. W tej fazie powstaje zestaw artefaktów transformacji, w tym wykres transform_fn . Wykres transform_fn to wykres TensorFlow, który ma logikę transformacji jako operacje na poziomie instancji. Zawiera statystyki obliczone w fazie analizy w postaci stałych.
  • Faza transformacji: podczas fazy transformacji wykres transform_fn jest stosowany do surowych danych szkoleniowych, gdzie obliczone statystyki są wykorzystywane do przetwarzania rekordów danych (na przykład w celu skalowania kolumn liczbowych) w sposób na poziomie instancji.

Takie podejście dwufazowe rozwiązuje wyzwanie związane z przetwarzaniem wstępnym , jakim jest wykonywanie transformacji pełnoprzepustowych.

Gdy dane ewaluacyjne są wstępnie przetwarzane, stosowane są wyłącznie operacje na poziomie instancji, wykorzystując logikę z wykresu transform_fn i statystyki obliczone z fazy analizy w danych szkoleniowych. Innymi słowy, nie analizuje się danych ewaluacyjnych w sposób pełnoprzepustowy, aby obliczyć nowe statystyki, takie jak μ i σ, w celu normalizacji cech numerycznych w danych ewaluacyjnych. Zamiast tego używasz statystyk obliczonych na podstawie danych szkoleniowych, aby przekształcić dane oceny w sposób na poziomie instancji.

Przekształcone dane szkoleniowe i ewaluacyjne są przygotowywane na dużą skalę przy użyciu Dataflow, zanim zostaną użyte do uczenia modelu. Ten proces przygotowywania danych partii rozwiązuje wyzwanie wstępne, polegające na przygotowaniu danych z góry w celu poprawy wydajności treningu. Jak pokazano na rycinie 4, model wewnętrzny model oczekuje przekształconych funkcji.

Dołącz transformacje do modelu eksportowanego

Jak wspomniano, wykres transform_fn , który jest wytwarzany przez rurociąg tf.Transform jest przechowywany jako eksportowany wykres tensorflow. Wyeksportowany wykres składa się z logiki transformacji jako operacji na poziomie instancji, a wszystkie statystyki obliczone w transformacjach pełnego pasa jako stałe wykresu. Gdy wyszkolony model jest eksportowany do obsługi, wykres transform_fn jest przymocowany do SavedModel w ramach funkcji serving_fn .

Podczas gdy obsługuje model prognozowania, interfejs obsługujący model oczekuje punktów danych w formacie RAW (to znaczy przed jakąkolwiek transformacją). Jednak model wewnętrzny model oczekuje danych w formacie transformowanym.

Wykres transform_fn , który jest obecnie częścią modelu, stosuje całą logikę wstępnego przetwarzania w przychodzącym punkcie danych. Wykorzystuje przechowywane stałe (takie jak μ i σ do normalizacji cech numerycznych) w operacji na poziomie instancji podczas prognozowania. Dlatego wykres transform_fn przekształca surowy punkt danych w format transformowany. Przekształcony format jest oczekiwany przez model wewnętrzny model w celu uzyskania prognoz, jak pokazano na rycinie 4.

Mechanizm ten rozwiązuje wyzwanie wstępnego przetwarzania pochylania szkolnictwa, ponieważ ta sama logika (implementacja), która jest wykorzystywana do przekształcenia danych dotyczących szkolenia i oceny, jest stosowane do przekształcenia nowych punktów danych podczas serwowania prognozowania.

Podsumowanie opcji wstępnego przetwarzania

Poniższa tabela podsumowuje opcje wstępnego przetwarzania danych, które omówiono ten dokument. W tabeli „nie dotyczy” oznacza „nie dotyczy”.

Opcja wstępnego przetwarzania danych Poziom instancji
(Transformacje bez statystyki)

Pełny przebieg podczas szkolenia i poziomu instancji podczas serwowania (transformacje stanowe)

Agregacje w czasie rzeczywistym (okno) podczas szkolenia i obsługi (transformacje przesyłania strumieniowego)

BigQuery (SQL)

Punktacja partii: OK - Ta sama implementacja transformacji jest stosowana na danych podczas szkolenia i punktacji partii.

Prognozowanie online: Nie jest zalecane -możesz przetwarzać dane szkolenia, ale powoduje to, że w skewce prowadzenia szkoleń przetwarzasz dane za pomocą różnych narzędzi.

Punktacja partii: nie jest zalecana .

Prognozowanie online: nie zalecane .

Chociaż możesz korzystać z statystyk obliczonych za pomocą transformacji partii/online na poziomie BigQuery, nie jest to łatwe, ponieważ musisz zachować sklep z statystykami, który ma być wypełniony podczas szkolenia i używać podczas prognozowania.

Punktacja partii: Nie dotyczy- takie jak te są obliczane na podstawie wydarzeń w czasie rzeczywistym.

Prognozowanie online: Nie jest zalecane -możesz przetwarzać dane szkolenia, ale powoduje to, że w skewce prowadzenia szkoleń przetwarzasz dane za pomocą różnych narzędzi.

Data Flow (Apache Beam)

Punktacja partii: OK - Ta sama implementacja transformacji jest stosowana na danych podczas szkolenia i punktacji partii.

Prognozowanie online: OK - Jeśli dane w serwowaniu pochodzą z pubu/substancji substancji do zużycia przez przepływ danych. W przeciwnym razie skutkuje skośnięciem do prowadzenia treningów.

Punktacja partii: nie jest zalecana .

Prognozy online: nie zalecane .

Chociaż możesz korzystać z statystyk obliczonych za pomocą przepływu danych na przykład transformacji partii/online na poziomie, nie jest to łatwe, ponieważ musisz utrzymać sklep statystyk, który ma być wypełniony podczas szkolenia i używać podczas prognozowania.

Punktacja partii: Nie dotyczy- takie jak te są obliczane na podstawie wydarzeń w czasie rzeczywistym.

Prognozy online: OK - Ta sama transformacja wiązki Apache jest stosowana na danych podczas szkolenia (partia) i obsługi (strumień).

Data Flow (Apache Beam + TFT)

Punktacja partii: OK - Ta sama implementacja transformacji jest stosowana do danych podczas szkolenia i punktacji partii.

Prognozowanie online: Zalecane -unikając szkolenia w zakresie wykrzyku i przygotowuje dane szkoleniowe z góry.

Punktacja partii: Zalecane .

Prognozowanie online: Zalecane .

Oba zastosowania są zalecane, ponieważ logika transformacji i obliczone statystyki podczas szkolenia są przechowywane jako wykres tensorflow, który jest dołączony do eksportowanego modelu do obsługi.

Punktacja partii: Nie dotyczy- takie jak te są obliczane na podstawie wydarzeń w czasie rzeczywistym.

Prognozy online: OK - Ta sama transformacja wiązki Apache jest stosowana na danych podczas szkolenia (partia) i obsługi (strumień).

Tensorflow *
( input_fn & serving_fn )

Punktacja partii: nie jest zalecana .

Prognozowanie online: nie zalecane .

W przypadku wydajności treningu w obu przypadkach lepiej jest przygotować dane szkoleniowe z góry.

Punktacja partii: Nie jest to możliwe .

Prognozy online: niemożliwe .

Punktacja partii: Nie dotyczy- takie jak te są obliczane na podstawie wydarzeń w czasie rzeczywistym.

Prognozy online: niemożliwe .

* W przypadku TensorFlow transformacje takie jak skrzyżowanie, osadzanie i jedno gorące kodowanie powinny być wykonywane deklaratywnie jako kolumny feature_columns .

Co dalej

,

Ten dokument jest pierwszym z dwuczęściowej serii, która bada temat inżynierii danych i inżynierii funkcji do uczenia maszynowego (ML), ze szczególnym uwzględnieniem nadzorowanych zadań uczenia się. Ta pierwsza część omawia najlepsze praktyki dotyczące wstępnego przetwarzania danych w rurociągu ML w Google Cloud. Dokument koncentruje się na użyciu TensorFlow i biblioteki TensorFlow Transform ( tf.Transform ) w celu przygotowania danych, szkolenia modelu i obsługi modelu do prognozowania. Ten dokument podkreśla wyzwania związane z przetwarzaniem danych dla ML oraz opisuje opcje i scenariusze skutecznego wykonywania transformacji danych w Google Cloud.

Ten dokument zakłada, że ​​znasz BigQuery , Data Flow , Vertex AI i API Keras Tensorflow.

Drugi dokument, przetwarzanie danych dla ML z Google Cloud , zawiera samouczek krok po kroku, jak wdrożyć rurociąg tf.Transform .

Wstęp

ML pomaga automatycznie znaleźć złożone i potencjalnie przydatne wzorce w danych. Wzorce te są skondensowane w modelu ML, który można następnie wykorzystać w nowych punktach danych - proces zwany prognozami lub wykonywaniem wnioskowania .

Budowanie modelu ML jest procesem wieloetapowym. Każdy krok przedstawia własne wyzwania techniczne i koncepcyjne. Ta dwuczęściowa seria koncentruje się na nadzorowanych zadaniach uczenia się i procesie wybierania, przekształcania i rozszerzaniu danych źródłowych w celu stworzenia potężnych sygnałów predykcyjnych do zmiennej docelowej. Operacje te łączą wiedzę domenową z technikami nauki danych. Operacje są esencją inżynierii funkcji .

Rozmiar zestawów danych treningowych dla rzeczywistych modeli ML może być łatwo równy lub większy niż jeden terabajt (TB). Dlatego potrzebujesz na dużą skalę ramy przetwarzania danych, aby wydajnie i rozpowszechniać te zestawy danych. Kiedy używasz modelu ML do przewidywania, musisz zastosować te same transformacje, które użyłeś do danych szkoleniowych w nowych punktach danych. Stosując te same transformacje, prezentujesz zestaw danych na żywo w modelu ML sposób, w jaki model oczekuje.

Dokument ten omawia te wyzwania dla różnych poziomów szczegółowości operacji inżynierii cech: agregacji na poziomie instancji, pełnego i przerywania czasu. Ten dokument opisuje również opcje i scenariusze do wykonywania transformacji danych dla ML w Google Cloud.

Dokument ten zawiera również przegląd TensorFlow Transform ( tf.Transform ), biblioteki dla TensorFlow, która pozwala zdefiniować zarówno transformację danych na poziomie instancji, jak i pełnoprzepustowe za pośrednictwem rurociągów wstępnych danych. Rurociągi te są wykonywane za pomocą wiązki Apache i tworzą artefakty, które pozwalają zastosować te same transformacje podczas prognozowania, jak w przypadku obsługi modelu.

Dane wstępne dla ML

W tej sekcji przedstawiono operacje wstępne do przetwarzania danych i etapy gotowości danych. Omawia także rodzaje operacji wstępnych i ich szczegółowości.

Inżynieria danych w porównaniu do inżynierii cech

Wstępne przetwarzanie danych dla ML obejmuje zarówno inżynierię danych, jak i inżynierię cech. Inżynieria danych to proces przekształcania surowych danych na przygotowane dane . Inżynieria funkcji następnie dostosowuje przygotowane dane, aby utworzyć funkcje oczekiwane przez model ML. Niniejsze Warunki mają następujące znaczenie:

Surowe dane (lub po prostu dane )
Dane w formie źródłowej, bez wcześniejszych przygotowań do ML. W tym kontekście dane mogą znajdować się w formie surowej (w jeziorze danych) lub w formie transformowanej (w hurtowni danych). Przekształcone dane w hurtowni danych mogły zostać przekonwertowane z oryginalnej surowej formy, które mają być wykorzystane do analizy. Jednak w tym kontekście surowe dane oznaczają, że dane nie zostały przygotowane specjalnie dla twojego zadania ML. Dane są również uważane za surowe dane, jeśli są wysyłane z systemów strumieniowych, które ostatecznie wywołują modele ML do prognoz.
Przygotowane dane
Zestaw danych w formularzu gotowy do zadania ML: Źródła danych zostały przeanalizowane, połączone i umieszczone w formie tabelarycznej. Przygotowane dane są agregowane i podsumowane do prawej szczegółowości - na przykład każdy wiersz w zestawie danych reprezentuje unikalnego klienta, a każda kolumna reprezentuje informacje podsumowujące dla klienta, takie jak całkowita wydana w ciągu ostatnich sześciu tygodni. W przygotowanej tabeli danych usunięto nieistotne kolumny, a nieprawidłowe zapisy zostały przefiltrowane. W przypadku nadzorowanych zadań edukacyjnych cecha docelowa jest obecna.
Funkcje zaprojektowane
Zestaw danych z dostrojonymi funkcjami, które są oczekiwane przez model-to znaczy funkcje tworzone przez wykonanie niektórych operacji specyficznych dla ML w kolumnach w przygotowanym zestawie danych i tworzenie nowych funkcji modelu podczas szkolenia i prognozy, jak opisano później w operacjach wstępnego przetwarzania . Przykłady tych operacji obejmują skalowanie kolumn numerycznych do wartości od 0 do 1, wartości przycinania i jednej kodowania kodowania .

Poniższy schemat, ryc. 1, pokazuje kroki zaangażowane w przygotowanie wstępnie przetworzonych danych:

Schemat przepływu pokazujący surowe dane przenoszące się do przygotowanych danych przenoszących się do funkcji zaprojektowanych.
Rysunek 1. Przepływ danych z surowych danych do przygotowanych danych do zaprojektowanych funkcji do uczenia maszynowego.

W praktyce dane z tego samego źródła są często na różnych etapach gotowości. Na przykład pole z tabeli w hurtowni danych może być używane bezpośrednio jako funkcja zaprojektowana. Jednocześnie kolejne pole w tej samej tabeli może wymagać przejścia przez transformacje, zanim stanie się funkcją zaprojektowaną. Podobnie operacje inżynierii danych i inżynierii cech mogą być łączone na tym samym etapie wstępnego przetwarzania danych.

Operacje wstępne

Przedstawienie danych obejmuje kilka operacji. Każda operacja została zaprojektowana, aby pomóc ML w tworzeniu lepszych modeli predykcyjnych. Szczegóły tych operacji wstępnych przetwarzania są poza zakresem tego dokumentu, ale niektóre operacje są krótko opisane w tej sekcji.

W przypadku danych ustrukturyzowanych operacje wstępne danych obejmują następujące:

  • Oczyszczanie danych: usuwanie lub korygowanie rekordów, które mają uszkodzone lub nieprawidłowe wartości z surowych danych, oraz usuwanie rekordów, w których brakuje dużej liczby kolumn.
  • Wybór i partycjonowanie instancji: Wybór punktów danych z danych wejściowych w celu utworzenia szkolenia, oceny (sprawdzania poprawności) i zestawów testowych . Proces ten obejmuje techniki powtarzalnego losowego próbkowania, klas mniejszościowych nadpróbkowania i partycjonowania stratyfikowanego.
  • Strojenie funkcji: poprawa jakości funkcji dla ML, która obejmuje skalowanie i normalizację wartości liczbowych, przypisanie brakujących wartości, odstraszacze do przycinania i dostosowywanie wartości, które mają wypaczone rozkłady.
  • Transformacja cech: Przekształcenie funkcji liczbowej w cechę kategoryczną (poprzez wicketizacja ) i przekształcenie cech kategorycznych w reprezentację numeryczną (poprzez jeden upały kodowanie, uczenie się z liczbą , rzadkie osadzanie funkcji itp.). Niektóre modele działają tylko z funkcjami liczbowymi lub kategorycznymi, podczas gdy inne mogą obsługiwać funkcje typu mieszanego. Nawet gdy modele obsługują oba typy, mogą skorzystać z różnych reprezentacji (liczbowych i kategorycznych) tej samej funkcji.
  • Ekstrakcja cech: Zmniejszenie liczby funkcji poprzez tworzenie niższych wymiarów, mocniejsze reprezentacje danych przy użyciu technik takich jak PCA , ekstrakcja osadzania i mieszanie .
  • Wybór funkcji: Wybór podzbioru funkcji wejściowych do szkolenia modelu i ignorowanie nieistotnych lub zbędnych, za pomocą metod filtra lub opakowania . Wybór funkcji może również obejmować po prostu zrzucanie funkcji, jeśli funkcje brakuje dużej liczby wartości.
  • Konstrukcja funkcji: Tworzenie nowych funkcji za pomocą typowych technik, takich jak rozszerzenie wielomianowe (przy użyciu jednoczynnikowych funkcji matematycznych) lub skrzyżowanie funkcji (w celu przechwytywania interakcji cech). Funkcje można również zbudować za pomocą logiki biznesowej z domeny przypadków użycia ML.

Podczas pracy z nieustrukturyzowanymi danymi (na przykład obrazami, dokumentami audio lub tekstowymi) głębokie uczenie się zastępuje inżynierię funkcji opartą na wiedzy domeny, składając ją do architektury modelu. Warstwa splotowa jest automatycznym preprocesorem funkcji. Konstruowanie właściwej architektury modelu wymaga pewnej wiedzy empirycznej na temat danych. Ponadto potrzebna jest pewna ilość wstępnego przetwarzania, na przykład:

  • W przypadku dokumentów tekstowych: łodyga i lemmatyzacja , obliczenia TF-IDF i ekstrakcja N-gram , osadzanie wyszukiwania.
  • W przypadku obrazów: przycinanie, rozmiar, przycinanie, rozmycie Gaussa i filtry kanaryjskie.
  • W przypadku wszystkich rodzajów danych (w tym tekstu i obrazów): uczenie się transferu , które traktuje wszystkie, ale Last warstwy w pełni wyszkolonego modelu jako etap inżynierii funkcji.

Granatowość wstępna

W tej sekcji omówiono szczegółowość rodzajów transformacji danych. Pokazuje, dlaczego ta perspektywa ma kluczowe znaczenie przy przygotowaniu nowych punktów danych do prognoz przy użyciu transformacji stosowanych na danych szkoleniowych.

Operacje wstępne i transformacyjne można podzielić na następujący sposób, w oparciu o szczegółowość operacji:

  • Transformacje na poziomie instancji podczas szkolenia i prognozy . Są to proste transformacje, w których do transformacji potrzebne są tylko wartości z tego samego instancji. Na przykład transformacje na poziomie instancji mogą obejmować przycinanie wartości funkcji do pewnego progu, wielomiastego rozszerzania innej funkcji, pomnożenia dwóch funkcji lub porównania dwóch funkcji w celu utworzenia flagi booletowej.

    Transformacje te muszą być stosowane identycznie podczas szkolenia i prognozy, ponieważ model zostanie przeszkolony w zakresie przekształconych cech, a nie na surowe wartości wejściowe. Jeśli dane nie są identycznie przekształcone, modelu zachowuje się słabo, ponieważ przedstawiono je z danymi, które mają rozkład wartości, z którymi nie były przeszkolone. Aby uzyskać więcej informacji, zobacz dyskusję na temat skośnego skośnego w sekcji Wyzwania związane z przetwarzaniem .

  • Transformacje pełnego pasa podczas szkolenia, ale transformacje na poziomie instancji podczas prognozowania . W tym scenariuszu transformacje są stanowe, ponieważ wykorzystują pewne wstępnie obliczone statystyki do przeprowadzenia transformacji. Podczas szkolenia analizujesz całą masę danych treningowych w celu obliczenia ilości, takich jak minimum, maksimum, średnia i wariancja w celu transformacji danych szkoleniowych, danych oceny i nowych danych w czasie prognozowania.

    Na przykład, aby znormalizować liczbową funkcję szkolenia, obliczasz jej średnią (μ) i odchylenie standardowe (σ) w całym danych treningowych. Obliczenia to nazywa się operacją pełnoprzepustową (lub analizowaną ). Kiedy obsługujesz model prognozowania, wartość nowego punktu danych jest znormalizowana, aby uniknąć skośnego skośnego. Dlatego wartości μ i σ, które są obliczane podczas szkolenia, służą do dostosowania wartości funkcji, co jest następującą prostą operacją na poziomie instancji :

    $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

    Transformacje pełnego pasa obejmują następujące:

    • Minmax Scaling Numerical Funkcje przy użyciu MIN i MAX obliczone z zestawu danych szkoleniowych.
    • Standardowe skalowanie (normalizacja Z-Score) Cechy numeryczne przy użyciu μ i σ obliczonych na zestawie danych szkoleniowych.
    • Kręgne funkcje numeryczne za pomocą kwantyli.
    • Przypisanie brakujących wartości przy użyciu mediany (funkcje numeryczne) lub trybu (cechy kategoryczne).
    • Przekształcanie ciągów (wartości nominalne) na liczby całkowite (indeksy) poprzez wyodrębnienie wszystkich odrębnych wartości (słownictwa) funkcji kategorii wejściowej.
    • Zliczanie występowania terminu (wartość cechy) we wszystkich dokumentach (instancjach) w celu obliczenia dla TF-IDF.
    • Obliczanie PCA funkcji wejściowych w celu wyświetlania danych w przestrzeni dolnej wymiarowej (z funkcjami zależnymi od liniu).

    Należy użyć tylko danych treningowych do obliczenia statystyk, takich jak μ, σ, min i maks . Jeśli dodasz dane testowe i oceny dla tych operacji, wyciekasz informacje z oceny i danych testowych, aby wyszkolić model. To wpływa na wiarygodność wyników testu i oceny. Aby upewnić się, że stosujesz spójną transformację do wszystkich zestawów danych, używasz tych samych statystyk obliczonych na podstawie danych szkoleniowych, aby przekształcić dane testowe i oceny.

  • Historyczne agregacje podczas szkolenia i prognozy . Obejmuje to tworzenie agregacji biznesowych, pochodnych i flag jako sygnałów wejściowych do zadania prognozowania - na przykład tworzenie wskaźników powolnych, częstotliwości i pieniężnych (RFM) dla klientów do budowania modeli skłonności. Tego rodzaju funkcje mogą być wstępnie obliczone i przechowywane w sklepie z funkcjami, które mają być używane podczas treningu modelu, oceny wsadowej i serwowania przewidywania online. Możesz także wykonać dodatkową inżynierię funkcji (na przykład transformacja i strojenie) do tych agregacji przed szkoleniem i przewidywaniem.

  • Historyczne agregacje podczas szkolenia, ale agregacje w czasie rzeczywistym podczas prognozowania . Takie podejście polega na tworzeniu funkcji poprzez podsumowanie wartości w czasie rzeczywistym w czasie. W tym podejściu przypadki, które mają być agregowane, są zdefiniowane przez czasowe klauzule okien. Na przykład możesz zastosować to podejście, jeśli chcesz wyszkolić model, który szacuje czas podróży taksówek na podstawie wskaźników ruchu na trasie w ciągu ostatnich 5 minut, w ciągu ostatnich 10 minut, w ciągu ostatnich 30 minut, a na drugim odstępy. Możesz również zastosować to podejście do przewidywania awarii części silnika w oparciu o średnią ruchomą temperatury i wartości wibracji obliczonych w ciągu ostatnich 3 minut. Chociaż agregacje te można przygotować offline do szkolenia, są one obliczane w czasie rzeczywistym ze strumienia danych podczas serwowania.

    Mówiąc dokładniej, przygotowując dane szkoleniowe, jeśli agregowana wartość nie jest w danych surowych, wartość jest tworzona podczas fazy inżynierii danych. Surowe dane są zwykle przechowywane w bazie danych z formatem (entity, timestamp, value) . W poprzednich przykładach entity jest identyfikatorem segmentu trasy dla tras taksówek i identyfikatorem części silnika dla awarii silnika. Możesz użyć operacji okienkowania do obliczenia (entity, time_index, aggregated_value_over_time_window) i użyć funkcji agregacji jako wejścia do szkolenia modelu.

    Gdy serwowany jest model prognozy w czasie rzeczywistym (online), model oczekuje funkcji uzyskanych od wartości zagregowanych jako danych wejściowych. Dlatego możesz użyć technologii przetwarzania strumienia, takiej jak Apache Beam do obliczenia agregacji z punktów danych w czasie rzeczywistym przesyłanym do systemu. Technologia przetwarzania strumienia agreguje dane w czasie rzeczywistym w oparciu o okna czasowe w miarę nadchodzenia nowych punktów danych. Możesz także wykonać dodatkową inżynierię funkcji (na przykład transformacja i strojenie) do tych agregacji przed szkoleniem i przewidywaniem.

ML Pipeline w Google Cloud

W tej sekcji omówiono podstawowe elementy typowego potoku z kompleksowego do końca szkolenia i obsługi modeli ML TensorFlow w Google Cloud za pomocą usług zarządzanych. Omawia także, gdzie możesz wdrożyć różne kategorie operacji wstępnego przetwarzania danych, oraz wspólne wyzwania, z którymi możesz się stawić czoła podczas wdrażania takich transformacji. Sekcja Works TF.Transform pokazuje, w jaki sposób biblioteka transformacji tensorflow pomaga zająć się tymi wyzwaniami.

Architektura wysokiego poziomu

Poniższy schemat, ryc. 2, pokazuje architekturę wysokiego poziomu typowego rurociągu ML do treningu i obsługi modeli tensorflow. Etykiety A, B i C na schemacie odnoszą się do różnych miejsc w rurociągu, w których może mieć miejsce wstępne przetwarzanie danych. Szczegóły dotyczące tych kroków podano w następnej sekcji.

Schemat architektury pokazujący etapy przetwarzania danych.
Rysunek 2. Architektura wysokiego poziomu do szkolenia i obsługi ML w Google Cloud.

Rurociąg składa się z następujących kroków:

  1. Po zaimportowaniu surowych danych dane tabelaryczne są przechowywane w BigQuery, a inne dane, takie jak obrazy, audio i wideo, są przechowywane w przechowywaniu w chmurze. Druga część tej serii wykorzystuje jako przykład dane tabelaryczne przechowywane w BigQuery.
  2. Inżynieria danych (przygotowanie) i inżynieria funkcji są wykonywane na skalę za pomocą DataFlow. To wykonanie tworzy zestawy szkoleń, oceny i testów gotowych do ML, które są przechowywane w chmurze. Idealnie, te zestawy danych są przechowywane jako pliki TFRecord , które są zoptymalizowanym formatem dla obliczeń tensorflow.
  3. Pakiet trenera modelu TensorFlow jest przesyłany do szkolenia Vertex AI, który wykorzystuje wstępnie przetworzone dane z poprzednich kroków w celu szkolenia modelu. Wyjście tego kroku to wyszkolony tensorflow SavedModel , który jest eksportowany do przechowywania w chmurze.
  4. Wyszkolony model tensorflow jest wdrażany w prognozie Vertex AI jako usługa, która ma interfejs API REST, aby można go było używać do prognoz online. Ten sam model można również wykorzystać do zadań prognozowania partii.
  5. Po wdrożeniu modelu jako interfejs API REST, aplikacje klienckie i systemy wewnętrzne mogą wywołać interfejs API, wysyłając żądania z niektórymi punktami danych i otrzymując odpowiedzi z modelu z prognozami.
  6. W celu zorganizowania i automatyzacji tego rurociągu możesz użyć rurociągów Vertex AI jako harmonogramu, aby wywołać przygotowanie danych, szkolenie modelu i etapy wdrażania modelu.

Możesz także użyć sklepu z funkcjami Vertex AI do przechowywania funkcji wejściowych, aby dokonać prognoz. Na przykład możesz okresowo tworzyć funkcje zaprojektowane z najnowszych surowych danych i przechowywać je w sklepie funkcji Vertex AI. Aplikacje klientów pobierają wymagane funkcje wejściowe ze sklepu funkcji Vertex AI i wyślij je do modelu, aby otrzymać prognozy.

Gdzie zrobić wstępne przetwarzanie

Na ryc. 2 etykiety A, B i C pokazują, że operacje wstępne danych mogą odbywać się w BigQuery, Data Flow lub TensorFlow. Poniższe sekcje opisują, jak działa każda z tych opcji.

Opcja A: BigQuery

Zazwyczaj logika jest zaimplementowana w BigQuery dla następujących operacji:

  • Próbowanie: losowe wybór podzbioru z danych.
  • Filtrowanie: usuwanie nieistotnych lub nieprawidłowych instancji.
  • Podział: podział danych w celu tworzenia zestawów szkoleniowych, oceny i testów.

Skrypty SQL BigQuery mogą być używane jako zapytanie źródłowe dla rurociągu wstępnego przetwarzania przepływu danych, który jest etapem przetwarzania danych na rysunku 2. Na przykład, jeśli system jest używany w Kanadzie, a hurtownia danych ma transakcje z całego świata, filtrując do filtrowania do Pobierz dane szkoleniowe wyłącznie w Kanadzie najlepiej wykonać w BigQuery. Inżynieria funkcji w BigQuery jest prosta i skalowalna oraz obsługuje wdrażanie agregacji na poziomie instancji i historyczne transformacje.

Zalecamy jednak korzystanie z BigQuery do inżynierii funkcji tylko wtedy, gdy używasz swojego modelu do prognozowania partii (punktacji) lub jeśli funkcje są wstępnie obliczone w BigQuery, ale przechowywane w sklepie funkcji Vertex AI, które będą używane podczas prognoz online. Jeśli planujesz wdrożyć model prognoz online, a jeśli nie masz funkcji zaprojektowanej w internetowym sklepie z funkcjami, musisz powtórzyć operacje wstępne SQL, aby przekształcić surowe punkty danych, które generują inne systemy. Innymi słowy, musisz dwukrotnie zaimplementować logikę: jeden raz w SQL, aby przedstawić dane dotyczące szkolenia w BigQuery, a drugi raz w logice aplikacji, która zużywa model do wstępnego przetwarzania punktów danych do przewidywania.

Na przykład, jeśli aplikacja kliencka jest zapisana w Javie, musisz ponownie zaimplementować logikę w Javie. Może to wprowadzić błędy spowodowane rozbieżnościami wdrożeniowymi, jak opisano w sekcji szkieletowej szkolenia wyzwań wstępnych w dalszej części tego dokumentu. Utrzymanie dwóch różnych implementacji jest również dodatkowe koszty ogólne. Za każdym razem, gdy zmienisz logikę w SQL, aby wstępnie przetwarzać dane szkoleniowe, musisz odpowiednio zmienić implementację Java, aby przedstawić dane dotyczące przetwarzania w czasie.

Jeśli używasz swojego modelu tylko do przewidywania partii (na przykład przy użyciu prognozy partii Vertex AI) i jeśli dane dotyczące punktacji pochodzą z BigQuery, możesz zaimplementować te operacje wstępne w ramach skryptu SQL BigQuery. W takim przypadku możesz użyć tego samego wstępnego przetwarzania skryptu SQL, aby przygotować zarówno dane treningowe, jak i punktacyjne.

Państwowe transformacje stanowe nie są odpowiednie do wdrożenia w BigQuery. Jeśli używasz BigQuery do transformacji pełnoprzepustowych, potrzebujesz tabel pomocniczych do przechowywania ilości potrzebnych przez transformacje stanowe, takie jak środki i wariancje do skalowania funkcji numerycznych. Ponadto wdrożenie transformacji pełnego pasa przy użyciu SQL w BigQuery stwarza zwiększoną złożoność w skryptach SQL i stwarza skomplikowaną zależność między treningiem a skryptami SQL punktacji.

Opcja B: przepływ danych

Jak pokazano na rysunku 2, możesz zaimplementować drogie obliczeniowo operacje wstępne w ramach Beam APACHE i uruchomić je na skalę za pomocą Data Flow. Data Flow to w pełni zarządzana usługa autoscalingu do przetwarzania danych partii i strumienia. Podczas korzystania z DataFlow możesz również używać zewnętrznych specjalistycznych bibliotek do przetwarzania danych, w przeciwieństwie do BigQuery.

Data Flow może wykonywać transformacje na poziomie instancji oraz transformacje funkcji agregacji historycznej i agregacji w czasie rzeczywistym. W szczególności, jeśli twoje modele ML oczekują funkcji wejściowej, takiej jak total_number_of_clicks_last_90sec , funkcje okiennego wiązki Apache mogą obliczyć te funkcje w oparciu o agregowanie danych dotyczących danych zdarzeń w czasie rzeczywistym (na przykład kliknij zdarzenia). We wcześniejszej dyskusji na temat szczegółowości transformacji nazywano to „agregacjami historycznymi podczas szkolenia, ale agregacji w czasie rzeczywistym podczas prognozowania”.

Poniższy schemat, ryc. 3, pokazuje rolę przepływu danych w przetwarzaniu danych strumienia dla prognoz w czasie rzeczywistym.

Architektura do używania danych strumieniowych do przewidywania.
Rysunek 3. Architektura wysokiego poziomu z wykorzystaniem danych strumienia do przewidywania w przepływie danych.

Jak pokazano na rycinie 3, podczas przetwarzania zdarzenia zwane punktami danych są spożywane do pub/sub . Data Flow zużywa te punkty danych, oblicza funkcje oparte na agregatach w czasie, a następnie wywołuje wdrożony interfejs API modelu ML do prognoz. Prognozy są następnie wysyłane do wychodzącego pubu/substancji podrzędnej. Z PUB/SUB prognozy mogą być zużywane przez systemy niższe, takie jak monitorowanie lub kontrola, lub można je odepchnąć (na przykład, jako powiadomienia) do pierwotnego żądającego klienta. Prognozy można również przechowywać w magazynie danych o niskiej opóźnieniu, takim jak Cloud BigTable do pobierania w czasie rzeczywistym. Cloud BigTable można również wykorzystać do gromadzenia się i przechowywania tych agregacji w czasie rzeczywistym, aby można je było sprawdzić w razie potrzeby do przewidywania.

Tę samą implementację wiązki Apache można użyć do danych szkoleniowych procesów, które pochodzą z danych z danych offline, takich jak BigQuery i Stream Process Dane w czasie rzeczywistym do serwowania prognoz online.

W innych typowych architekturach, takich jak architektura pokazana na rysunku 2, aplikacja kliencka bezpośrednio wywołuje wdrożony interfejs API modelu do prognoz online. W takim przypadku, jeśli operacje wstępne zostaną wdrożone w przepływie danych w celu przygotowania danych szkoleniowych, operacje nie są stosowane do danych prognozujących bezpośrednio do modelu. Dlatego takie transformacje powinny być zintegrowane z modelem podczas serwowania prognoz online.

Data Flow może być używany do przeprowadzenia transformacji pełnoprzepustowej poprzez obliczenie wymaganych statystyk na dużą skalę. Jednak statystyki te muszą być przechowywane gdzieś podczas prognozowania w celu przekształcenia punktów danych prognozowania. Korzystając z biblioteki TensorFlow Transform ( tf.Transform ), możesz bezpośrednio osadzić te statystyki w modelu zamiast przechowywać je gdzie indziej. Takie podejście zostało wyjaśnione w dalszej części , jak działa TF.Transform .

Opcja C: Tensorflow

Jak pokazano na rysunku 2, możesz wdrożyć operacje wstępne i transformacyjne dane w samym modelu TensorFlow. Jak pokazano na rysunku, wstępne przetwarzanie, które wdrażasz do szkolenia modelu tensorflow, staje się integralną częścią modelu, gdy model jest eksportowany i wdrażany do prognoz. Przekształcenia w modelu Tensorflow można wykonać na jeden z następujących sposobów:

Kod logiki transformacji w funkcji serving_fn określa interfejs obsługi SavedModel do prognozy online. Jeśli zaimplementujesz te same transformacje, które zostały wykorzystane do przygotowywania danych szkoleniowych w kodeksu logiki transformacji funkcji serving_fn , zapewnia, że ​​te same transformacje są stosowane do nowych punktów danych prognozowania po ich obsłudze.

Ponieważ jednak model tensorflow przetwarza każdy punkt danych niezależnie lub w małej partii, nie można obliczyć agregacji ze wszystkich punktów danych. W rezultacie w modelu TensorFlow nie można zaimplementować transformacji pełnego pasa.

Wyzwania związane z przetwarzaniem

Poniżej przedstawiono główne wyzwania związane z wdrożeniem przetwarzania danych:

  • Skewki do serwisu . Skewki z zakresu szkolenia odnosi się do różnicy między skutecznością (wydajność predykcyjna) podczas szkolenia i podczas służby. Ten skoś może być spowodowany rozbieżnością między tym, jak obsługujesz dane w szkoleniach a rurociągami. Na przykład, jeśli twój model jest przeszkolony w zakresie przekształconej logarytmicznie, ale jest on przedstawiony z funkcją surowej podczas serwowania, wyjście prognoz mogą nie być dokładne.

    Jeśli transformacje stają się częścią samego modelu, może być proste, aby obsłużyć transformacje na poziomie instancji, jak opisano wcześniej w opcji C: TensorFlow . W takim przypadku interfejs obsługi modelu (funkcja serving_fn ) oczekuje surowych danych, podczas gdy model wewnętrznie przekształca te dane przed obliczeniem wyjścia. Transformacje są takie same jak te, które zostały zastosowane w punktach danych szkoleniowych i prognozowania RAW.

  • Przekształcenia pełnego pasa . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

  • Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

    Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

    Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Diagram showing flow from raw data through tf.Transform to predictions.
Figure 4. Behavior of tf.Transform for preprocessing and transforming data.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

  • Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
  • Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option Instance-level
(stateless transformations)

Full-pass during training and instance-level during serving (stateful transformations)

Real-time (window) aggregations during training and serving (streaming transformations)

BigQuery (SQL)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Batch scoring: Not recommended .

Online prediction: Not recommended .

Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Dataflow (Apache Beam)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.

Batch scoring: Not recommended .

Online predictions: Not recommended .

Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

Dataflow (Apache Beam + TFT)

Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring.

Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.

Batch scoring: Recommended .

Online prediction: Recommended .

Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

TensorFlow *
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

For training efficiency in both cases, it's better to prepare the training data up front.

Batch scoring: Not Possible .

Online prediction: Not Possible .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not Possible .

* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Co dalej

,

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Wstęp

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )
The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
Prepared data
The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
Engineered features
The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

Flow diagram showing raw data moving to prepared data moving to engineered features.
Figure 1. The flow of data from raw data to prepared data to engineered features to machine learning.

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

  • Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
  • Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
  • Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
  • Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
  • Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
  • Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
  • Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

  • For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
  • For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
  • For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

  • Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

    These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

  • Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

    For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

    $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

    Full-pass transformations include the following:

    • MinMax scaling numerical features using min and max computed from the training dataset.
    • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
    • Bucketizing numerical features using quantiles.
    • Imputing missing values using the median (numerical features) or the mode (categorical features).
    • Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
    • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
    • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

    You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

  • Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

  • Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

    More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

    When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

Architecture diagram showing stages for processing data.
Figure 2. High-level architecture for ML training and serving on Google Cloud.

The pipeline consists of the following steps:

  1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
  2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
  3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
  4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
  5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
  6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

  • Sampling: randomly selecting a subset from the data.
  • Filtering: removing irrelevant or invalid instances.
  • Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

Architecture for using stream data for prediction.
Figure 3. High-level architecture using stream data for prediction in Dataflow.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

  • Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
  • Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

  • Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

    If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

  • Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

  • Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

    Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

    Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Diagram showing flow from raw data through tf.Transform to predictions.
Figure 4. Behavior of tf.Transform for preprocessing and transforming data.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

  • Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
  • Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option Instance-level
(stateless transformations)

Full-pass during training and instance-level during serving (stateful transformations)

Real-time (window) aggregations during training and serving (streaming transformations)

BigQuery (SQL)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Batch scoring: Not recommended .

Online prediction: Not recommended .

Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Dataflow (Apache Beam)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.

Batch scoring: Not recommended .

Online predictions: Not recommended .

Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

Dataflow (Apache Beam + TFT)

Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring.

Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.

Batch scoring: Recommended .

Online prediction: Recommended .

Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

TensorFlow *
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

For training efficiency in both cases, it's better to prepare the training data up front.

Batch scoring: Not Possible .

Online prediction: Not Possible .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not Possible .

* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Co dalej

,

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Wstęp

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )
The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
Prepared data
The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
Engineered features
The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

Flow diagram showing raw data moving to prepared data moving to engineered features.
Figure 1. The flow of data from raw data to prepared data to engineered features to machine learning.

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

  • Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
  • Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
  • Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
  • Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
  • Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
  • Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
  • Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

  • For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
  • For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
  • For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

  • Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

    These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

  • Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

    For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

    $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

    Full-pass transformations include the following:

    • MinMax scaling numerical features using min and max computed from the training dataset.
    • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
    • Bucketizing numerical features using quantiles.
    • Imputing missing values using the median (numerical features) or the mode (categorical features).
    • Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
    • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
    • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

    You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

  • Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

  • Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

    More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

    When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

Architecture diagram showing stages for processing data.
Figure 2. High-level architecture for ML training and serving on Google Cloud.

The pipeline consists of the following steps:

  1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
  2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
  3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
  4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
  5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
  6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

  • Sampling: randomly selecting a subset from the data.
  • Filtering: removing irrelevant or invalid instances.
  • Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

Architecture for using stream data for prediction.
Figure 3. High-level architecture using stream data for prediction in Dataflow.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

  • Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
  • Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

  • Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

    If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

  • Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

  • Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

    Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

    Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Diagram showing flow from raw data through tf.Transform to predictions.
Figure 4. Behavior of tf.Transform for preprocessing and transforming data.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

  • Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
  • Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option Instance-level
(stateless transformations)

Full-pass during training and instance-level during serving (stateful transformations)

Real-time (window) aggregations during training and serving (streaming transformations)

BigQuery (SQL)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Batch scoring: Not recommended .

Online prediction: Not recommended .

Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Dataflow (Apache Beam)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.

Batch scoring: Not recommended .

Online predictions: Not recommended .

Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

Dataflow (Apache Beam + TFT)

Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring.

Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.

Batch scoring: Recommended .

Online prediction: Recommended .

Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

TensorFlow *
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

For training efficiency in both cases, it's better to prepare the training data up front.

Batch scoring: Not Possible .

Online prediction: Not Possible .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not Possible .

* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Co dalej