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

מדוע פרסור של ליסטינגים בבורסות קריפטו נשבר בזרם הנתונים

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

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

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

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

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

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

תגובה לליסטינג: דקות במקום שעות

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

שלמות המרשם: שיעור האירועים שהוחמצו

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

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

כשלים שלא מגיעים יותר למסחר

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

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

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

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

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

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

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

סדר העבודות: מסיור במקורות ועד מסירת תקנונים

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

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

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

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

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

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

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

איך זה היה

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

מה עשינו

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

• השהיה מפרסום ההודעה ועד להתראה: מ-3–5 שעות ל-40–90 שניות.
• דיוק זיהוי הדליסטינג: שיעור ההתראות הכוזבות ירד מ-12% לפחות מ-1%.
• אירועים שהוחמצו: בתקופת התצפית אף לא אחד, לעומת 2–3 בחודש במעבר ידני.
• הודעות מבוטלות: נרשמות לפני פתיחת המסחר, ולא בדיעבד.

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

במה שונה איסוף אירועים מטעינת ציטוטים?

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

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

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

ספקות טכניים נפוצים באיסוף נתונים מבורסות

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

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

כיצד להבדיל בין הודעה אמיתית לבין שמועה וזיוף?

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

עד כמה האיסוף עמיד בתקלות בצד הבורסה?

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

מה כולל הליווי של אוסף הנתונים?

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

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

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

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

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

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

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