איסוף נתוני עסקאות מבורסות קריפטו

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

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

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

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

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

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

מה נותנת קליטת עסקאות מסודרת: שלמות, מהירות, התאמה

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

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

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

שיטות איסוף עסקאות: מנויים בזרם והורדות באצוות

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

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

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

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

מביקורת מקורות ועד מסירת קו עסקאות

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

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

ערכת מסירה: תצורות, תרשיםים, נהלים

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

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

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

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

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

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

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

מדדים לפני ואחרי

• שיעור העסקאות האבודות: 0.3–0.5% מהרשומות → אפס פערים בהתאמות בקרה.
• זמן התכנסות התצוגות עם הפלטפורמה: 40–60 דקות → 2–3 דקות.
• שיעור ההשלמות הידניות: 12–15% מהטווחים → פחות מ-1%, ורק ביוזמת האנליטיקאי.
• התכנסות לפי מספר ונפח עסקאות: פער בטווח של 0.01% בחלון יומי.

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

מה לעשות אם ההורדה שלכם כבר עובדת, אבל הנתונים לא מתכנסים?

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

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

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

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

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

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

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

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

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

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

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

כיצד אתם מבינים שהנתונים מדויקים?

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

נדון במשימה: מקורות, נפחים, מצב הגעה

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

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

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

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