# נתונים מובנים למחצה מוסברים עבור צוותי אנליטיקה מודרניים

> למדו מהם נתונים מובנים למחצה, כיצד JSON, XML ויומנים פועלים באנליטיקה, וכיצד הצוות שלכם יכול לנתח ולשלב אותם עם פלטפורמות מבוססות בינה מלאכותית.

Source: https://www.electe.net/he/post/semi-structured-data

Site guide: https://www.electe.net/he/llms.txt

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

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

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

## פורמט הנתונים שסירב להישאר יציב

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

{"event": "view", "product\_id": "P-42", "channel": "web"}
{"event": "purchase", "product\_id": "P-42", "amount": 29.99, "promotion": "spring"}

כל רשומה מציינת את השדות שלה. לעומת זאת, טבלה קונבנציונלית מגדירה עמודות קודם, ואז שומרת כל רשומה בהתאם למבנה המשותף הזה. JSON שומר על תוויות שימושיות אך מאפשר לרשומות להיות שונות. השילוב הזה של **מבנה קריא למכונה ושדות משתנים** הוא הרעיון המרכזי מאחורי נתונים מובנים למחצה. [הסקירה של IBM על מבני נתונים](https://www.ibm.com/think/topics/structured-vs-unstructured-data) מתארת את התווך הזה בהקשר של מידע מובנה ולא מובנה.

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

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

הגמישות הזו הפכה לשימושית יותר ויותר ככל שחוקרי מסדי נתונים בחנו כיצד לשאול ולשלב מידע מהאינטרנט שלא חלק סכמה מוגדרת מראש. גישת **schema-on-read** מאפשרת למערכת לפרש שדות במהלך הייבוא או השאילתה במקום לדרוש שכל מקור יעוצב מחדש מראש.

## כיצד JSON ו-XML הפכו לעמוד השדרה של נתונים גמישים

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

XML הגיע לאבן דרך רשמית כאשר קונסורציום הרשת העולמית (World Wide Web Consortium) פרסם את **XML 1.0 כהמלצה (Recommendation) ב-10 בפברואר 1998**. התקן תיאר דרך להגדיר, לאמת ולשתף פורמטים של מסמכים ברחבי הרשת. XML מייצג מידע באמצעות אלמנטים ומאפיינים היררכיים, כך שמסמך יכול לבטא יחסים ולא רק ערכים. [ELECTE מסביר כיצד לקרוא XML](https://www.electe.net/post/leggere-file-xml) עבור קוראים המעוניינים במבוא מעשי לפענוח הפורמט הזה.

JSON נקט בדרך קלה יותר, תוך שימוש באובייקטים הבנויים מזוגות מפתח-ערך ובמערכים לייצוג אוספים. המפרט האינטרנטי המתוקנן שלו, **RFC 4627, פורסם ב-2006**. JSON הפך לנפוץ ביישומי אינטרנט וב-API-ים, שבהם מטענים קומפקטיים ופענוח פשוט מתאימים לחילופי מידע בין מערכות. XML נותר שימושי עבור מסמכים היררכיים וחילופי מידע ארגוניים מבוססים.

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

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

## ארבעת האתגרים שהופכים נתונים חצי-מובְנים לקשים לניתוח

לוח מחוונים (dashboard) קמעונאי יכול להיכשל גם כאשר כל רשומה נכנסת היא JSON תקין. הבעיה היא לעיתים קרובות שהרשומות שונות באופן שמנתח פשוט מקבל אך דוח אינו מצפה לו. ארבע סוגיות ראויות לתשומת לב מיוחדת.

- **שמות שדות משתנים:** אירוע תשלום אחד קורא לערך `amount`; אחר קורא לו `total`. שאילתה המצפה לשם אחד עלולה לפספס רשומות תחת השם האחר, ולהניב תוצאות חלקיות.
- **סוגים נסחפים:** שדה מגיע כמספר באירוע אחד וכמחרוזת באחר. צבירה עלולה להיכשל, או שצינור עיבוד עלול להמיר את הערך הבלתי צפוי ל-null מבלי להבהיר את הסיבה.
- **שדות הם אופציונליים:** אירוע ללא מאפיין קידום מכירות או מכשיר אינו בהכרח פגום. אך כל דוח בהמשך השרשרת צריך להתייחס לערכים חסרים באופן מכוון, במקום להניח שכל רשומה מכילה אותם.
- **מערכים מוסיפים שכבה:** רכישה עשויה לכלול מערך של מוצרים. כדי לדווח ברמת המוצר, ייתכן שצוות יצטרך להרחיב את המערך הזה או להשתמש בפונקציות שאילתה שמערכת ה-BI שלו אינה מטפלת בהן בקלות.

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

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

> **כלל מעשי:** התייחסו למטען הניתן לפיענוח כאל קלט, לא כהוכחה שהשדות שלו עקביים דיים לניתוח.

## טכניקות פענוח ועיבוד מקדים שניתן ליישם כבר היום

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

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

לאחר מכן בנו מודל עבודה של מה שמגיע. הסקת סכימה (schema inference) במנוע עיבוד כמו Apache Spark יכולה לסייע בזיהוי נתיבים וסוגים סבירים. מאמתי JSON Schema יכולים לבדוק האם שדות קריטיים עומדים בכללים המוסכמים. הסקה היא כלי גילוי שימושי, לא תחליף להחלטה אילו שדות העסק שלכם תלוי בהם.

לדוגמה, צינור קמעונאות עשוי למפות את `amount` ואת `total` לשדה הכנסות משותף, תוך המרה מפורשת של מחרוזות מספריות מקובלות. ערכים בלתי צפויים צריכים להיות מסומנים או מובדלים (quarantined) במקום להיכפות ללא התראה. זרימת עיבוד קלה עשויה להיות:

`ingest → parse → validate → normalize → test → publish`

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

עבור צוותים המתכננים נתוני קמפיין בין מערכות שיווק, [מדריך ניהול הנתונים של doornoc](https://doornoc.com/blog/campaign-data-management) מציע הקשר שימושי לארגון המידע הזורם בין פלטפורמות. יהיה המקור אשר יהיה, הוסיפו בדיקות איכות לפני הפרסום: אמתו שדות חשובים, תעדו אילו טרנספורמציות הופעלו, והפכו חריגים לגלויים עבור האנשים האחראים על הדוחות.

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

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

מבחן ביצועים (benchmark) של Databricks שהשתמש בנתונים חצי-מובְנים שמקורם ב-TPC-DS דיווח כי **ייצוג ה-Variant של Apache Parquet קרא JSON מהר פי 8 לעומת אחסון מחרוזות רגיל**. באותו מבחן, פירוק (shredding) הנתונים לעמודות ניתנות לשאילתה הפך את הכתיבה **לאיטית יותר ב-20%–50%**, בעוד שהקריאה הייתה **מהירה יותר בכ-30%**. התוצאות הללו תלויות בעומס העבודה הספציפי, ואינן הבטחה לאותם שיפורים בכל מחסן נתונים. [ההסבר של Databricks על Variant ב-Parquet](https://www.databricks.com/blog/introducing-variant-new-open-standard-semi-structured-data-apache-parquettm-delta-lake) מתאר את מבחן הביצועים ואת הפשרה הארכיטקטונית.

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

עבור פיד עתיר-הטמעה (ingestion), מזעור השינויים (transformation) יכול להיות נקודת פתיחה סבירה. עבור לוחות מחוונים או זיהוי חריגות שמבצעים שאילתות חוזרות על אותם שדות, חילוץ סלקטיבי עשוי לחסוך עבודה בזמן הקריאה. בצעו בנצ'מרק לשאילתות שהצוות שלכם מריץ, כולל ההתנהגות שלהן מול מערכים מקוננים (nested-array) ומסננים. [מדריך זה לבחירה בין אגם נתונים למחסן נתונים](https://www.electe.net/post/data-lake-vs-data-warehouse) יכול לסייע למסגר את החלטת האחסון הרחבה יותר.

## מדוע Schema-on-Read עדיין זקוק לאסטרטגיית סכמה

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

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

אסטרטגיית סחיפה (drift) אמינה יכולה להתחיל בארבעה הרגלים:

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

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

> Schema-on-read לא מבטל סכמות. הוא הופך את הצוותים לאחראים על ניהולן לאורך הדוחות והמודלים שקוראים את הנתונים.

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

## פרטיות ואבטחה בתוך רשומות מקוננות

הרשאת מסד נתונים יכולה להגן על טבלה אך לפספס ערך רגיש החבוי בתוך אובייקט מקונן, מערך, או שדה שהתווסף לאחרונה. מטען נתונים (payload) של API עשוי לכלול כתובת אימייל בתוך אובייקט לקוח, בעוד ששדה טקסט חופשי מכיל מידע שהמקור מעולם לא התכוון לחשוף לכל אנליסט.

סקר של Cloud Security Alliance דיווח שנתונים חצי-מובְנים מהווים **כ-21% מנתוני הארגון בקרב הארגונים שנסקרו**. אותו הסקר דיווח ש**ל-56% מהמשיבים הייתה רק נראות חלקית למיקומי הנתונים**, כאשר אבטחה, ממשל נתונים, פרטיות ועמידה ברגולציה נמנו עם החששות המובילים. [הודעת המחקר של Cloud Security Alliance](https://cloudsecurityalliance.org/press-releases/2026/03/31/unstructured-data-surges-as-enterprises-struggle-to-maintain-visibility-and-security-cloud-security-alliance-study-finds) מספקת את ההקשר לסקר.

צוותים יכולים לשפר את תהליך הגילוי על ידי סריקה רקורסיבית של תוכן מקונן ושילוב בדיקות תבנית עם הקשר, במקום לחפש רק שם שדה מסוים. עליהם גם לעקוב אחר שושלת (lineage) עבור שדות רגישים וליישם בקרות גישה ברמת השורה והשדה בהתאם לאופן שבו הנתונים ישמשו. הכללים צריכים לקחת בחשבון גם את הסיכון וגם את מטרת העסק: עריכת-יתר (over-redaction) עלולה להפוך ניתוח תפעולי לבלתי שמיש, בעוד שערכים שהוחמצו עלולים ליצור חשיפה.

למבוא מעשי לתיעוד היכן זורם מידע רגיש, [מיפוי נתונים לעמידה ברגולציה](https://refer.sourcex.si/guides/data-mapping-for-privacy-compliance) יכול לעזור לצוותים לארגן את העבודה הזו. שלבו זאת עם [בקרות אבטחה עבור צוותי אנליטיקה](https://www.electe.net/post/security-and-privacy). יש לבדוק מחדש את הגנות הפרטיות כאשר הסכמות משתנות, ולא להתייחס אליהן כאל הגדרת מסד נתונים חד-פעמית.

## שילוב מקורות חצי-מובְנים עם פלטפורמת אנליטיקה מבוססת בינה מלאכותית

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

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

ממשל נתונים משתרע גם מעבר לפורמט המטען (payload). כאשר עסק משתמש בנתונים חיצוניים או מורשים, עליו להבין את השימוש המותר, את המקור, ואת דרישות הטיפול. צוותים הבוחנים שאלות אלו יכולים [לעיין באפשרויות רישוי נתונים ארגוניים](https://sourcex.si/ai-training-data) כחלק מסקירת ניהול הנתונים הרחבה יותר שלהם.

לפני פרסום מקור חדש למשתמשי העסק, עברו על רשימת הבדיקה הבאה:

- **קליטה (Ingestion):** תפסו את המטען (payload) בצורה אמינה ושמרו מספיק הקשר כדי לחקור בעיות.
- **אסטרטגיית סכמה:** הגדירו את השדות הקריטיים והחליטו כיצד להתמודד עם תוספות, שינויי שמות ושינויי סוג.
- **אחסון:** בחרו ייצוג שמתאים לשאילתות ולדפוס הקליטה.
- **ממשל (Governance):** אתרו ערכים רגישים והחילו בקרות שעוקבות אחרי הנתונים לאורך כל מסלולם.
- **התאמה עסקית:** חברו את הניתוח המתקבל למדד KPI ברור, כגון זמינות מלאי או דיוק תחזיות, והפכו חריגות לגלויות.

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

---

ELECTE, פלטפורמת אנליטיקת נתונים מבוססת בינה מלאכותית לעסקים קטנים ובינוניים, מחברת בין נתוני עסק ועוזרת לצוותים להפוך אותם לדוחות, תחזיות ותובנות ישימות. גלו כיצד [ELECTE](https://www.electe.net) יכולה לעזור לצוות שלכם להביא מקורות נתונים חצי-מובְנים לתוך תהליך אנליטי ברור יותר.