מידע על גישה לנתונים בענן

התכונה 'גישה לנתונים בענן' מאפשרת לשלוח שאילתות לנתונים שמאוחסנים אצל ספקי ענן אחרים ישירות מ- Google Cloud בלי להעביר קבצים או לבנות צינורות ETL מורכבים באמצעות Cross-Cloud Interconnect.

היכולת הזו היא חלק מborderless Lakehouse, והיא מאפשרת לכם לבצע ניתוח מאוחד ולהחיל AI על מערכי הנתונים המבוזרים שלכם באמצעות BigQuery, סביבות עצמאיות של Apache Spark או Managed Service for Apache Spark.

בנוסף לשאילתות אנליטיות, אפשר להשתמש בנתונים המאוחדים כדי לקבל תובנות מבוססות-AI ולנהל את הנתונים:

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

תרחישים לדוגמה

‫Lakehouse תומך בכמה תרחישי שימוש מרכזיים לגישה לנתונים בכמה ספקי ענן:

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

איך מתבצעת גישה לנתונים חוצי-עננים (cross-cloud)

שאילתות ב-Lakehouse שולפות נתונים מרחוק באמצעות התהליך הבא:

  1. גילוי מטא-נתונים: Lakehouse של Google Cloudמתחבר לקטלוגים מרוחקים של Apache Iceberg REST, כמו Databricks Unity או AWS Glue. ‫Lakehouse מגלה את הנתונים בלי להעתיק קבצים. בהתאם לספק הקטלוג המרוחק, Lakehouse מבצע אימות בצורה מאובטחת באמצעות Secret Manager או איחוד אסימונים של OpenID Connect עם Google כספק הזהויות (איחוד אסימונים של OIDC).
  2. העברה מאובטחת: ניתוב התנועה דרך חיבור פרטי (לדוגמה, Dedicated CCI או Partner Interconnect) מפחית באופן משמעותי את עלויות העברת הנתונים בהשוואה לאינטרנט הציבורי, ומאפשר לחזות את זמן האחזור בצורה מדויקת.
  3. ביצוע אופטימלי: כששאילתות קוראות נתונים מעננים מרוחקים, Lakehouse שומר באופן זמני במטמון את פלחי הנתונים האלה באופן מקומי בתוך Google Cloud באחסון ייעודי. שאילתות עוקבות משתמשות במטמון המקומי, וכך נמנעות חלק ניכר מהחיובים על תעבורת נתונים יוצאת חוצת-עננים.

קטלוגים נתמכים

‫Lakehouse תומך בשליחת שאילתות לנתונים מהספקים הבאים של קטלוגים מרוחקים:

מושגי ליבה

בקטע הזה מתוארים הרכיבים העיקריים שנדרשים לשימוש בתכונה של גישה לנתונים חוצה-עננים (cross-cloud).

שכבת מטא-נתונים

שכבת המטא-נתונים מתחברת לנקודות קצה מרוחקות של קטלוג REST של Apache Iceberg כדי לסנכרן מטא-נתונים של משאבי Iceberg (מרחב שמות, טבלה) על סמך מרווח רענון. ‫Lakehouse מבצע אימות מאובטח באמצעות פרטי כניסה של OAuth שמאוחסנים ב-Secret Manager או באמצעות איחוד טוקנים של OIDC.

שכבת התעבורה

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

בוחרים את שיטת ההעברה שתואמת לדרישות הארכיטקטורה והאבטחה שלכם:

בבעלות הלקוח (CCI)

אפשר להגדיר את BigQuery כך שיבצע שאילתות על נתונים שמאוחסנים בקטגוריות של Amazon S3 ב-Amazon Web Services ‏ (AWS) באמצעות חיבור פרטי של Cross-Cloud Interconnect, באמצעות Dedicated Cross-Cloud Interconnect או Partner Cross-Cloud Interconnect.

היתרונות של שימוש בחיבור פרטי בין רשתות:

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

סקירה כללית של הארכיטקטורה

כדי להפעיל שאילתות פרטיות, צריך להגדיר נתיב מ-BigQuery לקטגוריית AWS Amazon S3 דרך חיבור פרטי. רכיב מרכזי ב Google Cloudענן וירטואלי פרטי (VPC) הוא מאזן עומסים פנימי (ILB). מאזן העומסים הפנימי (ILB) מחלק את הבקשות מ-BigQuery לנקודות הקצה הפרטיות של Amazon S3 ב-AWS VPC, שמוקצות באמצעות AWS PrivateLink.

שימוש במאזן עומסים פנימי (ILB) עם כמה ממשקי רשת אלסטיים (ENI) כבק-אנד הוא חיוני לאיזון עומסים, למדרגיות ולזמינות גבוהה. זה רלוונטי גם אם משתמשים ב-Dedicated CCI או ב-Partner Interconnect.

תהליך העבודה של שאילתות פרטיות מתבצע באופן הבא:

  1. ב-BigQuery נעשה שימוש בחיבור שהוגדר עם שירות Service Directory.
  2. ‫Service Directory מתרגם את שם השירות לכתובת ה-IP הפנימית של Google Cloud ILB.
  3. מאזן העומסים הפנימי מקבל את הבקשות מ-BigQuery ומפיץ אותן לשרתי קצה עורפיים שהוגדרו.
  4. הקצוות העורפיים של ILB הם קבוצות של נקודות קצה ברשת (NEG) לקישוריות היברידית, וכל אחת מהן מצביעה על כתובת ה-IP הפרטית של ENI ב-AWS VPC.
  5. תנועת הנתונים זורמת מ-ILB, דרך NEGs, דרך חיבור פרטי, אל AWS ENIs.
  6. ממשקי הרשת של AWS, שהם חלק מנקודת קצה (endpoint) של ממשק Amazon S3 VPC ‏(AWS PrivateLink), מספקים גישה פרטית לשירות Amazon S3.

