מדריך

נתונים רציפים ובנפח גבוה דורשים ניתוח בתוך דקות מרגע הגעתם.

→Pub/Sub לקליטה -> Dataflow (סטרימינג) לטרנספורמציה -> BigQuery עם הוספות בסטרימינג או Storage Write API לניתוח נתונים.

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

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

→השתמש בשירותים מנוהלים ומוטי קנה מידה אוטומטי: Pub/Sub לקליטה, Dataflow עם קנה מידה אוטומטי מופעל, ו-BigQuery לאחסון.

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

העברת מחסן נתונים גדול מקומי מבוסס Hadoop/Hive ל-Google Cloud.

→העברת נתונים ל-Cloud Storage, ולאחר מכן טעינה ל-BigQuery. החלפת Hive/Spark SQL ב-BigQuery עבור ניתוחים סרברלס. שימוש ב-Dataproc עבור משימות Spark שלא ניתנות לתרגום קל ל-SQL.

למה: BigQuery מספק תחליף סרברלס ובעל ביצועים גבוהים למחסני נתונים של Hadoop, ומפחית את העומס התפעולי.

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

→פרסום הודעות ל-Pub/Sub עם מפתח סדר (ordering key). עיבוד עם צינור סטרימינג של Dataflow, המבטיח עיבוד לפי סדר עבור מפתח נתון.

למה: מפתחות סדר ב-Pub/Sub בשילוב עם Dataflow מספקים עיבוד מנוהל, מותאם לקנה מידה, מסודר ובדיוק פעם אחת ללא ניהול מצב ידני.

מקור↗

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

→שימוש ב-Cloud Storage כשכבת האחסון. שימוש ב-Dataflow עבור עיבוד אצווה וזרם. שימוש ב-Dataplex עם Data Catalog לניהול מטא-נתונים, גילוי וניהול.

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

צינור המעבד נתונים רגישים (לדוגמה, PHI, PII) חייב לציית לתקנות כמו HIPAA או GDPR.

→הפעלת Cloud Audit Logs עבור כל גישה לנתונים. הטמעת VPC Service Controls ליצירת היקף אבטחה המונע דליפת נתונים.

למה: תיעוד ביקורת חיוני למעקב אחר גישה לנתונים לצורך עמידה בתקנים. VPC Service Controls מספקים הגנה חזקה מפני דליפת נתונים, דרישה מרכזית לנתונים רגישים.

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

→שימוש ב-BigQuery כשכבת ההגשה. שימוש בהצהרת `MERGE` לעדכון/הוספת נתונים מעובדים באצווה לטבלת אב, תוך דריסת נתוני סטרימינג עבור אותה תקופה. חשיפת תצוגה שמאחדת (UNION) נתוני אצווה היסטוריים עם נתוני סטרימינג בזמן אמת עבור התקופה הנוכחית.

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

הטמעת ארכיטקטורת Data Mesh מבוזרת שבה דומיינים הם הבעלים של מוצרי הנתונים שלהם.

→שימוש ב-Dataplex לניהול מאוחד על פני "אגמים" ו"אזורים" ספציפיים לדומיינים. שימוש במערכי נתונים של BigQuery לכל דומיין. שימוש ב-Analytics Hub לשיתוף מוצרי נתונים בין דומיינים.

למה: Dataplex מספק את מישור הניהול המרכזי תוך מתן אוטונומיה לדומיינים, עקרון ליבה של Data Mesh.

שילוב אגם נתונים ומחסן נתונים, המאפשר משימות Spark על נתונים גולמיים ו-SQL מהיר על נתונים מעובדים.

→אחסון נתונים בפורמטים פתוחים (Iceberg, Delta Lake) ב-Cloud Storage. שימוש ב-BigLake כדי לספק שכבת ניהול וגישה מאוחדת. שליפת נתונים מ-Dataproc (Spark) ומ-BigQuery.

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

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

→הגדרת שכפול מערכי נתונים חוצה אזורים ב-BigQuery עבור מערכי נתונים קריטיים. שימוש ב-Terraform או Dataform לניהול סכימה והגדרות תצוגה. תזמור מעבר כשל עם Cloud Functions המופעלים על ידי התראות Cloud Monitoring.

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

שכפול רציף של שינויים ממסד נתונים OLTP (לדוגמה, Oracle, PostgreSQL, MySQL) ל-BigQuery עם השהיה נמוכה.

