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

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

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

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

מתי כדאי להשתמש בגישה לנתונים חוצי-עננים

הנה כמה תרחישי שימוש נפוצים:

  • הרצת שאילתות על טבלאות בכמה עננים: אתם יכולים להריץ ניתוחים של BigQuery SQL ושל Managed Service for Apache Spark ישירות על טבלאות חיצוניות של Apache Iceberg ב-Amazon Web Services (AWS) וב-Microsoft Azure, בלי להעביר קבצים או לתחזק צינורות עיבוד נתונים של ETL.
  • אכיפת בידוד פרטי של רשתות בכמה עננים: ניתוב של קריאת נתוני שאילתות ושל רענון מטא-נתונים ברקע דרך Cross-Cloud Interconnect, כדי לעמוד בדרישות של מדיניות אבטחה ותאימות שמגבילה את תעבורת הנתונים הציבורית באינטרנט.
  • הפחתת העלויות החוזרות של העברת נתונים חוצי-עננים: שילוב של שיעורי תעבורת נתונים יוצאת צפויים בחיבורים פרטיים עם שמירה אוטומטית של בלוקים במטמון מקומי ב-Google Cloud , בשביל לוחות בקרה חוזרים של BI ועומסי עבודה אנליטיים.
  • איחוד של סוכני AI ופיקוח חוצה-עננים: אפשר להשתמש בטבלאות מבוזרות כדי לבסס את הסוכנים של ניתוח נתונים באמצעות שיחה, ולהחיל את יכולות הגילוי, הפרופיילינג והשושלת של Knowledge Catalog על עננים שונים.

ארכיטקטורה

התרשים הבא ממחיש את ארכיטקטורת הגישה לנתונים חוצי-עננים ב-Lakehouse:

ארכיטקטורה של גישה לנתונים חוצי-עננים ב-Lakehouse ב- Google Cloud, ב-Amazon Web Services (AWS) ובשותפי SaaS.
הארכיטקטורה של Lakehouse מחברת בין מנועי Google Cloud AI וניתוח נתונים לבין קטלוגים חיצוניים בענן, מאגרי אובייקטים ושותפי SaaS.

בתרשים הקודם מוצגת הארכיטקטורה ב- Google Cloud ובסביבות ענן ו-SaaS חיצוניות:

  • ‫Google Cloud: מספק גישה ל-AI, לממשל, לניתוח נתונים ולנתונים חוצי-עננים בקבוצות נתונים מרוחקות:
    • סוכני AI וחוויות שימוש: יוצרים סוכנים אוטונומיים ב-Conversational Analytics וב-Gemini Enterprise, שמחפשים נתונים ומשמעות סמנטית ב-Knowledge Catalog ומריצים שאילתות באמצעות מנועי ניתוח ועיבוד.
    • ‫Knowledge Catalog: מספק ניהול אחיד והשתלשלות נתונים, יחד עם תובנות מנתונים, יצירת פרופילים ומוצרי נתונים, על ידי סנכרון מטא-נתונים והשתלשלות נתונים מ-Lakehouse.
    • מנועי ניתוח ועיבוד: מריצים עומסי עבודה של BigQuery SQL,‏ BigQuery AI ו-Looker, או מעבדים נתונים מרוחקים באמצעות Managed Service for Apache Spark ומנועים פתוחים (Apache Spark,‏ Apache Flink ו-Trino) על ידי פתרון מטא-נתונים וקריאת טבלאות דרך Lakehouse.
    • גישה לנתונים חוצי-עננים ב-Lakehouse: שאילתות על נתונים מרוחקים במקום, בלי העברת קבצים או צינורות עיבוד נתונים של ETL:
      • סנכרון מטא-נתונים: מגלה ומסנכרן מטא-נתונים של טבלאות ב-Apache Iceberg REST וב-Delta Sharing באמצעות הקטלוג הייעודי לזמן ריצה של Lakehouse, מאמת באמצעות OpenID Connect‏ (OIDC) או Secret Manager ומספק פרטי כניסה זמניים ברמת ההיקף.
      • יכולות חוצות-עננים (AWS): שמירת בלוקים של נתונים שנקראו במטמון ב- Google Cloud באמצעות מטמון קריאה דרך ברמת הבלוק (שמירה חכמה במטמון (מטמון מקומי)), וניתוב תנועה דרך Dedicated Cross-Cloud Interconnect ‏ (CCI), ‏Partner Interconnect או האינטרנט (עם TLS) באמצעות העברת נתונים ברשת חוצת-עננים.
  • מקורות נתונים חיצוניים בענן וב-SaaS: מארחים את הקטלוגים המרוחקים, את ענני הנתונים של SaaS ואת מאגר האובייקטים:
    • קטלוגים חיצוניים של ענן ו-SaaS: סנכרון מטא-נתונים מקטלוגים של נתונים בענן (AWS Glue Data Catalog ב-AWS, ו-Databricks Unity Catalog ו-Snowflake Horizon Catalog ב-AWS או ב- Google Cloud) ומענני נתונים של SaaS (Salesforce Data Cloud,‏ Workday Data Lake ב-AWS או ב-Google Cloudו-SAP Business Data Cloud (BDC)) באמצעות Iceberg API בארכיטקטורת REST ו-Delta Sharing (ל-SAP BDC).
    • אחסון אובייקטים בענן חיצוני (AWS): מאחסן טבלאות Apache Iceberg (קובצי נתונים של Parquet) וטבלאות Amazon S3 ב-Amazon S3 לקריאות ישירות של בלוקים דרך CCI או האינטרנט (עם TLS).

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

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

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

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

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

מושגי ליבה

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

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

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

כברירת מחדל, בקשות לאימות ולרענון מטא-נתונים ברקע עוברות באינטרנט הציבורי באמצעות TLS. אם הקטלוג המרוחק מגביל את הגישה לרשת הציבורית או אם דרישות המדיניות של האבטחה דורשות תעבורת נתונים פרטית במישור הבקרה, אתם יכולים להגדיר שירות של ספריית שירותים (--metadata-service-directory-name) למטא-נתונים בשביל AWS Glue Data Catalog (ב-AWS), בשביל Databricks Unity Catalog (ב-AWS וב-Azure) ובשביל Snowflake Horizon Catalog (ב-AWS וב-Azure). ההגדרה הזו מנתבת את תעבורת הנתונים של המטא-נתונים והאימות באופן פרטי דרך Dedicated Cross-Cloud Interconnect או Partner Cross-Cloud Interconnect (ל-AWS), בנפרד או ביחד עם העברת שאילתות פרטיות (--service-directory-name).

שכבת התעבורה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשמפעילים את המטמון חוצה-העננים, Lakehouse שומר במטמון בלוקים של קבצים שאוחזרו מ-Amazon S3 או מ-Azure Blob Storage באופן מקומי באזור הביצוע של השאילתה ב- Google Cloud . שאילתות עוקבות, כולל שאילתות שונות שמטרגטות את אותם בלוקים של קבצים, קוראות ישירות מהמטמון המקומי במקום לאחזר מחדש את הקבצים מהענן המרוחק.

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

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

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

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

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

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

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

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

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

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

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

מצב זהות

‫Lakehouse תומך בשני מצבי זהות לגישה לנתונים חוצי-עננים:

  • זהות השירות (ברירת המחדל): גם רענון המטא-נתונים ברקע וגם השאילתות מופעלים באמצעות חשבון השירות של הקטלוג, שאפשר להגדיר באמצעות OIDC (מומלץ) או אימות מבוסס-סוד.

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

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