איסוף נתונים מפלטפורמות NFT: OpenSea, Blur, Magic Eden — 5 ימים

פרסינג של מרקטפלייסים ל-NFT: היכן נשבר איסוף הנתונים

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

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

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

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

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

מה משתנה לאחר הטמעת איסוף נתונים קבוע

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

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

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

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

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

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

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

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

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

שיטות והמגבלות שלהן

סדר הטמעה: מסיור מקורות ועד מסירה

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

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

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

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

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

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

ערכת מסירה: קונפיגורציות, סכימות ונוהלים

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

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

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

מקרה בוחן: השוואת ויטרינה מול נתונים משלוש פלטפורמות מסחר

מה היה לפני ההרצה

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

מה שינו ומה קיבלו

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

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

שלמות הנתונים עלתה מ-92% ל-99.5%, השוואת הוויטרינה הצטמצמה מיום עבודה לכמה דקות, ומחלקת הכשלים «לוט שהוחמץ, מחיר מיושן, כפילות» הפסיקה לשחזר את עצמה. המפעיל מטפל בפערים בודדים במקום בהסרה ידנית, ההרצה ארכה חמישה ימי עבודה — מאישור הסכימה ועד ההרצה האוטומטית הראשונה.

מה לעשות אם הפלטפורמה סגרה גישה פתוחה

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

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

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

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

שאלות שפותרות לפני תחילת איסוף הנתונים

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

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

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

מה לעשות אם אין מפתחות לממשק?

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

איך בודקים איכות נתונים?

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

נדון במשימה ונחזור עם אומדן ותוכנית

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

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

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