Dokumen ini adalah bagian pertama dari seri dua bagian yang mengeksplorasi topik rekayasa data dan rekayasa fitur untuk pembelajaran mesin (ML), dengan fokus pada tugas pembelajaran yang diawasi. Bagian pertama ini membahas praktik terbaik untuk prapemrosesan data dalam pipeline ML di Google Cloud. Dokumen ini berfokus pada penggunaan TensorFlow dan pustaka TensorFlow Transform ( tf.Transform ) open source untuk menyiapkan data, melatih model, dan menyajikan model untuk prediksi. Dokumen ini menyoroti tantangan prapemrosesan data untuk ML, serta menjelaskan opsi dan skenario untuk melakukan transformasi data di Google Cloud secara efektif.
Dokumen ini mengasumsikan bahwa Anda sudah familiar dengan BigQuery , Dataflow , Vertex AI , dan TensorFlow Keras API.
Dokumen kedua, Pemrosesan awal data untuk ML dengan Google Cloud , memberikan tutorial langkah demi langkah tentang cara mengimplementasikan pipeline tf.Transform .
Perkenalan
ML membantu Anda secara otomatis menemukan pola yang kompleks dan berpotensi berguna dalam data. Pola-pola ini diringkas dalam model ML yang kemudian dapat digunakan pada titik data baru—sebuah proses yang disebut membuat prediksi atau melakukan inferensi .
Membangun model ML adalah proses multilangkah. Setiap langkah menghadirkan tantangan teknis dan konseptual tersendiri. Seri dua bagian ini berfokus pada tugas pembelajaran yang diawasi dan proses pemilihan, transformasi, dan penambahan data sumber untuk menciptakan sinyal prediktif yang kuat terhadap variabel target. Operasi ini menggabungkan pengetahuan domain dengan teknik ilmu data. Operasi adalah inti dari rekayasa fitur .
Ukuran set data pelatihan untuk model ML dunia nyata dapat dengan mudah sama dengan atau lebih besar dari satu terabyte (TB). Oleh karena itu, Anda memerlukan kerangka pemrosesan data berskala besar agar dapat memproses kumpulan data tersebut secara efisien dan terdistribusi. Saat Anda menggunakan model ML untuk membuat prediksi, Anda harus menerapkan transformasi yang sama seperti yang Anda gunakan untuk data pelatihan pada titik data baru. Dengan menerapkan transformasi yang sama, Anda menyajikan kumpulan data langsung ke model ML seperti yang diharapkan oleh model tersebut.
Dokumen ini membahas tantangan-tantangan ini untuk berbagai tingkat perincian operasi rekayasa fitur: agregasi level instance, full-pass, dan time-window. Dokumen ini juga menjelaskan opsi dan skenario untuk melakukan transformasi data untuk ML di Google Cloud.
Dokumen ini juga memberikan ringkasan TensorFlow Transform ( tf.Transform ), sebuah pustaka untuk TensorFlow yang memungkinkan Anda menentukan transformasi data level instance dan full-pass melalui pipeline prapemrosesan data. Alur ini dijalankan dengan Apache Beam , dan membuat artefak yang memungkinkan Anda menerapkan transformasi yang sama selama prediksi seperti saat model disajikan.
Memproses data sebelumnya untuk ML
Bagian ini memperkenalkan operasi prapemrosesan data dan tahapan kesiapan data. Bagian ini juga membahas jenis operasi prapemrosesan dan rinciannya.
Rekayasa data dibandingkan dengan rekayasa fitur
Pemrosesan awal data untuk ML melibatkan rekayasa data dan rekayasa fitur. Rekayasa data adalah proses mengubah data mentah menjadi data siap pakai . Rekayasa fitur kemudian menyesuaikan data yang telah disiapkan untuk membuat fitur yang diharapkan oleh model ML. Istilah-istilah ini mempunyai arti sebagai berikut:
- Data mentah (atau hanya data )
- Data dalam bentuk sumbernya, tanpa persiapan sebelumnya untuk ML. Dalam konteks ini, data mungkin dalam bentuk mentah (dalam data lake) atau dalam bentuk transformasi (dalam gudang data). Data yang diubah yang ada di gudang data mungkin telah dikonversi dari bentuk mentah aslinya untuk digunakan untuk analisis. Namun, dalam konteks ini, data mentah berarti data tersebut belum disiapkan secara khusus untuk tugas ML Anda. Data juga dianggap data mentah jika dikirim dari sistem streaming yang pada akhirnya memanggil model ML untuk melakukan prediksi.
- Data yang sudah disiapkan
- Kumpulan data dalam formulir siap untuk tugas ML Anda: sumber data telah diurai, digabungkan, dan dimasukkan ke dalam bentuk tabel. Data yang telah disiapkan dikumpulkan dan diringkas hingga perincian yang tepat—misalnya, setiap baris dalam kumpulan data mewakili pelanggan unik, dan setiap kolom mewakili informasi ringkasan untuk pelanggan, seperti total pembelanjaan dalam enam minggu terakhir. Dalam tabel data yang telah disiapkan, kolom yang tidak relevan telah dihilangkan, dan catatan yang tidak valid telah disaring. Untuk tugas pembelajaran yang diawasi, fitur target hadir.
- Fitur yang direkayasa
- Kumpulan data dengan fitur yang disesuaikan yang diharapkan oleh model—yaitu, fitur yang dibuat dengan melakukan operasi khusus ML tertentu pada kolom dalam kumpulan data yang telah disiapkan, dan membuat fitur baru untuk model Anda selama pelatihan dan prediksi, seperti yang dijelaskan nanti dalam operasi Pra-pemrosesan . Contoh operasi ini mencakup penskalaan kolom numerik ke nilai antara 0 dan 1, pemotongan nilai, dan fitur kategorikal enkode one-hot .
Diagram berikut, Gambar 1, menunjukkan langkah-langkah yang terlibat dalam menyiapkan data yang telah diproses sebelumnya:
Dalam praktiknya, data dari sumber yang sama seringkali berada pada tahap kesiapan yang berbeda. Misalnya, bidang dari tabel di gudang data Anda mungkin digunakan secara langsung sebagai fitur rekayasa. Pada saat yang sama, bidang lain dalam tabel yang sama mungkin perlu melalui transformasi sebelum menjadi fitur rekayasa. Demikian pula, operasi rekayasa data dan rekayasa fitur dapat digabungkan dalam langkah prapemrosesan data yang sama.
Operasi pra-pemrosesan
Pemrosesan awal data mencakup beberapa operasi. Setiap operasi dirancang untuk membantu ML membangun model prediktif yang lebih baik. Detail operasi prapemrosesan ini berada di luar cakupan dokumen ini, namun beberapa operasi dijelaskan secara singkat di bagian ini.
Untuk data terstruktur, operasi prapemrosesan data mencakup hal berikut:
- Pembersihan data: menghapus atau memperbaiki catatan yang memiliki nilai yang rusak atau tidak valid dari data mentah, dan menghapus catatan yang kehilangan banyak kolom.
- Pemilihan dan partisi instans: memilih titik data dari kumpulan data masukan untuk membuat kumpulan pelatihan, evaluasi (validasi), dan pengujian . Proses ini mencakup teknik pengambilan sampel acak berulang, pengambilan sampel kelas minoritas yang berlebihan, dan partisi bertingkat.
- Penyetelan fitur: meningkatkan kualitas fitur untuk ML, yang mencakup penskalaan dan normalisasi nilai numerik, memasukkan nilai yang hilang, memotong outlier, dan menyesuaikan nilai yang distribusinya miring.
- Transformasi fitur: mengonversi fitur numerik menjadi fitur kategorikal (melalui bucketisasi ), dan mengonversi fitur kategorikal menjadi representasi numerik (melalui enkode one-hot, pembelajaran dengan counts , penyematan fitur renggang, dll.). Beberapa model hanya bekerja dengan fitur numerik atau kategorikal, sementara model lainnya dapat menangani fitur tipe campuran. Meskipun model menangani kedua jenis tersebut, model dapat memperoleh manfaat dari representasi berbeda (numerik dan kategorikal) dari fitur yang sama.
- Ekstraksi fitur: mengurangi jumlah fitur dengan membuat representasi data berdimensi lebih rendah dan lebih kuat menggunakan teknik seperti PCA , ekstraksi penyematan , dan hashing .
- Pemilihan fitur: memilih subkumpulan fitur masukan untuk melatih model, dan mengabaikan fitur yang tidak relevan atau berlebihan, menggunakan metode filter atau wrapper . Pemilihan fitur juga dapat melibatkan penghapusan fitur jika fitur tersebut kehilangan sejumlah besar nilai.
- Konstruksi fitur: membuat fitur baru dengan menggunakan teknik umum, seperti perluasan polinomial (dengan menggunakan fungsi matematika univariat) atau persilangan fitur (untuk menangkap interaksi fitur). Fitur juga dapat dibangun dengan menggunakan logika bisnis dari domain kasus penggunaan ML.
Saat Anda bekerja dengan data tidak terstruktur (misalnya, gambar, audio, atau dokumen teks), pembelajaran mendalam menggantikan rekayasa fitur berbasis pengetahuan domain dengan menggabungkannya ke dalam arsitektur model. Lapisan konvolusional adalah praprosesor fitur otomatis. Membangun arsitektur model yang tepat memerlukan pengetahuan empiris tentang data. Selain itu, diperlukan beberapa tahap pra-pemrosesan, seperti berikut:
- Untuk dokumen teks: stemming dan lemmatization , perhitungan TF-IDF , dan ekstraksi n-gram , pencarian penyematan.
- Untuk gambar: kliping, pengubahan ukuran, pemotongan, Gaussian blur, dan filter canary.
- Untuk semua jenis data (termasuk teks dan gambar): pembelajaran transfer , yang memperlakukan semua lapisan kecuali lapisan terakhir dari model yang dilatih sepenuhnya sebagai langkah rekayasa fitur.
Granularitas pra-pemrosesan
Bagian ini membahas rincian jenis transformasi data. Hal ini menunjukkan mengapa perspektif ini sangat penting ketika menyiapkan titik data baru untuk prediksi menggunakan transformasi yang diterapkan pada data pelatihan.
Operasi pra-pemrosesan dan transformasi dapat dikategorikan sebagai berikut, berdasarkan rincian operasi:
Transformasi tingkat instans selama pelatihan dan prediksi . Ini adalah transformasi langsung, yang hanya memerlukan nilai dari instance yang sama untuk transformasi. Misalnya, transformasi tingkat instans mungkin mencakup pemotongan nilai suatu fitur ke ambang batas tertentu, memperluas fitur lain secara polinomial, mengalikan dua fitur, atau membandingkan dua fitur untuk membuat tanda Boolean.
Transformasi ini harus diterapkan secara identik selama pelatihan dan prediksi, karena model akan dilatih berdasarkan fitur yang ditransformasikan, bukan pada nilai masukan mentah. Jika data tidak ditransformasikan secara identik, model akan berperilaku buruk karena disajikan dengan data yang memiliki distribusi nilai yang tidak digunakan untuk melatihnya. Untuk informasi selengkapnya, lihat diskusi tentang kemiringan penyajian pelatihan di bagian Tantangan pra-pemrosesan .
Transformasi tingkat penuh selama pelatihan, namun transformasi tingkat instans selama prediksi . Dalam skenario ini, transformasi bersifat stateful, karena transformasi tersebut menggunakan beberapa statistik yang telah dihitung sebelumnya untuk melakukan transformasi. Selama pelatihan, Anda menganalisis seluruh data pelatihan untuk menghitung kuantitas seperti minimum, maksimum, mean, dan varians untuk mentransformasikan data pelatihan, data evaluasi, dan data baru pada waktu prediksi.
Misalnya, untuk menormalkan fitur numerik untuk pelatihan, Anda menghitung rata-rata (μ) dan deviasi standarnya (σ) di seluruh data pelatihan. Perhitungan ini disebut operasi full-pass (atau analisa ). Saat Anda menyajikan model untuk prediksi, nilai titik data baru dinormalisasi untuk menghindari distorsi penyajian pelatihan. Oleh karena itu, nilai μ dan σ yang dihitung selama pelatihan digunakan untuk menyesuaikan nilai fitur, yang merupakan operasi tingkat instans sederhana berikut:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Transformasi full-pass meliputi hal berikut:
- MinMax menskalakan fitur numerik menggunakan min dan max yang dihitung dari dataset pelatihan.
- Fitur numerik penskalaan standar (normalisasi skor-z) menggunakan μ dan σ yang dihitung pada kumpulan data pelatihan.
- Mengelompokkan fitur numerik menggunakan kuantil.
- Menghitung nilai yang hilang menggunakan median (fitur numerik) atau mode (fitur kategorikal).
- Mengonversi string (nilai nominal) menjadi bilangan bulat (indeks) dengan mengekstraksi semua nilai berbeda (kosa kata) dari fitur kategori masukan.
- Menghitung kemunculan suatu istilah (nilai fitur) di semua dokumen (instance) untuk menghitung TF-IDF.
- Menghitung PCA fitur masukan untuk memproyeksikan data ke ruang berdimensi lebih rendah (dengan fitur bergantung linier).
Anda sebaiknya hanya menggunakan data pelatihan untuk menghitung statistik seperti μ, σ, min , dan max . Jika Anda menambahkan data pengujian dan evaluasi untuk operasi ini, Anda membocorkan informasi dari data evaluasi dan pengujian untuk melatih model. Hal ini akan mempengaruhi reliabilitas hasil tes dan evaluasi. Untuk memastikan bahwa Anda menerapkan transformasi yang konsisten ke semua kumpulan data, Anda menggunakan statistik yang sama yang dihitung dari data pelatihan untuk mentransformasikan data pengujian dan evaluasi.
Agregasi sejarah selama pelatihan dan prediksi . Hal ini melibatkan pembuatan agregasi, derivasi, dan tanda bisnis sebagai sinyal masukan untuk tugas prediksi—misalnya, membuat metrik keterkinian, frekuensi, dan moneter (RFM) bagi pelanggan untuk membangun model kecenderungan. Jenis fitur ini dapat dihitung sebelumnya dan disimpan di penyimpanan fitur untuk digunakan selama pelatihan model, penilaian batch, dan penyajian prediksi online. Anda juga dapat melakukan rekayasa fitur tambahan (misalnya, transformasi dan penyesuaian) pada agregasi ini sebelum pelatihan dan prediksi.
Agregasi historis selama pelatihan, namun agregasi real-time selama prediksi . Pendekatan ini melibatkan pembuatan fitur dengan merangkum nilai real-time dari waktu ke waktu. Dalam pendekatan ini, instance yang akan dikumpulkan ditentukan melalui klausa jendela temporal. Misalnya, Anda dapat menggunakan pendekatan ini jika ingin melatih model yang memperkirakan waktu perjalanan taksi berdasarkan metrik lalu lintas untuk rute tersebut dalam 5 menit terakhir, dalam 10 menit terakhir, dalam 30 menit terakhir, dan pada waktu lain. interval. Anda juga dapat menggunakan pendekatan ini untuk memprediksi kegagalan bagian mesin berdasarkan rata-rata pergerakan nilai suhu dan getaran yang dihitung selama 3 menit terakhir. Meskipun agregasi ini dapat disiapkan secara offline untuk pelatihan, agregasi ini dihitung secara real-time dari aliran data selama penayangan.
Lebih tepatnya, saat Anda menyiapkan data pelatihan, jika nilai agregat tidak ada dalam data mentah, nilai tersebut dibuat selama fase rekayasa data. Data mentah biasanya disimpan dalam database dengan format
(entity, timestamp, value). Pada contoh sebelumnya,entityadalah pengidentifikasi segmen rute untuk rute taksi dan pengidentifikasi bagian mesin untuk kegagalan mesin. Anda dapat menggunakan operasi windowing untuk menghitung(entity, time_index, aggregated_value_over_time_window)dan menggunakan fitur agregasi sebagai masukan untuk pelatihan model Anda.Saat model untuk prediksi real-time (online) disajikan, model mengharapkan fitur yang berasal dari nilai agregat sebagai masukan. Oleh karena itu, Anda dapat menggunakan teknologi pemrosesan aliran seperti Apache Beam untuk menghitung agregasi dari titik data real-time yang dialirkan ke sistem Anda. Teknologi pemrosesan aliran mengumpulkan data waktu nyata berdasarkan jangka waktu saat titik data baru tiba. Anda juga dapat melakukan rekayasa fitur tambahan (misalnya, transformasi dan penyesuaian) pada agregasi ini sebelum pelatihan dan prediksi.
Saluran ML di Google Cloud
Bagian ini membahas komponen inti dari pipeline end-to-end yang umum untuk melatih dan menyajikan model TensorFlow ML di Google Cloud menggunakan layanan terkelola. Bab ini juga membahas di mana Anda dapat menerapkan berbagai kategori operasi prapemrosesan data, dan tantangan umum yang mungkin Anda hadapi saat menerapkan transformasi tersebut. Bagian Cara kerja tf.Transform menunjukkan bagaimana pustaka Transformasi TensorFlow membantu mengatasi tantangan ini.
Arsitektur tingkat tinggi
Diagram berikut, gambar 2, menunjukkan arsitektur tingkat tinggi dari pipeline ML pada umumnya untuk melatih dan menyajikan model TensorFlow. Label A, B, dan C dalam diagram mengacu pada tempat berbeda di pipeline tempat prapemrosesan data dapat dilakukan. Detail tentang langkah-langkah ini disediakan di bagian berikut.
Jalur pipa terdiri dari langkah-langkah berikut:
- Setelah data mentah diimpor, data tabular disimpan di BigQuery, dan data lain seperti gambar, audio, dan video, disimpan di Cloud Storage. Bagian kedua dari seri ini menggunakan data tabel yang disimpan di BigQuery sebagai contoh.
- Rekayasa data (persiapan) dan rekayasa fitur dijalankan dalam skala besar menggunakan Dataflow. Eksekusi ini menghasilkan set pelatihan, evaluasi, dan pengujian yang siap ML yang disimpan di Cloud Storage. Idealnya, kumpulan data ini disimpan sebagai file TFRecord , yang merupakan format yang dioptimalkan untuk komputasi TensorFlow.
- Paket pelatih model TensorFlow dikirimkan ke Pelatihan Vertex AI, yang menggunakan data yang telah diproses sebelumnya dari langkah sebelumnya untuk melatih model. Output dari langkah ini adalah TensorFlow SavedModel terlatih yang diekspor ke Cloud Storage.
- Model TensorFlow yang dilatih diterapkan ke Vertex AI Prediction sebagai layanan yang memiliki REST API sehingga dapat digunakan untuk prediksi online. Model yang sama juga dapat digunakan untuk pekerjaan prediksi batch.
- Setelah model diterapkan sebagai REST API, aplikasi klien dan sistem internal dapat memanggil API dengan mengirimkan permintaan dengan beberapa titik data, dan menerima respons dari model dengan prediksi.
- Untuk mengatur dan mengotomatisasi alur ini, Anda dapat menggunakan Vertex AI Pipelines sebagai penjadwal untuk menjalankan langkah-langkah persiapan data, pelatihan model, dan penerapan model.
Anda juga dapat menggunakan Vertex AI Feature Store untuk menyimpan fitur masukan untuk membuat prediksi. Misalnya, Anda dapat secara berkala membuat fitur rekayasa dari data mentah terbaru dan menyimpannya di Vertex AI Feature Store. Aplikasi klien mengambil fitur masukan yang diperlukan dari Vertex AI Feature Store dan mengirimkannya ke model untuk menerima prediksi.
Dimana melakukan preprocessing
Pada gambar 2, label A, B, dan C menunjukkan bahwa operasi prapemrosesan data dapat dilakukan di BigQuery, Dataflow, atau TensorFlow. Bagian berikut menjelaskan cara kerja masing-masing opsi ini.
Opsi A: BigQuery
Biasanya, logika diimplementasikan di BigQuery untuk operasi berikut:
- Sampling: memilih subset dari data secara acak.
- Pemfilteran: menghapus contoh yang tidak relevan atau tidak valid.
- Partisi: memisahkan data untuk menghasilkan set pelatihan, evaluasi, dan pengujian.
Skrip BigQuery SQL dapat digunakan sebagai kueri sumber untuk pipeline prapemrosesan Dataflow, yang merupakan langkah pemrosesan data pada gambar 2. Misalnya, jika sistem digunakan di Kanada, dan gudang data memiliki transaksi dari seluruh dunia, pemfilteran akan dilakukan. mendapatkan data pelatihan khusus Kanada paling baik dilakukan di BigQuery. Rekayasa fitur di BigQuery sederhana dan skalabel, serta mendukung penerapan transformasi fitur agregasi historis dan tingkat instance.
Namun, kami menyarankan Anda menggunakan BigQuery untuk rekayasa fitur hanya jika Anda menggunakan model untuk prediksi batch (penilaian), atau jika fitur telah dihitung sebelumnya di BigQuery, namun disimpan di Vertex AI Feature Store untuk digunakan selama prediksi online. Jika Anda berencana menerapkan model untuk prediksi online, dan jika Anda tidak memiliki fitur rekayasa di penyimpanan fitur online, Anda harus mereplikasi operasi prapemrosesan SQL untuk mengubah titik data mentah yang dihasilkan sistem lain. Dengan kata lain, Anda perlu mengimplementasikan logika tersebut dua kali: satu kali di SQL untuk melakukan praproses data pelatihan di BigQuery, dan kedua kali dalam logika aplikasi yang menggunakan model untuk melakukan praproses titik data online untuk prediksi.
Misalnya, jika aplikasi klien Anda ditulis dalam Java, Anda perlu mengimplementasikan ulang logika di Java. Hal ini dapat menimbulkan kesalahan karena perbedaan implementasi, seperti yang dijelaskan di bagian kemiringan penyajian pelatihan pada tantangan Pra-pemrosesan di bagian selanjutnya dalam dokumen ini. Ini juga merupakan biaya tambahan untuk mempertahankan dua implementasi yang berbeda. Setiap kali Anda mengubah logika dalam SQL untuk melakukan praproses data pelatihan, Anda perlu mengubah implementasi Java sesuai dengan praproses data pada waktu penyajian.
Jika Anda menggunakan model hanya untuk prediksi batch (misalnya, menggunakan prediksi batch Vertex AI ), dan jika data untuk penilaian bersumber dari BigQuery, Anda dapat menerapkan operasi prapemrosesan ini sebagai bagian dari skrip BigQuery SQL. Dalam hal ini, Anda dapat menggunakan skrip SQL prapemrosesan yang sama untuk menyiapkan data pelatihan dan penilaian.
Transformasi stateful jalur penuh tidak cocok untuk diterapkan di BigQuery. Jika Anda menggunakan BigQuery untuk transformasi menyeluruh, Anda memerlukan tabel tambahan untuk menyimpan kuantitas yang diperlukan oleh transformasi stateful, seperti rata-rata dan varians untuk menskalakan fitur numerik. Selain itu, penerapan transformasi menyeluruh menggunakan SQL di BigQuery menciptakan peningkatan kompleksitas dalam skrip SQL, dan menciptakan ketergantungan yang rumit antara pelatihan dan penilaian skrip SQL.
Opsi B: Aliran Data
Seperti yang ditunjukkan pada gambar 2, Anda dapat mengimplementasikan operasi prapemrosesan yang mahal secara komputasi di Apache Beam, dan menjalankannya dalam skala besar menggunakan Dataflow. Dataflow adalah layanan penskalaan otomatis yang terkelola sepenuhnya untuk pemrosesan data batch dan streaming. Saat menggunakan Dataflow, Anda juga dapat menggunakan pustaka khusus eksternal untuk pemrosesan data, tidak seperti BigQuery.
Dataflow dapat melakukan transformasi tingkat instans, serta transformasi fitur agregasi historis dan real-time. Khususnya, jika model ML Anda mengharapkan fitur masukan seperti total_number_of_clicks_last_90sec , fungsi jendela Apache Beam dapat menghitung fitur ini berdasarkan agregasi nilai jendela waktu dari data peristiwa (streaming) waktu nyata (misalnya, peristiwa klik). Dalam pembahasan sebelumnya tentang granularitas transformasi , hal ini disebut sebagai "Agregasi historis selama pelatihan, namun agregasi real-time selama prediksi".
Diagram berikut, gambar 3, menunjukkan peran Dataflow dalam memproses data aliran untuk prediksi hampir real-time.
Seperti yang ditunjukkan dalam gambar 3, selama pemrosesan, peristiwa yang disebut titik data diserap ke dalam Pub/Sub . Dataflow menggunakan titik data ini, menghitung fitur berdasarkan agregat dari waktu ke waktu, lalu memanggil API model ML yang diterapkan untuk prediksi. Prediksi kemudian dikirim ke antrean Pub/Sub keluar. Dari Pub/Sub, prediksi dapat digunakan oleh sistem downstream seperti pemantauan atau kontrol, atau prediksi dapat dikirim kembali (misalnya, sebagai notifikasi) ke klien asli yang meminta. Prediksi juga dapat disimpan di penyimpanan data berlatensi rendah seperti Cloud Bigtable untuk pengambilan waktu nyata. Cloud Bigtable juga dapat digunakan untuk mengumpulkan dan menyimpan agregasi ini secara real-time sehingga dapat dicari saat diperlukan untuk prediksi.
Implementasi Apache Beam yang sama dapat digunakan untuk memproses data pelatihan secara batch yang berasal dari penyimpanan data offline seperti BigQuery dan memproses aliran data real-time untuk menyajikan prediksi online.
Dalam arsitektur umum lainnya, seperti arsitektur yang ditunjukkan pada gambar 2, aplikasi klien secara langsung memanggil API model yang diterapkan untuk prediksi online. Dalam hal ini, jika operasi prapemrosesan diterapkan di Dataflow untuk menyiapkan data pelatihan, operasi tersebut tidak diterapkan pada data prediksi yang langsung masuk ke model. Oleh karena itu, transformasi seperti ini harus diintegrasikan ke dalam model saat digunakan untuk prediksi online.
Dataflow dapat digunakan untuk melakukan transformasi menyeluruh, dengan menghitung statistik yang diperlukan dalam skala besar. Namun, statistik ini perlu disimpan di suatu tempat untuk digunakan selama prediksi guna mengubah titik data prediksi. Dengan menggunakan pustaka TensorFlow Transform ( tf.Transform ), Anda dapat langsung menyematkan statistik ini ke dalam model alih-alih menyimpannya di tempat lain. Pendekatan ini dijelaskan nanti di Cara kerja tf.Transform .
Opsi C: TensorFlow
Seperti yang ditunjukkan pada gambar 2, Anda dapat mengimplementasikan operasi prapemrosesan dan transformasi data dalam model TensorFlow itu sendiri. Seperti yang ditunjukkan pada gambar, prapemrosesan yang Anda terapkan untuk melatih model TensorFlow menjadi bagian integral dari model saat model diekspor dan di-deploy untuk prediksi. Transformasi dalam model TensorFlow dapat dilakukan dengan salah satu cara berikut:
- Menerapkan semua logika transformasi tingkat instans dalam fungsi
input_fndan fungsiserving_fn. Fungsiinput_fnmenyiapkan kumpulan data menggunakantf.data.DatasetAPI untuk melatih model. Fungsiserving_fnmenerima dan menyiapkan data untuk prediksi. - Menempatkan kode transformasi langsung di model TensorFlow Anda dengan menggunakan lapisan prapemrosesan Keras atau membuat lapisan khusus .
Kode logika transformasi dalam fungsi serving_fn mendefinisikan antarmuka penyajian SavedModel Anda untuk prediksi online. Jika Anda menerapkan transformasi yang sama yang digunakan untuk menyiapkan data pelatihan dalam kode logika transformasi fungsi serving_fn , hal ini memastikan bahwa transformasi yang sama diterapkan ke titik data prediksi baru saat disajikan.
Namun, karena model TensorFlow memproses setiap titik data secara independen atau dalam batch kecil, Anda tidak dapat menghitung agregasi dari semua titik data. Akibatnya, transformasi menyeluruh tidak dapat diterapkan dalam model TensorFlow Anda.
Tantangan pra-pemrosesan
Berikut ini adalah tantangan utama dalam penerapan pra-pemrosesan data:
Kemiringan penyajian pelatihan . Kemiringan penyajian pelatihan mengacu pada perbedaan antara efektivitas (kinerja prediktif) selama pelatihan dan selama penyajian. Kemiringan ini dapat disebabkan oleh perbedaan antara cara Anda menangani data dalam pelatihan dan alur penyajian. Misalnya, jika model Anda dilatih pada fitur yang diubah secara logaritmik, namun model tersebut disajikan dengan fitur mentah selama penayangan, keluaran prediksi mungkin tidak akurat.
Jika transformasi menjadi bagian dari model itu sendiri, penanganan transformasi tingkat instance dapat dilakukan dengan mudah, seperti yang dijelaskan sebelumnya dalam Opsi C: TensorFlow . Dalam hal ini, antarmuka penyajian model (fungsi
serving_fn) mengharapkan data mentah, sementara model secara internal mengubah data ini sebelum menghitung keluarannya. Transformasinya sama dengan yang diterapkan pada titik data pelatihan dan prediksi mentah.Transformasi menyeluruh . Anda tidak dapat menerapkan transformasi menyeluruh seperti transformasi penskalaan dan normalisasi dalam model TensorFlow Anda. Dalam transformasi full-pass, beberapa statistik (misalnya, nilai
maxdanminuntuk menskalakan fitur numerik) harus dihitung pada data pelatihan terlebih dahulu, seperti yang dijelaskan dalam Opsi B: Dataflow . Nilai-nilai tersebut kemudian harus disimpan di suatu tempat untuk digunakan selama penyajian model untuk prediksi guna mengubah titik data mentah baru sebagai transformasi tingkat instans, yang menghindari kemiringan penyajian pelatihan. Anda dapat menggunakan pustaka TensorFlow Transform (tf.Transform) untuk menyematkan statistik secara langsung ke model TensorFlow Anda. Pendekatan ini dijelaskan nanti di Cara kerja tf.Transform .Mempersiapkan data di awal untuk efisiensi pelatihan yang lebih baik . Menerapkan transformasi tingkat instans sebagai bagian dari model dapat menurunkan efisiensi proses pelatihan. Degradasi ini terjadi karena transformasi yang sama diterapkan berulang kali pada data pelatihan yang sama pada setiap epoch. Bayangkan Anda memiliki data pelatihan mentah dengan 1.000 fitur, dan Anda menerapkan campuran transformasi tingkat instans untuk menghasilkan 10.000 fitur. Jika Anda menerapkan transformasi ini sebagai bagian dari model Anda, dan kemudian memasukkan data pelatihan mentah ke model, 10.000 operasi ini akan diterapkan sebanyak N kali pada setiap instans, dengan N adalah jumlah periode. Selain itu, jika Anda menggunakan akselerator (GPU atau TPU), akselerator tersebut tidak akan digunakan saat CPU melakukan transformasi tersebut, sehingga penggunaan akselerator Anda yang mahal tidak efisien.
Idealnya, data pelatihan ditransformasikan sebelum pelatihan, menggunakan teknik yang dijelaskan dalam Opsi B: Aliran Data , dengan 10.000 operasi transformasi diterapkan hanya sekali pada setiap instans pelatihan. Data pelatihan yang diubah kemudian disajikan ke model. Tidak ada transformasi lebih lanjut yang diterapkan, dan akselerator selalu sibuk. Selain itu, penggunaan Dataflow membantu Anda melakukan praproses data dalam jumlah besar dalam skala besar, menggunakan layanan yang terkelola sepenuhnya.
Mempersiapkan data pelatihan terlebih dahulu dapat meningkatkan efisiensi pelatihan. Namun, menerapkan logika transformasi di luar model (pendekatan yang dijelaskan dalam Opsi A: BigQuery atau Opsi B: Dataflow ) tidak menyelesaikan masalah kemiringan penyajian pelatihan. Kecuali Anda menyimpan fitur rekayasa di penyimpanan fitur untuk digunakan dalam pelatihan dan prediksi, logika transformasi harus diimplementasikan di suatu tempat untuk diterapkan pada titik data baru yang datang untuk prediksi, karena antarmuka model mengharapkan data yang diubah. Pustaka TensorFlow Transform (
tf.Transform) dapat membantu Anda mengatasi masalah ini, seperti yang dijelaskan di bagian berikut.
Bagaimana tf.Transform bekerja
Pustaka tf.Transform berguna untuk transformasi yang memerlukan penyelesaian penuh. Output dari perpustakaan tf.Transform diekspor sebagai grafik TensorFlow yang mewakili logika transformasi tingkat instance dan statistik yang dihitung dari transformasi full-pass, untuk digunakan dalam pelatihan dan penyajian. Menggunakan grafik yang sama untuk pelatihan dan penyajian dapat mencegah penyimpangan, karena transformasi yang sama diterapkan di kedua tahap. Selain itu, pustaka tf.Transform dapat berjalan dalam skala besar di pipeline pemrosesan batch di Dataflow untuk menyiapkan data pelatihan terlebih dahulu dan meningkatkan efisiensi pelatihan.
Diagram berikut, gambar 4, menunjukkan bagaimana perpustakaan tf.Transform memproses dan mentransformasikan data untuk pelatihan dan prediksi. Prosesnya dijelaskan di bagian berikut.
tf.Transform untuk prapemrosesan dan transformasi data. Transformasikan data pelatihan dan evaluasi
Anda melakukan praproses data pelatihan mentah menggunakan transformasi yang diterapkan di tf.Transform Apache Beam API, dan menjalankannya dalam skala besar di Dataflow. Pra-pemrosesan terjadi dalam fase berikut:
- Fase analisis: Selama fase analisis, statistik yang diperlukan (seperti rata-rata, varians, dan kuantil) untuk transformasi stateful dihitung pada data pelatihan dengan operasi full-pass. Fase ini menghasilkan sekumpulan artefak transformasi, termasuk grafik
transform_fn. Grafiktransform_fnadalah grafik TensorFlow yang memiliki logika transformasi sebagai operasi tingkat instance. Ini mencakup statistik yang dihitung dalam fase analisis sebagai konstanta. - Fase transformasi: Selama fase transformasi, grafik
transform_fnditerapkan pada data pelatihan mentah, di mana statistik yang dihitung digunakan untuk memproses rekaman data (misalnya, untuk menskalakan kolom numerik) dengan cara tingkat instans.
Pendekatan dua fase seperti ini mengatasi tantangan pra-pemrosesan dalam melakukan transformasi menyeluruh.
Saat data evaluasi diproses sebelumnya, hanya operasi tingkat instans yang diterapkan, menggunakan logika dalam grafik transform_fn dan statistik dihitung dari fase analisis dalam data pelatihan. Dengan kata lain, Anda tidak menganalisis data evaluasi secara menyeluruh untuk menghitung statistik baru, seperti μ dan σ, untuk menormalkan fitur numerik dalam data evaluasi. Sebagai gantinya, Anda menggunakan statistik yang dihitung dari data pelatihan untuk mengubah data evaluasi dalam cara tingkat instans.
Data pelatihan dan evaluasi yang diubah disiapkan dalam skala besar menggunakan Dataflow, sebelum digunakan untuk melatih model. Proses persiapan data batch ini membahas tantangan preprocessing untuk mempersiapkan data di muka untuk meningkatkan efisiensi pelatihan. Seperti yang ditunjukkan pada Gambar 4, antarmuka internal model mengharapkan fitur yang diubah.
Lampirkan transformasi ke model yang diekspor
Seperti dicatat, grafik transform_fn yang diproduksi oleh pipa tf.Transform disimpan sebagai grafik TensorFlow yang diekspor. Grafik yang diekspor terdiri dari logika transformasi sebagai operasi tingkat instance, dan semua statistik yang dihitung dalam transformasi penuh-pass sebagai konstanta grafik. Ketika model yang dilatih diekspor untuk disajikan, grafik transform_fn dilampirkan pada SavedModel sebagai bagian dari fungsi serving_fn -nya.
Sementara itu melayani model untuk prediksi, antarmuka model yang melayani mengharapkan titik data dalam format mentah (yaitu, sebelum transformasi apa pun). Namun, antarmuka internal model mengharapkan data dalam format yang diubah.
Grafik transform_fn , yang sekarang menjadi bagian dari model, menerapkan semua logika preprocessing pada titik data yang masuk. Ini menggunakan konstanta yang disimpan (seperti μ dan σ untuk menormalkan fitur numerik) dalam operasi level instance selama prediksi. Oleh karena itu, grafik transform_fn mengubah titik data mentah menjadi format yang diubah. Format yang diubah adalah apa yang diharapkan oleh antarmuka internal model untuk menghasilkan prediksi, seperti yang ditunjukkan pada Gambar 4.
Mekanisme ini menyelesaikan tantangan preprocessing dari kemiringan pelatihan, karena logika (implementasi) yang sama yang digunakan untuk mengubah data pelatihan dan evaluasi diterapkan untuk mengubah titik data baru selama penyajian prediksi.
Ringkasan Opsi Preprocessing
Tabel berikut merangkum opsi pemrosesan data yang dibahas dokumen ini. Dalam tabel, "N/A" adalah singkatan dari "tidak berlaku."
| Opsi Preprocessing Data | Level instance (Transformasi tanpa kewarganegaraan) | Full-pass selama pelatihan dan level instance selama melayani (transformasi stateful) | Agregasi real-time (jendela) selama pelatihan dan porsi (transformasi streaming) |
|---|---|---|---|
BigQuery (SQL) | Skor Batch: OK - Implementasi transformasi yang sama diterapkan pada data selama pelatihan dan penilaian batch. Prediksi online: Tidak disarankan -Anda dapat memproses data pelatihan, tetapi ini menghasilkan kemiringan pelatihan karena Anda memproses data yang melayani menggunakan alat yang berbeda. | Skor Batch: Tidak dianjurkan . Prediksi online: Tidak dianjurkan . Meskipun Anda dapat menggunakan statistik yang dihitung menggunakan BigQuery untuk transformasi batch/online tingkat instance, itu tidak mudah karena Anda harus mempertahankan toko statistik untuk diisi selama pelatihan dan digunakan selama prediksi. | Penilaian Batch: N/A —Gagregat seperti ini dihitung berdasarkan acara real-time. Prediksi online: Tidak disarankan -Anda dapat memproses data pelatihan, tetapi ini menghasilkan kemiringan pelatihan karena Anda memproses data yang melayani menggunakan alat yang berbeda. |
DataFlow (Apache Beam) | Skor Batch: OK - Implementasi transformasi yang sama diterapkan pada data selama pelatihan dan penilaian batch. Prediksi Online: OK —Jika Data pada Waktu Melayani berasal dari pub/sub untuk dikonsumsi oleh DataFlow. Kalau tidak, hasilnya condong pelatihan. | Skor Batch: Tidak dianjurkan . Prediksi online: Tidak disarankan . Meskipun Anda dapat menggunakan statistik yang dihitung menggunakan dataflow untuk transformasi batch/online tingkat instan, itu tidak mudah karena Anda harus mempertahankan toko statistik untuk diisi selama pelatihan dan digunakan selama prediksi. | Penilaian Batch: N/A —Gagregat seperti ini dihitung berdasarkan acara real-time. Prediksi Online: OK - Transformasi balok Apache yang sama diterapkan pada data selama pelatihan (batch) dan porsi (stream). |
DataFlow (Apache Beam + TFT) | Skor Batch: OK - Implementasi transformasi yang sama diterapkan pada data selama pelatihan dan penilaian batch. Prediksi Online: Direkomendasikan -Ini menghindari kemiringan pelatihan dan menyiapkan data pelatihan di muka. | Skor Batch: Direkomendasikan . Prediksi online: Direkomendasikan . Kedua penggunaan direkomendasikan karena logika transformasi dan statistik yang dihitung selama pelatihan disimpan sebagai grafik TensorFlow yang melekat pada model yang diekspor untuk disajikan. | Penilaian Batch: N/A —Gagregat seperti ini dihitung berdasarkan acara real-time. Prediksi Online: OK - Transformasi balok Apache yang sama diterapkan pada data selama pelatihan (batch) dan porsi (stream). |
Tensorflow * | Skor Batch: Tidak dianjurkan . Prediksi online: Tidak dianjurkan . Untuk efisiensi pelatihan dalam kedua kasus, lebih baik menyiapkan data pelatihan di muka. | Skor Batch: Tidak mungkin . Prediksi online: tidak mungkin . | Penilaian Batch: N/A —Gagregat seperti ini dihitung berdasarkan acara real-time. Prediksi online: tidak mungkin . |
* Dengan TensorFlow, Transformasi Seperti Persilangan, Tanah, dan Pengkodean Satu-Hot harus dilakukan secara deklaratif sebagai kolom feature_columns .
Apa selanjutnya
- Untuk mengimplementasikan pipa
tf.Transformdan menjalankannya menggunakan DataFlow, baca bagian dua dari seri ini, preprocessing data untuk ML menggunakan TensorFlow Transform . - Ambil spesialisasi Coursera di ML dengan TensorFlow di Google Cloud .
- Pelajari tentang praktik terbaik untuk rekayasa ML dalam aturan ML .
- Untuk lebih banyak arsitektur referensi, diagram, dan praktik terbaik, jelajahi solusi cloud TFX .
Dokumen ini adalah yang pertama dalam seri dua bagian yang mengeksplorasi topik rekayasa data dan rekayasa fitur untuk pembelajaran mesin (ML), dengan fokus pada tugas pembelajaran yang diawasi. Bagian pertama ini membahas praktik terbaik untuk preprocessing data dalam pipa ML di Google Cloud. Dokumen ini berfokus pada penggunaan TensorFlow dan perpustakaan TensorFlow Transform ( tf.Transform ) terbuka untuk menyiapkan data, melatih model, dan melayani model untuk prediksi. Dokumen ini menyoroti tantangan data preprocessing untuk ML, dan ini menjelaskan opsi dan skenario untuk melakukan transformasi data di Google Cloud secara efektif.
Dokumen ini mengasumsikan bahwa Anda terbiasa dengan BigQuery , Dataflow , Vertex AI , dan Tensorflow Keras API.
Dokumen kedua, preprocessing data untuk ML dengan Google Cloud , menyediakan tutorial langkah demi langkah untuk cara mengimplementasikan pipa tf.Transform .
Perkenalan
ML membantu Anda secara otomatis menemukan pola yang kompleks dan berpotensi berguna dalam data. Pola -pola ini dikondensasi dalam model ML yang kemudian dapat digunakan pada titik data baru - proses yang disebut membuat prediksi atau melakukan inferensi .
Membangun model ML adalah proses multistep. Setiap langkah menghadirkan tantangan teknis dan konseptualnya sendiri. Seri dua bagian ini berfokus pada tugas-tugas pembelajaran yang diawasi dan proses memilih, mengubah, dan menambah data sumber untuk membuat sinyal prediktif yang kuat ke variabel target. Operasi ini menggabungkan pengetahuan domain dengan teknik ilmu data. Operasi adalah inti dari rekayasa fitur .
Ukuran kumpulan data pelatihan untuk model ML dunia nyata dapat dengan mudah sama atau lebih besar dari satu terabyte (TB). Oleh karena itu, Anda memerlukan kerangka pemrosesan data skala besar untuk memproses kumpulan data ini secara efisien dan didistribusikan. Saat Anda menggunakan model ML untuk membuat prediksi, Anda harus menerapkan transformasi yang sama yang Anda gunakan untuk data pelatihan pada titik data baru. Dengan menerapkan transformasi yang sama, Anda menyajikan dataset langsung ke model ML seperti yang diharapkan oleh model.
Dokumen ini membahas tantangan-tantangan ini untuk berbagai tingkat granularitas operasi rekayasa fitur: level instance, full-pass, dan agregasi window waktu. Dokumen ini juga menjelaskan opsi dan skenario untuk melakukan transformasi data untuk ML di Google Cloud.
Dokumen ini juga memberikan tinjauan umum TensorFlow Transform ( tf.Transform ), perpustakaan untuk TensorFlow yang memungkinkan Anda mendefinisikan transformasi data level-instance dan full-pass melalui saluran pipa preprocessing data. Pipa -pipa ini dieksekusi dengan Apache Beam , dan mereka membuat artefak yang memungkinkan Anda menerapkan transformasi yang sama selama prediksi seperti ketika model dilayani.
Data preprocessing untuk ML
Bagian ini memperkenalkan operasi preprocessing data dan tahapan kesiapan data. Ini juga membahas jenis operasi preprocessing dan granularitasnya.
Rekayasa data dibandingkan dengan rekayasa fitur
Preprocessing data untuk ML melibatkan rekayasa data dan rekayasa fitur. Rekayasa data adalah proses mengubah data mentah menjadi data yang disiapkan . Teknik fitur kemudian menyetel data yang disiapkan untuk membuat fitur yang diharapkan oleh model ML. Istilah -istilah ini memiliki makna berikut:
- Data mentah (atau hanya data )
- Data dalam bentuk sumbernya, tanpa persiapan sebelumnya untuk ML. Dalam konteks ini, data mungkin dalam bentuk mentahnya (di danau data) atau dalam bentuk yang diubah (di gudang data). Data yang diubah yang ada di gudang data mungkin telah dikonversi dari bentuk mentah aslinya untuk digunakan untuk analitik. Namun, dalam konteks ini, data mentah berarti bahwa data belum disiapkan secara khusus untuk tugas ML Anda. Data juga dianggap sebagai data mentah jika dikirim dari sistem streaming yang akhirnya memanggil model ML untuk prediksi.
- Data yang disiapkan
- Dataset dalam bentuk yang siap untuk tugas ML Anda: Sumber data telah diuraikan, bergabung, dan dimasukkan ke dalam bentuk tabel. Data yang disiapkan dikumpulkan dan dirangkum ke rincian kanan - misalnya, setiap baris dalam dataset mewakili pelanggan yang unik, dan setiap kolom mewakili informasi ringkasan untuk pelanggan, seperti total yang dihabiskan dalam enam minggu terakhir. Dalam tabel data yang disiapkan, kolom yang tidak relevan telah dijatuhkan, dan catatan tidak valid telah disaring. Untuk tugas belajar yang diawasi, fitur target hadir.
- Fitur yang direkayasa
- Dataset dengan fitur yang disetel yang diharapkan oleh model-yaitu, fitur yang dibuat dengan melakukan operasi spesifik ML tertentu pada kolom dalam dataset yang disiapkan, dan membuat fitur baru untuk model Anda selama pelatihan dan prediksi, seperti yang dijelaskan nanti dalam operasi preprocessing . Contoh operasi ini termasuk penskalaan kolom numerik ke nilai antara 0 dan 1, nilai kliping, dan fitur kategorikal satu-panas .
Diagram berikut, Gambar 1, menunjukkan langkah -langkah yang terlibat dalam menyiapkan data preprocessed:
Dalam praktiknya, data dari sumber yang sama sering pada tahap kesiapan yang berbeda. Misalnya, bidang dari tabel di gudang data Anda dapat digunakan secara langsung sebagai fitur yang direkayasa. Pada saat yang sama, bidang lain dalam tabel yang sama mungkin perlu melalui transformasi sebelum menjadi fitur yang direkayasa. Demikian pula, rekayasa data dan operasi rekayasa fitur dapat digabungkan dalam langkah preprocessing data yang sama.
Operasi preprocessing
Preprocessing data mencakup beberapa operasi. Setiap operasi dirancang untuk membantu ML membangun model prediktif yang lebih baik. Rincian operasi preprocessing ini berada di luar ruang lingkup dokumen ini, tetapi beberapa operasi dijelaskan secara singkat di bagian ini.
Untuk data terstruktur, operasi preprocessing data termasuk yang berikut:
- Pembersihan Data: Menghapus atau mengoreksi catatan yang telah merusak nilai atau tidak valid dari data mentah, dan menghapus catatan yang kehilangan sejumlah besar kolom.
- Contoh Pemilihan dan Partisi: Memilih titik data dari dataset input untuk membuat pelatihan, evaluasi (validasi), dan set tes . Proses ini mencakup teknik untuk pengambilan sampel acak yang dapat diulang, kelas minoritas yang berlebihan, dan partisi bertingkat.
- Tuning fitur: Meningkatkan kualitas fitur untuk ML, yang mencakup penskalaan dan menormalkan nilai numerik, menghambat nilai -nilai yang hilang, memotong outlier, dan penyesuaian nilai yang memiliki distribusi miring.
- Transformasi Fitur: Mengubah fitur numerik ke fitur kategorikal (melalui bucketization ), dan mengonversi fitur kategorikal menjadi representasi numerik (melalui pengkodean satu-panas, belajar dengan jumlah , embeddings fitur yang jarang, dll.). Beberapa model hanya bekerja dengan fitur numerik atau kategori, sementara yang lain dapat menangani fitur tipe campuran. Bahkan ketika model menangani kedua jenis, mereka dapat memperoleh manfaat dari representasi yang berbeda (numerik dan kategori) dari fitur yang sama.
- Ekstraksi fitur: Mengurangi jumlah fitur dengan membuat dimensi rendah, representasi data yang lebih kuat menggunakan teknik seperti PCA , ekstraksi penyematan , dan hashing .
- Pemilihan Fitur: Memilih subset fitur input untuk melatih model, dan mengabaikan yang tidak relevan atau berlebihan, menggunakan metode filter atau pembungkus . Pilihan fitur juga dapat melibatkan hanya menjatuhkan fitur jika fiturnya kehilangan sejumlah besar nilai.
- Konstruksi fitur: Membuat fitur baru dengan menggunakan teknik khas, seperti ekspansi polinomial (dengan menggunakan fungsi matematika univariat) atau persimpangan fitur (untuk menangkap interaksi fitur). Fitur juga dapat dibangun dengan menggunakan logika bisnis dari domain case penggunaan ML.
Saat Anda bekerja dengan data yang tidak terstruktur (misalnya, gambar, audio, atau dokumen teks), pembelajaran mendalam menggantikan rekayasa fitur berbasis pengetahuan-domain dengan melipatnya ke dalam arsitektur model. Lapisan konvolusional adalah preprocessor fitur otomatis. Membangun arsitektur model yang tepat membutuhkan beberapa pengetahuan empiris tentang data. Selain itu, beberapa jumlah preprocessing diperlukan, seperti berikut:
- Untuk dokumen teks: Stemming dan lemmatisasi , perhitungan TF-IDF , dan ekstraksi N-gram , pencarian yang menanamkan.
- Untuk gambar: Kliping, pengubah ukuran, pemangkasan, Gaussian blur, dan filter canary.
- Untuk semua jenis data (termasuk teks dan gambar): Transfer Learning , yang memperlakukan lapisan semua-tetapi-terakhir dari model yang sepenuhnya terlatih sebagai langkah rekayasa fitur.
Granularitas preprocessing
Bagian ini membahas granularitas jenis transformasi data. Ini menunjukkan mengapa perspektif ini sangat penting ketika menyiapkan titik data baru untuk prediksi menggunakan transformasi yang diterapkan pada data pelatihan.
Operasi preprocessing dan transformasi dapat dikategorikan sebagai berikut, berdasarkan Operasi Granularity:
Transformasi tingkat instance selama pelatihan dan prediksi . Ini adalah transformasi langsung, di mana hanya nilai -nilai dari contoh yang sama diperlukan untuk transformasi. Sebagai contoh, transformasi tingkat instance mungkin termasuk kliping nilai fitur ke beberapa ambang batas, memperluas fitur lain secara polinomi, melipatgandakan dua fitur, atau membandingkan dua fitur untuk membuat bendera boolean.
Transformasi ini harus diterapkan secara identik selama pelatihan dan prediksi, karena model akan dilatih pada fitur yang diubah, bukan pada nilai input mentah. Jika data tidak diubah secara identik, maka model berperilaku buruk karena disajikan dengan data yang memiliki distribusi nilai yang tidak dilatih. Untuk informasi lebih lanjut, lihat diskusi tentang kemiringan pelatihan di bagian tantangan preprocessing .
Transformasi penuh selama pelatihan, tetapi transformasi level instance selama prediksi . Dalam skenario ini, transformasi itu stateful, karena mereka menggunakan beberapa statistik yang telah dikomputasi untuk melakukan transformasi. Selama pelatihan, Anda menganalisis seluruh badan data pelatihan untuk menghitung jumlah seperti minimum, maksimum, rata -rata, dan varian untuk mengubah data pelatihan, data evaluasi, dan data baru pada waktu prediksi.
Misalnya, untuk menormalkan fitur numerik untuk pelatihan, Anda menghitung rata -rata (μ) dan standar deviasi (σ) di seluruh data pelatihan. Perhitungan ini disebut operasi full-pass (atau analisis ). Saat Anda melayani model untuk prediksi, nilai titik data baru dinormalisasi untuk menghindari kemiringan pelayanan. Oleh karena itu, nilai μ dan σ yang dihitung selama pelatihan digunakan untuk menyesuaikan nilai fitur, yang merupakan operasi tingkat instance sederhana berikut:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Transformasi penuh termasuk yang berikut:
- MinMax Scaling Fitur Numerik Menggunakan MIN dan MAX Dihitung dari Dataset Pelatihan.
- Fitur numerik penskalaan standar (normalisasi z-skor) menggunakan μ dan σ yang dihitung pada dataset pelatihan.
- Fitur numerik bucketisasi menggunakan kuantil.
- Menghambat nilai yang hilang menggunakan median (fitur numerik) atau mode (fitur kategorikal).
- Konversi string (nilai nominal) ke bilangan bulat (indeks) dengan mengekstraksi semua nilai yang berbeda (kosa kata) dari fitur kategori input.
- Menghitung terjadinya istilah (nilai fitur) di semua dokumen (instance) untuk menghitung untuk TF-IDF.
- Menghitung PCA fitur input untuk memproyeksikan data menjadi ruang dimensi yang lebih rendah (dengan fitur yang bergantung secara linier).
Anda hanya harus menggunakan data pelatihan untuk menghitung statistik seperti μ, σ, min , dan maks . Jika Anda menambahkan data tes dan evaluasi untuk operasi ini, Anda membocorkan informasi dari evaluasi dan data pengujian untuk melatih model. Melakukan hal itu mempengaruhi keandalan hasil tes dan evaluasi. Untuk memastikan bahwa Anda menerapkan transformasi yang konsisten untuk semua set data, Anda menggunakan statistik yang sama yang dihitung dari data pelatihan untuk mengubah data tes dan evaluasi.
Agregasi historis selama pelatihan dan prediksi . Ini melibatkan pembuatan agregasi bisnis, derivasi, dan bendera sebagai sinyal input ke tugas prediksi - misalnya, menciptakan metrik kebaruan, frekuensi, dan moneter (RFM) bagi pelanggan untuk membangun model kecenderungan. Jenis -jenis fitur ini dapat dikomputasi dan disimpan di toko fitur yang akan digunakan selama pelatihan model, penilaian batch, dan porsi prediksi online. Anda juga dapat melakukan rekayasa fitur tambahan (misalnya, transformasi dan tuning) ke agregasi ini sebelum pelatihan dan prediksi.
Agregasi historis selama pelatihan, tetapi agregasi real-time selama prediksi . Pendekatan ini melibatkan pembuatan fitur dengan merangkum nilai waktu nyata dari waktu ke waktu. Dalam pendekatan ini, contoh yang akan dikumpulkan didefinisikan melalui klausa jendela temporal. Misalnya, Anda dapat menggunakan pendekatan ini jika Anda ingin melatih model yang memperkirakan waktu perjalanan taksi berdasarkan metrik lalu lintas untuk rute dalam 5 menit terakhir, dalam 10 menit terakhir, dalam 30 menit terakhir, dan di lainnya interval. Anda juga dapat menggunakan pendekatan ini untuk memprediksi kegagalan bagian mesin berdasarkan rata -rata bergerak dari nilai suhu dan getaran yang dihitung selama 3 menit terakhir. Meskipun agregasi ini dapat disiapkan secara offline untuk pelatihan, mereka dihitung secara real time dari aliran data selama melayani.
Lebih tepatnya, ketika Anda menyiapkan data pelatihan, jika nilai agregat tidak ada dalam data mentah, nilainya dibuat selama fase rekayasa data. Data mentah biasanya disimpan dalam database dengan format
(entity, timestamp, value). Dalam contoh sebelumnya,entityadalah pengidentifikasi segmen rute untuk rute taksi dan pengidentifikasi bagian mesin untuk kegagalan mesin. Anda dapat menggunakan operasi windowing untuk menghitung(entity, time_index, aggregated_value_over_time_window)dan menggunakan fitur agregasi sebagai input untuk pelatihan model Anda.Ketika model untuk prediksi real-time (online) dilayani, model mengharapkan fitur yang berasal dari nilai agregat sebagai input. Oleh karena itu, Anda dapat menggunakan teknologi pemrosesan aliran seperti Apache Beam untuk menghitung agregasi dari titik data real-time yang dialirkan ke sistem Anda. Teknologi pemrosesan aliran agregat data real-time berdasarkan waktu Windows saat titik data baru tiba. Anda juga dapat melakukan rekayasa fitur tambahan (misalnya, transformasi dan tuning) ke agregasi ini sebelum pelatihan dan prediksi.
Pipa ML di Google Cloud
Bagian ini membahas komponen inti dari pipa ujung ke ujung yang khas untuk melatih dan melayani model ML TensorFlow di Google Cloud menggunakan layanan terkelola. Ini juga membahas di mana Anda dapat menerapkan berbagai kategori operasi preprocessing data, dan tantangan umum yang mungkin Anda hadapi ketika Anda menerapkan transformasi tersebut. Bagian How.Transform Works menunjukkan bagaimana TensorFlow Transform Library membantu untuk mengatasi tantangan ini.
Arsitektur tingkat tinggi
Diagram berikut, Gambar 2, menunjukkan arsitektur tingkat tinggi dari pipa ML yang khas untuk melatih dan melayani model TensorFlow. Label A, B, dan C dalam diagram merujuk ke berbagai tempat di dalam pipa tempat preprocessing data dapat terjadi. Rincian tentang langkah -langkah ini disediakan di bagian berikut.
Pipa terdiri dari langkah -langkah berikut:
- Setelah data mentah diimpor, data tabel disimpan di BigQuery, dan data lainnya seperti gambar, audio, dan video, disimpan dalam penyimpanan cloud. Bagian kedua dari seri ini menggunakan data tabel yang disimpan di BigQuery sebagai contoh.
- Rekayasa data (persiapan) dan rekayasa fitur dieksekusi pada skala menggunakan DataFlow. Eksekusi ini menghasilkan pelatihan, evaluasi, dan set tes siap-ML yang disimpan dalam penyimpanan cloud. Idealnya, kumpulan data ini disimpan sebagai file Tfrecord , yang merupakan format yang dioptimalkan untuk perhitungan TensorFlow.
- Paket TensorFlow Model Trainer diserahkan ke Vertex AI Training, yang menggunakan data yang diproses dari langkah -langkah sebelumnya untuk melatih model. Output dari langkah ini adalah TensorFlow SavedModel yang terlatih yang diekspor ke penyimpanan cloud.
- Model TensorFlow terlatih digunakan untuk prediksi Vertex AI sebagai layanan yang memiliki API REST sehingga dapat digunakan untuk prediksi online. Model yang sama juga dapat digunakan untuk pekerjaan prediksi batch.
- Setelah model digunakan sebagai API REST, aplikasi klien dan sistem internal dapat memohon API dengan mengirim permintaan dengan beberapa titik data, dan menerima tanggapan dari model dengan prediksi.
- Untuk mengatur dan mengotomatisasi pipa ini, Anda dapat menggunakan pipa Vertex AI sebagai penjadwal untuk memohon persiapan data, pelatihan model, dan langkah -langkah penyebaran model.
Anda juga dapat menggunakan toko fitur Vertex AI untuk menyimpan fitur input untuk membuat prediksi. Misalnya, Anda dapat secara berkala membuat fitur rekayasa dari data mentah terbaru dan menyimpannya di toko fitur Vertex AI. Aplikasi klien mengambil fitur input yang diperlukan dari toko fitur Vertex AI dan mengirimkannya ke model untuk menerima prediksi.
Di mana melakukan preprocessing
Pada Gambar 2, label A, B, dan C menunjukkan bahwa operasi preprocessing data dapat terjadi di BigQuery, Dataflow, atau TensorFlow. Bagian berikut menjelaskan cara kerja masing -masing opsi ini.
Opsi A: BigQuery
Biasanya, logika diimplementasikan di BigQuery untuk operasi berikut:
- Pengambilan sampel: Memilih secara acak subset dari data.
- Penyaringan: Menghapus instance yang tidak relevan atau tidak valid.
- Partisi: Memecah data untuk menghasilkan pelatihan, evaluasi, dan set tes.
BigQuery SQL Script dapat digunakan sebagai permintaan sumber untuk pipa preprocessing dataflow, yang merupakan langkah pemrosesan data pada Gambar 2. Misalnya, jika suatu sistem digunakan di Kanada, dan gudang data memiliki transaksi dari seluruh dunia, memfilter ke Dapatkan data pelatihan khusus Kanada paling baik dilakukan di BigQuery. Rekayasa fitur di BigQuery sederhana dan dapat diskalakan, dan mendukung penerapan level instance dan agregasi historis transformasi fitur.
Namun, kami menyarankan Anda menggunakan BigQuery untuk rekayasa fitur hanya jika Anda menggunakan model Anda untuk prediksi batch (mencetak), atau jika fitur -fitur tersebut dikomputasi di BigQuery, tetapi disimpan di toko fitur AI Vertex untuk digunakan selama prediksi online. Jika Anda berencana untuk menggunakan model untuk prediksi online, dan jika Anda tidak memiliki fitur rekayasa di toko fitur online, Anda harus mereplikasi operasi preprocessing SQL untuk mengubah titik data mentah yang dihasilkan oleh sistem lain. Dengan kata lain, Anda perlu mengimplementasikan logika dua kali: satu kali di SQL untuk preprocess pelatihan data di BigQuery, dan yang kedua kalinya dalam logika aplikasi yang mengkonsumsi model untuk preprocess poin data online untuk prediksi.
Misalnya, jika aplikasi klien Anda ditulis di Java, Anda perlu mengimplementasikan logika di Java. Hal ini dapat menimbulkan kesalahan karena perbedaan implementasi, seperti yang dijelaskan dalam bagian miring pelatihan dari tantangan preprocessing nanti dalam dokumen ini. Ini juga ekstra overhead untuk mempertahankan dua implementasi yang berbeda. Setiap kali Anda mengubah logika di SQL untuk melakukan preprocess data pelatihan, Anda perlu mengubah implementasi Java sesuai dengan data preprocess pada waktu melayani.
Jika Anda menggunakan model Anda hanya untuk prediksi batch (misalnya, menggunakan prediksi batch Vertex AI), dan jika data Anda untuk penilaian bersumber dari BigQuery, Anda dapat mengimplementasikan operasi preprocessing ini sebagai bagian dari skrip SQL BigQuery. Dalam hal ini, Anda dapat menggunakan skrip SQL preprocessing yang sama untuk menyiapkan data pelatihan dan penilaian.
Transformasi stateful penuh-pass tidak cocok untuk implementasi di BigQuery. Jika Anda menggunakan BigQuery untuk transformasi penuh, Anda memerlukan tabel tambahan untuk menyimpan jumlah yang dibutuhkan oleh transformasi stateful, seperti cara dan varian untuk skala fitur numerik. Lebih lanjut, implementasi transformasi penuh menggunakan SQL pada BigQuery menciptakan peningkatan kompleksitas dalam skrip SQL, dan menciptakan ketergantungan yang rumit antara pelatihan dan skor skrip SQL.
Opsi B: Dataflow
Seperti yang ditunjukkan pada Gambar 2, Anda dapat mengimplementasikan operasi preprocessing yang mahal secara komputasi di balok Apache, dan menjalankannya pada skala menggunakan dataflow. DataFlow adalah layanan autoscaling yang dikelola sepenuhnya untuk pemrosesan data batch dan streaming. Saat Anda menggunakan DataFlow, Anda juga dapat menggunakan perpustakaan khusus eksternal untuk pemrosesan data, tidak seperti BigQuery.
DataFlow dapat melakukan transformasi tingkat instance, dan transformasi fitur agregasi historis dan real-time. Secara khusus, jika model ML Anda mengharapkan fitur input seperti total_number_of_clicks_last_90sec , fungsi windowing berkas Apache dapat menghitung fitur-fitur ini berdasarkan agregasi nilai-nilai waktu jendela waktu real-time (streaming) (misalnya, klik peristiwa). Dalam diskusi sebelumnya tentang granularitas transformasi , ini disebut sebagai "agregasi historis selama pelatihan, tetapi agregasi real-time selama prediksi."
Diagram berikut, Gambar 3, menunjukkan peran Dataflow dalam memproses data aliran untuk prediksi hampir real-time.
Seperti yang ditunjukkan pada Gambar 3, selama pemrosesan, peristiwa yang disebut titik data dicerna ke pub/sub . DataFlow mengkonsumsi titik data ini, menghitung fitur berdasarkan agregat dari waktu ke waktu, dan kemudian memanggil API model ML yang digunakan untuk prediksi. Prediksi kemudian dikirim ke pub/sub antrian keluar. Dari pub/sub, prediksi dapat dikonsumsi oleh sistem hilir seperti pemantauan atau kontrol, atau mereka dapat didorong kembali (misalnya, sebagai pemberitahuan) ke klien yang meminta asli. Prediksi juga dapat disimpan di penyimpanan data latensi rendah seperti Cloud BigTable untuk pengambilan real-time. Cloud BigTable juga dapat digunakan untuk menumpuk dan menyimpan agregasi real-time ini sehingga mereka dapat dicari saat dibutuhkan untuk prediksi.
Implementasi balok Apache yang sama dapat digunakan untuk data pelatihan pemrosesan-proses yang berasal dari data datastore offline seperti BigQuery dan stream-proses real-time untuk melayani prediksi online.
Dalam arsitektur khas lainnya, seperti arsitektur yang ditunjukkan pada Gambar 2, aplikasi klien secara langsung memanggil API model yang digunakan untuk prediksi online. Dalam hal ini, jika operasi preprocessing diimplementasikan di DataFlow untuk menyiapkan data pelatihan, operasi tidak diterapkan pada data prediksi yang langsung ke model. Oleh karena itu, transformasi seperti ini harus diintegrasikan dalam model selama melayani untuk prediksi online.
DataFlow dapat digunakan untuk melakukan transformasi penuh, dengan menghitung statistik yang diperlukan pada skala. Namun, statistik ini perlu disimpan di suatu tempat untuk digunakan selama prediksi untuk mengubah titik data prediksi. Dengan menggunakan perpustakaan TensorFlow Transform ( tf.Transform ), Anda dapat secara langsung menyematkan statistik ini dalam model alih -alih menyimpannya di tempat lain. Pendekatan ini dijelaskan nanti dalam cara kerja TF.Transform .
Opsi C: TensorFlow
Seperti yang ditunjukkan pada Gambar 2, Anda dapat mengimplementasikan operasi preprocessing dan transformasi data dalam model TensorFlow itu sendiri. Seperti yang ditunjukkan pada gambar, preprocessing yang Anda terapkan untuk melatih model TensorFlow menjadi bagian integral dari model ketika model diekspor dan digunakan untuk prediksi. Transformasi dalam model TensorFlow dapat dicapai dengan salah satu cara berikut:
- Menerapkan semua logika transformasi level instance dalam fungsi
input_fndan dalam fungsiserving_fn. Fungsiinput_fnmenyiapkan dataset menggunakantf.data.DatasetAPI untuk melatih model. Fungsiserving_fnmenerima dan menyiapkan data untuk prediksi. - Menempatkan kode transformasi secara langsung dalam model TensorFlow Anda dengan menggunakan lapisan preprocessing keras atau membuat lapisan khusus .
Kode logika transformasi dalam fungsi serving_fn mendefinisikan antarmuka penyajian saveDmodel Anda untuk prediksi online. Jika Anda menerapkan transformasi yang sama yang digunakan untuk menyiapkan data pelatihan dalam kode logika transformasi dari fungsi serving_fn , ini memastikan bahwa transformasi yang sama diterapkan pada titik data prediksi baru saat dilayani.
Namun, karena model TensorFlow memproses setiap titik data secara independen atau dalam batch kecil, Anda tidak dapat menghitung agregasi dari semua titik data. Akibatnya, transformasi penuh tidak dapat diimplementasikan dalam model TensorFlow Anda.
Tantangan preprocessing
Berikut ini adalah tantangan utama dalam mengimplementasikan preprocessing data:
LINGKARAN PELATIHAN MENYELESAIKAN . Kemiringan pelatihan-pelayanan mengacu pada perbedaan antara efektivitas (kinerja prediktif) selama pelatihan dan selama melayani. Kemiringan ini dapat disebabkan oleh perbedaan antara bagaimana Anda menangani data dalam pelatihan dan pipa yang melayani. Misalnya, jika model Anda dilatih pada fitur yang ditransformasikan secara logaritmik, tetapi disajikan dengan fitur mentah selama porsi, output prediksi mungkin tidak akurat.
Jika transformasi menjadi bagian dari model itu sendiri, ia dapat langsung menangani transformasi tingkat instance, seperti yang dijelaskan sebelumnya dalam opsi C: TensorFlow . Dalam hal ini, antarmuka model yang melayani (fungsi
serving_fn) mengharapkan data mentah, sedangkan model secara internal mengubah data ini sebelum menghitung output. Transformasi sama dengan yang diterapkan pada pelatihan mentah dan titik data prediksi.Transformasi penuh . 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,
maxandminvalues 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.
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_fngraph. Thetransform_fngraph 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_fngraph 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 * | 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.
What's next
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .
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.
Perkenalan
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:
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 interval. 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,entityis 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.
The pipeline consists of the following steps:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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_fnfunction and in theserving_fnfunction. Theinput_fnfunction prepares a dataset using thetf.data.DatasetAPI for training a model. Theserving_fnfunction 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_fnfunction) 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,
maxandminvalues 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.
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_fngraph. Thetransform_fngraph 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_fngraph 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 * | 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.
What's next
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .