איך פועל Lakehouse ללא גבולות

הארכיטקטורה הטכנית של borderless Lakehouse תומכת בפעולה הדדית בין מנועים על ידי ריכוז של ניהול המטא-נתונים וטיפול בשאילתות באמצעות נתיבים ספציפיים.

ארכיטקטורה

פיתוח Lakehouse ב-Google Cloud כולל את הרכיבים הטכניים הבאים:

  • אחסון: אחסון ב-Cloud Storage וב-BigQuery משמש כשכבת האחסון, ו-Apache Iceberg הוא פורמט הטבלה המומלץ בקוד פתוח לאחסון עם יכולת פעולה הדדית וביצועים גבוהים ב-Cloud Storage. עם Lakehouse ללא גבולות, הנתונים לא צריכים להיות ב- Google Cloud. אם מגדירים חיבורים בין עננים (בגרסת Preview) לקטלוגים מרוחקים נתמכים, אפשר לשמור את הנתונים במערכות אחסון בענן אחרות, כמו Amazon S3, ולשאול שאילתות בלי להעביר קבצים או לבנות צינורות ETL.

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

  • מנוע שאילתות: מנועי BigQuery וקוד פתוח – כולל Apache Spark,‏ Apache Flink ו-Trino – פועלים יחד בצורה חלקה באמצעות התחברות לקטלוג של זמן הריצה של Lakehouse. מנועי מחשוב כמו Managed Service for Apache Spark משתמשים ב-Apache Spark בקוד פתוח עם אופטימיזציות של ביצוע כדי להבטיח ניידות של עומסי עבודה ולמנוע נעילה של ספק.

  • ניהול: ב-Knowledge Catalog יש אבטחה, שושלת ומדיניות ניהול מרכזיות בכל ה-lakehouse.

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

היררכיית המשאבים

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

  1. ‫Lakehouse runtime catalog: משאב השירות האזורי ברמה העליונה ב- Google Cloud שמארח את המטא-נתונים שלכם. כדי לחבר מנועי שאילתות לשירות הזה ולנהל קטלוגים בסיסיים, צריך להגדיר אפליקציות לקוח באמצעות נקודת קצה (endpoint) ספציפית של קטלוג, כמו נקודת הקצה של קטלוג REST של Apache Iceberg.
  2. קטלוג: מאגר לוגי בשירות של קטלוג ייעודי לזמן ריצה. במבנה השמות של פרויקט/קטלוג/מרחב שמות/טבלה (P.C.N.T), זה מייצג את מופע הקטלוג הספציפי שמתבצעת לגביו שאילתה.
  3. ‫Namespace: קיבוץ לוגי של טבלאות בקטלוג. למשתמשים שמכירים את BigQuery, מרחב שמות דומה מבחינת הפונקציונליות לקבוצת נתונים.
  4. טבלה: הישות הספציפית שמפנה לנתונים ב-Cloud Storage. המטא-נתונים של הטבלה מכילים את הסכימה, את פרטי החלוקה למחיצות ומצביע למצב הנוכחי של הטבלה באמצעות קובץ metadata.json של Apache Iceberg.

נקודות קצה נתמכות

קטלוג זמן הריצה של Lakehouse מספק כמה נקודות קצה לחיבור הנתונים ב-Cloud Storage וב-BigQuery.

  • נקודת הקצה של קטלוג REST של Apache Iceberg: מספקת ממשק REST סטנדרטי לתאימות רחבה עם מנועי קוד פתוח כמו Apache Spark,‏ Apache Flink ו-Trino. זהו הממשק המומלץ לעומסי עבודה חדשים, והוא מציע יכולת פעולה הדדית מלאה של קריאה וכתיבה.

  • קטלוג מותאם אישית של Apache Iceberg לנקודת קצה של BigQuery: מאפשר למנועים לבצע אינטראופרביליות ישירות עם קטלוג BigQuery. הממשק הזה משמש בעיקר לטבלאות Apache Iceberg שמנוהלות על ידי BigQuery ולעומסי עבודה קיימים שעוברים לארכיטקטורת Lakehouse.

  • נקודת הקצה של קטלוג Apache Hive (גרסת Preview): מספקת תאימות לעומסי עבודה של קוד פתוח שתלויים בממשק של Apache Hive metastore‏ (HMS). כך תוכלו להריץ עומסי עבודה של Apache Hive או Spark מול שירות metastore מנוהל ב- Google Cloud.

קטלוג ייעודי לזמן ריצה של Lakehouse

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

הוא מטמיע את Apache Iceberg REST Catalog API בקוד פתוח כדי לנהל מרחבי שמות וטבלאות, ומספק תוספים במיוחד לניהול קטלוגים.

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

קטלוג

