תבניות תכנון לאימות כתובות בנפח גבוה ב-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.
  • אפשר להרחיב את ספריית Python של Dataflow כדי שתהיה לוגיקה לאימות כתובות בנפח גבוה שיאמת את הכתובות ממשימת ה-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 | מהנדסי פתרונות
תומס אנגלרט | מהנדסי פתרונות
סרתאק גאנגולי | מהנדסי פתרונות