אינטרנט ציבורי (ללא CCI)

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

כששולחים שאילתות לנתונים דרך האינטרנט הציבורי, חשוב להביא בחשבון את ההשלכות הבאות:

  • הצפנה רגילה: בקשות לגישה לנתונים והעברות נתונים מוצפנות בזמן המעבר באמצעות פרוטוקולי TLS רגילים באינטרנט הציבורי.
  • עלויות של תעבורת נתונים יוצאת (egress): על העברת נתונים חלים חיובים סטנדרטיים של תעבורת נתונים יוצאת באינטרנט מספק שירותי הענן המרוחק (לדוגמה, AWS), שבדרך כלל גבוהים יותר מתעריפי תעבורת נתונים יוצאת של חיבור פרטי.
  • זמן אחזור משתנה: הביצועים, רוחב הפס וזמן האחזור של הרשת תלויים בניתוב ובגודש של האינטרנט הציבורי, ולכן זמני הביצוע של השאילתות פחות צפויים בהשוואה לחיבור פרטי ייעודי.
  • הגדרה פשוטה: לא נדרשת תשתית רשת נוספת, קישור בין רשתות VPC או הגדרה של Service Directory ב- Google Cloud או בספק שירותי הענן המרוחק.

סקירה כללית של הארכיטקטורה

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

תהליך העבודה של שאילתות באינטרנט הציבורי מתבצע כך:

  1. מערכת BigQuery מפעילה שאילתה על טבלה מאוחדת שהוגדרה בקטלוג של Lakehouse.
  2. ‫Lakehouse מאמת בצורה מאובטחת את קטלוג Apache Iceberg המרוחק באמצעות פרטי כניסה שמאוחסנים ב-Secret Manager או באיחוד טוקנים של OIDC.
  3. ‫Lakehouse מאחזר את המטא-נתונים של הטבלה ואת קובצי המניפסט באינטרנט הציבורי כדי לזהות את קובצי הנתונים הרלוונטיים (לדוגמה, ב-AWS Amazon S3).
  4. בקשות לגישה לנתונים של האובייקטים הבסיסיים נשלחות ישירות מ-Google Cloud דרך האינטרנט הציבורי באמצעות הצפנת TLS רגילה.
  5. שירות האחסון המרוחק מאמת את הבקשה באמצעות פרטי כניסה זמניים עם היקף הרשאות מוגבל שמונפקים על ידי Lakehouse, ומחזיר את בלוקי הנתונים המבוקשים דרך האינטרנט הציבורי אל Google Cloud.

שמירה חכמה במטמון

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

חיסכון בעלויות של תעבורת נתונים יוצאת (egress)

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

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

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

כדי לבדוק את שיעורי הפגיעה במטמון ואת החיסכון בעלויות של תעבורת נתונים יוצאת בשאילתה, צריך לבדוק את נתוני השאילתה במסוף BigQuery או ב-API (JobStatistics2). מכיוון ששאילתה יכולה להפנות לנתונים אצל כמה ספקים, נתוני המשימה כוללים שדה חוזר object_storage_stats (objectStorageStats) עם רשומה לכל ספק ענן שהייתה אליו גישה במהלך ההפעלה.

כל רשומה object_storage_stats כוללת את המדדים הבאים:

  • ‫cloud_provider (cloudProvider): ספק שירותי הענן שמארח את האחסון של האובייקט (לדוגמה, AWS או AZURE).
  • ‫cache_bytes_read (cacheBytesRead): המספר הכולל של הבייטים שנקראו מהמטמון המקומי Google Cloud , כדי להימנע מקריאה של אחסון אובייקטים מרחוק.
  • ‫object_storage_bytes_read (objectStorageBytesRead): סך הבייטים שנקראו ישירות מאחסון האובייקטים של ספק הענן המרוחק.

שיקולים לגבי מיקום אחסון הנתונים ותחום שיפוט

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

אם נתוני הענן המרוחקים שלכם נמצאים באזור גיאוגרפי או בתחום שיפוט אחר (לדוגמה, AWS Amazon S3 באיחוד האירופי בשילוב עם BigQuery compute בus-east4), שאילתות חוצות ענן מאחסנות נתונים במנוחה, עותקים במטמון של נתונים מרוחקים באזור היעדGoogle Cloud . המשתמש או האדמין שיוצרים את החיבור או הקטלוג צריכים לוודא שהשמירה במטמון חוצה הגבולות עומדת בדרישות של הארגון בנוגע למיקום אחסון הנתונים, לריבונות ולתאימות.

הצפנה ותמיכה ב-CMEK

אין תמיכה במפתחות הצפנה בניהול הלקוח (CMEK) בשמירת נתונים במטמון ב-Lakehouse. כל בלוקי הנתונים שנשמרים במטמון מוצפנים במצב מנוחה באמצעותGoogle-owned and Google-managed encryption keysכברירת מחדל.

אם בארגון שלכם נאכף אילוץ מדיניות הארגון הגבלת שירותים שלא תומכים ב-CMEK (constraints/gcp.restrictNonCmekServices), מערכת Lakehouse משביתה אוטומטית את השמירה במטמון של שאילתות שמתבצעת גישה לטבלאות מוגבלות. השאילתות עדיין מורצות בהצלחה, אבל הן לא שומרות במטמון בלוקים של נתונים ולא נהנות מחיסכון ביציאת נתונים שקשור למטמון.

המאמרים הבאים