קטלוג הוא מאגר מטא-נתונים לוגי שמגובה במיקומי מחסני נתונים של Cloud Storage. במבנה השמות Project.Catalog.Namespace.Table (P.C.N.T), הקטלוג מייצג את מופע המאגר הייחודי של המטא-נתונים שמקשר בין המטא-נתונים של הטבלה הפתוחה לבין מנועי השאילתות.

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

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

מרחב שמות

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

מאפיינים מרכזיים של מרחבי שמות:

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

Tables

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

נתמך על ידי קטלוג זמן הריצה של Lakehouse

מומלץ

  • טבלאות Apache Iceberg: טבלאות Apache Iceberg שנוצרו ממנועי קוד פתוח ומאוחסנות ב-Cloud Storage. הם מציעים תאימות וניהול פתוחים באמצעות נקודת הקצה של REST בקטלוג של Lakehouse בזמן הריצה. כדי לוודא ששתי טבלאות לא יתפסו את אותו מיקום, נתיבי הטבלאות המותאמים אישית צריכים להיות מוטמעים בנתיב של מרחב השמות של ישויות האב, והמיקומים של הטבלאות שנוצרות מקבלים אוטומטית סיומת של מחרוזת אקראית כדי למנוע התנגשויות.

    פורמטים נתמכים של טבלאות

    יש תמיכה בטבלאות Apache Iceberg V2 (זמינות כללית) ובטבלאות V3 (גרסת Preview). אין תמיכה בטבלאות Iceberg V1. כדי להשתמש בטבלאות קיימות מגרסה 1 עם Lakehouse, צריך לשדרג אותן לגרסה נתמכת. מידע נוסף זמין במאמר שדרוג טבלאות Iceberg V1 ל-V2.

נתמך על ידי BigQuery

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

השוואה מפורטת של האפשרויות האלה

רצף עיבוד השאילתות

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

  1. שליחה: אתם שולחים שאילתת SQL למנוע תואם כמו Apache Spark,‏ Trino או BigQuery.
  2. בקשה למטא-נתונים: המנוע מבקש מטא-נתונים של הטבלה מקטלוג זמן הריצה של Lakehouse כדי לזהות את הטבלה ואת המיקום של המטא-נתונים שלה.
  3. הרשאה: אם נקודת הקצה שבה אתם משתמשים תומכת בכך, הקטלוג מאמת את הבקשה מול ניהול הזהויות והרשאות הגישה (IAM) ומדיניות האבטחה הפרטנית.
  4. תגובת המטא-נתונים: הקטלוג מחזיר את המטא-נתונים. אם מופעלת הקצאת פרטי כניסה, המערכת מספקת גם אסימון לטווח קצר כדי לעזור בגישה מאובטחת לאחסון.
  5. אחזור נתונים: המנוע משתמש במטא-נתונים ובטוקן אופציונלי כדי לקרוא קובצי נתונים ישירות מ-Cloud Storage.
  6. ביצוע: המנוע מעבד את הנתונים ומחזיר את התוצאות.

שיטות מומלצות

כשמתכננים ומפעילים lakehouse ב-Google Cloud, כדאי לפעול לפי השיטות המומלצות הבאות:

  • אימוץ ארכיטקטורת מדליון: מבנה מחסן הנתונים בשכבות לוגיות מתקדמות (ברונזה להטמעה של נתונים גולמיים, כסף לנתונים שעברו ניקוי והתאמה, וזהב לצבירות ברמת העסק). כדי למקסם את ביצועי השאילתות ואת יכולת ההרצה שלהן במקביל, מומלץ להשתמש ב-BigQuery בשכבת הצריכה של נתוני הזהב.
  • שימוש בתבניות של סשנים לעומסי עבודה אינטראקטיביים: כדי לבצע ניתוח נתונים לצורך גילוי תובנות ולכתוב מחברות, אפשר להשתמש בתבניות של סשנים כדי ליצור סטנדרטיזציה של הגדרות הסביבה בצוותי פיתוח שונים, וכך לצמצם את הצורך בהגדרות חוזרות.
  • הקצאת מזהים מותאמים אישית לאצווה: כששולחים עומסי עבודה של אצווה ב-Apache Spark ללא שרתים, שאינם אינטראקטיביים, צריך להקצות שמות מותאמים אישית לאצווה ולמשימה. כך משתפרת הניראות (observability), ועכשיו אפשר לסנן ולעקוב אחרי הרצות של משימות ב-Cloud Logging ובמסוף Google Cloud .
  • הפעלת רישום ביומן לצורכי אבחון: בצינורות מורכבים של מהנדסי מערכות מידע, מומלץ להפעיל חבילות אבחון ולוודא שיומני מנהלי ההתקנים וההפעלה נשמרים כדי לעזור בפתרון בעיות ובמתן תמיכה.

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