תבניות תכנון לאימות כתובות בנפח גבוה ב-Google Cloud Platform

יעד

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

נתחיל בסקירה כללית על הפעלה של אימות כתובות בנפח גדול ב-Google Cloud Platform עם Cloud Run, Compute Engine או Google Kubernetes Engine, להפעלה חד-פעמית. לאחר מכן נראה כיצד ניתן לכלול את היכולת הזו כחלק מצינור הנתונים.

בסוף המאמר הזה אמורה להיות לכם הבנה על האפשרויות השונות להפעלה של אימות כתובות בנפח גדול בסביבת Google Cloud.

דוגמאות לארכיטקטורות ב-Google Cloud Platform

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

הפעלה חד-פעמית של אימות כתובות בנפח גדול ב-Google Cloud Platform

למטה מוצגת ארכיטקטורת עזר שמדגימה איך ליצור שילוב ב-Google Cloud Platform שמתאים יותר לבדיקה חד-פעמית או לבדיקה חד-פעמית.

תמונה

במקרה כזה מומלץ להעלות את קובץ ה-CSV לקטגוריה של Cloud Storage. לאחר מכן אפשר להריץ את סקריפט האימות של כתובות בנפח גבוה מסביבת Cloud Run. עם זאת, אפשר להריץ אותו בכל סביבת זמן ריצה אחרת כמו Compute Engine או Google Kubernetes Engine. אפשר גם להעלות את קובץ ה-CSV לפלט לקטגוריה Cloud Storage.

פועל כצינור נתונים של Google Cloud Platform

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

תמונה

  • במקרה הזה, אפשר לדלוק קובצי CSV בקטגוריות של Cloud Storage.
  • משימת Dataflow יכולה לאסוף את הכתובות לעיבוד ולאחר מכן לשמור אותן במטמון ב-BigQuery.
  • ניתן להרחיב את ספריית Dataflow Python כך שתכלול לוגיקה לאימות כתובות בנפח גבוה כדי לאמת את הכתובות ממשימת Dataflow.

הרצת הסקריפט מצינור נתונים כתהליך חוזר ארוך טווח

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

תמונה

  • העלו את קובץ ה-CSV הראשוני לקטגוריה של Cloud Storage.
  • שימוש ב-Memorystore כמאגר נתונים קבוע כדי לשמור על מצב ביניים למשך התהליך הארוך.
  • שומרים את הכתובות הסופיות במאגר נתונים של BigQuery.
  • צריך להגדיר את Cloud Scheduler כדי להריץ את הסקריפט מעת לעת.

לארכיטקטורה הזו יש את היתרונות הבאים:

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

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

  • השימוש ב-Memorystore מספק יותר גמישות ויכולת לעבד יותר כתובות. השלב הזה מוסיף משמרת לכל צינור העיבוד, שנדרש לטיפול במערכי נתונים גדולים מאוד של כתובות. אפשר להשתמש גם כאן בטכנולוגיות אחרות של מסדי נתונים, כמו Cloud SQL [https://cloud.google.com/sql] או כל תבנית של מסד נתונים אחרת ש-Google Cloud Platform מציע. עם זאת, אנחנו מאמינים שמאגר הזיכרונות מאזן בצורה מושלמת בין צורכי קנה המידה והפשטות, ולכן הוא צריך להיות הבחירה הראשונה.

סיכום

בעזרת הדפוסים שמתוארים כאן אפשר להשתמש ב-Address Validation API בתרחישים שונים לדוגמה ובתרחישים שונים ב-Google Cloud Platform.

כתבנו ספריית Python בקוד פתוח כדי לעזור לכם להתחיל לעבוד עם התרחישים לדוגמה שמתוארים למעלה. אפשר להפעיל אותו משורת פקודה במחשב או דרך Google Cloud Platform או דרך ספקי שירותי ענן אחרים.

מידע נוסף על השימוש בספרייה זמין במאמר הזה.

השלבים הבאים

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

הצעות נוספות לקריאה:

תורמים

Google מנהלת את המאמר הזה. תורמי התוכן הבאים כתבו אותו במקור.
המחברים הראשיים:

Henrik Valve | מהנדס פתרונות
תומאס אנגלרט | מהנדס פתרונות
סרתק גנגולי | מהנדס פתרונות