למה TheMarker הוא לא עוד אתר חדשות סטנדרטי
במבט ראשון, TheMarker נראה כמו אתר תוכן. יש כתבות, קטגוריות, ארכיון. קל לחשוב שאפשר פשוט להריץ crawler רקורסיבי על כל הקישורים ולקבל את כל הדאטה. זו הטעות הראשונה. הליבה של TheMarker היא לא רק התוכן המערכתי, אלא הדאטה הפיננסי שמשולב בו. מחירי מניות, מדדים, נתוני קרנות – כל אלה לא מגיעים כ-HTML סטטי. הם נטענים דינמית, לרוב דרך קריאות AJAX ל-endpoints פנימיים.
המשמעות היא שספרייה כמו requests לבדה תיתן לכם רק את המעטפת. אתם תראו את שלד הדף, אבל תפספסו את כל המידע הפיננסי העשיר. פרויקט של איסוף קטלוג TheMarker לאינדוקס כל הכתבות הוא משימה שונה לחלוטין מפרויקט ניטור מחירים TheMarker שעוקב אחרי מדד ת"א 35. הראשון דורש יכולת טיפול בפג'ינציה וניהול מצב על פני עשרות אלפי דפים. השני דורש ניתוח תעבורת רשת, זיהוי ה-API הפנימי, והבנה של איך לבנות בקשות שיחזירו JSON נקי. אם תנסו להשתמש בכלי אחד לשתי המשימות, סביר שתכשלו באחת מהן. צריך להבין שהאתר משרת שני use cases, ולכן גם ה-scraper צריך להיות מורכב משני מודולים נפרדים עם לוגיקה שונה.
ה-Stack הנכון: למה Requests לא יספיק לכם
בואו נהיה ברורים: תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד כשצריך גם יכולות network interception וגם אינטראקציה עם הדף. עבור TheMarker, זה לא nice-to-have, זו דרישת חובה. למה? כי הגישה ההיברידית היא היחידה שעובדת כאן בצורה אמינה.
הגישה שאני בונה בפרויקטים כאלה מתחילה עם Playwright כדי לטעון את הדף, לנתח את קריאות הרשת שהוא מבצע, ולזהות את ה-endpoints המעניינים. אחרי שמצאתם את הקריאה שמביאה את נתוני המניות, למשל, אתם יכולים לנסות לשחזר אותה ישירות עם httpx (הגרסה האסינכרונית של requests). זה מאפשר לכם להגיע לקצב גבוה בהרבה. אבל ה-API הזה כנראה דורש headers מסוימים, קוקיז, או טוקנים שנוצרים על ידי JavaScript בצד הלקוח. פה Playwright נכנס שוב לתמונה: הוא מנהל את הסשן, מרענן טוקנים כשצריך, ומזין את המידע הזה למודול ה-httpx המהיר. כך אתם מקבלים את הטוב משני העולמות: מהירות של בקשות ישירות עם האמינות של דפדפן מלא. ניסיון לבצע מודיעין מתחרים TheMarker רק עם בקשות ישירות יוביל מהר מאוד ל-rate limiting או לחסימה. אל תחסכו בזמן ההשקעה הראשוני בבניית המודל ההיברידי הזה. זה ישתלם בטווח הארוך.
תרחיש הכשל הנפוץ ביותר: דאטה לא מעודכן ו-Rate Limiting סמוי
אחד הכשלים המתסכלים ביותר שראיתי בפרויקטי scraping של אתרי חדשות פיננסיים הוא לא חסימה מוחלטת, אלא קבלת מידע שגוי או לא מעודכן. אתם חושבים שה-scraper עובד כי הוא מחזיר סטטוס 200, אבל בפועל אתם מקבלים נתונים מגרסת cache ישנה. ב-TheMarker, זה יכול לקרות כשמנסים לפנות ל-API הפנימי בתדירות גבוהה מדי. במקום להחזיר שגיאת 429, המערכת עשויה פשוט להפנות אתכם ל-CDN שיגיש לכם עותק מלפני 15 דקות. עבור ניטור מניות, זה חסר ערך.
איך מזהים את זה? ניטור. אתם חייבים להוסיף לוגיקה שבודקת את טריות המידע. למשל, השוו את ה-timestamp שחוזר ב-payload לזמן הנוכחי. אם הפער גדול מדי, משהו לא בסדר. סיבה נוספת היא ניהול סשנים לקוי. אם לא תנהלו קוקיז בצורה נכונה בין בקשות, או אם כל בקשה שלכם תגיע מכתובת IP אחרת דרך איך לבחור פרוקסי residential באיכות נמוכה, השרת עלול לזהות אתכם כאיום ולהגיש לכם תוכן מוגבל. הצלחה של 99% בבקשות היא לא המטרה. המטרה היא 99% הצלחה בקבלת דאטה מדויק וטרי. זו הבחנה קריטית.
בניית צינור דאטה אמין: מאיסוף גולמי ל-API מסודר
איסוף הדאטה הוא רק 20% מהעבודה. 80% הנותרים הם ניקוי, נרמול, ואריזה של המידע לפורמט שמיש. המטרה הסופית של רוב הפרויקטים האלה היא API / קובץ נתונים TheMarker שאפשר לצרוך בקלות. זה אומר שצריך לחשוב על סכמת הנתונים מהיום הראשון. אילו שדות אתם אוספים? מה ה-data type של כל שדה? איך תטפלו בערכים חסרים?
לדוגמה, כשאתם אוספים כתבות, אתם רוצים לחלץ באופן עקבי שמות מוצרים/מודעות (במקרה זה, כותרות), תאריך פרסום, שם הכותב, ותוכן הכתבה. חשוב מאוד לנרמל את התאריכים לפורמט ISO 8601 ולנקות את ה-HTML מהתוכן לפני השמירה. כשמדובר בנתונים פיננסיים, חשוב לוודא שכל המספרים נשמרים כ-float או decimal ולא כ-string.
השלב הבא הוא הארכיטקטורה. אל תריצו את הלוגיקה כסקריפט בודד. הפרידו בין ה-crawler (שמביא HTML/JSON גולמי), ה-parser (שמחלץ את השדות הרצויים), וה-loader (שטוען את הנתונים הנקיים לבסיס נתונים). שימוש בתור משימות כמו RabbitMQ או Redis בין השלבים האלה יאפשר לכם масштабируемость ועמידות בפני תקלות. אם ה-parser נכשל על דף מסוים, המשימה פשוט חוזרת לתור במקום להפיל את כל התהליך. זה ההבדל בין פרויקט חובבני למערכת production-ready.
מתי לא להשתמש בגישה המורכבת הזו
אחרי כל מה שאמרתי על Playwright וארכיטקטורה מורכבת, חשוב לדעת מתי לעצור. לא כל משימה דורשת את התותחים הכבדים. אם כל מה שאתם צריכים זה מעקב מלאי/זמינות TheMarker במובן של בדיקה יומית האם פורסמה כתבה חדשה על חברה ספציפית, אתם כנראה לא צריכים דפדפן מלא. ייתכן שפיד ה-RSS של האתר, אם קיים וחשוף, יספיק. גישה פשוטה דרך בקשת GET רגילה לפיד הזה פעם ביום היא הרבה יותר קלה לתחזוקה.
המורכבות צריכה להיות פרופורציונלית לבעיה. רוצים לחלץ את 50,000 הכתבות מהארכיון למודל שפה? כן, תצטרכו מערכת חזקה עם ניהול פרוקסי, retries, ודפדפן אמיתי. רוצים לקבל התראה כשיש כתבה חדשה במדור "נדל"ן"? אולי מספיק סקריפט פשוט שבודק את עמוד המדור פעם בשעה. הבעיה היא שמהנדסים נוטים ליפול לאחת משתי הקיצונויות: או שהם מנסים לפתור בעיה מורכבת עם פתרון פשטני (requests לכל דבר), או שהם בונים מערכת מפלצתית למשימה שאפשר היה לפתור ב-50 שורות קוד. לפני שאתם כותבים שורת קוד אחת, תגדירו במדויק מה ה-output הנדרש ומה תדירות העדכון. זה יכתיב 90% מההחלטות הטכניות שלכם.