→שימוש ב-Datastream לביצוע Change Data Capture (CDC). הגדרתו להזרמת שינויים ישירות ל-BigQuery, אשר מיישם אותם באמצעות יכולת ה-`MERGE` שלו.

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

מקור↗

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

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

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

צינור Dataflow הכותב ל-BigQuery חווה כפילויות לאחר הפעלות מחדש או כשלים חולפים.

→שימוש בכיור BigQuery Storage Write API (`STORAGE_WRITE_API`) עם המצב מוגדר ל-`at-least-once` (ברירת מחדל, בעבר `STREAMING_INSERTS`) או `exactly-once` (מצב `COMMITTED`).

למה: ה-Storage Write API במצב `COMMITTED` מספק סמנטיקת בדיוק-פעם-אחת מובנית עבור סטרימינג, ומבטל את הצורך בלוגיקת הסרת כפילויות מותאמת אישית.

קליטת נתונים מ-REST API מחולק לדפים ומוגבל בקצב באמצעות Dataflow.

→שימוש ב-`SplittableDoFn` לעיבוד המקור המחולק לדפים במקביל. הטמעת לוגיקת הגבלת קצב (לדוגמה, באמצעות Guava RateLimiter) ו-exponential backoff עבור ניסיונות חוזרים בתוך ה-DoFn.

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

זרם נתונים יחיד צריך להיכתב למספר יעדים (לדוגמה, BigQuery, Bigtable, Cloud Storage).

→בצינור Dataflow יחיד, לאחר עיבוד ראשוני, יישום מספר כותבי `PTransform` לאותו `PCollection` סופי.

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

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

→שימוש בדפוס ה-side input ב-Dataflow. טעינת טבלת המימדים כ-`PCollectionView`. הגדרת טריגר תקופתי לרענון ה-side input בלוח זמנים, מונע הפעלות מחדש של הצינור.

למה: Side inputs משדרים את נתוני המימדים לכל העובדים עבור חיפושים מהירים בזיכרון, תוך הימנעות מקריאות API/DB לכל אלמנט. רענון תקופתי מטפל בעדכונים ביעילות.

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

→יצירת אשכול Dataproc עם מדיניות קנה מידה אוטומטית. הגדרת מספר עובדים ראשיים ומשניים מינימליים/מקסימליים. המדיניות תתאים את קנה מידת האשכול בהתבסס על מדדי YARN.

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

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

→בניית תמונת קונטיינר מותאמת אישית עם כל התלויות המותקנות מראש. דחיפת התמונה ל-Artifact Registry. פריסת הצינור באמצעות Flex Template המפנה לקונטיינר המותאם אישית.

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

משימת Dataflow או Spark המבצעת `GroupByKey` איטית מכיוון שלחלק מהמפתחות יש מספר לא פרופורציונלי של ערכים ("מפתח חם").

→הטמעת צבירה דו-שלבית (key salting). ראשית, הוספת סיומת אקראית למפתח כדי לפצל את המפתח החם על פני מספר עובדים. צבירה חלקית. שנית, הסרת הסיומת וצבירת התוצאות החלקיות.

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

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

→ב-`DoFn`, השתמש בבלוק try-catch לניתוח. השתמש ב-DoFn מרובה פלטים עם `TupleTag` כדי לנתב רשומות חוקיות לפלט הראשי ורשומות לא חוקיות (עם הקשר שגיאה) לפלט שגיאה נפרד. הטבע את ה-PCollection של השגיאות ליעד של "Dead-Letter Queue" כמו נושא Pub/Sub או טבלת BigQuery.

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

שאילתות BigQuery איטיות ויקרות, בדרך כלל מסננות לפי עמודת תאריך/שעה ועמודות אחרות בעלות קרדינליות גבוהה (לדוגמה, `customer_id`).

→חלוקת הטבלה לפי עמודת התאריך/שעה (לדוגמה, מחיצות יומיות). קיבוץ הטבלה לפי עד ארבע עמודות שמסוננות לעתים קרובות (לדוגמה, `customer_id`, `product_category`).

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

מקור↗

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

→שימוש ב-Bigtable. תכנון מפתח שורה התומך בדפוס הגישה הראשי. עבור סדרות זמן, שימוש ב-`entity_id#reverse_timestamp`.

למה: Bigtable הוא מסד נתונים NoSQL מסוג wide-column המותאם לעומסי עבודה בעלי תפוקה גבוהה והשהיה נמוכה בקנה מידה. BigQuery מיועד לניתוח ובעל השהיה גבוהה יותר לחיפושים נקודתיים.

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

