מעבר מ-SQL ל-KQL ב-Microsoft Fabric: מדריך למפתחים
By Mirko Peters ·
למדו כיצד לעבור מ-SQL ל-KQL ב-Microsoft Fabric במדריך למפתחים שמכסה מיפוי בין פסקאות, שינויים בתחביר ושאילתות סדרות עתיות.
Automatically translated with AI from the original post. Read the English original

העברת עומסי עבודה אנליטיים מ-SQL מסורתי לשפת השאילתות של Kusto (KQL) ב-Microsoft Fabric יכולה להיראות מאיימת עבור מנהלי בסיסי נתונים. מדריך זה בוחן את המיפויים המבניים הישירים בין פסקאות SQL לאופרטורים של KQL, ומראה כיצד להפוך את הניסיון הקיים שלכם במסדי נתונים לחקירות מהירות של נתוני סדרות עתיות, בלי עקומת למידה ראשונית תלולה.
עיקרי הדברים
- KQL מחליפה את פסקת 'FROM' של SQL על ידי הצבת שם הטבלה בתחילת השאילתה.
- סימן הצינור (|) ב-KQL משרשר פעולות עוקבות, ומחקה את האופן שבו מנוע השאילתות מעבד את הנתונים באופן לוגי.
- 'SELECT' ב-SQL מתמפה לאופרטור 'project' ב-KQL, ואילו פעולות 'GROUP BY' הופכות ישירות ל-'summarize'.
- Microsoft Fabric כולל סיוע מובנה בתרגום, שמאפשר למפתחים להתנסות וללמוד באמצעות מקבילות פקודות מעשיות.
- הבנת רגישות לאותיות רישיות וקיבוץ זמנים (time-bucket binning) הם שלבים חיוניים לכתיבת שאילתות KQL מוכנות לייצור.
המעבר המנטלי מ-SQL ל-KQL
כשפותחים לראשונה מסד נתונים של KQL ב-Microsoft Fabric, התחביר נראה זר במשך כחמש דקות. SQL מסורתי מחייב לעטוף שאילתות בפסקאות מסוימות, ולרוב מתחיל ב-'SELECT' ודוחף את טבלת המקור לפסקת 'FROM' שמוטמעת באמצע ההצהרה. KQL הופכת את זה לגמרי.
ב-KQL תמיד מתחילים משם הטבלה. אם הטבלה שלכם נקראת service_events, זו השורה הראשונה והמוחלטת. אין מילים נוספות שעוטפות את השאילתה. לאחר שהגדרתם את הטבלה, כל שלב נוסף משורשר באמצעות סימן הצינור (|). הגישה הזו מאלצת לקרוא שאילתות באופן טבעי מלמעלה למטה: מתחילים בכל האירועים, משאירים רק הכישלונות, סופרים אותם לפי שעה, ומדרגים את המקרים הגרועים ביותר.
מיפוי פסקאות SQL לאופרטורים של KQL
אם אתם כבר מכירים SQL, השתמשו בניסיון הזה כגשר ולא כמכשול. מנוע Kusto שבו משתמשים ב-Eventhouse של Fabric כולל מקבילות ישירות כמעט לכל פעולת SQL סטנדרטית, אם כי הן מופיעות בסדר שמותאם לניתוח טלמטריה ולוגים.
דגימה והקרנה של נתונים
כשחוקרים טבלה לא מוכרת ב-SQL, אולי תכתבו שאילתה מהירה שמגבילה את מספר השורות. ב-KQL משתמשים באופרטור take. הרצת service_events | take 10 נותנת דגימה קטנה של רשומות לבדיקת שמות עמודות, פורמטים של תאריכים וערכי סטטוס.
לבחירת עמודות ספציפיות, בדומה לפסקת 'SELECT' ב-SQL, KQL משתמשת באופרטור project. חשוב לציין ש-project מופיע מאוחר יותר בזרימת השאילתה. אפשר גם לשנות שמות עמודות תוך כדי ההקרנה, וזה עוזר מאוד כשמכינים דוחות לבעלי עניין שאינם בצוות ההנדסה.
סינון והרחבת מאפיינים
סינון שורות ב-KQL נשען על האופרטור where. אפשר לשרשר כמה תנאי where בשורות נפרדות, וזה משפר משמעותית את קריאות השאילתה כשמתמודדים עם לוגיקה מורכבת:
service_events | where timestamp > ago(24h) | where status_code == 500
אם הנתונים שלכם חסרים מאפיין ספציפי הנדרש לניתוח, האופרטור extend יוצר עמודה מחושבת זמנית, מבלי לשנות את טבלת המקור. זה אידיאלי לחילוץ ערכים ממחרוזות שגיאה גולמיות או לסיווג חותמות זמן לצורך צבירות עתידיות.
טיפול בצבירות ובנתוני סדרות זמן
בשאילתות SQL, קיבוץ נתונים מתבצע באמצעות הפסקה 'GROUP BY'. ב-KQL, האופרטור summarize מטפל בכל החישובים המקובצים, כגון ספירות, ממוצעים, מינימום ומקסימום. לדוגמה, כך נראית ספירת כשלים לפי שם שירות:
service_events | summarize failure_count = count() by service_name
כשעובדים עם לוגים וטלמטריה ב-Fabric, זמן הוא כמעט תמיד הממד המרכזי לקיבוץ. KQL משתמשת בפונקציה bin() כדי לקבץ חותמות זמן לפרקי זמן קבועים, כגון שעתיים או חמש דקות, ובכך הופכת רשימה עצומה ורועשת של רישומי עסקאות בודדים לציר זמן נקי וברור שניתן לפעול לפיו.
סיכום וצעדים הבאים
שליטה ב-KQL בתוך Microsoft Fabric פותחת יכולות עוצמתיות לאינטליגנציה בזמן אמת, ניטור טלמטריה ואנליטיקת לוגים. על ידי מיפוי הידע הקיים שלכם ב-SQL לאופרטורים של KQL המתאימים לצינורות עיבוד נתונים, תוכלו לקצר את זמן פתרון התקלות ולהתחיל לחלץ ערך מיידי מנתוני הזרמה. כדי להעמיק בארכיטקטורה הרחבה של בתי האירועים ומנועי האנליטיקה בזמן אמת, האזינו לפרק המלא לתובנות ממומחים ולאסטרטגיות מעשיות.