למה Volume Profile לא עולה בקנה אחד עם סרט העסקאות
סוחר רואה בסרט העסקאות עסקה גדולה במחיר אחד, ואילו פרופיל נפח (Volume Profile) עבור המכשיר מצייר ריכוז כמה רמות מעל. זה אינו פגם בציור: אי־התאמה של פרופיל הנפח משמעה שהחלטה מתקבלת לפי רמה שלא הייתה בעסקאות אמת.
השורש בדרך כלל במקור הנתונים לפרופיל. סרט העסקאות הוא זרם של עסקאות בודדות עם מחיר וגודל, ואילו פרופיל נפח בבורסת קריפטו נבנה לעיתים קרובות מנרות מצטברים: נר נותן נפח לתקופה, אך אינו אומר כיצד הוא מתפלג בפנים. אם מפלגים לפי מחיר אופייני, הפרופיל משקר בדיוק היכן שצריך אותו — ברמות עם עסקה גדולה אחת.
המחצית השנייה של התקלה — השהיה בחישוב הפרופיל. כאשר חלון מחושב מחדש כולו לפי לוח זמנים, ולא ככל שעסקאות מגיעות, הפיגור מצטבר: באימפולס הרמה כבר נסחרה, והגרף רק משלים את ציורה.
לכך מתווספים כללים שונים לצבירת עסקאות בפלטפורמות שונות, שעות מסחר שונות ועסקאות מחוץ לבורסה — ופרופיל הנפח עבור המכשיר מפסיק להיות בר־השוואה לסרט העסקאות.
אנו לוקחים את הפרופיל מאותו זרם עסקאות כמו סרט העסקאות, מעדכנים אותו עם הגעת עסקאות ומחזיקים השוואה מול הסרט כקריטריון קבלה: אי־התאמה היא באג, לא מאפיין של הגרף. בהמשך נראה כיצד זה בנוי בעבודה שלנו.
מה Volume Profile נותן לפלטפורמה ולסוחרים
פרופיל נפח מפרק את זרם העסקאות לפי רמות מחיר בחלון נבחר ומראה היכן הנפח עבר בפועל והיכן התנועה נשענה על ספר ההזמנות דק. עבור הסוחר אלו רמות שהמחיר נדחף מהן, ועבור הפלטפורמה — אגרגט מוכן שנמסר ללקוח במקום חישוב מקומי מחדש של נרות בכל גרף.
מה משתנה עבור הסוחר
פרופיל הנפח עבור סוחרים מחושב בשרת ומגיע כצילום מצב עם דלתות שינוי. לאחר פרץ פעילות הציור אינו מדרדר: במקום מעבר מלא על החלון מחושבים מחדש רק הרמות שנפגעו, ולכן ההיסטוגרמה מתעדכנת באותו זמן כמו בשוק רגוע. שינוי רזולוציה — שימוש חוזר באגרגטים שכבר חושבו, ולא חישוב חדש מאפס.
מה משתנה עבור הפלטפורמה
אנליטיקת נפח בבורסה נשענת על מודול חישוב אחד שמשרת את כל הסשנים של לקוחות: מספר המנויים גדל, אך העומס על מודול החישוב — לא, החלון מחושב פעם אחת ומופץ. שיעור החישובים מחדש יורד: דלתות שינוי מכסות את רוב העדכונים, ומעבר מלא נשאר לשחזור חלון ולשינוי רזולוציה.
התאמת נתוני הבורסה נבדקת בהשוואת אגרגט מול צילום מצב בלתי תלוי: אי־התאמה לפי רמה מסומנת ואינה עוברת לממשק, ולכן מספר הפניות בגלל נתונים שגויים מצטמצם — השגיאה נראית בניטור, ולא במסוף הסוחר. כסטנדרט תצוגה אנו לוקחים TradingView: אותן אזורי ערך, אך החישוב כולו בצד הפלטפורמה.
גישות לחישוב פרופיל נפח: השוואה
צבירת עסקאות לפרופיל נשענת על אחד משני מקורות: זרם עסקאות בזמן אמת או ברים שכבר נשמרו. הראשון נותן פירוט עד לעסקה בודדת, השני זול יותר בעומס, אך מאבד את ההתפלגות בתוך הבר אם במאגר יש רק מחירי פתיחה, שיא, שפל וסגירה. מכאן גם ההסתעפות: איזו דיוק נדרש לסוחר ומה כבר קיים בליבת המסחר של הפלטפורמה.
על התאימות למערכת פעילה משפיע לא רק המקור, אלא גם רגע החישוב מחדש. פרופיל שנספר אונליין דורש סרט עסקאות יציב ומלא; פרופיל שנבנה באצוות מיושם על ההיסטוריה ללא שינויים בלוגיקת ההתאמה. להלן ארבעה אפשרויות והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חישוב אונליין מזרם עסקאות | נדרש פירוט עד עסקה בודדת, הפרופיל מתעדכן בכל עסקה | מחזיק חוצץ חם לפי מכשיר; פספוס בסרט לאחר מעשה אינו משוחזר |
| צבירה לפי ברים שמורים | היסטוריית מחירים כבר קיימת, העומס על המאגר מינימלי | ההתפלגות בתוך הבר אובדת, הפרופיל מנוון להיסטוגרמה לפי סגירות |
| חישוב פרופיל היברידי | נדרש דיוק בקטע טרי והיסטוריה עמוקה בלי לחשב מחדש את כל המערך | שני מודלי נתונים צריכים להתכנס בנקודת החיבור, נדרשת השוואה סדירה |
| חישוב מחדש היסטורי של הפרופיל | מתודולוגיית קיבוץ המחיר או עומק האחסון משתנים | דורש חלון תחזוקה או חישוב על רפליקה, מתחרה על משאבים עם הליבה |
הבחירה נעולה בקונפיגורציה לפני תחילת העבודה: מרווח קיבוץ המחיר, עומק האחסון, מצב החישוב מחדש ודרך ההשוואה בנקודת החיבור בין הזרמים. המהנדסים שלנו מתאימים אפשרות לליבה שכבר פעילה — הפרופיל משתלב בלי לכתוב מחדש את לוגיקת המסחר.
שלבי הטמעת פרופיל נפח בפלטפורמה
פרופיל נפח הוא לא פאנל נפרד, אלא מעגל חישוב: זרם עסקאות, צבירה לפי רמות מחיר, אחסון ומסירה לממשק המסחר. לכן הטמעת פרופיל נפח מתנהלת ברצף קבוע — כך אי־התאמה בפלט מאותרת לשלב מסוים, ולא מחפשים אותה בכל השרשרת.
- ניתוח מקורות נתונים. בודקים אילו זרמים הבורסה מספקת, כיצד מגיעות עסקאות וספר ההזמנות, היכן אפשריים כפילויות וקטיעות בעת חיבור מחדש, ואיזה עומק היסטוריה זמין.
- ביקורת סכמת החישוב. קובעים את מרווח קיבוץ המחירים, חלון הצבירה, כללי הטיפול במכרזים ובעסקאות חוץ־בורסאיות גדולות — עד לרמת הנוסחאות, אחרת אין במה להשוות את התוצאה.
- אחסון וחישוב מחדש. בוחרים בין השלמת עסקאות חדשות לבין חישוב מחדש מלא, קובעים עומק היסטוריה וסט אינטרוולים, כדי שהגרף ייפתח בלי המתנה.
- קבלה על נתונים היסטוריים. מריצים את החישוב על תקופות נבחרות, כולל ימים תנודתיים, ומשווים למדגם ייחוס: אי־התאמה צריכה להיות מוסברת, ולא «בערך דומה».
- בדיקת עומס לחישוב. מזרימים זרם עסקאות שיא ובודקים השהיית מסירה וצריכת זיכרון; קובעים סף שמעבר לו ההידרדרות מורגשת למשתמש.
- עמידות לתקלות. בודקים הפעלה מחדש של השירות, שחזור לאחר ניתוק חיבור וחישוב חוזר בלי כפילות רמות.
- מסירת המעגל. מוסרים קונפיגורציות, מטריקות, נוהל עדכון וסדר פעולה במקרה של אי־התאמה.
כל שלב מסתיים בארטיפקט: מפרט מקורות, תיאור סכמת החישוב, פרוטוקול קבלה, דוח עומס. צוות הלקוח מקבל את העבודה לפי מספרים, ולא לפי רושם מהגרף.
הרכב הארטיפקטים: סכמות, נהלים, קונפיגורציות
אנו מוסרים לא רק מעגל חישוב פעיל, אלא גם ערכת מסמכים שלפיה ניתן לפתח ולתחזק אותו בכוחות עצמכם. הארטיפקטים משויכים לשלבי התפעול: פריסה, בקרה יומיומית, חישוב מחדש מתוכנן וניתוח אירועים. להלן מה בדיוק נשאר אצל צוות הלקוח.
- סכמת זרמי נתונים — המסלול ממקור העסקאות ועד פרופיל הנפח האגרגטי: אילו מעגלים משתתפים, היכן יש חוצץ, היכן תור, ואיזו נקודה נחשבת לנקודת כשל יחידה.
- קונפיגורציות של מעגל החישוב — פרמטרי צבירה (מרווח מחיר, חלון צבירה, עומק היסטוריה), מגבלות עומס, כללי הפעלה מחדש אוטומטית והתנהגות בעת אובדן חלקי של הזרם.
- נוהל חישוב מחדש של נתונים — מתי מופעל חישוב מחדש, אילו מקורות חייבים להיות זמינים, כיצד נבדקת שלמות צילום המצב ומה לעשות במקרה של אי־התאמה לתוצאה הקודמת.
- תיעוד לפרופיל נפח — מודל החישוב, פורמטי אחסון, יחידות וכללי עיגול, טיפול בחסרים ובקפיצות חריגות.
- הוראות למשמרת תורנית — אותות ניטור אופייניים, סדר אבחון, נקודות הסלמה וסדר חזרה לאחור לצילום המצב הקודם.
- סכמת גישה ותפקידים — למי מותר לשנות פרמטרי חישוב, כיצד מתועדים שינויים וכיצד מופרדות הרשאות קריאה וכתיבה.
- מתודולוגיית קבלה — סט תרחישי בקרה וערכי ייחוס שלפיהם נבדקת תקינות הפרופיל לאחר כל שיפור.
ערכת המסמכים נכתבת בהתאמה לתשתית שלכם ומתעדכנת יחד עם הקוד, ולכן אינה סוטה ממצב המערכת בפועל. אם יש לכם משימה — תארו אותה, נחזור עם הערכה ותוכנית.
מקרה בוחן: אי־התאמה בין פרופיל נפח לסרט העסקאות בבורסה
הפלטפורמה בנתה פרופיל נפח לפי ברים מצטברים ממספר מקורות: זרם פקודות, סיכומי נרות ומטמון זוגות מסחר. סרט העסקאות לא נכלל בבנייה, לכן בעת ניתוק זרם או הפעלה מחדש של צומת ההיסטוגרמה נראתה סבירה אך סוטה מהעסקאות בפועל: הסוחר ראה רמות שלא היו בשוק.
הניתוח חשף שתי סיבות. האגרגטים הודבקו לפי זמן השרת, ולא לפי זמן העסקה, וקטע שנמסר מחדש נלקח בחשבון פעמיים.
העברנו את הבנייה לסרט העסקאות כמקור האמת היחיד: הפרופיל נבנה מזרם עסקאות עם הסרת כפילויות לפי מזהה, חלון הצבירה נקשר לזמן העסקה, וכסטנדרט להשוואה משמשת סרט ציבורי של Binance בזוגות תואמים.
מה השתנה במספרים
| מטריקה | לפני | אחרי |
|---|---|---|
| אי־התאמה בין הפרופיל לסרט | 4–6% מסשני המסחר | 2–3 מקרים בחודש, כל אחד עם התראה |
| זיהוי אי־התאמה | לפנייה של סוחר, שעות של ניתוח | השוואה אוטומטית, דקות |
| שחזור לאחר ניתוק זרם | חישוב מחדש מלא של ההיסטוריה ידנית | חישוב מחדש ממוקד של חלון אי־ההתאמה |
| סוג כשל | אגרגט בלי סרט, ספירה כפולה | סגור בבדיקות רגרסיה |
התוצאה המרכזית — לא מספר בודד, אלא מחלקת כשלים שהוסרה: הפרופיל כבר לא יכול לסטות מהסרט בלי שיבחינו, אי־ההתאמה צפה בהשוואה בתוך החלון שלה. חזרה לאחור לגרסת הצבירה הקודמת נשארת אפשרית, וההיסטוריה מחושבת מחדש מסרט העסקאות בלי אובדן נתונים.
מה עושים אם הפרופיל כבר מחושב לפי נרות?
כן, זה נפתר בלי לעצור את המסחר — אבל לא בהחלפת חישוב אחד באחר. פרופיל לפי אגרגטים ופרופיל לפי עסקאות נותנים היסטוגרמות שונות: נר מפרק נפח לפי מחיר בעזרת יוריסטיקה, ועסקה נושאת מחיר ביצוע מדויק. לכן מחליפים מקור, ולא נוסחה — ועושים זאת במקביל.
תחילה בפלטפורמה מופיע מעגל חישוב שני. הוא קורא זרם עסקאות מהפלטפורמות, מנהל היסטוגרמה משלו לפי רשת מחירים נתונה ומתמלא רטרוספקטיבית מקבצי עסקאות היסטוריים. המעגל הראשון ממשיך לספק פרופיל לפי נרות, חזית ה־API ולוגיקת התצוגה לא משתנים.
תקופת מעבר — חישוב כפול: שני הפרופילים מחושבים על אותו חלון, ואי־ההתאמה נמדדת לפי מטריקות יציבות — נקודת בקרת נפח, גבולות אזור ערך, התפלגות לפי רמות מחיר. כך רואים היכן היוריסטיקת הנר מעוותת את התמונה, ויש קריטריון מספרי למוכנות למעבר.
תאימות לאחור נשמרת בסכמת התגובה: שדות קיימים נשמרים, חדשים מתווספים כאופציונליים, ובחירת המקור מוחלפת בפרמטר קונפיגורציה ברמת הבקשה. חזרה לאחור לחישוב הקודם אורכת דקות ואינה דורשת הפצה של אפליקציות לקוח.
פלטפורמות כמו Coinbase מספקות סרט עסקאות בזמן אמת, ולכן השלמה לפי הזרם מתכנסת עם ההיסטוריה הטעונה בלי קטיעות.
זרם העסקאות צפוף בסדרי גודל מאגרגטים, ולכן רשומות גולמיות נשמרות בחלון מוגבל, וההיסטוגרמה נבנית תוך כדי. במקום שבו היסטוריית הפלטפורמה כבר מדוללת, פרופיל לפי נרות נשאר מקור גיבוי.
השורה התחתונה: הפלטפורמה מחשבת Volume Profile לפי ביצועים אמיתיים, והמסחר אינו נעצר באף אחד משלבי המיגרציה.
חששות טכניים לפני תחילת העבודה
לפני תחילת העבודה מהנדסים ומנהלי תחומים שואלים כמעט את אותה קבוצת שאלות: כיצד לבדוק את תקינות החישוב, מה יקרה בעת כשל תקשורת והאם החישוב החדש יסתדר עם מה שכבר עובד בפרודקשן. להלן התשובות כפי שאנו נותנים אותן בסשן טכני.
כיצד לוודא שפרופיל הנפח מתכנס עם נתוני הבורסה?
בונים השוואות בקרה: מצברים את זרם העסקאות לאותם אינטרוולים ורמות מחיר שהמקור מספק, ומשווים נפחים סופיים בכל אזור. אי־התאמה מעל סף נתון מודגשת — זה אות לפרק את צינור העיבוד, ולא «מאפיין של השוק».
מה יקרה בעת ניתוק זרם הנתונים?
חלון שבו אבדו עסקאות מסומן כלא שלם — הסוחר רואה זאת ישירות בממשק ואינו מקבל פרופיל מעוות כחתך מלא. חיבור מחדש מתבצע אוטומטית, והקטע שהוחמץ מושלם מהיסטוריית העסקאות עם שחזור התקשורת.
האם אפשר להטמיע פרופיל נפח בפלטפורמה פעילה בלי לעצור את המסחר?
כן. מודול חישוב חדש עולה לצד הנוכחי, קורא את אותו זרם ומחשב במצב צל — התוצאות מושוות על נתונים חיים. המעבר נעשה רק לאחר שלא נותרו אי־התאמות עם הלוגיקה הקודמת.
מה עושים עם היסטוריית עסקאות לתקופה ארוכה?
היסטוריה נשמרת כרמות מחיר מצטברות, ולא כזרם גולמי, ולכן חישוב מחדש לתקופות קודמות מתבצע באצוות ואינו מעמיס על המעגל המקוון. עומק ההיסטוריה הזמינה מוגבל למה שהפלטפורמה עצמה מספקת לכל מכשיר.
מי מגדיר את מרווח המחיר ואת תקופת הפרופיל?
הפרמטרים מוצאים לקונפיגורציה: מרווח מחיר וחלון צבירה מוגדרים בנפרד לכל מכשיר, ספוט ונגזרים מחושבים כפרופילים שונים. הערכים משתנים בלי הוצאת גרסה חדשה — שינוי ההגדרה חל בחלון הבא.
נדון במשימה: מה דרוש להערכה ולתוכנית
כדי לחזור עם הערכה ריאלית של העבודה על פרופיל נפח, דרושים לנו מינימום נתוני פתיחה — מהם נראה את ההיקף, הרכב הצוות וסדר השלבים. אין צורך להכין אפיון טכני מראש: די בתשובות לכמה שאלות, ואת השאר נחדד בשיחה ונקבע בכתב.
- אילו פלטפורמות ושווקים במעגל — ספוט, חוזים עתידיים, נגזרים: מכך תלוי סט מקורות הנתונים וכללי הנרמול של עסקאות.
- מה קיים בהיסטוריה: עומק, קיום זרם עסקאות או רק נרות מצטברים, היכן הנתונים נמצאים כעת ובאיזה פורמט.
- מצב שימוש: רק בניית פרופיל נפח לניתוח או גם אותות, התראות וביצוע.
- ממשקים ועומס: ווב, דסקטופ או אפליקציית מובייל, כמה סשנים במקביל ואיזו השהיית תגובה מקובלת.
- תשתית: פריסה במעגל שלכם או אצלנו, מהן הדרישות לגישות, אחסון ורישום פעולות.
- אינטגרציות: מסוף, שער ברוקר, מודול סיכון, דיווח — מה כבר עובד ובאילו ממשקים מתבצע החלף נתונים.
- לוחות זמנים ואבני דרך: אילו תאריכים קריטיים ובאיזה סדר נוח לאשר שלבים.
תארו את המשימה בצורה חופשית — נחזור עם הערכה, תוכנית הטמעה והצעה להרכב הצוות. אישור השלבים נפרט לפי אבני דרך: עם קריטריוני קבלה והיקף עבודה ברור בכל שלב.