Google Cloud Associate Data Practitioner
נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן ADP בודק. קראו מלמעלה למטה, או דלגו לסעיף.
טעינת קבצי אצווה גדולים (CSV, Parquet, Avro) מ-Cloud Storage אל BigQuery.
השתמש בעבודת טעינה של BigQuery. ציין URI עם תו כללי (לדוגמה, `gs://bucket/path/*`) כדי לטעון מספר קבצים בעבודה אחת.
למה: זו השיטה המהירה והחסכונית ביותר להזרמת אצווה. עבודות טעינה הן בחינם. היא מונעת עלויות לכל שורה של הזרמה.
הזרמת נתונים בזמן אמת ובנפח גבוה (IoT, clickstream) עם פוטנציאל לטרנספורמציה.
Pub/Sub -> Dataflow -> BigQuery.
למה: תבנית הזרמה קנונית וניתנת להרחבה. Pub/Sub מספק חיץ עמיד וניתן להרחבה. Dataflow מאפשר טרנספורמציות מורכבות, חלונות (windowing), ועיבוד "בדיוק פעם אחת" (exactly-once processing).
שכפול מסד נתונים תפעולי (MySQL, PostgreSQL, Oracle) אל BigQuery עם השהיה נמוכה, וקליטת כל השינויים (הכנסות, עדכונים, מחיקות).
השתמש ב-Datastream עבור Change Data Capture (CDC).
למה: נבנה במיוחד עבור CDC בזמן אמת ובעל השפעה נמוכה. הוא מטפל במילוי חוזר ראשוני ומזרים שינויים מתמשכים ישירות ל-BigQuery.
ביצוע אימות נתונים מורכב, העשרה או טרנספורמציה (לדוגמה, שיטוח JSON/XML מקונן) לפני הטעינה ל-BigQuery.
השתמש בצינור עיבוד נתונים של Dataflow עם טרנספורמציות מותאמות אישית של Apache Beam (לדוגמה, ParDo).
למה: Dataflow מספק גמישות מרבית עבור קוד מותאם אישית (Python/Java), לוגיקה מורכבת, וניתוב רשומות לא חוקיות לתור הודעות כושלות (dead-letter queue).
העברת טרה-בייט או פטה-בייט של נתונים מענן אחר (לדוגמה, S3) או ממרכז נתונים מקומי אל Cloud Storage.
עבור ענן-לענן, השתמש ב-Storage Transfer Service. עבור מקומי עם רוחב פס רשת מוגבל, השתמש ב-Transfer Appliance.
למה: STS הוא שירות מנוהל ועתיר ביצועים עבור העברות מקוונות. Transfer Appliance מיועד להעברות לא מקוונות (משלוח פיזי) כאשר הרשת היא צוואר הבקבוק.
שאילת נתונים הנמצאים ב-Cloud Storage או Amazon S3 ישירות מ-BigQuery ללא טעינתם.
צור טבלה חיצונית ב-BigQuery. עבור ממשל אחיד עם Spark, השתמש בטבלת BigLake.
למה: מונע שכפול נתונים ועלויות אחסון ב-BigQuery. BigLake מוסיף אבטחה מדויקת (ברמת שורה/עמודה) וממשל על נתוני אחסון אובייקטים.
צינור הזנה חייב להתאים את עצמו אוטומטית כאשר עמודות חדשות מתווספות לקבצי מקור (JSON, Avro).
הגדר את עבודת הטעינה של BigQuery עם `schemaUpdateOptions` המוגדר ל-`ALLOW_FIELD_ADDITION`.
למה: מייצר אוטומציה של אבולוציית סכימה. BigQuery מוסיף את העמודות החדשות לסכימת הטבלה מבלי שהעבודה תיכשל.
הזרמת נתונים בנפח גבוה ל-BigQuery עם סמנטיקה של "בדיוק פעם אחת" (exactly-once semantics) בעלות נמוכה יותר מאשר ה-API הזרמה הישן.
השתמש ב-BigQuery Storage Write API.
למה: מספק תפוקה גבוהה יותר ועלויות נמוכות יותר מאשר ה-API הישן `insertAll`, עם הבטחות חזקות כמו אספקה "בדיוק פעם אחת" בתוך זרם.
תזמור תהליך עבודה מורכב עם משימות תלויות מרובות (לדוגמה, Dataflow, BigQuery, Cloud Functions) על פי לוח זמנים.
השתמש ב-Cloud Composer (Apache Airflow מנוהל).
למה: הסטנדרט לתזמור תהליכי עבודה מורכבים. מספק DAGs להגדרת תלות, תזמון, ניסיונות חוזרים, התראות, ומערכת אקולוגית עשירה של אופרטורים.
DAG של Cloud Composer צריך להשהות ולהמתין שקובץ ספציפי יופיע בדלי Cloud Storage לפני ההמשך.
השתמש ב-`GCSObjectExistenceSensor` ב-DAG של Airflow.
למה: זוהי תבנית "חיישן" (sensor) האידיומטית של Airflow להמתנה לתנאים חיצוניים. היא יעילה יותר מלולאת בדיקה מותאמת אישית ב-PythonOperator.
צינור Dataflow זורם צריך לצבור אירועים כראוי לפי חותמת זמן, גם אם אירועים מגיעים שלא לפי הסדר או באיחור.
השתמש בחלונות זמן אירוע (event-time windowing) עם סימני מים (watermarks) והגדר `allowedLateness`.
למה: תכונה זו של Dataflow/Beam מקבצת נתונים כראוי בהתבסס על מועד התרחשות האירוע, ולא מועד עיבודו. `allowedLateness` מונע מנתונים מאוחרים להיזרק.
הפעל עבודות Apache Spark בקנה מידה גדול ולא אינטראקטיביות עבור עיבוד אצווה או למידת מכונה (ML).
השתמש באשכול Dataproc. לחיסכון מרבי בעלויות, השתמש באשכול ארעי (ephemeral) עם Spot VMs (לשעבר preemptible VMs).
למה: Dataproc הוא שירות Spark/Hadoop המנוהל. אשכולות ארעיים קיימים רק למשך זמן העבודה, ו-Spot VMs מציעים הנחות עמוקות לעומסי עבודה סובלניים לתקלות.
צור צינור Dataflow סטנדרטי שניתן להפעיל על ידי צוותים שונים עם פרמטרים משתנים (לדוגמה, נתיבי קלט/פלט).
ארוז את הצינור כתבנית Dataflow Flex Template.
למה: Flex Templates הם הסטנדרט המודרני לעבודות Dataflow שניתנות לשימוש חוזר. הם מבוססי קונטיינרים, תומכים בתלות מותאמת אישית ומקבלים פרמטרים בזמן ריצה.
משימה ב-DAG של Cloud Composer נכשלת באופן זמני עקב בעיות חיצוניות ארעיות (לדוגמה, הגבלת קצב API, תחרות על משאבים).
הגדר `retries` ו-`retry_delay` עם `retry_exponential_backoff=True` עבור המשימה.
למה: זה הופך את הצינור לעמיד על ידי ניסיונות חוזרים אוטומטיים של משימות כושלות עם עיכובים הולכים וגדלים, ולעיתים קרובות פותר בעיות ארעיות ללא התערבות ידנית.
צינור Dataflow זורם מפגר, ומציג השהיה גבוהה של המערכת או רעננות נתונים ירודה.
בדוק מדדי ניטור של Dataflow. וודא אם המדרגיות האוטומטית מגיעה למגבלת `maxNumWorkers`. הגדל את `maxNumWorkers` או עבור לסוג מכונה גדול יותר.
למה: השהיה גבוהה של המערכת היא אינדיקטור עיקרי של יכולת עיבוד בלתי מספקת. הצינור זקוק ליותר עובדים או לעובדים גדולים יותר כדי לעמוד בקצב זרימת הנתונים.
אופטימיזציה של טבלת BigQuery גדולה עבור עלויות שאילתה וביצועים.
חלק את הטבלה לפי עמודת יחידת זמן המסוננת לעיתים קרובות (לדוגמה, תאריך עסקה). מקבץ את הטבלה לפי עמודות אחרות בעלות קרדינליות גבוהה ומסוננות לעיתים קרובות (לדוגמה, `customer_id`).
למה: חלוקה היא הדרך היעילה ביותר להפחית עלויות והשהיה על ידי קיטום כמות הנתונים הנסרקים. קיבוץ משפר עוד יותר את הביצועים על ידי מיון נתונים בתוך מחיצות.
מנע העתקת נתונים ממערך נתונים רגיש של BigQuery ליעד לא מורשה (לדוגמה, דלי GCS ציבורי), אפילו על ידי משתמש עם אישורים תקפים.
השתמש ב-VPC Service Controls כדי ליצור היקף שירות (service perimeter) סביב הפרויקט המכיל את מערך הנתונים של BigQuery.
למה: VPC Service Controls פועלים כ"חומת אש וירטואלית" לשירותי GCP, ומונעים מנתונים לעזוב את ההיקף. זוהי בקרת הגנה עמוקה קריטית נגד דליפת נתונים.
הגבל גישה לעמודות רגישות (לדוגמה, PII) בטבלת BigQuery לקבוצות מורשות, תוך כדי התרת גישה לאחרים לשאילתות על העמודות הנותרות.
השתמש ב-Data Catalog כדי ליצור טקסונומיה ותגי מדיניות. החל תגי מדיניות על עמודות רגישות והענק את תפקיד ה-"Fine-Grained Reader" לקבוצות מורשות.
למה: זוהי השיטה המקורית והניתנת להרחבה לאבטחת ברמת העמודה ב-BigQuery. היא מספקת ממשל מרכזי ללא צורך ביצירה וניהול של תצוגות נפרדות.
סנן טבלה כך שמשתמשים יוכלו לראות רק שורות הנוגעות להם (לדוגמה, מנהלי מכירות רואים רק את נתוני האזור שלהם).
צור מדיניות אבטחה ברמת שורה (Row-Level Security Policy) בטבלה שמסננת שורות על בסיס `SESSION_USER()`א.
למה: מספק סינון דינמי מבוסס פרדיקטים בזמן שאילתה. זה בטוח וניתן לניהול יותר מאשר יצירת תצוגה מורשית לכל משתמש או תפקיד.
מחק נתונים אוטומטית מטבלת BigQuery לאחר תקופת שמירה מוגדרת כדי לציית לתקנות (לדוגמה, מחיקת נתונים ישנים מ-7 שנים).
עבור נתוני סדרות זמן, הגדר תפוגת מחיצה בטבלה מחולקת לפי זמן. עבור טבלאות אחרות, הגדר את תפוגת הטבלה המוגדרת כברירת מחדל.
למה: זוהי תכונה מובנית של "הגדר ושכח" המבטיחה ציות ללא סקריפטים ידניים לניקוי או תזמור חיצוני.
טבלת BigQuery שונתה או נמחקה בטעות.
השתמש ב-BigQuery Time Travel כדי לבצע שאילתה על הטבלה כפי שהייתה קיימת בנקודת זמן לפני האירוע, באמצעות `FOR SYSTEM_TIME AS OF`.
למה: BigQuery שומר אוטומטית היסטוריה של 7 ימים של נתוני טבלה. זה מאפשר שחזור מיידי בתוך חלון ה-Time Travel ללא צורך בשחזור מגיבויים.
גלה, נהל, אבטח ונטר נכסי נתונים (BigQuery, GCS) ברחבי ארגון שלם.
השתמש ב-Dataplex.
למה: Dataplex פועל כרשת נתונים חכמה, המספקת לוח בקרה מאוחד לממשל נתונים, איכות, שושלת, גילוי וניהול מחזור חיים על פני מאגרי נתונים מפוזרים.
הבן ודמיין כיצד נתונים זורמים ממערכות מקור, דרך עבודות טרנספורמציה, לטבלאות דיווח סופיות.
השתמש ב-Dataplex Data Lineage.
למה: קולט אוטומטית מידע שושלת מיומני BigQuery, Data Fusion ו-Composer כדי לספק תצוגה אינטראקטיבית מבוססת גרפים של תלות נתונים לצורך ניתוח השפעה וביקורת.
הבטח ביצועי שאילתה ועלות צפויים עבור עומסי עבודה קריטיים, הימנעות מ"תחרות על חריצים" (slot contention) ממשתמשים אחרים.
רכוש BigQuery Editions (תמחור מבוסס קיבולת). צור הזמנות כדי להקדיש מאגר של חריצים לפרויקטים או תיקיות ספציפיים.
למה: מעבר ממאגר משותף, לפי דרישה, לקיבולת חישוב ייעודית, המבטיח משאבים לעבודות קריטיות ומספק חיוב צפוי.
סרוק את כל נכסי הנתונים ב-BigQuery וב-Cloud Storage כדי לזהות ולסווג אוטומטית PII ונתונים רגישים אחרים.
הגדר עבודת סריקת גילוי של Cloud Data Loss Prevention (DLP).
למה: Cloud DLP משתמש במאות גלאים מוגדרים מראש כדי למצוא נתונים רגישים בקנה מידה. הוא יכול להשתלב עם Data Catalog כדי להחיל אוטומטית תגי מדיניות לצורך ממשל.
יישום מבוסס קונטיינרים (ב-GKE או Cloud Run) צריך לבצע אימות מאובטח ל-BigQuery ללא ניהול מפתחות חשבון שירות.
השתמש ב-Workload Identity.
למה: השיטה המומלצת לאימות שירות-לשירות. היא ממפה חשבון שירות של Kubernetes לחשבון שירות של GCP IAM, תוך שימוש באסימונים קצרי מועד המסתובבים אוטומטית.
לצורך ציות, הפק דוח של כל המשתמשים שביצעו שאילתה על טבלת BigQuery רגישה ב-90 הימים האחרונים.
אפשר ובצע שאילתה על יומני הביקורת של BigQuery Data Access, אשר ניתן לנתב למערך נתונים של BigQuery לצורך ניתוח.
למה: יומני Data Access מספקים תיעוד בלתי ניתן לשינוי של מי ניגש לאיזה נתונים ומתי. הם חיוניים לביקורות אבטחה וציות אך חייבים להיות מופעלים במפורש.
זהה אילו משתמשים או שאילתות אחראים לעלויות גבוהות ב-BigQuery.
בצע שאילתה על התצוגה `INFORMATION_SCHEMA.JOBS`.
למה: תצוגת מטא-נתונים זו מכילה מידע מפורט על כל הרצת שאילתה, כולל המשתמש, בייטים שחויבו, וחריצים שנצרכו, מה שמאפשר ייחוס וניתוח עלויות מדויק.
בצע חישובים אנליטיים מורכבים כמו סיכומים מצטברים, דירוג בתוך קבוצות (לדוגמה, N המובילים לכל קטגוריה), או השוואת שורה לשורה קודמת.
השתמש בפונקציות חלון SQL של BigQuery (`SUM() OVER (...)`, `RANK() OVER (...)`, `LAG() OVER (...)`).
למה: שיטת ה-SQL הסטנדרטית והיעילה ביותר לביצוע חישובים על פני קבוצת שורות טבלה הקשורות בדרך כלשהי לשורה הנוכחית.
צור ושתף לוחות מחוונים אינטראקטיביים המתעדכנים אוטומטית על נתוני BigQuery עבור משתמשים עסקיים שאינם כותבים SQL.
השתמש ב-Looker Studio.
למה: כלי הוויזואליזציה המובנה והחינמי של GCP. הוא מתחבר ישירות ל-BigQuery ומאפשר שיתוף באמצעות קישור פשוט, תוך ניהול פרטי כניסה של מקורות נתונים בנפרד מגישת המשתמש.
אפשר לאנליסטים עסקיים להשתמש בכלי גיליונות אלקטרוניים מוכרים (טבלאות ציר, תרשימים, נוסחאות) כדי לנתח טרה-בייט של נתונים ב-BigQuery.
השתמש ב-Connected Sheets.
למה: מספק חיבור חי מ-Google Sheets ל-BigQuery. כל העיבוד והחישוב מתבצעים ב-BigQuery, ועוקפים את מגבלות הגודל והביצועים של גיליון אלקטרוני מסורתי.
לוח מחוונים של Looker Studio שמבצע שאילתות על אגרגציות גדולות ומורכבות הוא איטי ויקר.
צור תצוגה ממומשת (Materialized View) ב-BigQuery כדי לחשב מראש את האגרגציות. הפנה את מקור הנתונים של Looker Studio לתצוגה הממומשת.
למה: תצוגות ממומשות מחשבות מראש ושומרות במטמון תוצאות שאילתות יקרות. זה משפר באופן דרמטי את ביצועי לוחות המחוונים ומפחית את עלויות השאילתה עבור עומסי עבודה חוזרים.
בנה, אמן והפעל מודל למידת מכונה (לדוגמה, לסיווג, רגרסיה או חיזוי) באמצעות נתונים הנמצאים ב-BigQuery.
השתמש ב-BigQuery ML (BQML).
למה: מבצע דמוקרטיזציה של למידת מכונה על ידי מתן אפשרות למשתמשים לאמן מודלים באמצעות תחביר `CREATE MODEL` סטנדרטי של SQL. המודל חי ורץ בתוך BigQuery, מה שמפשט את הפריסה והחיזוי.
חזה מדדי עסקים עתידיים (לדוגמה, מכירות, ביקוש) בהתבסס על נתוני סדרות זמן היסטוריים.
השתמש ב-BigQuery ML עם סוג המודל `ARIMA_PLUS`.
למה: `ARIMA_PLUS` הוא מודל BQML ייעודי לחיזוי סדרות זמן המטפל אוטומטית במגמות, עונתיות, חגים וזיהוי חריגות.
שאילתת BigQuery המצרפת טבלת עובדות גדולה מאוד (TB) עם טבלת ממדים קטנה (<100MB) היא איטית.
וודא ש-BigQuery משתמש בחיבור שידור (broadcast join). למרות שלרוב זה אוטומטי, ניתן לבדוק את תוכנית השאילתה או להשתמש ברמז `JOIN` במידת הצורך.
למה: חיבור שידור שולח את הטבלה הקטנה כולה לכל חריץ עיבוד, ובכך נמנע ערבוב נתונים יקר ואיטי של הטבלה הגדולה על פני הרשת.
מודל BigQuery ML צריך להיות מאומן מחדש באופן קבוע (לדוגמה, שבועי) על נתונים חדשים כדי למנוע סחיפת מודל (model drift).
השתמש בשאילתה מתוזמנת של BigQuery כדי להריץ הצהרת `CREATE OR REPLACE MODEL`.
למה: זוהי הדרך הפשוטה והמשולבת ביותר לאוטומציה של אימון מחדש של BQML. היא אינה דורשת שירותים חיצוניים כמו Composer או Cloud Functions.
בנה מערכת המלצות של סינון שיתופי (collaborative filtering) (לדוגמה, "משתמשים שקנו X קנו גם Y").
השתמש ב-BigQuery ML עם סוג המודל `MATRIX_FACTORIZATION`.
למה: מודל זה תוכנן במיוחד למשימות המלצה המבוססות על נתוני אינטראקציה בין משתמש לפריט.