→שימוש ב-Cloud Spanner עם תצורת ריבוי אזורים.

למה: Spanner הוא השירות היחיד המספק את כל היכולות הללו: מפוזר גלובלית, טרנזקציות ACID וסכימה יחסית. Cloud SQL הוא אזורי; Bigtable אינו יחסי ובעל עקביות בסופו של דבר בין אשכולות.

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

→אין צורך בפעולה עבור מחיצות/טבלאות שלא שונו במשך 90 ימים רצופים. BigQuery מיישם באופן אוטומטי תמחור אחסון לטווח ארוך, הפחתת עלות של כ-50%.

למה: זוהי אופטימיזציה אוטומטית ומובנית. העברת נתונים ידנית ל-GCS (אלא אם כן עבור שכבת Archive) היא לרוב מיותרת ומוסיפה מורכבות.

לנתונים בדלי Cloud Storage יש דפוס גישה צפוי: תכוף למשך 30 יום, מדי פעם למשך 90 יום, ואז נדיר.

→הגדרת מדיניות מחזור חיים של דלי למעבר אובייקטים: Standard -> Nearline (ב-30 יום) -> Coldline (ב-90 יום).

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

טבלת BigQuery חייבת לאכוף אילוץ מפתח ייחודי.

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

למה: BigQuery אינו אוכף אילוצי `PRIMARY KEY` או `UNIQUE`. יש לנהל את הייחודיות בתהליך טעינת הנתונים.

טבלת מימדים ב-BigQuery צריכה לשמור היסטוריה מלאה של שינויים לצורך ניתוח בנקודת זמן (SCD Type 2).

→הוספת עמודות חותמת זמן `valid_from` ו-`valid_to`. כאשר מתרחש שינוי, שימוש בהצהרת `MERGE` לעדכון ה-`valid_to` ברשומה הישנה והוספת רשומה חדשה.

למה: זהו הדפוס הסטנדרטי ליישום SCD Type 2 במחסן נתונים. `MERGE` מספק דרך יעילה ואטומית לביצוע פעולות העדכון וההוספה הנדרשות.

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

→שימוש ב-Firestore במצב Native. שימוש באוספים, מסמכים ותת-אוספים למודל הנתונים. יצירת אינדקסים מורכבים עבור שאילתות מורכבות.

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

