פיתוח ויזואליזציה של זרימת הזמנות (Footprint Chart)

מדוע ויזואליזציה של זרימת פקודות נשברת בשוק תנודתי

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

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

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

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

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

מה נותנת זרימת הפקודות: אפקטים מדידים

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

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

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

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

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

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

השוואת גישות לויזואליזציה של זרימת פקודות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: זרימת פקודות עבור מסוף בורסאי

מה היה לפני

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

מה שינו

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

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

מה נהיה

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

במה Footprint Chart שונה מספר ההזמנות הבורסאי

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

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

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

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

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

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

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

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

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

האם התשתית תעמוד בעומס שיא?

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

האם זה תואם למערכת הנוכחית ובטוח לנתוני מסחר?

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