הגדרת איסוף נתוני קריפטו תעשייתי לפי לוח זמנים (cron)

הגדרת איסוף נתוני קריפטו: היכן נשבר האיסוף

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

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

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

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

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

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

מה נותן איסוף קבוע של נתוני בורסה

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

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

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

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

מצבי קבלת נתונים: השוואת גישות

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

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

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

שלבי הגדרת איסוף נתונים קבוע

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

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

מה נשאר בפלט: סכמות, תצורות, נהלים

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

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

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

מקרה בוחן: החזרנו את שלמות איסוף הנתונים ב-14 מקורות

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

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

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

מה נהיה: שלמות הנתונים עלתה מ-88% ל-99.7%, הפערים בין הערוצים — מ-7% ל-0.4%. זמן השחזור לאחר כשל מקור הצטמצם מ-40 דקות של טעינה ידנית ל-90 שניות של השלמה אוטומטית — המחזור הבא מתחיל כבר עם נתונים מלאים.

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

במה שונה איסוף לפי לוח זמנים מזרם בזמן אמת

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

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

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

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

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

ספקות טכניים: החמצות, מגבלות, כפילויות רשומות

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

כיצד נמנעות כפילויות רשומות?

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

מה עושים עם מגבלות מקורות על תדירות שאילתות?

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

המקור החליף פורמט תגובה — מה אז?

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

נדון במשימה: מה להבהיר לפני תחילת העבודה

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

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

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