המלצות לשדרוג
בדף הזה מפורטות המלצות לשדרוג לגרסאות חדשות מתוך Cortex Framework Data Foundation בהתאמה אישית. בכל גרסה, צוות Cortex מתחייב לצמצם את השיבושים בזמן שהוא מוסיף תכונות חדשות ל-Cortex Framework. בעדכונים החדשים יש עדיפות לתאימות לאחור. עם זאת, המדריך הזה יעזור לכם לצמצם את הבעיות האפשריות.
Cortex Framework Data Foundation מספקת קבוצה של תבניות ותוכן מוגדרים מראש כדי להפיק ערך מהר יותר מנתונים ששוכפלו אל BigQuery. ארגונים מתאימים את התבניות, המודולים, ה-SQL, סקריפטים של Python, צינורות עיבוד נתונים ותוכן אחר שסופק לצרכים שלהם.
רכיבי ליבה
התוכן של Cortex Framework Data Foundation מבוסס על עיקרון הפתיחות. ארגונים יכולים להשתמש בכלים שהכי מתאימים להם כשהם עובדים עם מודלים של נתונים ב-BigQuery. הפלטפורמה היחידה שהשכבה הבסיסית תלויה בה באופן הדוק היא BigQuery. אפשר להשתמש בכלים האחרים לפי הצורך:
- שילוב נתונים: אפשר להשתמש בכל כלי שילוב שיש לו קישוריות עם BigQuery, בתנאי שהוא יכול לשכפל טבלאות ומבנים של נתונים גולמיים. לדוגמה, טבלאות גולמיות צריכות להיות דומות לסכימה שבה הן נוצרו ב-SAP (אותם שמות, שדות וסוגי נתונים). בנוסף, כלי השילוב צריך לספק שירותי טרנספורמציה בסיסיים, כמו עדכון של סוגי נתוני היעד לצורך תאימות ל-BigQuery, וגם הוספה של שדות נוספים כמו חותמת זמן או דגל פעולות להדגשה של רשומות חדשות ורשומות שעברו שינוי.
- עיבוד נתונים: סקריפטים לעיבוד נתונים של Change Data Capture (CDC) מספקים עבודה עם Managed Service for Apache Airflow (או Apache Airflow) הם אופציונליים. לעומת זאת, הצהרות ה-SQL נוצרות בנפרד מהקבצים הספציפיים ל-Airflow ככל האפשר, כדי שהלקוחות יוכלו להשתמש בקובצי ה-SQL הנפרדים בכלי אחר לפי הצורך.
- המחשת נתונים: למרות שמוצעים תבניות של לוחות בקרה ב-Looker שמכילות המחשות ומינימום לוגיקה, הלוגיקה הבסיסית נשארת זמינה בשכבת הנתונים ב-BigQuery. זאת כדי לאפשר לכם ליצור המחשות באמצעות כלי הדיווח שתבחרו.
יתרונות מרכזיים
התשתית של Cortex Framework Data Foundation מתוכננת להתאמה לצרכים עסקיים שונים. הרכיבים שלה בנויים בצורה גמישה, כך שארגונים יכולים להתאים את הפלטפורמה לדרישות הספציפיות שלהם וליהנות מהיתרונות הבאים:
- פתיחות: משתלב בצורה חלקה עם מגוון כלים לשילוב נתונים, לעיבוד נתונים ולהצגה חזותית של נתונים, מעבר ל-BigQuery.
- התאמה אישית: ארגונים יכולים לשנות ולהרחיב רכיבים מוכנים מראש כמו תצוגות SQL כדי להתאים אותם למודלים של הנתונים וללוגיקה העסקית שלהם.
- אופטימיזציה של הביצועים: אפשר לשנות טכניקות כמו חלוקה למחיצות, בדיקות של איכות הנתונים וקיבוץ לאשכולות, בהתאם לעומסי העבודה ולנפחי הנתונים.
- תאימות לדור קודם: Cortex שואף לשמור על תאימות לדור קודם בגרסאות עתידיות, כדי לצמצם את ההפרעות להטמעות קיימות. בנתוני הגרסה אפשר למצוא מידע על שינויים בגרסאות.
- תרומה לקהילה: מעודדת שיתוף ידע ושיתוף פעולה בין משתמשים.
תהליך העדכון
בקטעים הבאים מוסבר על דרך אחת שבה מפתחים יכולים לעדכן את הקוד שלהם באמצעות מאגר Cortex Framework Data Foundation, תוך שמירה על ההתאמות האישיות שלהם. שימוש בסקריפטים של פריסה שסופקו מראש בצינורות עיבוד נתונים של CI/CD. עם זאת, ארגונים יכולים להשתמש בכלים ובמתודולוגיות חלופיים שמתאימים להעדפות שלהם, כמו Dataform או כלי אוטומציה שסופקו על ידי מארחי Git שונים, כמו GitHub actions.
הגדרת מאגר
בקטע הזה מפורטת גישה אחת להגדרת המאגר. לפני שמבצעים את השלבים האלה, מומלץ להכיר היטב את Git.
מבצעים Fork למאגר הליבה: יוצרים Fork של מאגר Cortex Framework Data Foundation. הפיצול מאפשר למאגר הזה להמשיך לקבל עדכונים מהמאגר Google Cloud , וליצור מאגר נפרד עבור המאגר הראשי של החברה.
יצירת מאגר של החברה: יוצרים מארח Git חדש למאגר של החברה (לדוגמה, Cloud Source). יוצרים מאגר עם אותם שמות כמו במאגר המפוצל במארח החדש.
מאחלים את מאגר החברה: מעתיקים את הקוד מהמאגר המפוצל אל מאגר החברה החדש שיצרתם. מוסיפים את המאגר המקורי שהתפצל כמאגר מרוחק במעלה הזרם באמצעות הפקודה הבאה, ומוודאים שהמאגר המרוחק נוסף. כך נוצר חיבור בין המאגר של החברה לבין המאגר המקורי.
git remote add google <<remote URL>> git remote -v git push --all googleאימות הגדרת המאגר: מוודאים שהמאגר של החברה מכיל את הקוד המשוכפל ואת ההיסטוריה. אחרי השימוש בפקודה, אמורים להופיע שני מאגרי Git מרוחקים, origin והמאגר שהוספתם:
git remote -v:עכשיו יש לכם את המאגר, המאגר של החברה, שבו מפתחים יכולים לשלוח את השינויים שלהם. מפתחים יכולים עכשיו לשכפל ולעבוד על ענפים במאגר החדש.
מיזוג השינויים עם גרסה חדשה של Cortex
בקטע הזה מתואר תהליך המיזוג של שינויים מהמאגר של החברה ושינויים שמגיעים ממאגר Google Cloud .
עדכון של עותקים מסועפים: לוחצים על סנכרון של עותק מסועף כדי לעדכן את העותקים המסועפים של המאגר עם השינויים ממאגר Google Cloud . לדוגמה, השינויים הבאים בוצעו במאגר של החברה. בנוסף, בוצעו שינויים נוספים במאגר Data Foundation על ידי Google Cloud בגרסה חדשה.
- יצירת תצוגה חדשה ב-SQL ושילוב השימוש בה
- שינוי תצוגות קיימות
- החלפנו סקריפט שלם בלוגיקה משלנו
רצף הפקודות הבא מוסיף את המאגר המחובר כמאגר מרוחק במעלה הזרם כדי למשוך ממנו את הגרסה המעודכנת כ-GitHub, ומבצע checkout של הענף הראשי שלו כ-GitHub-main. לאחר מכן, בדוגמה הזו מתבצעת הוצאה של הענף הראשי מהמאגר של החברה ב- Google Cloud Source ונוצר ענף למיזוג בשם
merging_br.git remote add github <<github fork>> git fetch github main git checkout -b github-main github/main git checkout main git checkout -b merging_brיש כמה דרכים לבנות את התהליך הזה. תהליך המיזוג יכול להתבצע גם בפיצול ב-GitHub, או להיות מוחלף במיזוג מחדש במקום במיזוג, וענף המיזוג יכול להישלח גם כבקשת מיזוג. השינויים האלה בתהליך תלויים במדיניות הארגונית הנוכחית, בהיקף השינויים ובנוחות.
אחרי שמגדירים את זה, אפשר להשוות את השינויים הנכנסים לשינויים המקומיים. מומלץ להשתמש בכלי בסביבת פיתוח משולבת (IDE) גרפית לבחירתכם כדי לראות את השינויים ולבחור מה למזג. לדוגמה, Visual Studio.
מומלץ לסמן התאמות אישיות באמצעות תגובות שקל לראות, כדי להקל על תהליך ההשוואה.
מתחילים את תהליך המיזוג: משתמשים בענף שנוצר (בדוגמה הזו, הענף נקרא
merging_br) כדי למזג את כל השינויים ולמחוק את הקבצים. כשמוכנים, אפשר למזג את הענף הזה חזרה לענף הראשי או לענף אחר במאגר של החברה כדי ליצור בקשת מיזוג. מתוך ענף המיזוג שהוצא ממאגר המאגרים הראשי של החברה שלך (git checkout merging_br), ממזגים את השינויים הנכנסים מהמזלג המרוחק.## git branch -a ## The command shows github-main which was created from the GitHub fork ## You are in merging_br git merge github-main ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`הפקודה יוצרת רשימה של התנגשויות. משתמשים בהשוואה הגרפית של סביבות הפיתוח המשולבות כדי להבין את השינויים ולבחור בין נוכחי, נכנס ושניהם. כאן נכנסת לתמונה האפשרות להוסיף הערה בקוד לגבי ההתאמות האישיות. אפשר לבחור לבטל את כל השינויים, למחוק קבצים שלא רוצים למזג ולהתעלם משינויים בתצוגות או בתסריטים שכבר התאמתם אישית.
מיזוג השינויים: אחרי שמחליטים אילו שינויים רוצים להחיל, בודקים את הסיכום ומבצעים את השינויים באמצעות הפקודה:
git status ## If something doesn't look right, you can use git rm or git restore accordingly git add --all #Or . or individual files git commit -m "Your commit message"אם אתם לא בטוחים לגבי אחד מהשלבים, כדאי לעיין במאמר ביטול פעולות בסיסיות ב-Git.
בדיקה ופריסה: עד עכשיו המיזוג בוצע רק לענף "זמני". בשלב הזה מומלץ להריץ פריסת בדיקה מהסקריפטים של
cloudbuild\*.yamlכדי לוודא שהכול מתבצע כמצופה. בדיקות אוטומטיות יכולות לעזור לייעל את התהליך הזה. אחרי שמוודאים שהסתעפות המיזוג נראית טוב, אפשר להוציא את הסתעפות היעד הראשית ולמזג לתוכה את הסתעפותmerging_br.