אינטגרציה של Dune Analytics API: אנליטיקת on-chain במוצר שלכם

Dune Analytics API: היכן נשברת שאיבת נתונים אל המוצר

Dune Analytics API מטמיעים כאשר המוצר זקוק למטריקות on-chain בלי אינדקסר משלו: יתרות ארנקים, נפחים לפי pools, פעילות חוזים. השירות החיצוני כבר אסף את הנתונים ופרס אותם במארטי נתונים, השאילתה מחזירה תוצאה מוכנה, והמוצר מצייר אותה בממשק. הפשטות מטעה — מכאן מתחילה הפעלה של מארט נתונים של מישהו אחר, עם לוח הזמנים שלו לבנייה מחדש.

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

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

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

מה נותן למוצר גישה מובנית לנתוני בלוקצ'יין

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

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

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

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

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

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

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

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

עומק היסטוריית השאילתות

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

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

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

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

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

סכמות שאילתות, מפתחות גישה ונוהלי עדכון

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

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

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

מקרה בוחן: השהיית הנתונים הצטמצמה משעות לדקות

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

מה שינו

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

מה יצא

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

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

במה שירות נתונים מוכן שונה מאינדוקס עצמאי

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

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

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

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

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

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

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

מה יקרה אם שאילתות חיצוניות ישתנו או יישברו?

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

איך להגביל גישה ומתי אינטגרציה בכלל לא נחוצה?

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

נדבר על המשימה: אילו נתונים נדרשים להערכה מדויקת

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

כדאי לקבל מכם:

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