איסוף נתונים מ-CoinGecko ו-CoinMarketCap: סקרייפינג, API, מטמון

למה פרסינג CoinGecko נופל בעומסי שיא של השוק

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

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

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

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

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

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

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

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

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

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

פורמטים של איסוף: פרסינג CoinGecko, API רשמי, Webhooks

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

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

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

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

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

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

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

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

מה מוסרים: תצורות, סכימות נתונים ותיעוד

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

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

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

מקרה בוחן: איך מצרף מחירים הפסיק לאבד היסטוריית מחירים

היכן אבדה ההיסטוריה

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

מה שינו

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

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

מדדים לפני ואחרי

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

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

במה CoinMarketCap שונה ממצרף בורסאי

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

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

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

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

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

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

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

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

למה המחירים בשני מקורות שונים בשברירי אחוז?

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

מה יקרה אם המקור ישנה את פורמט התשובה?

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

אפשר לחשב מחדש את ההיסטוריה לתקופה שחלפה?

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

נדון במשימה: ממה נתחיל באיסוף הנתונים שלכם

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

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

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