לוגיקה עסקית ב-Provisa¶

הבעיה¶

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

לחלקים מהבעיה הזו יש תשובות בתעשייה. שכבת מדדים, שנמכרת לרוב כשכבה סמנטית, מגדירה "הכנסה נטו" פעם אחת כדי שכל כלי יקרא אותה. ה-Open Data Product Standard (ODPS) מתאר מוצרי נתונים וה-Open Data Contract Standard (ODCS) מתאר חוזי נתונים. Provisa מייצאת את שניהם. כולם רעיונות טובים וכולם צוברים תאוצה, אבל כל אחד מכסה חלק אחד. השאלה הגדולה יותר היא איך הם משתלבים בנתונים מבוקרים ומנוהלים כמודל אחד, עקבי וניתן להרכבה. לוגיקה שגוזרת או משנה נתונים צריכה את אותה משילות כמו הנתונים עצמם: מי רשאי להשתמש בה, מה היא קוראת וכותבת, ולאן הולכות התוצאות שלה.

ערוצי האספקה מחמירים את המצב. הלוגיקה נבנית בתוך כל אחד מהם: שדה מחושב בכלי ה-BI, כלל ב-handler של ה-API, מסנן ב-resolver של האפליקציה. לכל ערוץ יש בסוף גרסה משלו לאמת, כך שאותה שאלה שנשאלת דרך שניים מהם מקבלת לעיתים רחוקות את אותה תשובה. בסוף, אנשים מוותרים: הם מתחילים לקבל את הבלגן כמחיר של התמחות ושל שירות לבעלי עניין רבים ושונים.

מהי לוגיקה עסקית¶

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

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

שלושה תפקידים¶

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

תפקיד	SQL	קריאה חיצונית	קוד
מערך נתונים	view, פקודת משפט	API או פרוצדורה שמחזירים שורות	מפענח קוד `@table`, `@stream`; פקודת `python` או `script`
ערך	ביטוי של view, מדד	—	פקודת `python` או `script`
שינוי	`INSERT`, `UPDATE`, `DELETE`, פקודת משפט	כתיבה ל-API, mutation, פרוצדורה	`@command`; פקודת `python` או `script`

קריאה חיצונית. ה-API של GraphQL, REST או gRPC של מערכת אחרת, או הפרוצדורה המאוחסנת של מסד נתונים, שנרשמו כפקודה.
טבלאות כארגומנטים. פקודה יכולה לקבל טבלאות כארגומנטים, כך שאפשר לבנות מערך נתונים ממערכי נתונים אחרים.
מדד. צבירה בעלת שם, שמוגדרת פעם אחת, למשל net_revenue כ-SUM(orders.amount) - SUM(orders.refunds). כל שאילתה מפרקת אותה לפי הממדים שהיא מבקשת, כך שה-warehouse, לוח המחוונים וה-API קוראים את אותו מספר.

תופעות לוואי נסתרות¶

תופעת לוואי נסתרת היא תופעה שאי אפשר לראות מהגדרת הכלל.

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

	תופעות לוואי אפשריות	מוגבלות על ידי
SQL	אין	—
קריאה חיצונית	תהליכי העבודה, ההתראות והשרשראות של המערכת האחרת עצמה	רשימת יציאה מותרת (HTTP, gRPC); אישורי גישה השמורים כסודות (פרוצדורות, פעולות מקור)
מפענח קוד	קריאות לשירותים ולרשתות חיצוניים; תוצאות שמשתנות; עלות	קוד מוצמד, טביעת אצבע מוצמדת של המארח, ארגז חול, מדידה
קוד במארח	קורא כל מה שהשרת יכול לקרוא (זיכרון, אישורי גישה, קבצים, רשת); יכול להרעיב את השרת או להפיל אותו	`commands.allow_host_code`, כבוי כברירת מחדל

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

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

קוד במארח הוא פקודת python או script. הוא רץ בתוך השרת עם כל הגישה של השרת, כך שקוד זדוני, באגי או חמדן יכול לקרוא כל מה שהשרת יכול, להרעיב אותו או להפיל אותו. זה נוח, ובטוח כשאתם סומכים על הקוד. המודל מחזיק רק הפניה (module:attr או שורת פקודה), כך שהקוד לא עובר עם הקידום. הוא רץ רק היכן ש-commands.allow_host_code מופעל.

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

מה המודל נותן לכם¶

הלוגיקה חיה במודל, לא בערוץ. כל ערוץ (SQL, GraphQL, REST, Arrow Flight, MCP והשאר) קורא את אותם כללים, כך שאותה שאלה מקבלת את אותה תשובה בכל מקום.
כל כלל רשום בתחום, עם הרשאות.
כל כלל מנוהל באותה דרך, לא משנה איך נכתב.
כל כלל גלוי ב-lineage.