צורך לשלוף נתונים ב-Cloud Storage (Parquet, Avro, וכו') באמצעות BigQuery תוך אכיפת אבטחה מדויקת (ברמת שורה/עמודה).

→יצירת טבלאות BigLake על פני נתוני Cloud Storage. החלת מדיניות אבטחה ברמת שורה וברמת עמודה של BigQuery על טבלאות BigLake.

למה: BigLake מרחיב את ניהול BigQuery לנתונים בפורמט פתוח ב-Cloud Storage, ומאפשר ארכיטקטורת Lakehouse מאובטחת ומאוחדת.

צוות מדעי נתונים צריך לאמן מודלי ML על מערכי נתונים גדולים ב-BigQuery מבלי להעביר או לייצא נתונים.

→שימוש ב-BigQuery ML. כתיבת הצהרות `CREATE MODEL` ב-SQL לאימון, הערכה וחיזוי ישירות בתוך BigQuery.

למה: BQML מבטל העברת נתונים, מפשט את זרימת העבודה של ML, וממנף את כוח העיבוד של BigQuery, מאיץ את האיטרציה.

מקור↗

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

→שימוש ב-Vertex AI Feature Store. קליטת תכונות באמצעות אצווה או סטרימינג. הוא מספק חנות לא מקוונת (BigQuery) לאימון וחנות מקוונת (Bigtable) להגשה בהשהיה נמוכה.

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

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

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

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

צורך ליישם בדיקות איכות נתונים אוטומטיות (ריק, ייחודיות, טווחי ערכים) וניטור עבור נתונים ב-BigQuery וב-Cloud Storage.

→שימוש ב-Dataplex Data Quality. הגדרת כללים ב-YAML או שימוש בכללים שנוצרו אוטומטית מפרופיל. תזמון סריקות לניטור איכות לאורך זמן.

למה: Dataplex מספק פתרון איכות נתונים מנוהל ומשולב שהוא ניתן להרחבה וקל יותר לתחזוקה מבדיקות או סקריפטים מותאמים אישית של SQL.

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

→שימוש ב-BigQuery ML לאימון מודל אשכולות `KMEANS` ישירות על נתוני הלקוחות.

למה: K-means הוא אלגוריתם למידה בלתי מפוקחת אידיאלי לפילוח. BQML הופך אותו לנגיש באמצעות SQL ללא ייצוא נתונים.

הפעלת חיפוש סמנטי (מבוסס משמעות, לא מילות מפתח) על נתוני טקסט המאוחסנים ב-BigQuery.

→שימוש בפונקציה `ML.GENERATE_EMBEDDING` עם מודל בסיס של Vertex AI ליצירת הטמעות וקטוריות. אחסון אותן ושימוש בפונקציה `VECTOR_SEARCH` לחיפוש דמיון.

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

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

→יצירת מודל מרוחק של BigQuery ML המצביע על נקודת קצה של Vertex AI LLM. שימוש בפונקציה `ML.GENERATE_TEXT` בתוך שאילתת SQL לעיבוד נתוני טקסט.

למה: זה משלב בצורה הדוקה AI גנרטיבי ב-SQL, ומאפשר לאנליסטים למנף LLMs על הנתונים שלהם מבלי לעזוב את סביבת BigQuery או לכתוב קוד יישום מורכב.

צינור נתונים מרובה שלבים כולל תלויות מורכבות, ניסיונות חוזרים ומשימות על פני שירותי GCP שונים (לדוגמה, Dataflow, BigQuery, Dataproc).

→שימוש ב-Cloud Composer (Apache Airflow מנוהל). הגדרת זרימת העבודה כגרף מכוון חסר מעגלים (DAG) באמצעות Python.

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

משימת Airflow DAG הקוראת ל-API חיצוני נכשלת לעתים קרובות עקב בעיות רשת חולפות.

→הגדרת ניסיונות חוזרים ברמת המשימה ב-DAG עם `retry_exponential_backoff=True`. זה מגדיל את העיכוב בין הניסיונות החוזרים, ומעניק למערכת החיצונית זמן להתאושש.

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

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

→שימוש ב-Dataform. הגדרת טבלאות ותלויות בקבצי SQLX, שימוש ב-Git לבקרת גרסאות, כתיבת הצהרות איכות נתונים ותזמון זרימות עבודה של ביצוע.

למה: Dataform הוא הפתרון המקורי של Google Cloud עבור ELT, המספק ניהול תלויות, בדיקות ובקרת גרסאות לטרנספורמציות BigQuery, ומקדם שיטות עבודה מומלצות של DataOps.

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

→שימוש ב-Dataplex, אשר לוכד ומציג אוטומטית את אילן היוחסין של הנתונים משירותי Google Cloud נתמכים בממשק המשתמש של Data Catalog.

למה: מעקב אוטומטי אחר אילן יוחסין חיוני לניתוח השפעה, ניפוי באגים וניהול. Dataplex מספק זאת "מחוץ לקופסה" עבור שירותים משולבים.

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

→הפעלת גרסת הצינור החדשה באמצעות אפשרות שורת הפקודה `--update` וציון מזהה המשימה של הצינור הפועל. שימוש במצב `drain` כדי לאפשר למשימה הישנה לסיים את עיבוד הנתונים הנמצאים בתהליך.

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

לצורך עמידה בתקנים, כל גישה לקריאה וכתיבה לנתונים רגישים ב-BigQuery וב-Cloud Storage חייבת להיות מתועדת וניתנת לביקורת.

→הפעלת Cloud Audit Logs, ובמיוחד יומני גישה לנתונים, עבור השירותים הרלוונטיים. יצירת כיור יומן לייצוא יומנים אלה ל-BigQuery לצורך שמירה וניתוח לטווח ארוך.

למה: Cloud Audit Logs מספקים תיעוד מקיף ובלתי ניתן לשינוי של גישה לנתונים. הטבעת יומנים ל-BigQuery מאפשרת ביקורת ודיווח עוצמתיים מבוססי SQL.

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

→הגדרת כל משאבי BigQuery (מערכי נתונים, טבלאות, מדיניות IAM) בקבצי תצורת Terraform (`.tf`). ניהול פריסות באמצעות צינור CI/CD.

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

מודל ML בייצור מציג ירידה בביצועים לאורך זמן.

→הטמעת Vertex AI Model Monitoring. הגדרת משימת ניטור לזיהוי הטיה באימון-הגשה וסטייה בחיזוי על ידי השוואת תעבורת הייצור מול קו בסיס. הגדרת התראות להפעלת חקירה או אימון מחדש אוטומטי.

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