פיתוח מערכת גריפת ספר פקודות בזמן אמת

למה איסוף order book scraping נכשל בעומסי שיא

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

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

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

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

לכן איסוף ספר הפקודות הוא прежде всего עניין של נכונות המצב, לא של מהירות הקריאה: השוואת תמונת מצב, אחסון עדכונים בזמן חיבור מחדש, בקרת השהיה ותיעוד מפורש של אובדנים. נסביר איך זה נסגר.

איסוף רציף של נתוני שוק: מהירות ושלמות התמונה

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

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

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

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

השוואת גישות לאיסוף קוטות: מה לבחור לפי המשימה

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

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

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

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

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

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

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

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

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

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

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

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

מה היה לפני

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

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

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

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

במה איסוף order book זורם שונה מסקירה תקופתית?

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

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

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

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

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

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

להלן תשובות להתנגדויות הנדסיות שעולות בשלב הערכת הארכיטקטורה.

איך מונעים כפילויות רשומות?

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

המקור מגביל את מספר הבקשות — מה אז?

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

איך מבינים שהנתונים לא התפצלו?

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

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

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

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

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