Volume screener: איפה נשברת בנייה עצמית
אנומליות של נפח מסחר חיות שניות בודדות, והגרסה הראשונה של הסקרינר לומדת עליהן רק כעבור דקות.
פיתוח volume screener מתחיל לרוב בסקירה (polling) של הממשק הציבורי של הבורסה עבור עשרות זוגות — וכבר במאה כלים סקרינר הבורסה העצמאי נתקל במגבלות של בקשות לבורסה: מכסת הפניות המוקצית נאכלת תוך עשרות שניות, בתגובה מגיעה הגבלה, ולאחריה חסימה זמנית של הכתובת. האות או מאחר, או מגיע כבר אחרי שהתנועה נאכלה.
העקיפה ברורה — זרם עסקאות במקום polling. הוא נשבר בניתוקים: הערוץ נופל לדקות, ואם לא לשמור סמן (cursor) של האירוע האחרון שעובד, לא להכניס עסקאות באופן אידמפוטנטי לפי המזהה שלהן ולא להשלים את הקטע החסר מהארכיון — הנפח בחלון מוכפל. בגרף זה נראה כמו פרץ שלא היה, והכניסה מתבצעת על אנומליה כוזבת.
הסדק השלישי — פער בין מדדים ממקורות שונים. נפח במטבע בסיס ובמטבע מצוטט, ספוט ושוק חוזים, גבולות חלון שונים ואזורי זמן שונים מניבים מספרים שלא מתיישבים זה עם זה.
כל עוד אין נרמול אחיד והמרה ליחידה משותפת, סקרינר הנפחים של מטבעות קריפטו מרעיש בהתראות ומאבד את אמון הסוחרים — והם חוזרים לבדיקה ידנית של ספר הפקודות.
כל שלושת הצמתים — איסוף, התאוששות לאחר ניתוק ונרמול — נסגרים לפני שמופיעה ההתראה הראשונה. להלן נפרק איך זה בנוי בפועל ואיפה עובר הגבול בין פיתוח פנימי לבין מערכת מוכנה.
מה נותן סקרינר נפחים מוכן על נתוני בורסה
סקרינר נפחים למסחר לא מחשב נפח מוחלט, אלא סטייה מהפרופיל של הכלי עצמו: חציון וסטייה חציונית על חלון נע במקום ממוצע. נפח ממוצע נשבר מעסקה גדולה אחת, החציון לא — ולכן פרץ בשוק דליל לא נראה כאנומליה עד שהוא באמת כזו.
מדריך הזוגות והערכת הנזילות נשלפים ממקורות פתוחים, למשל CoinGecko, ומצליבים אותם עם מה שהבורסות עצמן מספקות.
ניטור פרצים בנפח מתבצע על זרם העסקאות: האות נוצר ברגע הגעת העסקה, ולא בסגירת הנר, ולכן השהיית האות היא שברירי שנייה. הנפח מנורמל לתנודתיות של הכלי ומובא לסף בסיגמות, כך שאותו סף עובד גם על זוגות גדולים וגם על זוגות בדלי נזילות. דה-דופליקציה מדביקה סדרת עסקאות של מהלך אחד להתראה אחת, כדי שהסוחר לא יקבל חמש הודעות על אירוע אחד.
דיוק האותות של הסקרינר נשען על מסננים, ולא על כיוונון הסף: עומק מינימלי של ספר הפקודות, מרווח (spread) מקסימלי, אישור בדקת נפח שנייה. אל הסוחר מגיעה בערך רבע מכמות מה שנותן סף 'חשוף' לנפח, ובמקביל פספוס של אנומליות אמיתיות נשאר בגבולות טעות המדידה.
סוג הכשלים שמפסיק להגיע לסוחר הוא אנומליה בשוק שבו הזמנה אחת מזיזה את המחיר: כניסה לפיה מייצרת החלקה (slippage) גדולה מהתנועה הפוטנציאלית. אנחנו לוגים מה בדיוק סינן כל מסנן, ועל פי הנתונים האלה מכיילים את הספים לכלי מסחר ולשעות מסחר ספציפיות, ולא לשוק ממוצע.
מצבי העבודה של הסקרינר: זרם, חישוב מחדש באצווה, היברידי
מצב העבודה של הסקרינר קובע מה המזמין מקבל קודם — אות על אנומליה או תמונה מתיישבת של הכלי. עיבוד זרם של עסקאות קורא את הפיד מערוצי הבורסה וצובר נפחים בחלונות נעים: הפרץ נראה שניות אחרי העסקה, אבל בעת ניתוק החיבור קטע מהפיד הולך לאיבוד ללא שוב.
חישוב מחדש באצווה של ההיסטוריה לוקח עסקאות ונרות לתקופה מהארכיון ומחשב את המדדים מחדש — הנתונים מתיישבים עד העסקה האחרונה, אבל התוצאה מגיעה באיחור.
המצב ההיברידי של הסקרינר משלב את השניים: הזרם מנהל מדדים בזמן אמת ומספק אותות, וחישוב מחדש פעם בכמה דקות מצליב את החלונות עם הארכיון וסוגר פערים.
השוואת המצבים
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| עיבוד זרם של עסקאות | תגובה לפרץ נפח ברגע האירוע, אותות למסחר ידני ואלגוריתמי | השהיה משברירי שנייה; ניתוק חיבור מותיר חור בהיסטוריה; רגיש לעומס שיא |
| חישוב מחדש באצווה של ההיסטוריה | אנליטיקה, בדיקת אסטרטגיות על היסטוריה, דוחות, איתור אנומליות בדיעבד | השהיה מדקות ועד שעות; אין אותות מיידיים; העומס גדל עם עומק הארכיון |
| מצב היברידי של הסקרינר | הווריאנט העיקרי למוצר מסחרי: אותות בזמן אמת פלוס היסטוריה מאומתת | יקר יותר בפיתוח ובתמיכה: תיאום חלונות, דה-דופליקציה, בקרת פערים |
הבחירה נקבעת על פי המשימה: לתגובה לאירוע די בזרם, לאנליטיקה — באצווה, ולמערכת מסחר עובדת מציבים היברידי עם בדיקה אוטומטית של פערים.
פיתוח סקרינר נפחים: שלבים מהאודיט ועד המסירה
פיתוח סקרינר נפחים מתחיל לא בקוד, אלא באודיט של מקורות הנתונים. בשלב הזה אנחנו מצליבים בין הפלטפורמות: האם הן מחשבות נפח באופן זהה, באיזו השהיה הן מספקות את זרם העסקאות, האם יש פערים בהיסטוריה, ואיך להתמודד עם תקופות שבהן המסחר הופסק.
תוצאת האודיט — רשימת מקורות שנותנים נתונים ברי-השוואה, ורשימה מפורשת של פערים שנצטרך לפצות עליהם בצד שלנו.
- אודיט של מקורות הנתונים. אוספים היסטוריה לכל פלטפורמה, מצליבים נפח מצטבר עם חתכים בלתי תלויים, מסמנים פערים, כפילויות וקרעים בזמן.
- תרשים הזרמים והאחסון. מתארים את מסלול הנתונים: קליטה של ערוצי זרם, נרמול לסקאלת זמן אחידה, סינון כפילויות, אגרגציה לחלונות ולנרות. בנפרד מחליטים מה לשמור בצורה מקורית ומה — רק בצורה מסוכמת.
- כיוונון ספי הנפח. פרץ מחושב לא כמספר מוחלט, אלא כחריגה מעל קו בסיס בחלון: קובעים אורך חלון, מכפיל הפעלה, סף נזילות מינימלי וחתך לפי רוחב המרווח.
- כללי סינון ודיכוי רעידות. קובעים אילו אירועים נכנסים לתפוקה, איך הם מדורגים ואיך פרץ אחד לא הופך לעשרה אותות זהים.
- בדיקות על נתונים היסטוריים. מריצים את הכללים על הארכיון, מודדים את שיעור האירועים שהוחמצו ואת ההתראות הכוזבות, את הזמן מהופעת הנפח ועד לאות, ומדייקים פרמטרים.
- קבלת הסקרינר. מצליבים את העבודה על זרם חי עם מדגם ייחוס, מתעדים את הפער, בודקים את יומן האותות ואת החזרה להגדרות קודמות.
- מסירה. מוסרים קונפיגורציות, תרשימי זרמים ותקנון: איך לשנות ספים, איך להוסיף פלטפורמה, ולפי אילו סימנים להבין שמקור החל לספק נתונים חלקיים.
לאחר המסירה הספים והכללים משתנים בלי לגעת בקוד — ההגדרות מופרדות, וההחלטות על כל שינוי נשענות על הרצות היסטוריות, ולא על תחושות בטן.
מה נשאר אצלכם: קונפיגורציות, תרשימים, תקנונים
סקרינר נפח חסר תועלת אם כללי הסינון חיים בראש של מהנדס אחד ובכמה סקריפטים על השרת. לכן כל שלב אנחנו סוגרים בארטיפקטים שאפשר לפתוח, לקרוא ולהעביר לצוות אחר בלי שיחות ארוכות. להלן — מה בדיוק נשאר אצלכם במאגר (repository) ובתיעוד.
- קונפיגורציות של התראות — קבצים עם ספים לנפח, חלון הצטברות ומקדם סטייה מהנורמה; נערכים בלי לקמפל מחדש, מנוהלים בגרסאות ומוחזרים לסט הקודם.
- תרשים זרמי הנתונים — מסלול האות ממקור העסקאות וספר הפקודות ועד לחישוב ולמאגר: איפה יש חציצה (buffering), איפה דה-דופליקציה, ואיזו השהיה בכל קטע.
- תיאור כללי הסינון — נוסחאות המדדים (פרץ נפח ביחס לממוצע נע, חוסר איזון בין קניות למכירות) וספים בנפרד לכלים בעלי נזילות שונה.
- תיעוד הסקרינר — מפת השירותים, משתני סביבה, פורמט ההודעות הנכנסות, סדר החישוב מחדש של ההיסטוריה לתקופות קודמות.
- תקנון תפעול — מה לבדוק כשמפספסים אותות, איך להפעיל מחדש את צומת החישוב, איפה לראות יומנים ולאן נשלחת ההתראה.
- תקנון כוננות — שלוש רמות אירוע (רעש, חשד, תקרית), זמן תגובה לכל אחת וסדר הסלמה.
- תרשים האינטגרציות — נקודות החיבור לממשקי הבורסה, לטרמינל המסחר ולדיווח, והפרדת הרשאות גישה.
- ערכת בדיקה — חלונות היסטוריים שעליהם מריצים מחדש את הכללים, ובדיקה ששינוי סף לא שובר את הסינון.
מקרה בוחן: איך סקרינר נפחים הסיר אותות כוזבים
לפני: זרם אותות שאין במה לסנן
הסקרינר עבד לפי תנאי פשוט אחד — לשלוח כל מקרה שבו הנפח בשעה האחרונה סטה מהממוצע. עם יותר מארבעים זוגות במעקב זה הניב 70–90 התראות ביממה, שמתוכן רק בודדות היו קשורות לפרץ אמיתי.
האנליסט בילה 3–4 שעות בבדיקה ידנית: הצליב נרות, בחן את עומק השוק, ובכל זאת לעתים קרובות לא הספיק להיכנס לתנועה.
מה שינו במכניקת הסינון
זרם העסקאות מ-Binance ומפלטפורמות נוספות אוחד לסדרה מנורמלת אחת, והנפח הושווה לא לממוצע, אלא לפרופיל חציוני לפי שעת היום ויום בשבוע. האות דרש אישור בטיימפריימים סמוכים וסונן אם את הפרץ יצרו עסקה גדולה אחת או שתיים בלי גידול במספר המשתתפים. זוגות עם נזילות דלילה יצאו מהמדגם לפי סף מינימלי של מחזור.
מה קרה אחרי ההטמעה
מספר ההתראות ירד מ-70–90 ל-8–12 ביממה, ושיעור הכוזבות — מכ-85% לכ-20%. זמן התגובה הצטמצם מ-25–40 דקות של בדיקה ידנית ל-1–2 דקות: האות מגיע כבר עם הקשר — טיימפריים, נזילות הזוג, פרופיל הנפח.
פרצים שהוחמצו ברבעון הראשון של העבודה — אפס, לעומת 5–6 בשבוע לפני כן, וניתוח האותות הפסיק לתפוס יום עבודה שלם.
הספים וחלונות המיצוע הועברו לקונפיגורציה, ולכן לאופק מסחר אחר הכללים נבנים מחדש בלי לשכתב את הלוגיקה. היסטוריית ההתראות נשמרת עם הפרמטרים שהיו ברגע ההפעלה — כל אות אפשר לבדוק מחדש בדיעבד ולהבין למה הוא עבר את המסנן.
במה סקרינר זרימתי שונה מחישוב מחדש באצווה?
סקרינר באצווה עובד לפי לוח זמנים: לוקח חתך של היסטוריית עסקאות לחלון, מחשב מחדש את מדדי הנפח לכל הזוגות ומפיק רשימה מוכנה. אותו חתך תמיד מניב תוצאה זהה — פערים בין הרצות ניתנים להסבר, ומצב שנוי במחלוקת קל לשחזר. המגבלה היא שבין חישוב לחישוב השוק ממשיך לחיות, ופרץ נפח בתחילת החלון תראו רק בהרצה הבאה.
המצב הזרימתי מחזיק את המדדים בזיכרון ומעדכן אותם בכל עסקה — השהיית האות נמדדת בשניות, ולא במרווח החישוב מחדש. המחיר של המהירות: התוצאה תלויה בסדר ובשלמות האירועים, ולכן דרושים חלונות נעים עם גבול ברור וכללי דה-דופליקציה לחזרות.
השוואת המצבים מצטמצמת לשלושה צירים: השהיית האות, שלמות הנתונים והתנהגות בעת ניתוק החיבור. האצווה עוברת ניתוק בלי לשים לב: ההרצה הבאה לוקחת את ההיסטוריה מחדש ומשלימה את הקטע שהוחמץ. הזרימתי מאבד קטע מהחלון — המדד יורד, והאות או לא מופעל, או מגיע על נפח מעוות.
לכן סביב הזרם בונים חוצץ אירועים, בקרת פיגור של הצרכן, והשלמה של הקטע שהוחמץ מההיסטוריה עם חישוב מחדש של החלונות שנפגעו.
את הבחירה מכתיבה הלוגיקה המסחרית. צריך דיווח בר-שחזור והחלטה בסגירת המרווח — די בחישוב מחדש באצווה. צריך תגובה בשניות הראשונות ואות קצר-חיים — לוקחים מצב זרימתי ומתכננים בנפרד התאוששות אחרי ניתוקים. בפועל לרוב בונים היברידי: הזרם נותן אות מיידי, והרצת האצווה אחת למרווח מצליבה פערים ומנקה החמצות.
ספקות טכניים: השהיות, מגבלות הבורסות, התראות כוזבות
רוב השאלות ההנדסיות כלפי הסקרינר נוגעות לגבול עם הפלטפורמות: תדירות הבקשות, שוק דליל, ניתוקי חיבור. להלן — תשובות למה שבודקים לרוב לפני ההתחלה.
איך עוקפים את מגבלות נתוני הבורסה?
הבקשות לא משוכפלות: אוסף אחד לכל פלטפורמה, והאותות מופצים למנויים בתוך המערכת. עסקאות וספר פקודות נלקחים במנוי זרימה, היסטוריה משלימים במנות עם מרווח מהמגבלה, ומדריכי המטבעות נשמרים במטמון. כשמגיעים לתקרה, האוסף עצמו מוריד את התדירות בזוגות המשניים — המועדפים נשארים במלואם.
מאיפה מגיעות התראות כוזבות בשוק דליל?
המסנן חותך זוגות שבהם נפח של עסקאות בודדות מעוות את התמונה: עומק מינימלי של ספר הפקודות, מרווח מקסימלי, מספר עסקאות בחלון. האות מאושר לפי כמה מקורות, ופרץ נפח בלי תנועת מחיר מסומן כחד-פעמי.
מה קורה בעת ניתוק חיבור?
התחברות מחדש בלי אובדן מצב: החוצץ מחזיק את הטיקים האחרונים, אחרי ההתאוששות אנחנו מדביקים את הקטע שהוחמץ ומצליבים את החתך. אם הפער גבוה מהסבילות, החלון מסומן כלא שלם והאותות לפיו לא מפורסמים — עדיף לפספס מאשר לפלוט אות מעוות. עמידות אנחנו בודקים לפי תקנון: מנתקים את החיבור ומפעילים מחדש את האוסף בסביבת בדיקות.
איך מודדים השהיות של הסקרינר?
המדד — מהופעת העסקה בפלטפורמה ועד פרסום האות, בנפרד לזרם ולסקירה (polling). המדידה נעשית בכל צומת, ולכן רואים איפה מצטבר הזמן: באיסוף, בחישוב או במסירת ההתראה. את הסף קובעים לפי הלוגיקה המסחרית של המזמין, ולא לפי 'ממוצע שוק'.
נדון במשימה: נחזור עם תרשים ותוכנית הטמעה
כדי שהערכת פיתוח הסקרינר תישען על עובדות ולא על ניחושים, לפני ההתחלה צריך סט קצר של נתוני פתיחה. מהמזמין אנחנו מצפים לדברים הבאים.
- רשימת בורסות וזוגות: ספוט, חוזי פרפטואל, זוגות מצוטטים נפרדים — ממנה תלוי מספר זרמי העסקאות.
- עומק ההיסטוריה: ממתי צריך פרצים בנפח ובאיזו תקופה מחשבים את הנורמה — זה קובע את אופן ההשלמה והאחסון.
- כלל האנומליה: גידול נפח ביחס לממוצע בחלון, חלק מהמחזור של הזוג או מספר עסקאות בדקה — איזה סימן נחשב לאות.
- ערוצי מסירת האות והנמענים: אזור אישי, צ'אט, קריאה למערכת שלכם.
- הרשאות גישה: מפתחות לקריאה בלבד, סביבת בדיקות של הבורסה, מגבלות על תדירות הבקשות.
- קריטריון קבלה: השהיה מותרת מהעסקה ועד האות ושיעור מקובל של התראות כוזבות.
בתגובה אנחנו מוסרים לא הערכה במילים, אלא ערכה עובדת כתוצאה מהניתוח הראשון של המשימה.
- תרשים הפתרון: מקורות הנתונים, העיבוד, המאגר, נקודות כשל והעקיפה שלהן.
- הרכב העבודה לפי שלבים והערכת פיתוח הסקרינר עם תוכנית הטמעה.
- כללי סינון עם פרמטרים: חלון מיצוע, סף, מספר עסקאות מינימלי.
- יומן מדדים: רעננות הנתונים, החמצות, מספר האותות לזוג ולפי ימים.
- הוראות תפעול וסדר הבדיקה על ההיסטוריה לפני ההרצה.
תארו את משימת הסקרינר והנתונים הזמינים — נחזור עם הערכה ותוכנית הטמעה.







