ניתוח חדשות קריפטו: אגרגטור נתונים מ-RSS ו-API

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

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

שאלות נפוצות

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

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

מדוע איסוף חדשות קריפטו נשבר בעשרות מקורות

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

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

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

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

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

מה נותן זרם נתונים אחיד: מהירות, שלמות, עמידות בתקלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: כיצד הפיד של האגרגטור הפסיק לאבד פרסומים

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

מה היה לפני

במדידת הזרם במשך שבועיים, 8–14% מהפרסומים לא הגיעו לפיד: כפילויות דחקו רשומות טריות, ותקלה של מקור אחד השאירה בשקט פקק בתור המשותף. ההשהיה מהפרסום ועד להופעה בפיד נשמרה בטווח של 20–40 דקות, ובימים של תנועות חדות בשוק נמתחה עד שעה.

האוסף קרס 3–4 פעמים בשבוע — הוא לא שרד ניתוק חיבור והמשיך להחזיר תגובות ריקות עד שהמפעיל הבחין בהיעלמות.

מה קרה אחר כך

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

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

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

במה שונה איסוף ב־RSS מעבודה עם API של בורסה?

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

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

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

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

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

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

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

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

המקור מגביל את קצב הבקשות — מה אז?

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

כיצד להבדיל בין כפילות לפרסום חוזר?

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

החדשה הגיעה בהשהיה — כיצד לא להציג משהו מיושן?

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

המקור החליף פורמט של הפיד או שאינו זמין?

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

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

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

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

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