דף זה תורגם על ידי Cloud Translation API.

עיבוד מקדים של נתונים עבור ML: אפשרויות והמלצות

מסמך זה הוא הראשון בסדרה בת שני חלקים הבוחנת את הנושא של הנדסת נתונים והנדסת תכונות ללמידת מכונה (ML), תוך התמקדות במשימות למידה מפוקחות. חלק ראשון זה דן בשיטות העבודה המומלצות לעיבוד מוקדם של נתונים בצינור ML ב-Google Cloud. המסמך מתמקד בשימוש ב- TensorFlow ובספריית הקוד הפתוח TensorFlow Transform ( tf.Transform ) כדי להכין נתונים, לאמן את המודל ולשרת את המודל לחיזוי. מסמך זה מדגיש את האתגרים של עיבוד מוקדם של נתונים עבור ML, והוא מתאר את האפשרויות והתרחישים לביצוע טרנספורמציה של נתונים ב-Google Cloud ביעילות.

מסמך זה מניח שאתה מכיר את BigQuery , Dataflow , Vertex AI ו- TensorFlow Keras API.

המסמך השני, עיבוד מקדים של נתונים עבור ML עם Google Cloud , מספק מדריך שלב אחר שלב כיצד ליישם צינור tf.Transform .

מָבוֹא

ML עוזר לך למצוא באופן אוטומטי דפוסים מורכבים ועשויים שימושיים בנתונים. דפוסים אלה מתמצים במודל ML שניתן להשתמש בו בנקודות נתונים חדשות - תהליך שנקרא ביצוע חיזויים או ביצוע הסקת מסקנות .

בניית מודל ML היא תהליך רב-שלבי. כל שלב מציג אתגרים טכניים ורעיוניים משלו. סדרה זו בת שני חלקים מתמקדת במשימות למידה מפוקחות ובתהליך של בחירה, טרנספורמציה והגדלה של נתוני המקור כדי ליצור אותות חזויים רבי עוצמה למשתנה היעד. פעולות אלו משלבות ידע בתחום עם טכניקות של מדעי נתונים. הפעולות הן המהות של הנדסת תכונות .

גודלם של מערכי אימון עבור מודלים של ML בעולם האמיתי יכול בקלות להיות שווה או גדול מטרה-בייט אחד (TB). לכן, אתה צריך מסגרות עיבוד נתונים בקנה מידה גדול על מנת לעבד מערכי נתונים אלה ביעילות ובחלוקה. כאשר אתה משתמש במודל ML כדי ליצור תחזיות, עליך להחיל את אותן טרנספורמציות שבהן השתמשת עבור נתוני האימון בנקודות הנתונים החדשות. על ידי יישום אותן טרנספורמציות, אתה מציג את מערך הנתונים החי למודל ML כפי שהמודל מצפה לו.

מסמך זה דן באתגרים הללו עבור רמות שונות של פירוט של פעולות הנדסת תכונה: צבירות ברמת מופע, מעבר מלא וחלון זמן. מסמך זה מתאר גם את האפשרויות והתרחישים לביצוע שינוי נתונים עבור ML ב-Google Cloud.

מסמך זה מספק גם סקירה כללית של TensorFlow Transform ( tf.Transform ), ספרייה עבור TensorFlow המאפשרת לך להגדיר גם טרנספורמציה של נתונים ברמת המופע וגם במעבר מלא באמצעות צינורות עיבוד מקדים של נתונים. צינורות אלה מבוצעים עם Apache Beam , והם יוצרים חפצים המאפשרים לך להחיל את אותן טרנספורמציות במהלך חיזוי כמו בעת הגשת המודל.

עיבוד מוקדם של נתונים עבור ML

סעיף זה מציג פעולות עיבוד מוקדם של נתונים ושלבי מוכנות נתונים. הוא גם דן בסוגי פעולות העיבוד המקדים ובפירוט שלהן.

הנדסת נתונים בהשוואה להנדסת תכונות

עיבוד מוקדם של הנתונים עבור ML כרוך הן בהנדסת נתונים והן בהנדסת תכונות. הנדסת נתונים היא תהליך המרת נתונים גולמיים לנתונים מוכנים . לאחר מכן הנדסת תכונות מכווננת את הנתונים המוכנים כדי ליצור את התכונות הצפויות על ידי מודל ה-ML. למונחים אלה יש את המשמעויות הבאות:

נתונים גולמיים (או רק נתונים ): הנתונים בצורת המקור שלהם, ללא כל הכנה מוקדמת ל-ML. בהקשר זה, הנתונים עשויים להיות בצורתם הגולמית (באגם נתונים) או בצורה שעברה טרנספורמציה (במחסן נתונים). ייתכן שנתונים שעברו שינוי שנמצאים במחסן נתונים הומרו מהצורה הגולמית המקורית שלהם כדי לשמש לניתוח. עם זאת, בהקשר זה, נתונים גולמיים פירושם שהנתונים לא הוכנו במיוחד עבור משימת ה-ML שלך. נתונים נחשבים גם לנתונים גולמיים אם הם נשלחים ממערכות סטרימינג שבסופו של דבר מתקשרות למודלים של ML לצורך תחזיות.
נתונים מוכנים: מערך הנתונים בטופס מוכן למשימת ה-ML שלך: מקורות נתונים נותחו, הצטרפו והוכנסו לטופס טבלה. נתונים מוכנים מצטברים ומסוכמים לפי הפירוט הנכון - לדוגמה, כל שורה במערך הנתונים מייצגת לקוח ייחודי, וכל עמודה מייצגת מידע מסכם עבור הלקוח, כמו סך כל ההוצאות בששת השבועות האחרונים. בטבלת נתונים שהוכנה, עמודות לא רלוונטיות נשמטו ורשומות לא חוקיות סוננו. עבור משימות למידה בפיקוח, תכונת היעד קיימת.
תכונות מהונדסות: מערך הנתונים עם התכונות המכווננות הצפויות על ידי המודל - כלומר, תכונות שנוצרות על ידי ביצוע פעולות מסוימות ספציפיות ל-ML בעמודות במערך הנתונים המוכן, ויצירת תכונות חדשות עבור המודל שלך במהלך אימון וחיזוי, כפי שמתואר בהמשך בפעולות עיבוד מקדים . דוגמאות לפעולות אלו כוללות שינוי קנה מידה של עמודות מספריות לערך שבין 0 ל-1, ערכי חיתוך ותכונות קטגוריות בקידוד חם אחד .

התרשים הבא, איור 1, מציג את השלבים הכרוכים בהכנת נתונים מעובדים מראש:

דיאגרמת זרימה המציגה נתונים גולמיים העוברים לנתונים מוכנים העוברים למאפיינים מהונדסים. — **איור 1.** זרימת הנתונים מנתונים גולמיים לנתונים מוכנים למאפיינים מהונדסים ועד למידת מכונה.

בפועל, נתונים מאותו מקור נמצאים לרוב בשלבי מוכנות שונים. לדוגמה, שדה מטבלה במחסן הנתונים שלך עשוי לשמש ישירות כתכונה מהונדסת. במקביל, ייתכן ששדה אחר באותה טבלה יצטרך לעבור טרנספורמציות לפני שהוא יהפוך לתכונה מהונדסת. באופן דומה, הנדסת נתונים ופעולות הנדסת תכונות עשויות להיות משולבות באותו שלב עיבוד נתונים מראש.

פעולות עיבוד מקדים

עיבוד מקדים של נתונים כולל מספר פעולות. כל פעולה נועדה לעזור ל-ML לבנות מודלים חיזויים טובים יותר. הפרטים של פעולות עיבוד מקדים אלו נמצאים מחוץ לתחום של מסמך זה, אך חלק מהפעולות מתוארות בקצרה בסעיף זה.

עבור נתונים מובנים, פעולות עיבוד מקדים של נתונים כוללות את הדברים הבאים:

