הגדרת אנליטיקת בלוקצ'יין ב-Dune: SQL, לוחות מחוונים, API

הגדרת Dune Analytics: היכן נופל איסוף נתונים ידני

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

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

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

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

הגדרת Dune Analytics סוגרת בדיוק את החלק הזה: שאילתות SQL מבוצעות מעל נתוני בלוקצ'יין שכבר עברו אינדוקס, ולכן המדד נספר פעם אחת ולפי הגדרה אחת. הרשת התעדכנה — התעדכן גם תוצאת השאילתה, בלי ייצוא ידני ובלי התאמות.

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

מה משתנה אחרי ההטמעה: אפקט מדיד

האפקט של Dune נמדד ברמת התהליך, ולא כ״נהיה נוח יותר״. לפני ההטמעה, שאלה חדשה לנתוני בלוקצ'יין היא ייצוא נפרד, התאמה ידנית והמתנה של יום-יומיים; אחרי — שאילתה מעל חוזים שכבר עברו אינדוקס, שעונה תוך דקות. האנליסט מפסיק להיות צוואר בקבוק, ותור השאילתות מהמוצר כבר לא מצטבר.

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

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

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

גישות לאיסוף מדדים: השוואת אפשרויות

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

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

שלוש אפשרויות והגבולות שלהן

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

שלבי ההגדרה: מביקורת מקורות ועד מסירה

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

1. ביקורת מקורות. רשימת רשתות, כתובות וטבלאות מאומתות — הבסיס לכל השאילתות הבאות.
2. סכימת נתונים ומדדים. מסכימים מה משמעותם של ״כתובת פעילה״, ״נפח״ ו״קוהורטה״: בלי הגדרות אחידות המספרים בלוח לא יתאימו לחשבונאות הפנימית.
3. כתיבת שאילתות. SQL עם פרמטרים לפי תקופות ורשתות; חישובים לשימוש חוזר מוציאים לתצוגות נפרדות, כדי שלוחות לא ישכפלו לוגיקה.
4. בדיקת התאמה. משווים דגימות מול מקור בלתי תלוי ומנתחים פערים עד להסרתם — רק אחרי זה אפשר לסמוך על המספרים.
5. הרכבת לוחות. לוח מחוונים להחלטות קונקרטיות: דינמיקה, התפלגות, משתתפים גדולים, ולא גרפים לשם גרפים.
6. מסירת הרשאות. תפקידים בסביבת העבודה, הוראות לשאילתות ולמדדים, סדר תיקונים בלי המעורבות שלנו.

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

ארטיפקטים: שאילתות, לוחות, נהלים, הרשאות

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

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

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

מקרה בוחן: פערים בדיווח צומצמו לאפס

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

בחודש יצאו כ-40 ייצואים ידניים, ההכנה ארכה יומיים, והפערים בין הדוח לנתוני הרשת הגיעו ל-6–8% — חלק מהטרנזקציות אבדו בהעתקה, וחלק נספרו פעמיים אחרי העברות פנימיות.

מה שינו

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

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

התוצאה במדדים

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

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

במה שונה לוח מוכן מאיסוף נתונים עצמאי?

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

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

הבחירה מצטמצמת לשלושה מצבים:

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

ספקות טכניים נפוצים לפני ההתחלה

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

החוזה עודכן — הדוחות ימשיכו לעבוד?

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

איך לוודא שהמספרים נכונים?

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

איך למסור נתונים החוצה בלי לחשוף יותר מדי?

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

נדון במשימה: מה נדרש מכם כדי להתחיל

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

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

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