איסוף נתוני נרות היסטוריים (OHLCV) מבורסות לצורך בקטסטינג

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

נתוני OHLCV מהבורסות: היכן נשברים הטורים ההיסטוריים

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

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

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

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

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

טור נרות מכויל: מהירות בדיקה ופחות אותות שווא

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

את העלאת הנרות אנו מבצעים ישירות דרך ממשקי המסחר של הפלטפורמות, כולל Binance: עמוד אחר עמוד לפי זמן, עם ניסיונות חוזרים בעת תקלות רשת. הכנת הנתונים מצטמצמת לסכימה אחודה — חתימת זמן ב-UTC, open/high/low/close, נפח, טיקר, טיימפריים.

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

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

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

שיטות לאיסוף נתוני OHLCV: העלאה מלאה והעלאה משלימה

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

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

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

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

סדר איסוף ההיסטוריה: מביקורת המקורות ועד למסירה

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

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

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

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

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

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

מקרה בוחן: שחזור פערים בהיסטוריה עבור 40 זוגות

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

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

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

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

במה שונה העלאה משלימה אינקרמנטלית מטעינה מלאה מחדש?

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

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

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

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

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

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

ספקות טכניים: עומק ההיסטוריה, פערים, פורמטים

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

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

עד כמה עמוקה ההיסטוריה והיכן היא נפסקת?

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

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

מה לעשות עם פערים וסופי שבוע של הבורסה?

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

באיזה אזור זמן ובאיזה פורמט אתם מאחסנים את הנרות?

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

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

נדון במשימה: נאסוף היסטוריה עבור האסטרטגיה שלכם

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

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

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

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