ניקוי נתונים: הסרה או תיקון של רשומות שיש בהן ערכים פגומים או לא חוקיים מנתונים גולמיים, והסרת רשומות שחסרות בהן מספר רב של עמודות.
בחירת מופעים ומחיצות: בחירת נקודות נתונים ממערך הקלט ליצירת הדרכה, הערכה (אימות) וערכות בדיקה . תהליך זה כולל טכניקות לדגימה אקראית שניתן לחזור עליה, דגימת יתר של מחלקות מיעוט וחלוקה מרובדת.
כוונון תכונה: שיפור האיכות של תכונה עבור ML, הכוללת קנה מידה ונימול של ערכים מספריים, זקיפת ערכים חסרים, חיתוך חריגים והתאמת ערכים בעלי התפלגות מוטות.
טרנספורמציה של תכונה: המרת תכונה מספרית לתכונה קטגורית (באמצעות bucketization ), והמרת מאפיינים קטגוריים לייצוג מספרי (באמצעות קידוד חם אחד, למידה עם ספירות , הטמעות תכונות דלילות וכו'). דגמים מסוימים עובדים רק עם תכונות מספריות או קטגוריות, בעוד שאחרים יכולים להתמודד עם תכונות מסוג מעורב. גם כאשר מודלים מטפלים בשני הסוגים, הם יכולים להפיק תועלת מייצוגים שונים (מספריים וקטגוריים) של אותה תכונה.
חילוץ תכונות: צמצום מספר התכונות על ידי יצירת ייצוגי נתונים במימד נמוך יותר ועוצמתיים יותר באמצעות טכניקות כגון PCA , חילוץ הטבעה ו- hashing .
בחירת תכונה: בחירת תת-קבוצה של תכונות הקלט לאימון המודל, והתעלמות מהלא רלוונטיות או המיותרות, תוך שימוש בשיטות סינון או עטיפה . בחירת תכונות יכולה גם לכלול ביטול פשוט של תכונות אם חסרים לתכונות מספר רב של ערכים.
בניית תכונה: יצירת תכונות חדשות באמצעות טכניקות טיפוסיות, כגון התרחבות פולינומית (על ידי שימוש בפונקציות מתמטיות חד-משתניות) או חציית תכונה (כדי ללכוד אינטראקציות בין תכונה). ניתן לבנות תכונות גם באמצעות לוגיקה עסקית מהתחום של מקרה השימוש ב-ML.

כאשר אתה עובד עם נתונים לא מובנים (לדוגמה, תמונות, אודיו או מסמכי טקסט), למידה עמוקה מחליפה הנדסת תכונות מבוססת ידע בתחום על ידי קיפולה לארכיטקטורת המודל. שכבה קונבולוציונית היא מעבד קדם תכונה אוטומטי. בניית ארכיטקטורת המודל הנכונה דורשת ידע אמפירי מסוים של הנתונים. בנוסף, יש צורך בכמות מסוימת של עיבוד מקדים, כגון:

עבור מסמכי טקסט: סטנד ולמטיזציה , חישוב TF-IDF וחילוץ n-gram , בדיקת הטבעת.
לתמונות: גזירה, שינוי גודל, חיתוך, טשטוש גאוס ומסננים קנריים.
עבור כל סוגי הנתונים (כולל טקסט ותמונות): למידה של העברה , שמתייחסת לשכבות הכול חוץ אחרונות של המודל שעבר הכשרה מלאה כשלב הנדסי תכונה.

פירוט עיבוד מוקדם

סעיף זה דן בפירוט של סוגי טרנספורמציות נתונים. זה מראה מדוע פרספקטיבה זו היא קריטית בעת הכנת נקודות נתונים חדשות לתחזיות באמצעות טרנספורמציות המיושמות על נתוני אימון.

ניתן לסווג את פעולות העיבוד המקדים והטרנספורמציה כדלקמן, בהתבסס על פירוט הפעולה:

טרנספורמציות ברמת המופע במהלך אימון וחיזוי . אלו הן טרנספורמציות פשוטות, שבהן נדרשים רק ערכים מאותו מופע עבור הטרנספורמציה. לדוגמה, טרנספורמציות ברמת המופע עשויות לכלול גזירת ערך של תכונה לסף כלשהו, הרחבת תכונה אחרת באופן פולינומי, הכפלת שתי תכונות או השוואה של שתי תכונות ליצירת דגל בוליאני.
טרנספורמציות אלו חייבות להיות מיושמות באופן זהה במהלך אימון וחיזוי, מכיוון שהמודל יוכשר על התכונות שעברו טרנספורמציה, לא על ערכי הקלט הגולמיים. אם הנתונים לא עוברים טרנספורמציה זהה, אז המודל מתנהג בצורה גרועה מכיוון שהוא מוצג עם נתונים שיש להם התפלגות ערכים שהוא לא הוכשר איתם. למידע נוסף, עיין בדיון על הטיית הגשה של הכשרה בסעיף אתגרי עיבוד מוקדם .
טרנספורמציות מלאות במהלך האימון, אך טרנספורמציות ברמת המופע במהלך חיזוי . בתרחיש זה, טרנספורמציות הן מצביות, מכיוון שהן משתמשות בכמה נתונים סטטיסטיים מחושבים מראש כדי לבצע את השינוי. במהלך האימון, אתה מנתח את כל נתוני האימון כדי לחשב כמויות כגון מינימום, מקסימום, ממוצע ושונות להמרת נתוני אימון, נתוני הערכה ונתונים חדשים בזמן חיזוי.
לדוגמה, כדי לנרמל תכונה מספרית לאימון, אתה מחשב את הממוצע שלה (μ) ואת סטיית התקן שלה (σ) על פני כל נתוני האימון. חישוב זה נקרא פעולת מעבר מלא (או ניתוח ). כאשר אתה מגיש את המודל לחיזוי, הערך של נקודת נתונים חדשה מנורמל כדי למנוע הטיית אימון-הגשה. לכן, ערכי μ ו- σ שמחושבים במהלך האימון משמשים להתאמת ערך התכונה, שהוא הפעולה הפשוטה הבאה ברמת המופע :
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
טרנספורמציות מעבר מלא כוללות את הדברים הבאים:
- MinMax קנה מידה של תכונות מספריות תוך שימוש במינימום ומקסימום מחושבים מתוך מערך האימון.
- קנה מידה סטנדרטי (נורמליזציה של ציון z) תכונות מספריות באמצעות μ ו-σ המחושבים על מערך האימון.
- מיזוג תכונות מספריות באמצעות קוונטילים.
- זקיפת ערכים חסרים באמצעות החציון (מאפיינים מספריים) או המצב (מאפיינים קטגוריים).
- המרת מחרוזות (ערכים נומינליים) למספרים שלמים (אינדקסים) על ידי חילוץ כל הערכים (אוצר המילים) המובחנים של תכונה קטגורית קלט.
- ספירת התרחשות של מונח (ערך תכונה) בכל המסמכים (מופעים) לחישוב עבור TF-IDF.
- חישוב ה-PCA של תכונות הקלט כדי להקרין את הנתונים לתוך מרחב ממדי נמוך יותר (עם תכונות תלויות ליניארית).
עליך להשתמש רק בנתוני האימון כדי לחשב נתונים סטטיסטיים כמו μ, σ, min ומקסימום . אם אתה מוסיף את נתוני הבדיקה וההערכה עבור פעולות אלה, אתה מדליף מידע מנתוני ההערכה והבדיקה כדי להכשיר את המודל. פעולה זו משפיעה על מהימנות הבדיקה ותוצאות ההערכה. כדי להבטיח שאתה מיישם טרנספורמציה עקבית על כל מערכי הנתונים, אתה משתמש באותם נתונים סטטיסטיים המחושבים מנתוני ההדרכה כדי לשנות את נתוני הבדיקה וההערכה.
צבירות היסטוריות במהלך אימון וחיזוי . זה כרוך ביצירת אגרגציות עסקיות, גזירות ודגלים כאותות קלט למשימת החיזוי - לדוגמה, יצירת מדדים של עדכניות, תדירות ומוניטרית (RFM) עבור לקוחות לבניית מודלים של נטייה. סוגים אלה של תכונות ניתנים לחישוב מראש ולאחסן בחנות תכונות לשימוש במהלך אימון מודלים, ניקוד אצווה והגשת חיזוי מקוונת. אתה יכול גם לבצע הנדסת תכונה נוספת (לדוגמה, טרנספורמציה וכוונון) לצבירה אלו לפני אימון וחיזוי.
צבירות היסטוריות במהלך אימון, אך צבירות בזמן אמת במהלך חיזוי . גישה זו כוללת יצירת תכונה על ידי סיכום ערכי זמן אמת לאורך זמן. בגישה זו, המופעים שיש לצבור מוגדרים באמצעות סעיפי חלון זמניים. לדוגמה, אתה יכול להשתמש בגישה זו אם אתה רוצה להכשיר מודל שמעריך את זמן הנסיעה במונית על סמך מדדי התנועה של המסלול ב-5 הדקות האחרונות, ב-10 הדקות האחרונות, ב-30 הדקות האחרונות, ובשאר מרווחים. אתה יכול גם להשתמש בגישה זו כדי לחזות כשל של חלק מנוע בהתבסס על הממוצע הנע של ערכי הטמפרטורה והרעידות שחושבו במהלך 3 הדקות האחרונות. למרות שניתן להכין צבירות אלו במצב לא מקוון להדרכה, הן מחושבות בזמן אמת מזרם נתונים במהלך ההגשה.
ליתר דיוק, כאשר אתה מכין נתוני אימון, אם הערך המצטבר אינו נמצא בנתונים הגולמיים, הערך נוצר בשלב הנדסת הנתונים. הנתונים הגולמיים מאוחסנים בדרך כלל במסד נתונים בפורמט של (entity, timestamp, value) . בדוגמאות הקודמות, entity היא מזהה מקטע המסלול עבור נתיבי המוניות ומזהה חלק המנוע עבור כשל המנוע. אתה יכול להשתמש בפעולות חלונות לחישוב (entity, time_index, aggregated_value_over_time_window) ולהשתמש בתכונות הצבירה כקלט לאימון המודל שלך.
כאשר המודל לחיזוי בזמן אמת (מקוון) מוגש, המודל מצפה לתכונות הנגזרות מהערכים המצטברים כקלט. לכן, אתה יכול להשתמש בטכנולוגיית עיבוד זרם כמו Apache Beam כדי לחשב את הצבירה מנקודות הנתונים בזמן אמת המוזרמות למערכת שלך. טכנולוגיית עיבוד הזרם אוספת נתונים בזמן אמת על סמך חלונות זמן כאשר נקודות נתונים חדשות מגיעות. אתה יכול גם לבצע הנדסת תכונה נוספת (לדוגמה, טרנספורמציה וכוונון) לצבירה אלו לפני אימון וחיזוי.

צינור ML ב-Google Cloud

סעיף זה דן במרכיבי הליבה של צינור טיפוסי מקצה לקצה להכשרה ושירות של מודלים של TensorFlow ML ב-Google Cloud באמצעות שירותים מנוהלים. זה גם דן היכן אתה יכול ליישם קטגוריות שונות של פעולות עיבוד מוקדם של נתונים, ואתגרים נפוצים שאתה עלול להתמודד איתם כאשר אתה מיישם טרנספורמציות כאלה. החלק כיצד tf.Transform עובד מראה כיצד ספריית TensorFlow Transform עוזרת להתמודד עם אתגרים אלו.

ארכיטקטורה ברמה גבוהה

התרשים הבא, איור 2, מציג ארכיטקטורה ברמה גבוהה של צינור ML טיפוסי לאימון והגשה של מודלים של TensorFlow. התוויות A, B ו-C בתרשים מתייחסות למקומות השונים בצנרת שבהם יכול להתבצע עיבוד מקדים של נתונים. פרטים על שלבים אלה מסופקים בסעיף הבא.

דיאגרמת אדריכלות המציגה שלבים לעיבוד נתונים. — **איור 2.** ארכיטקטורה ברמה גבוהה להדרכה והגשה ב-ML ב-Google Cloud.

הצינור מורכב מהשלבים הבאים:

לאחר ייבוא נתונים גולמיים, נתונים טבלאיים מאוחסנים ב-BigQuery, ונתונים אחרים כמו תמונות, אודיו ווידאו מאוחסנים ב-Cloud Storage. החלק השני של סדרה זו משתמש בנתונים טבלאיים המאוחסנים ב-BigQuery כדוגמה.
הנדסת נתונים (הכנה) והנדסת תכונות מבוצעות בקנה מידה באמצעות Dataflow. ביצוע זה מייצר ערכות הדרכה, הערכה ובדיקות מוכנות ל-ML המאוחסנים ב-Cloud Storage. באופן אידיאלי, מערכי נתונים אלה מאוחסנים כקבצי TFRecord , שהוא הפורמט הממוטב עבור חישובי TensorFlow.
חבילת מאמן מודל TensorFlow מוגשת ל-Vertex AI Training, המשתמשת בנתונים המעובדים מראש מהשלבים הקודמים כדי לאמן את המודל. הפלט של שלב זה הוא TensorFlow SavedModel מאומן שמיוצא ל-Cloud Storage.
מודל TensorFlow המאומן נפרס ל-Vertex AI Prediction כשירות שיש לו REST API כך שניתן להשתמש בו עבור תחזיות מקוונות. אותו מודל יכול לשמש גם עבור עבודות חיזוי אצווה.
לאחר פריסת המודל כ- REST API, אפליקציות לקוח ומערכות פנימיות יכולות להפעיל את ה-API על ידי שליחת בקשות עם כמה נקודות נתונים, וקבלת תגובות מהמודל עם תחזיות.
לתזמור ואוטומציה של צינור זה, אתה יכול להשתמש ב- Vertex AI Pipelines כמתזמן כדי להפעיל את שלבי הכנת הנתונים, אימון המודלים והפריסה של המודל.

אתה יכול גם להשתמש ב-Vertex AI Feature Store כדי לאחסן תכונות קלט כדי לבצע תחזיות. לדוגמה, אתה יכול ליצור מעת לעת תכונות מהונדסות מהנתונים הגולמיים העדכניים ביותר ולאחסן אותם ב-Vertex AI Feature Store. אפליקציות לקוח מביאות את תכונות הקלט הנדרשות מחנות התכונות של Vertex AI ושולחות אותן לדגם כדי לקבל תחזיות.

איפה לעשות עיבוד מקדים

באיור 2, התוויות A, B ו-C מראות שפעולות עיבוד מקדים של נתונים יכולות להתבצע ב-BigQuery, Dataflow או TensorFlow. הסעיפים הבאים מתארים כיצד פועלת כל אחת מהאפשרויות הללו.

אפשרות א': BigQuery

בדרך כלל, לוגיקה מיושמת ב-BigQuery עבור הפעולות הבאות:

דגימה: בחירה אקראית של תת-קבוצה מהנתונים.
סינון: הסרת מופעים לא רלוונטיים או לא חוקיים.
חלוקה: פיצול הנתונים כדי לייצר ערכות הדרכה, הערכה ומבחנים.

ניתן להשתמש בסקריפטים של BigQuery SQL כשאילתת מקור עבור צינור העיבוד המקדים של Dataflow, שהוא שלב עיבוד הנתונים באיור 2. לדוגמה, אם משתמשים במערכת בקנדה, ובמחסן הנתונים יש עסקאות מכל העולם, סינון ל השגת נתוני הדרכה לקנדה בלבד מתבצעת בצורה הטובה ביותר ב-BigQuery. הנדסת תכונות ב-BigQuery היא פשוטה וניתנת להרחבה, ותומכת ביישום טרנספורמציות של תכונות צבירות היסטוריות ברמת המופע.

עם זאת, אנו ממליצים להשתמש ב-BigQuery להנדסת תכונות רק אם אתה משתמש במודל שלך לחיזוי אצווה (ניקוד), או אם התכונות מחושבות מראש ב-BigQuery, אך מאוחסנות ב-Vertex AI Feature Store לשימוש במהלך חיזוי מקוון. אם אתה מתכנן לפרוס את המודל לחיזוי מקוון, ואם אין לך את התכונה המהונדסת בחנות תכונות מקוונת, עליך לשכפל את פעולות העיבוד המקדים של SQL כדי לשנות את נקודות הנתונים הגולמיות שמערכות אחרות מייצרות. במילים אחרות, אתה צריך ליישם את ההיגיון פעמיים: פעם אחת ב-SQL כדי לעבד מראש נתוני אימון ב-BigQuery, ופעם שנייה בלוגיקה של האפליקציה שצורכת את המודל כדי לעבד מראש נקודות נתונים מקוונות לצורך חיזוי.

לדוגמה, אם אפליקציית הלקוח שלך כתובה ב-Java, עליך ליישם מחדש את ההיגיון ב-Java. זה יכול להציג שגיאות עקב אי-התאמות ביישום, כפי שמתואר בסעיף הטיית ההדרכה של אתגרי עיבוד מוקדם בהמשך מסמך זה. זה גם תוספת תקורה כדי לשמור על שני יישומים שונים. בכל פעם שאתה משנה את ההיגיון ב-SQL כדי לעבד מראש את נתוני האימון, עליך לשנות את יישום Java בהתאם לנתוני עיבוד מוקדם בזמן ההגשה.

אם אתה משתמש במודל שלך רק לחיזוי אצווה (לדוגמה, באמצעות חיזוי אצווה של Vertex AI), ואם הנתונים שלך לניקוד מקורם ב-BigQuery, תוכל ליישם את פעולות העיבוד המקדים האלה כחלק מהסקריפט של BigQuery SQL. במקרה זה, תוכל להשתמש באותו סקריפט SQL לעיבוד מקדים כדי להכין נתוני אימון וניקוד כאחד.

טרנספורמציות סטטיסטיות במעבר מלא אינן מתאימות ליישום ב-BigQuery. אם אתה משתמש ב-BigQuery עבור טרנספורמציות של מעבר מלא, אתה זקוק לטבלאות עזר לאחסון כמויות הדרושות לשינויים סטטיסטיים, כגון אמצעים ושונות לשינוי קנה מידה של תכונות מספריות. יתרה מכך, הטמעה של טרנספורמציות מעבר מלא באמצעות SQL ב-BigQuery יוצרת מורכבות מוגברת בסקריפטים של SQL, ויוצרת תלות מורכבת בין האימון לתסריטי ה-SQL הניקוד.

אפשרות ב': זרימת נתונים

כפי שמוצג באיור 2, אתה יכול ליישם פעולות עיבוד מקדים יקרות מבחינה חישובית ב-Apache Beam, ולהפעיל אותן בקנה מידה באמצעות Dataflow. Dataflow הוא שירות קנה מידה אוטומטי מנוהל במלואו לעיבוד נתונים אצווה וזרם. כאשר אתה משתמש ב-Dataflow, אתה יכול גם להשתמש בספריות מיוחדות חיצוניות לעיבוד נתונים, בניגוד ל-BigQuery.

Dataflow יכול לבצע טרנספורמציות ברמת המופע, ושינויים היסטוריים ובזמן אמת של תכונות צבירה. בפרט, אם דגמי ה-ML שלך מצפים לתכונת קלט כמו total_number_of_clicks_last_90sec , פונקציות החלונות של Apache Beam יכולות לחשב תכונות אלו על סמך צבירת ערכי חלונות זמן של נתוני אירועים בזמן אמת (הזרמה) (לדוגמה, אירועי קליקים). בדיון המוקדם יותר בפירוט של טרנספורמציות , זה כונה "הצטברויות היסטוריות במהלך אימון, אבל צבירות בזמן אמת במהלך חיזוי."

התרשים הבא, איור 3, מציג את התפקיד של Dataflow בעיבוד נתוני זרמים עבור תחזיות כמעט בזמן אמת.

ארכיטקטורה לשימוש בנתוני זרמים לצורך חיזוי. — **איור 3.** ארכיטקטורה ברמה גבוהה באמצעות נתוני זרמים לחיזוי ב-Dataflow.

כפי שמוצג באיור 3, במהלך העיבוד, אירועים הנקראים נקודות נתונים נקלטים ב- Pub/Sub . Dataflow צורך את נקודות הנתונים הללו, מחשב תכונות על סמך אגרגטים לאורך זמן, ולאחר מכן קורא ל-API של מודל ML הפרוס לצורך תחזיות. תחזיות נשלחות לאחר מכן לתור Pub/Sub יוצא. מ-Pub/Sub, ניתן לצרוך תחזיות על ידי מערכות במורד הזרם כמו ניטור או בקרה, או שניתן לדחות אותן אחורה (לדוגמה, כהתראות) ללקוח המבקש המקורי. ניתן לאחסן תחזיות גם במאגר נתונים עם אחזור נמוך כמו Cloud Bigtable לאחזור בזמן אמת. ניתן להשתמש ב-Cloud Bigtable גם כדי לצבור ולאחסן צבירות אלו בזמן אמת, כך שניתן יהיה לחפש אותן בעת הצורך לצורך חיזוי.

ניתן להשתמש באותו יישום Apache Beam לעיבוד אצווה של נתוני אימון המגיעים מחנות נתונים לא מקוונת כמו BigQuery ולעיבוד נתונים בזמן אמת בזרימה לצורך הגשת תחזיות מקוונות.

בארכיטקטורות טיפוסיות אחרות, כמו הארכיטקטורה המוצגת באיור 2, אפליקציית הלקוח קוראת ישירות ל-API של המודל הפרוס לצורך תחזיות מקוונות. במקרה זה, אם מיושמות פעולות עיבוד מקדים ב-Dataflow כדי להכין את נתוני האימון, הפעולות אינן מיושמות על נתוני החיזוי שמגיעים ישירות למודל. לכן, טרנספורמציות כמו אלה צריכות להיות משולבות במודל במהלך ההגשה לתחזיות מקוונות.

ניתן להשתמש בזרימת נתונים כדי לבצע טרנספורמציה מלאה, על ידי חישוב הסטטיסטיקה הנדרשת בקנה מידה. עם זאת, יש לאחסן את הנתונים הסטטיסטיים הללו במקום כלשהו כדי להשתמש בהם במהלך חיזוי כדי להפוך נקודות נתוני חיזוי. על ידי שימוש בספריית TensorFlow Transform ( tf.Transform ), אתה יכול להטמיע ישירות את הנתונים הסטטיסטיים האלה במודל במקום לאחסן אותם במקום אחר. גישה זו מוסברת בהמשך כיצד tf.Transform עובד .

אפשרות ג': TensorFlow

כפי שמוצג באיור 2, אתה יכול ליישם פעולות עיבוד מוקדם ושינוי נתונים במודל TensorFlow עצמו. כפי שמוצג באיור, העיבוד המקדים שאתה מיישם עבור אימון מודל TensorFlow הופך לחלק בלתי נפרד מהמודל כאשר המודל מיוצא ונפרס עבור חיזויים. ניתן לבצע טרנספורמציות במודל TensorFlow באחת מהדרכים הבאות:

הטמעת כל לוגיקת הטרנספורמציה ברמת המופע בפונקציה input_fn ובפונקציה serving_fn . הפונקציה input_fn מכינה מערך נתונים באמצעות tf.data.Dataset API להכשרת מודל. הפונקציה serving_fn מקבלת ומכינה את הנתונים לתחזיות.
הכנסת קוד השינוי ישירות למודל TensorFlow שלך על ידי שימוש בשכבות עיבוד מקדמות של Keras או יצירת שכבות מותאמות אישית .

קוד לוגיית הטרנספורמציה בפונקציה serving_fn מגדיר את ממשק ההגשה של SavedModel שלך לחיזוי מקוון. אם תטמיע את אותן טרנספורמציות ששימשו להכנת נתוני אימון בקוד לוגיית הטרנספורמציה של הפונקציה serving_fn , זה מבטיח שאותן טרנספורמציות מיושמות על נקודות נתוני חיזוי חדשות כאשר הן מוצגות.

עם זאת, מכיוון שמודל TensorFlow מעבד כל נקודת נתונים באופן עצמאי או באצווה קטנה, אינך יכול לחשב צבירות מכל נקודות הנתונים. כתוצאה מכך, לא ניתן ליישם טרנספורמציות של מעבר מלא במודל TensorFlow שלך.

אתגרי עיבוד מוקדם

להלן האתגרים העיקריים של הטמעת עיבוד מקדים של נתונים:

הטיה להגשה הכשרה . הטיית אימון-הגשה מתייחסת להבדל בין אפקטיביות (ביצועים חזויים) במהלך האימון ובמהלך ההגשה. הטיה זו יכולה להיגרם מאי התאמה בין אופן הטיפול בנתונים בהדרכה לבין צינורות ההגשה. לדוגמה, אם המודל שלך מאומן על תכונה שעברה טרנספורמציה לוגריתמית, אבל הוא מוצג עם התכונה הגולמית במהלך ההגשה, ייתכן שפלט החיזוי לא יהיה מדויק.
אם הטרנספורמציות הופכות לחלק מהמודל עצמו, זה יכול להיות פשוט לטפל בטרנספורמציות ברמת המופע, כפי שתואר קודם לכן באפשרות C: TensorFlow . במקרה זה, ממשק הגשת המודל (הפונקציה serving_fn ) מצפה לנתונים גולמיים, בעוד שהמודל הופך את הנתונים הללו באופן פנימי לפני חישוב הפלט. הטרנספורמציות זהות לאלו שהוחלו על נקודות האימון הגולמיות והניבוי.
טרנספורמציות במעבר מלא . אינך יכול ליישם טרנספורמציות של מעבר מלא כגון שינוי קנה מידה ונורמליזציה במודל TensorFlow שלך. בטרנספורמציות של מעבר מלא, יש לחשב כמה נתונים סטטיסטיים (לדוגמה, ערכי max min כדי לשנות את קנה המידה של תכונות מספריות) על נתוני האימון מראש, כמתואר באפשרות ב': זרימת נתונים . לאחר מכן יש לאחסן את הערכים במקום כלשהו כדי להשתמש בהם במהלך הגשת המודל לצורך חיזוי כדי להפוך את נקודות הנתונים הגולמיות החדשות כטרנספורמציות ברמת המופע, מה שמונע הטיית אימון-הגשה. אתה יכול להשתמש בספריית TensorFlow Transform ( tf.Transform ) כדי להטמיע ישירות את הנתונים הסטטיסטיים במודל TensorFlow שלך. גישה זו מוסברת בהמשך כיצד tf.Transform עובד .
הכנת הנתונים מראש ליעילות אימון טובה יותר . הטמעת טרנספורמציות ברמת המופע כחלק מהמודל עשויה לפגוע ביעילות תהליך ההדרכה. השפלה זו מתרחשת מכיוון שאותן טרנספורמציות מוחלות שוב ושוב על אותם נתוני אימון בכל תקופה. תאר לעצמך שיש לך נתוני אימון גולמיים עם 1,000 תכונות, ואתה מיישם שילוב של טרנספורמציות ברמת המופע כדי ליצור 10,000 תכונות. אם אתה מיישם את הטרנספורמציות האלה כחלק מהמודל שלך, ואם אתה מזין את המודל בנתוני האימון הגולמיים, 10,000 הפעולות האלה מיושמות N פעמים בכל מופע, כאשר N הוא מספר העידנים. בנוסף, אם אתה משתמש באקסלרטורים (GPUs או TPUs), הם יושבים בטל בזמן שה-CPU מבצע את הטרנספורמציות האלה, וזה לא שימוש יעיל במאיצים היקרים שלך.
באופן אידיאלי, נתוני האימון עוברים טרנספורמציה לפני האימון, תוך שימוש בטכניקה המתוארת תחת אפשרות ב': זרימת נתונים , שבה 10,000 פעולות השינוי מיושמות פעם אחת בלבד בכל מופע אימון. לאחר מכן מוצגים למודל נתוני האימון שעברו טרנספורמציה. לא מופעלות טרנספורמציות נוספות, והמאיצים עסוקים כל הזמן. בנוסף, השימוש ב-Dataflow עוזר לך לעבד כמויות גדולות של נתונים בקנה מידה, תוך שימוש בשירות מנוהל במלואו.
הכנת נתוני האימון מראש יכולה לשפר את יעילות האימון. עם זאת, הטמעת לוגיקת הטרנספורמציה מחוץ למודל (הגישות המתוארות באופציה א': BigQuery או אפשרות ב': זרימת נתונים ) אינה פותרת את הבעיה של הטיית אימון-הגשה. אלא אם כן אתה מאחסן את התכונה המהונדסת במאגר הפיצ'רים כדי לשמש הן לאימון והן לחיזוי, יש ליישם את לוגיקת הטרנספורמציה במקום כלשהו כדי להחיל אותה על נקודות נתונים חדשות המגיעות לחיזוי, מכיוון שממשק המודל מצפה לנתונים שעברו טרנספורמציה. ספריית TensorFlow Transform ( tf.Transform ) יכולה לעזור לך לטפל בבעיה זו, כמתואר בסעיף הבא.

איך tf.Transform עובד

ספריית tf.Transform שימושית עבור טרנספורמציות הדורשות מעבר מלא. הפלט של ספריית tf.Transform מיוצא כגרף TensorFlow המייצג את היגיון הטרנספורמציה ברמת המופע ואת הנתונים הסטטיסטיים המחושבים מהטרנספורמציות של מעבר מלא, שישמש להדרכה והגשה. שימוש באותו גרף גם לאימון וגם להגשה יכול למנוע הטיה, מכיוון שאותן טרנספורמציות מיושמות בשני השלבים. בנוסף, ספריית tf.Transform יכולה לפעול בקנה מידה בצינור עיבוד אצווה ב-Dataflow כדי להכין את נתוני ההדרכה מראש ולשפר את יעילות ההדרכה.

התרשים הבא, איור 4, מראה כיצד ספריית tf.Transform מעבדת מראש וממירה נתונים לצורך אימון וחיזוי. התהליך מתואר בסעיפים הבאים.

תרשים המציג זרימה מנתונים גולמיים דרך tf.Transform לתחזיות. — **איור 4.** התנהגות של `tf.Transform` לעיבוד מוקדם והמרת נתונים.

שינוי נתוני הכשרה והערכה

אתה מעבד מראש את נתוני האימון הגולמיים באמצעות הטרנספורמציה המיושמת ב- tf.Transform Apache Beam APIs, ומפעיל אותם בקנה מידה ב-Dataflow. העיבוד המקדים מתרחש בשלבים הבאים:

שלב הניתוח: במהלך שלב הניתוח, הנתונים הסטטיסטיים הנדרשים (כגון אמצעים, שונות וכמותיות) עבור טרנספורמציות מצב מחושבים על נתוני האימון עם פעולות מעבר מלא. שלב זה מייצר קבוצה של חפצי טרנספורמציה, כולל גרף transform_fn . הגרף transform_fn הוא גרף TensorFlow שיש לו את לוגיקת הטרנספורמציה כפעולות ברמת המופע. הוא כולל את הנתונים הסטטיסטיים המחושבים בשלב הניתוח כקבועים.
שלב הטרנספורמציה: במהלך שלב הטרנספורמציה, גרף ה- transform_fn מוחל על נתוני האימון הגולמיים, כאשר הנתונים הסטטיסטיים המחושבים משמשים לעיבוד רשומות הנתונים (לדוגמה, לשינוי קנה מידה של עמודות מספריות) בצורה ברמת המופע.

גישה דו-שלבית כמו זו נותנת מענה לאתגר העיבוד המקדים של ביצוע טרנספורמציות במעבר מלא.

כאשר נתוני ההערכה מעובדים מראש, רק פעולות ברמת המופע מוחלות, תוך שימוש בלוגיקה בגרף transform_fn והסטטיסטיקה המחושבת משלב הניתוח בנתוני האימון. במילים אחרות, אינך מנתח את נתוני ההערכה באופן מלא כדי לחשב נתונים סטטיסטיים חדשים, כגון μ ו-σ, כדי לנרמל תכונות מספריות בנתוני הערכה. במקום זאת, אתה משתמש בסטטיסטיקה המחושבת מנתוני האימון כדי לשנות את נתוני ההערכה בצורה ברמת המופע.

נתוני האימון וההערכה שעברו שינוי מוכנים בקנה מידה באמצעות Dataflow, לפני שהם משמשים לאימון המודל. תהליך הכנת נתונים אצווה זה עוסק באתגר העיבוד המקדים של הכנת הנתונים מלפנים לשיפור יעילות האימונים. כפי שמוצג באיור 4, הממשק הפנימי של המודל מצפה לתכונות טרנספורמציה.

צרף טרנספורמציות למודל המיוצא

כאמור, גרף transform_fn המיוצר על ידי צינור tf.Transform מאוחסן כגרף טנסורו מיוצא. הגרף המיוצא מורכב מהיגיון הטרנספורמציה כפעולות ברמת המופע, וכל הסטטיסטיקה המחושבת בטרנספורמציות של מעבר מלא כמתקני גרף. כאשר המודל המאומן מיוצא להגשה, גרף ה- transform_fn מחובר ל- SaveModel כחלק מפונקציית serving_fn שלו.

אמנם הוא משרת את המודל לחיזוי, אך ממשק הגשת המודל מצפה לנקודות נתונים בפורמט הגולמי (כלומר לפני כל טרנספורמציות). עם זאת, הממשק הפנימי של המודל מצפה לנתונים בפורמט הטרנספורמציה.

גרף ה- transform_fn , שהוא כיום חלק מהדגם, מיישם את כל ההיגיון לעיבוד מראש על נקודת הנתונים הנכנסת. הוא משתמש בקבועים המאוחסנים (כמו μ ו- σ כדי לנרמל את התכונות המספריות) בפעולה ברמת המופע במהלך החיזוי. לפיכך, גרף ה- transform_fn ממיר את נקודת הנתונים הגולמית לפורמט הטרנספורמציה. הפורמט הטרנספורמציה הוא מה שצפוי בממשק הפנימי של המודל על מנת לייצר חיזוי, כפי שמוצג באיור 4.

מנגנון זה פותר את האתגר העיבוד המוקדם של השיפוד המשרת את ההדרכה, מכיוון שאותו היגיון (יישום) המשמש להפיכת נתוני ההדרכה וההערכה מיושם כדי להפוך את נקודות הנתונים החדשות במהלך הגשת החיזוי.

סיכום אפשרויות עיבוד מראש

הטבלה הבאה מסכמת את אפשרויות העיבוד המקדימות של הנתונים עליהם דיבר מסמך זה. בטבלה, "N/A" מייצג "לא ישים".

אפשרות לעיבוד מקדים של נתונים

אפשרות לעיבוד מקדים של נתונים	ברמת מופע (טרנספורמציות חסרות מדינה)	מעבר מלא במהלך אימונים ורמת מופע במהלך ההגשה (טרנספורמציות ממלכתיות)	אגרגציות בזמן אמת (חלון) במהלך אימונים והגשה (טרנספורמציות סטרימינג)
Bigquery (SQL)	ניקוד אצווה: אישור - אותו יישום טרנספורמציה מיושם על נתונים במהלך אימונים וניקוד אצווה. חיזוי מקוון: לא מומלץ -אתה יכול לעבד נתוני הדרכה, אך זה מביא לגידול בהדרכה מכיוון שאתה מעבד נתונים משרתים באמצעות כלים שונים.	ניקוד אצווה: לא מומלץ . חיזוי מקוון: לא מומלץ . למרות שאתה יכול להשתמש בסטטיסטיקה המחושבת באמצעות BigQuery למשל טרנספורמציות אצווה/מקוונות ברמה, זה לא קל מכיוון שאתה חייב לתחזק חנות סטטיסטית שתאוכלס במהלך האימונים ולהשתמש בו במהלך החיזוי.	ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת. חיזוי מקוון: לא מומלץ -אתה יכול לעבד נתוני הדרכה, אך זה מביא לגידול בהדרכה מכיוון שאתה מעבד נתונים משרתים באמצעות כלים שונים.
Dataflow (Apache Beam)	ניקוד אצווה: אישור - אותו יישום טרנספורמציה מיושם על נתונים במהלך אימונים וניקוד אצווה. חיזוי מקוון: אישור - אם נתונים בזמן הגשה מגיעים מפאב/תת נצרך על ידי DataFlow. אחרת, מביא לשיפוע לשירות אימונים.	ניקוד אצווה: לא מומלץ . תחזיות מקוונות: לא מומלץ . למרות שאתה יכול להשתמש בסטטיסטיקה המחושבת באמצעות DataFlow למשל טרנספורמציות אצווה/מקוונות ברמה, זה לא קל מכיוון שאתה חייב לשמור על חנות סטטיסטית שתאוכלס במהלך האימונים ולהשתמש בו במהלך החיזוי.	ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת. חיזוי מקוון: בסדר - אותה טרנספורמציה של קרן אפאצ'י מיושמת על נתונים במהלך אימונים (אצווה) והגשה (זרם).
Dataflow (Apache Beam + TFT)	ניקוד אצווה: אישור - אותו יישום טרנספורמציה מיושם על נתונים במהלך אימונים וניקוד אצווה. חיזוי מקוון: מומלץ -זה נמנע מטיפוח לשרת אימונים ומכין נתוני אימונים מלפנים.	ניקוד אצווה: מומלץ . חיזוי מקוון: מומלץ . שני השימושים מומלצים מכיוון שהגיוני טרנספורמציה וסטטיסטיקה ממוחשבת במהלך האימונים מאוחסנים כגרף זרימת טנסור המחובר למודל המיוצא להגשה.	ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת. חיזוי מקוון: בסדר - אותה טרנספורמציה של קרן אפאצ'י מיושמת על נתונים במהלך אימונים (אצווה) והגשה (זרם).
Tensorflow ^* ( `input_fn` & `serving_fn` )	ניקוד אצווה: לא מומלץ . חיזוי מקוון: לא מומלץ . ליעילות אימונים בשני המקרים, עדיף להכין את נתוני האימונים מלפנים.	ציון אצווה: לא אפשרי . חיזוי מקוון: לא אפשרי .	ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת. חיזוי מקוון: לא אפשרי .

ברמת מופע
(טרנספורמציות חסרות מדינה)

מעבר מלא במהלך אימונים ורמת מופע במהלך ההגשה (טרנספורמציות ממלכתיות)

אגרגציות בזמן אמת (חלון) במהלך אימונים והגשה (טרנספורמציות סטרימינג)

Bigquery (SQL)

ניקוד אצווה: אישור - אותו יישום טרנספורמציה מיושם על נתונים במהלך אימונים וניקוד אצווה.

חיזוי מקוון: לא מומלץ -אתה יכול לעבד נתוני הדרכה, אך זה מביא לגידול בהדרכה מכיוון שאתה מעבד נתונים משרתים באמצעות כלים שונים.

ניקוד אצווה: לא מומלץ .

חיזוי מקוון: לא מומלץ .

למרות שאתה יכול להשתמש בסטטיסטיקה המחושבת באמצעות BigQuery למשל טרנספורמציות אצווה/מקוונות ברמה, זה לא קל מכיוון שאתה חייב לתחזק חנות סטטיסטית שתאוכלס במהלך האימונים ולהשתמש בו במהלך החיזוי.

ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת.

Dataflow (Apache Beam)

ניקוד אצווה: אישור - אותו יישום טרנספורמציה מיושם על נתונים במהלך אימונים וניקוד אצווה.

חיזוי מקוון: אישור - אם נתונים בזמן הגשה מגיעים מפאב/תת נצרך על ידי DataFlow. אחרת, מביא לשיפוע לשירות אימונים.

ניקוד אצווה: לא מומלץ .

תחזיות מקוונות: לא מומלץ .

למרות שאתה יכול להשתמש בסטטיסטיקה המחושבת באמצעות DataFlow למשל טרנספורמציות אצווה/מקוונות ברמה, זה לא קל מכיוון שאתה חייב לשמור על חנות סטטיסטית שתאוכלס במהלך האימונים ולהשתמש בו במהלך החיזוי.

ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת.

חיזוי מקוון: בסדר - אותה טרנספורמציה של קרן אפאצ'י מיושמת על נתונים במהלך אימונים (אצווה) והגשה (זרם).

Dataflow (Apache Beam + TFT)

ניקוד אצווה: אישור - אותו יישום טרנספורמציה מיושם על נתונים במהלך אימונים וניקוד אצווה.

חיזוי מקוון: מומלץ -זה נמנע מטיפוח לשרת אימונים ומכין נתוני אימונים מלפנים.

ניקוד אצווה: מומלץ .

חיזוי מקוון: מומלץ .

שני השימושים מומלצים מכיוון שהגיוני טרנספורמציה וסטטיסטיקה ממוחשבת במהלך האימונים מאוחסנים כגרף זרימת טנסור המחובר למודל המיוצא להגשה.

ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת.

חיזוי מקוון: בסדר - אותה טרנספורמציה של קרן אפאצ'י מיושמת על נתונים במהלך אימונים (אצווה) והגשה (זרם).

Tensorflow ^*
( input_fn & serving_fn )

ניקוד אצווה: לא מומלץ .

חיזוי מקוון: לא מומלץ .

ליעילות אימונים בשני המקרים, עדיף להכין את נתוני האימונים מלפנים.

ציון אצווה: לא אפשרי .

חיזוי מקוון: לא אפשרי .

ניקוד אצווה: N/A- אגרים כמו אלה מחושבים על בסיס אירועים בזמן אמת.

חיזוי מקוון: לא אפשרי .

^* עם זרימת Tensor, יש לבצע טרנספורמציות כמו מעבר, הטמעה וקידוד חם אחד בהצהרה כעמודות feature_columns .

מה הלאה

כדי ליישם צינור tf.Transform ולהפעיל אותו באמצעות DataFlow, קרא את החלק השני של סדרה זו, עיבוד מקדים של נתונים עבור ML באמצעות TensorFlow Transform .
קח את ההתמחות בקורסרה ב- ML עם TensorFlow ב- Google Cloud .
למדו על שיטות עבודה מומלצות להנדסת ML בכללי ML .
לקבלת ארכיטקטורות התייחסות נוספות, דיאגרמות ושיטות עבודה מומלצות, חקור את פתרונות הענן של TFX .

מסמך זה הוא הראשון בסדרה דו-חלקית הבוחנת את נושא הנדסת הנתונים והנדסת תכונות למידת מכונה (ML), תוך התמקדות במשימות למידה בפיקוח. חלק ראשון זה דן בשיטות העבודה המומלצות לעיבוד מראש של נתונים בצינור ML ב- Google Cloud. המסמך מתמקד בשימוש ב- TensorFlow ובספריית TensorFlow Tnoverflow ( tf.Transform ) כדי להכין נתונים, לאמן את המודל ולשרת את המודל לחיזוי. מסמך זה מדגיש את האתגרים של עיבוד מראש של נתונים עבור ML, והוא מתאר את האפשרויות והתרחישים לביצוע טרנספורמציה של נתונים ב- Google Cloud ביעילות.

מסמך זה מניח שאתה מכיר את Bigquery , Dataflow , Vertex AI ו- API של Tensorflow Keras .

המסמך השני, עיבוד מקדים של נתונים עבור ML עם Google Cloud , מספק הדרכה שלב אחר שלב כיצד ליישם צינור tf.Transform .

מָבוֹא

ML עוזר לך למצוא אוטומטית דפוסים מורכבים ועלולים להיות שימושיים בנתונים. דפוסים אלה מעובדים במודל ML שניתן להשתמש בו בנקודות נתונים חדשות - תהליך שנקרא ביצוע תחזיות או ביצוע הסקה .

בניית מודל ML הוא תהליך רב שלב. כל שלב מציג אתגרים טכניים ורעיוניים משלו. סדרה דו-חלקית זו מתמקדת במשימות למידה בפיקוח ובתהליך של בחירת, שינוי והגברת נתוני המקור ליצירת אותות חזוי עוצמתיים למשתנה היעד. פעולות אלה משלבות ידע בתחום עם טכניקות מדעי נתונים. הפעולות הן תמצית הנדסת תכונות .

גודל מערכי הנתונים לאימונים עבור דגמי ML בעולם האמיתי יכול בקלות להיות שווה או גדול יותר מ- Terabyte (TB). לכן, אתה זקוק למסגרות עיבוד נתונים בקנה מידה גדול על מנת לעבד מערכי נתונים אלה ביעילות ומפוזרת. כשאתה משתמש במודל ML כדי לבצע תחזיות, עליך ליישם את אותן טרנספורמציות בהן השתמשת לנתוני האימונים על נקודות הנתונים החדשות. על ידי יישום אותן טרנספורמציות, אתה מציג את מערך הנתונים החי על מודל ה- ML באופן שמצפה המודל.

מסמך זה דן באתגרים אלה לרמות שונות של גרגיריות של פעולות הנדסיות תכונות: צבירה של רמת מופע, מעבר מלא וחלל זמן. מסמך זה מתאר גם את האפשרויות והתרחישים לביצוע טרנספורמציה של נתונים עבור ML ב- Google Cloud.

מסמך זה מספק גם סקירה של TensorFlow Transform ( tf.Transform ), ספרייה ל- TensorFlow המאפשרת לך להגדיר גם טרנספורמציה ברמת המופע וגם טרנספורמציה של מעבר מלא באמצעות צינורות עיבוד מקדים של נתונים. צינורות אלה מבוצעים עם קרן אפאצ'י , והם יוצרים חפצים המאפשרים לך ליישם את אותן טרנספורמציות במהלך החיזוי כמו המוגש.

עיבוד מראש של נתונים עבור ML

פרק זה מציג פעולות עיבוד מראש של נתונים ושלבי מוכנות נתונים. הוא דן גם בסוגי פעולות העיבוד המוקדמות ובגרגיריותן.

הנדסת נתונים בהשוואה להנדסת תכונות

עיבוד מראש של הנתונים עבור ML כרוך בהנדסת נתונים וגם בהנדסת תכונות. הנדסת נתונים היא תהליך המרת נתונים גולמיים לנתונים מוכנים . הנדסת תכונות מכוונת את הנתונים המוכנים ליצירת התכונות שצפויות לדגם ML. לתנאים אלה המשמעויות הבאות:

נתונים גולמיים (או סתם נתונים ): הנתונים בצורת המקור שלהם, ללא כל הכנה מוקדמת ל- ML. בהקשר זה, הנתונים עשויים להיות בצורתם הגולמית (באגם נתונים) או בצורה טרנספורמצית (במחסן נתונים). נתונים שהופכים נתונים שנמצאים במחסן נתונים אולי הוסבו מצורתם הגולמית המקורית שישמשו לניתוח. עם זאת, בהקשר זה, נתונים גולמיים פירושם שהנתונים לא הוכנו באופן ספציפי למשימת ה- ML שלך. נתונים נחשבים גם לנתונים גולמיים אם הם נשלחים ממערכות סטרימינג שקוראים בסופו של דבר מודלים של ML לתחזיות.
נתונים מוכנים: מערך הנתונים בטופס מוכן למשימת ה- ML שלך: מקורות נתונים נבדקו, הצטרפו והוכנסו לצורה טבלאית. נתונים מוכנים מצטברים ומסוכמים לגרגיריות הימנית - לדוגמה, כל שורה במערך הנתונים מייצגת לקוח ייחודי, וכל עמודה מייצגת מידע מקוצר עבור הלקוח, כמו הסכום שהוצא בששת השבועות האחרונים. בטבלת נתונים מוכנה, עמודות לא רלוונטיות הושמטו, ורישומים לא חוקיים סוננו. למשימות למידה בפיקוח, תכונת היעד קיימת.
תכונות מהונדסות: מערך הנתונים עם התכונות המכוונות שצפויות לדגם-כלומר, תכונות שנוצרות על ידי ביצוע פעולות ספציפיות ל- ML בעמודות במערך הנתונים המוכנים, ויצירת תכונות חדשות למודל שלך במהלך אימונים ותחזית, כמתואר בהמשך בפעולות עיבוד מראש . דוגמאות לפעולות אלה כוללות קנה מידה עמודות מספריות לערך בין 0 ל -1, ערכי גזירה ותכונות קטגוריות מקודדות חד-חמות .

התרשים הבא, איור 1, מציג את הצעדים המעורבים בהכנת נתונים מעובדים מראש:

תרשים זרימה המציג נתונים גולמיים הנעים לנתונים מוכנים הנעים לתכונות מהונדסות. — **איור 1. איור 1.** זרימת הנתונים מנתונים גולמיים לנתונים מוכנים לתכונות מהונדסות ללימוד מכונה.

בפועל, נתונים מאותו מקור הם לרוב בשלבים שונים של מוכנות. לדוגמה, שדה מטבלה במחסן הנתונים שלך עשוי לשמש ישירות כתכונה מהונדסת. יחד עם זאת, שדה נוסף באותה טבלה עשוי לעבור טרנספורמציות לפני שהוא יהפוך לתכונה מהונדסת. באופן דומה, הפעולות הנדסיות נתונים ותכונות הנדסיות עשויות להיות משולבות באותו שלב עיבוד מראש של נתונים.

פעולות עיבוד מראש

עיבוד מקדים של נתונים כולל מספר פעולות. כל פעולה נועדה לעזור ל- ML לבנות דגמים חזויים טובים יותר. הפרטים של פעולות עיבוד מראש אלה נמצאות מחוץ לתחום של מסמך זה, אך פעולות מסוימות מתוארות בקצרה בסעיף זה.

עבור נתונים מובנים, פעולות עיבוד מראש של נתונים כוללות את הדברים הבאים:

ניקוי נתונים: הסרה או תיקון רשומות שהפשימו ערכים פגומים או לא חוקיים מנתונים גולמיים, והסרת רשומות שחסרות מספר גדול של עמודות.
בחירת מקרים ומחיצה: בחירת נקודות נתונים ממערך הנתונים של הקלט ליצירת הדרכה, הערכה (אימות) ומערכות בדיקה . תהליך זה כולל טכניקות לדגימה אקראית שניתן לחזור עליה, שיעורי מיעוט דגימות יתר ומחיצה מרובדת.
כוונון תכונות: שיפור האיכות של התכונה עבור ML, הכולל קנה מידה ונורמליזציה של ערכים מספריים, הקצאת ערכים חסרים, מחיצות גזירה והתאמת ערכים שיש להם התפלגות מוטה.
טרנספורמציה של תכונות: המרת תכונה מספרית לתכונה קטגורית (באמצעות דליזציה ), והמרת תכונות קטגוריות לייצוג מספרי (באמצעות קידוד חם אחד, למידה עם ספירות , תכונות דלילות וכו '). דגמים מסוימים עובדים רק עם תכונות מספריות או קטגוריות, בעוד שאחרים יכולים להתמודד עם תכונות מסוג מעורב. גם כאשר הדגמים מטפלים בשני הסוגים, הם יכולים ליהנות מייצוגים שונים (מספריים וקטגוריים) מאותה תכונה.
מיצוי תכונות: הפחתת מספר התכונות על ידי יצירת מימד נמוך יותר, ייצוג נתונים חזק יותר באמצעות טכניקות כמו PCA , מיצוי הטמעה וחסיד .
בחירת תכונות: בחירת קבוצת משנה של תכונות הקלט לאימוני הדגם, והתעלמות מהאנשים הלא רלוונטיים או המיותרים, בשיטות פילטר או עטיפה . בחירת תכונות יכולה לכלול גם ירידה של תכונות אם התכונות חסרות מספר גדול של ערכים.
בניית תכונות: יצירת תכונות חדשות באמצעות טכניקות טיפוסיות, כגון הרחבת פולינום (באמצעות פונקציות מתמטיות חד -משתנות) או מעבר תכונות (כדי ללכוד אינטראקציות תכונות). ניתן לבנות תכונות גם על ידי שימוש בהיגיון עסקי מתחום מקרה השימוש ב- ML.

כשאתה עובד עם נתונים לא מובנים (לדוגמה, תמונות, שמע או מסמכי טקסט), Deep Learse מחליף הנדסת תכונות מבוססת-ידיעה על ידי קיפולו לארכיטקטורת הדגם. שכבה מפותלת היא מעבד תכונה אוטומטית. בניית ארכיטקטורת המודל הנכונה דורשת ידע אמפירי כלשהו בנתונים. בנוסף, יש צורך בכמות של עיבוד מראש, כמו הדברים הבאים:

למסמכי טקסט: גזע ולמטיזציה , חישוב TF-IDF ומיצוי N-GRAM , בדיקת הטמעה.
לתמונות: גזירה, שינוי גודל, חיתוך, טשטוש גאוסי ומסננים קנריים.
עבור כל סוגי הנתונים (כולל טקסט ותמונות): למידת העברה , המתייחסת לשכבות כל-אחר כך של המודל המאומן לחלוטין כאל שלב הנדסי של תכונות.

עיבוד מראש גרגיריות

פרק זה דן בגרגיריות של סוגי טרנספורמציות נתונים. זה מראה מדוע נקודת מבט זו היא קריטית בעת הכנת נקודות נתונים חדשות לתחזיות באמצעות טרנספורמציות המיושמות על נתוני אימונים.

ניתן לסווג פעולות עיבוד ושינוי מראש כדלקמן, בהתבסס על גרגרי פעולה:

טרנספורמציות ברמת מופע במהלך אימונים וחיזוי . אלה טרנספורמציות פשוטות, כאשר רק ערכים מאותו מקרה נדרשים לשינוי. לדוגמה, טרנספורמציות ברמת המופע עשויות לכלול גזירת ערך של תכונה לסף כלשהו, פולינומלית להרחיב תכונה אחרת, להכפיל שתי תכונות, או להשוות בין שתי תכונות ליצירת דגל בוליאני.
יש ליישם טרנספורמציות אלה באופן זהה במהלך אימונים וחיזוי, מכיוון שהמודל יוכשר על התכונות הטרנספורמציות, ולא על ערכי הקלט הגולמיים. אם הנתונים לא משתנים זהה, המודל מתנהג בצורה לא טובה מכיוון שמוצג לנתונים שיש להם חלוקת ערכים שהוא לא הוכשר איתם. למידע נוסף, עיין בדיון על ספיגה של שירות אימונים בסעיף האתגרים לעיבוד מראש .
טרנספורמציות של מעבר מלא במהלך האימונים, אך טרנספורמציות ברמת מופע במהלך החיזוי . בתרחיש זה, טרנספורמציות הן מצביעות, מכיוון שהן משתמשות בכמה סטטיסטיקות מראש כדי לבצע את הטרנספורמציה. במהלך האימונים אתה מנתח את כל גוף נתוני האימונים כדי לחשב כמויות כמו מינימום, מקסימום, ממוצע ושונות לשינוי נתוני אימונים, נתוני הערכה ונתונים חדשים בזמן החיזוי.
לדוגמה, כדי לנרמל תכונה מספרית לאימונים, אתה מחשב את הממוצע (μ) ואת סטיית התקן שלה (σ) על כל נתוני האימונים. חישוב זה נקרא פעולה מלאה (או ניתוח ). כשאתה משרת את המודל לחיזוי, הערך של נקודת נתונים חדשה מנורמל כדי למנוע שיפוע לשירות אימונים. לפיכך, ערכי μ ו- σ המחושבים במהלך האימונים משמשים להתאמת ערך התכונה, שהוא הפעולה הפשוטה הבאה ברמת המופע :
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
טרנספורמציות מעבר מלא כוללות את הדברים הבאים:
- Minmax קנה מידה תכונות מספריות באמצעות Min ו- Max המחושב ממערך הנתונים של האימונים.
- תכונות מספריות קנה מידה סטנדרטיות (נורמליזציה של Z-SCORE) באמצעות μ ו- σ מחושבים במערך האימונים.
- דליקת תכונות מספריות באמצעות כמויות.
- קביעת ערכים חסרים באמצעות החציון (תכונות מספריות) או במצב (תכונות קטגוריות).
- המרת מיתרים (ערכים נומינליים) למספרים שלמים (אינדקסים) על ידי חילוץ כל הערכים המובחנים (אוצר המילים) של תכונה קטגורית קלט.
- ספירת התרחשות של מונח (ערך תכונה) בכל המסמכים (המקרים) כדי לחשב עבור TF-IDF.
- חישוב ה- PCA של תכונות הקלט כדי להקרין את הנתונים לחלל ממדי נמוך יותר (עם תכונות תלויות ליניאריות).
עליכם להשתמש רק בנתוני האימונים כדי לחשב סטטיסטיקות כמו μ, σ, min ו- max . אם אתה מוסיף את נתוני הבדיקה וההערכה עבור פעולות אלה, אתה מדליף מידע מנתוני ההערכה והבדיקה כדי להכשיר את המודל. פעולה זו משפיעה על אמינות תוצאות הבדיקה וההערכה. כדי להבטיח שתחיל טרנספורמציה עקבית על כל מערכי הנתונים, אתה משתמש באותה נתונים סטטיסטיים המחושבים מנתוני האימונים כדי לשנות את נתוני הבדיקה וההערכה.
אגרגציות היסטוריות במהלך אימונים וחיזוי . זה כרוך ביצירת אגרגציות עסקיות, נגזרות ודגלים כסימני קלט למשימת החיזוי - לדוגמה, יצירת מדדי תדירות, תדירות ומוניטריים (RFM) עבור הלקוחות לבניית דגמי נטייה. סוגים אלה של תכונות ניתנים למתחם ולאחסן אותם בחנות תכונות המשמשת במהלך אימוני דגם, ניקוד אצווה והגשת חיזוי מקוון. אתה יכול גם לבצע הנדסת תכונות נוספת (לדוגמה, טרנספורמציה וכוונון) לצבירות אלה לפני הכשרה וחיזוי.
אגרגציות היסטוריות במהלך אימונים, אך אגרגציות בזמן אמת במהלך החיזוי . גישה זו כוללת יצירת תכונה על ידי סיכום ערכים בזמן אמת לאורך זמן. בגישה זו, המקרים שיש לצבור מוגדרים באמצעות סעיפי חלון זמניים. לדוגמה, אתה יכול להשתמש בגישה זו אם ברצונך לאמן מודל שמעריך את זמן נסיעת המונית על סמך מדדי התנועה למסלול בחמש הדקות האחרונות, בעשר הדקות האחרונות, ב -30 הדקות האחרונות, ובאחרת מרווחים. אתה יכול גם להשתמש בגישה זו כדי לחזות את הכישלון של חלק מנוע על בסיס הממוצע הנע של ערכי הטמפרטורה והרטט המחושב במהלך שלוש הדקות האחרונות. למרות שניתן להכין אגרגציות אלה באופן לא מקוון לאימונים, הם מחושבים בזמן אמת מזרם נתונים במהלך ההגשה.
ליתר דיוק, כשאתה מכין נתוני אימונים, אם הערך המצטבר אינו נמצא בנתונים הגולמיים, הערך נוצר בשלב הנדסת נתונים. הנתונים הגולמיים נשמרים בדרך כלל בבסיס נתונים עם פורמט של (entity, timestamp, value) . בדוגמאות הקודמות, entity היא מזהה קטע המסלול עבור מסלולי המוניות ומזהה חלק המנוע לכישלון המנוע. אתה יכול להשתמש בפעולות חלונות כדי לחשב (entity, time_index, aggregated_value_over_time_window) ולהשתמש בתכונות הצבירה כקלט לאימוני הדגם שלך.
כאשר מוגש הדגם לחיזוי בזמן אמת (מקוון), המודל מצפה לתכונות הנגזרות מהערכים המצטברים כקלט. לכן, אתה יכול להשתמש בטכנולוגיית עיבוד זרם כמו Apache Beam כדי לחשב את הצביקות מנקודות הנתונים בזמן אמת המוזרמות למערכת שלך. טכנולוגיית עיבוד זרם אגרגטיית נתונים בזמן אמת המבוססים על Windows בזמן שמגיעים נקודות נתונים חדשות. אתה יכול גם לבצע הנדסת תכונות נוספת (לדוגמה, טרנספורמציה וכוונון) לצבירות אלה לפני הכשרה וחיזוי.

צינור ML ב- Google Cloud

פרק זה דן ברכיבי הליבה של צינור טיפוסי מקצה לקצה כדי להכשיר ולשרת דגמי ML של TensorFlow ב- Google Cloud באמצעות שירותים מנוהלים. הוא דן גם היכן אתה יכול ליישם קטגוריות שונות של פעולות עיבוד מראש של נתונים, ואתגרים נפוצים שעליהם אתה עשוי להתמודד כשאתה מיישם טרנספורמציות כאלה. קטע ה- Tf.Transform עובד מראה כיצד ספריית טרנספורמציה של TensorFlow עוזרת להתמודד עם אתגרים אלה.

ארכיטקטורה ברמה גבוהה

התרשים הבא, איור 2, מציג ארכיטקטורה ברמה גבוהה של צינור ML טיפוסי להכשרה והגשת דגמי טנזור. התוויות A, B ו- C בתרשים מתייחסים למקומות השונים בצינור בהם ניתן לעיבוד מקדים של נתונים. פרטים על שלבים אלה מופיעים בסעיף הבא.

תרשים אדריכלות המציג שלבים לנתוני עיבוד. — **איור 2. איור 2.** ארכיטקטורה ברמה גבוהה לאימוני ML והגשה ב- Google Cloud.

הצינור מורכב מהצעדים הבאים:

לאחר ייבוא נתונים גולמיים, נתונים טבלאיים מאוחסנים ב- Bigquery, ונתונים אחרים כמו תמונות, שמע ווידאו, מאוחסנים באחסון ענן. החלק השני של סדרה זו משתמש בנתונים טבלאיים המאוחסנים ב- Bigquery כדוגמה.
הנדסת נתונים (הכנה) והנדסת תכונות מבוצעים בקנה מידה באמצעות DataFlow. ביצוע זה מייצר מערכות אימונים, הערכה ומבחנים מוכנים ל- ML המאוחסנים באחסון ענן. באופן אידיאלי, מערכי נתונים אלה מאוחסנים כקבצי TFRECORD , שהם הפורמט המותאם לחישובי TensorFlow.
חבילת מאמנים של דגם TensorFlow מוגשת לאימוני Vertex AI, המשתמשת בנתונים המעובדים מראש מהשלבים הקודמים כדי לאמן את הדגם. הפלט של שלב זה הוא דוגמנית Tensorflow מיומנת המיוצאת לאחסון ענן.
מודל TensorFlow מיומן פרוס לחיזוי AI של קודקוד כשירות שיש לו ממשק API של REST כך שהוא יכול לשמש לתחזיות מקוונות. אותו מודל יכול לשמש גם למשרות חיזוי אצווה.
לאחר הפרוסה של המודל כ- API של REST, אפליקציות לקוח ומערכות פנימיות יכולות להפעיל את ה- API על ידי שליחת בקשות עם כמה נקודות נתונים, וקבלת תגובות מהמודל עם תחזיות.
לתזמורת ואוטומציה של צינור זה, אתה יכול להשתמש בצינורות AI של קודקוד כמתזמן כדי להפעיל את הכנת הנתונים, אימוני הדגם ושלבי פריסת הדגם.

אתה יכול גם להשתמש בחנות תכונות קודקוד AI כדי לאחסן תכונות קלט כדי לחזות. לדוגמה, אתה יכול ליצור מעת לעת תכונות מהונדסות מהנתונים הגולמיים האחרונים ולאחסן אותם בחנות תכונות של Vertex AI. אפליקציות לקוח משיגות את תכונות הקלט הנדרשות מחנות תכונות Vertex AI ושולחות אותן לדגם כדי לקבל תחזיות.

היכן לבצע עיבוד מראש

באיור 2 התוויות A, B ו- C מראים כי פעולות עיבוד מראש של נתונים יכולות להתקיים ב- Bigquery, Dataflow או TensorFlow. החלקים הבאים מתארים כיצד כל אחת מהאפשרויות הללו פועלת.

אפשרות א: Bigquery

בדרך כלל, ההיגיון מיושם ב- Bigquery לפעולות הבאות:

דגימה: בחירה אקראית של קבוצת משנה מהנתונים.
סינון: הסרת מקרים לא רלוונטיים או לא חוקיים.
חלוקה: פיצול הנתונים לייצור מערכות אימונים, הערכה ומבחנים.

סקריפטים של SQL של Bigquery יכולים לשמש כשאילתת מקור לצינור העיבוד המקדים של Dataflow, שהוא שלב עיבוד הנתונים באיור 2. לדוגמה, אם משתמשים במערכת בקנדה, ולמחסן הנתונים יש עסקאות מרחבי העולם, תוך סינון לסינון קבל נתוני אימונים בלבד לקנדה נעשה בצורה הטובה ביותר ב- Bigquery. הנדסת תכונות ב- Bigquery היא פשוטה וניתנת להרחבה, ותומכת ביישום אגרגציות ברמת מופע והיסטוריות תכונות תכונות.

עם זאת, אנו ממליצים להשתמש ב- BigQuery להנדסת תכונות רק אם אתה משתמש בדגם שלך לחיזוי אצווה (ניקוד), או אם התכונות מחוברות מראש ב- Bigquery, אך מאוחסן בחנות תכונות של Vertex AI שישמש במהלך חיזוי מקוון. אם אתה מתכנן לפרוס את הדגם לתחזיות מקוונות, ואם אין לך את התכונה המהונדסת בחנות תכונות מקוונת, עליך לשכפל את פעולות העיבוד המקדימות של SQL כדי להפוך את נקודות הנתונים הגולמיים שמערכות אחרות מייצרות. במילים אחרות, עליכם ליישם את ההיגיון פעמיים: פעם אחת ב- SQL כדי לעבד את נתוני האימונים בביגווירי, ופעם שנייה בהיגיון של האפליקציה הצורכת את המודל לעיבוד מקוון של נקודות נתונים מקוונות לחיזוי.

לדוגמה, אם אפליקציית הלקוחות שלך נכתבת ב- Java, עליך להגיש מחדש את ההיגיון ב- Java. זה יכול להציג שגיאות עקב אי התאמות יישום, כמתואר בסעיף הספירה המשרתת את האתגרים לעיבוד מראש בהמשך במסמך זה. זה גם תקורה נוספת לשמירה על שני יישומים שונים. בכל פעם שאתה משנה את ההיגיון ב- SQL כדי לעבד מראש את נתוני ההדרכה, עליך לשנות את יישום ה- Java בהתאם לנתוני עיבוד מקדים בזמן ההגשה.

אם אתה משתמש במודל שלך רק לצורך חיזוי אצווה (לדוגמה, באמצעות חיזוי אצווה של קודקוד AI), ואם הנתונים שלך לצורך ניקוד מקורם מ- Bigquery, אתה יכול ליישם את הפעולות לעיבוד מראש אלה כחלק מתסריט SQL של BigQuery. במקרה כזה, אתה יכול להשתמש באותו סקריפט SQL לעיבוד מראש כדי להכין נתונים אימונים וגם ניקוד.

טרנספורמציות ממשיכות של מעבר מלא אינן מתאימות ליישום ב- Bigquery. אם אתה משתמש ב- BigQuery לצורך טרנספורמציות של מעבר מלא, אתה זקוק לשולחנות עזר כדי לאחסן כמויות הדרושות על ידי טרנספורמציות מצביעות, כגון אמצעים ושונות כדי לקנה מידה של תכונות מספריות. יתר על כן, יישום טרנספורמציות של מעבר מלא באמצעות SQL ב- Bigquery יוצר מורכבות מוגברת בתסריטים של SQL, ויוצר תלות מורכבת בין אימונים לתסריטים SQL המבקעים.

אפשרות B: Dataflow

כפי שמוצג באיור 2, באפשרותך ליישם פעולות עיבוד מקדימות יקרות חישובית בקרן אפאצ'י, ולהריץ אותן בקנה מידה באמצעות DataFlow. DataFlow הוא שירות אוטומטי -שגיאה מנוהל לחלוטין לעיבוד נתונים של אצווה וזרם. כשאתה משתמש ב- DataFlow, אתה יכול גם להשתמש בספריות מתמחות חיצוניות לעיבוד נתונים, שלא כמו Bigquery.

DataFlow יכול לבצע טרנספורמציות ברמת מופע, ושינוי תכונות היסטוריות בזמן אמת. בפרט, אם דגמי ה- ML שלך מצפים לתכונת קלט כמו total_number_of_clicks_last_90sec , פונקציות פונקציות חלונות של Apache Beam יכולות לחשב תכונות אלה על סמך צבירת ערכי חלונות הזמן של נתוני אירועים בזמן אמת (סטרימינג) (לדוגמה, לחץ על אירועים). בדיון הקודם בגרגיריות של טרנספורמציות , זה נקרא "אגרגציות היסטוריות במהלך אימונים, אך אגרגציות בזמן אמת במהלך החיזוי."

התרשים הבא, איור 3, מציג את התפקיד של Dataflow בעיבוד נתוני זרם עבור תחזיות כמעט בזמן אמת.

ארכיטקטורה לשימוש בנתוני זרם לחיזוי. — **איור 3. איור 3.** ארכיטקטורה ברמה גבוהה באמצעות נתוני זרם לחיזוי ב- Dataflow.

כפי שמוצג באיור 3, במהלך העיבוד, אירועים הנקראים נקודות נתונים נבלעים בפאב/תת . DataFlow צורך נקודות נתונים אלה, מחשב תכונות המבוססות על אגרגטים לאורך זמן ואז מתקשר לממשק ה- API של ML מודל פרוס לתחזיות. לאחר מכן נשלחות תחזיות לפאב/תור יוצא. מפאב/תת, ניתן לצרוך תחזיות על ידי מערכות במורד הזרם כמו ניטור או בקרה, או שניתן לדחוף אותן לאחור (לדוגמה, כהודעות) ללקוח המבקש המקורי. ניתן לאחסן תחזיות גם בחנות נתונים נמוכה באגודה כמו Cloud BigTable לצורך הביצוע בזמן אמת. ניתן להשתמש ב- BigTable בענן גם לצבירה ולאחסן אגרגציות בזמן אמת, כך שניתן יהיה לחפש אותם בעת הצורך לחיזוי.

ניתן להשתמש באותו יישום של Apache Beam לנתוני אימונים לתהליך אצווה המגיעים ממאגר נתונים לא מקוון כמו Bigquery ונתוני תהליכי זרם בזמן אמת להגשת תחזיות מקוונות.

בארכיטקטורות טיפוסיות אחרות, כמו הארכיטקטורה המוצגת באיור 2, אפליקציית הלקוח מתקשרת ישירות לממשק ה- API של המודל הפרוס לתחזיות מקוונות. במקרה כזה, אם יושמו פעולות עיבוד מראש ב- Dataflow כדי להכין את נתוני ההדרכה, הפעולות אינן מיושמות על נתוני החיזוי העומדים ישירות למודל. לפיכך, יש לשלב טרנספורמציות כמו אלה במודל במהלך ההגשה לתחזיות מקוונות.

ניתן להשתמש ב- DataFlow לביצוע טרנספורמציה של מעבר מלא, על ידי חישוב הסטטיסטיקה הנדרשת בקנה מידה. עם זאת, יש לאחסן נתונים סטטיסטיים אלה איפשהו כדי לשמש במהלך החיזוי כדי לשנות נקודות נתוני חיזוי. על ידי שימוש בספריית TensorFlow Transform ( tf.Transform ), אתה יכול להטמיע ישירות את הסטטיסטיקה הזו במודל במקום לאחסן אותם במקום אחר. גישה זו מוסברת בהמשך כיצד פועלת tf.transform .

אפשרות C: Tensorflow

כפי שמוצג באיור 2, באפשרותך ליישם פעולות עיבוד ושינוי של נתונים במודל TensorFlow עצמו. כפי שמוצג באיור, העיבוד המוקדם שאתה מיישם לאימוני מודל TensorFlow הופך לחלק בלתי נפרד מהמודל כאשר המודל מיוצא ונפרס לתחזיות. ניתן לבצע טרנספורמציות במודל TensorFlow באחת הדרכים הבאות:

יישום כל היגיון הטרנספורמציה ברמת המופע בפונקציה input_fn ובפונקציה serving_fn . פונקציית input_fn מכינה מערך נתונים באמצעות API tf.data.Dataset לצורך אימון מודל. פונקציית serving_fn מקבלת ומכינה את הנתונים לתחזיות.
הצבת קוד הטרנספורמציה ישירות במודל TensorFlow שלך על ידי שימוש בשכבות עיבוד מקדים של Keras או יצירת שכבות בהתאמה אישית .

קוד ההיגיון של הטרנספורמציה בפונקציה serving_fn מגדיר את ממשק ההגשה של SaveModel שלך לחיזוי מקוון. אם אתה מיישם את אותן טרנספורמציות ששימשו להכנת נתוני אימונים בקוד ההיגיון של הטרנספורמציה של פונקציית serving_fn , הוא מבטיח כי אותן טרנספורמציות מיושמות על נקודות נתוני חיזוי חדשות כאשר הן מוגשות.

עם זאת, מכיוון שמודל TensorFlow מעבד כל נקודת נתונים באופן עצמאי או באצווה קטנה, אינך יכול לחשב אגרגציות מכל נקודות הנתונים. כתוצאה מכך, לא ניתן ליישם טרנספורמציות של מעבר מלא במודל TensorFlow שלך.

אתגרים לעיבוד מראש

להלן האתגרים העיקריים ביישום עיבוד מראש של נתונים:

שיפוע לשירות אימונים . שיפוע לשירות אימונים מתייחס להבדל בין יעילות (ביצועים חזויים) במהלך אימונים ובמהלך ההגשה. שיפוע זה יכול להיגרם כתוצאה מהתאמה בין האופן בו אתה מטפל בנתונים באימונים לבין צינורות ההגשה. לדוגמה, אם המודל שלך מאומן על פי תכונה שהשתנה לוגריתמית, אך הוא מוצג עם התכונה הגולמית במהלך ההגשה, ייתכן שתפוקת החיזוי אינה מדויקת.
אם התמורות הופכות לחלק מהמודל עצמו, זה יכול להיות פשוט לטפל בטרנספורמציות ברמת המופע, כמתואר קודם באפשרות C: TensorFlow . במקרה זה, ממשק ההגשה של המודל (פונקציית serving_fn ) מצפה לנתונים גולמיים, בעוד שהמודל הופך באופן פנימי נתונים אלה לפני חישוב הפלט. התמורות זהות לאלה שהוחלו בנקודות נתוני ההדרכה והחיזוי הגולמית.
טרנספורמציות של מעבר מלא . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .
Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

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

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

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

Transform training and evaluation data

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

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

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

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

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

Attach transformations to the exported model

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

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

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

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

Preprocessing options summary

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

Data preprocessing option

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

Instance-level
(stateless transformations)

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

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

BigQuery (SQL)

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

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

Batch scoring: Not recommended .

Online prediction: Not recommended .

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

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

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

Dataflow (Apache Beam)

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

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

Batch scoring: Not recommended .

Online predictions: Not recommended .

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

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

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

Dataflow (Apache Beam + TFT)

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

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

Batch scoring: Recommended .

Online prediction: Recommended .

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

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

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

TensorFlow ^*
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

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

Batch scoring: Not Possible .

Online prediction: Not Possible .

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

Online prediction: Not Possible .

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

מה הלאה

To implement a tf.Transform pipeline 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.

מָבוֹא

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

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

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

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

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

Preprocessing data for ML

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

Data engineering compared to feature engineering

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

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

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

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

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

Preprocessing operations

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

For structured data, data preprocessing operations include the following:

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

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

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

Preprocessing granularity

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

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

Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.
When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

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

High-level architecture

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

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

The pipeline consists of the following steps:

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.

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

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

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

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

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

Option C: TensorFlow

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

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

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

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

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.
Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .
Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The 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.

Transform training and evaluation data

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

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

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

Attach transformations to the exported model

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

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

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 .

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 .

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

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

Dataflow (Apache Beam + TFT)

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

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

Batch scoring: Recommended .

Online prediction: Recommended .

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

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

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

TensorFlow ^*
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

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

Batch scoring: Not Possible .

Online prediction: Not Possible .

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

Online prediction: Not Possible .

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

מה הלאה

To implement a tf.Transform pipeline 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 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.

מָבוֹא

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

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:

Preprocessing operations

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.

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

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

Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.
When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

High-level architecture

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.

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.

Option B: Dataflow

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

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.

Option C: TensorFlow

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

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.
Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .
Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The 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.

Transform training and evaluation data

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

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

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

Attach transformations to the exported model

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

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

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 .

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 .

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

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

Dataflow (Apache Beam + TFT)

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

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

Batch scoring: Recommended .

Online prediction: Recommended .

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

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

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

TensorFlow ^*
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

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

Batch scoring: Not Possible .

Online prediction: Not Possible .

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

Online prediction: Not Possible .

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

מה הלאה

To implement a tf.Transform pipeline 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 .