למה Requests לבד לא יספיק לכם במאיה
בואו נשים את זה על השולחן: אם אתם מנסים לחלץ מידע ממאיה - הבורסה עם ספריית HTTP סטנדרטית כמו requests בפייתון, אתם תראו בעיקר HTML ריק מתוכן או תבניות JavaScript. הסיבה פשוטה: האתר הוא Single Page Application (SPA), ככל הנראה מבוסס על Angular או React. התוכן שאתם מחפשים – הודעות חברה, נתוני מסחר, דוחות כספיים – לא נמצא ב-HTML הראשוני שהשרת שולח. הוא נטען דינמית באמצעות קריאות API אסינכרוניות שמתרחשות בדפדפן של המשתמש.
זה אומר שצריך כלי שיודע להריץ JavaScript. כן, אני מדבר על Headless Browsers. ולפני שאתם קופצים על Selenium, תעצרו. ב-2025, אין כמעט סיבה להתחיל פרויקט חדש עם Selenium. Playwright מהיר יותר, יציב יותר, וה-API שלו פשוט נקי ונוח יותר לעבודה. כשמדובר על איסוף קטלוג של כלל ההודעות או ניירות הערך באתר מאיה - הבורסה, היכולת לחכות לאלמנטים ספציפיים שיופיעו על המסך אחרי טעינת הנתונים היא קריטית. עם Playwright, אפשר לחכות לקריאת רשת ספציפית שתסתיים או לאלמנט DOM מסוים שיופיע, מה שמבטיח שהנתונים שלכם שלמים ולא חלקיים. זה ההבדל בין scraper שמצליח ב-70% מהזמן לבין כזה שמגיע ל-99.9% יציבות.
פענוח ה-API הנסתר ובניית 'API' פרטי
אז הבנו שצריך דפדפן. אבל להריץ headless browser לכל בקשה זה בזבוז משאבים מוחלט. הגישה המקצועית היא להשתמש בדפדפן רק פעם אחת – בשלב המחקר – כדי למצוא את ה-endpoints של ה-API הפנימי שהאתר משתמש בו. פתחו את ה-DevTools (F12), עברו לטאב 'Network', סננו לפי 'Fetch/XHR' ותתחילו לנווט באתר. מהר מאוד תגלו את הקריאות שבאמת מביאות את המידע.
באתר כמו מאיה - הבורסה, תמצאו כנראה endpoints לקבלת רשימת הודעות, נתוני מסחר היסטוריים, ופרטי נייר ערך ספציפי. הקריאות האלה מחזירות JSON נקי ונוח לעבודה. אחרי שזיהיתם את ה-endpoint, את ה-headers הדרושים (שימו לב ל-Authorization, X-CSRF-Token או cookies), ואת מבנה ה-payload, אתם יכולים לזרוק את Playwright ולחזור ל-requests או aiohttp. בניית מעטפת סביב ה-API הנסתר הזה מאפשרת לכם ליצור API / קובץ נתונים פרטי משלכם. המטרה היא להגיע ל-latency של פחות מ-400ms לבקשה, לעומת 3-5 שניות שיכול לקחת לדפדפן מלא לרנדר את הדף. זה משנה את כל המשחק כשצריך לאסוף אלפי נקודות מידע ביום. אם אתם נתקלים בקשיים, קראו את המדריך המלא לטיפול בשגיאות רשת נפוצות שיכול לעזור בזיהוי הבעיה.
Rate Limiting ו-Soft Bans: ה-Failure Scenario הצפוי
מצאתם את ה-API, בניתם את הסקריפט, והרצתם אותו בלופ. אחרי 500 בקשות, הכל נעצר. אתם מתחילים לקבל שגיאות 429 Too Many Requests, או גרוע מזה – 200 OK עם גוף ריק. ברוכים הבאים לעולם ה-rate limiting ו-soft bans. אתרים פיננסיים כמו מאיה - הבורסה רגישים במיוחד לנפח תעבורה גבוה. הם לא רוצים שתגרדו את כל האתר שלהם כל 5 דקות.
הפתרון הוא לא פשוט "להאט". הפתרון הוא להיראות כמו מספר משתמשים שונים. זה המקום שבו ניהול פרוקסי נכון נכנס לתמונה. שימוש ב-IP בודד הוא מתכון לאסון. אתם צריכים מאגר של פרוקסי איכותיים, ועדיף residential, ולעשות להם רוטציה חכמה. אל תעשו רוטציה על כל בקשה – זה חשוד. תחלקו את הבקשות שלכם לסשנים, כשכל סשן משתמש ב-IP אחר למשך מספר דקות. תשלבו את זה עם User-Agent אקראי (אבל הגיוני) והוספת דיליי קטן ורנדומלי בין בקשות. המטרה היא לא להעמיס על השרתים שלהם, אלא לבצע ניטור מחירים או שינויים באופן שלא מפעיל את מנגנוני ההגנה. עם ארכיטקטורה נכונה, אפשר לשמור על קצב הצלחה של מעל 99.5% גם בעשרות אלפי בקשות ביום.
איך לא להשתמש ב-Scraper: מתי הגישה הזו מסוכנת
חשוב להבין את המגבלות. בנינו מערכת איסוף נתונים מרשימה, אבל היא לא מתאימה לכל דבר. אם המטרה שלכם היא לקבל החלטות מסחר בזמן אמת, אלגוריתמיות, או כל פעולה שדורשת latency של מילי-שניות – scraping הוא הכלי הלא נכון. חד משמעית. כל תהליך scraping, יעיל ככל שיהיה, מכיל בתוכו עיכובים אינהרנטיים: latency של הרשת, זמן עיבוד של הפרוקסי, הזמן שלוקח לכם לנתח את התגובה. יכול להיות פער של שניות בודדות בין הרגע שהמידע מופיע באתר לבין הרגע שהוא זמין במערכת שלכם.
בשוק ההון, שניות הן נצח. שימוש במידע מ-scraper לקבלת החלטות מסחר מיידיות הוא הימור מסוכן. המערכות של מאיה - הבורסה עלולות להשתנות ללא הודעה מוקדמת, ה-scraper שלכם עלול להישבר, והמידע שתקבלו יהיה ישן. הגישה הזו מעולה עבור מודיעין מתחרים (במקרה זה, ניתוח שוק), בניית דאטהסטים היסטוריים, ניתוח מגמות, או קבלת התראות כלליות. אבל היא לא תחליף לחיבור ישיר לפיד נתונים רשמי מהבורסה אם אתם צריכים מידע ברמת אמינות ומהירות של מסחר. אל תנסו לבנות מערכת HFT (High-Frequency Trading) על בסיס Playwright. פשוט לא.
ארכיטקטורת איסוף נתונים: מ-Scraper בודד ל-Data Pipeline
איסוף ראשוני של כמה מאות רשומות זה נחמד. אבל מה קורה כשצריך לאסוף מיליוני רשומות לאורך זמן, לנטר שינויים, ולשמור את הכל בצורה מסודרת? סקריפט בודד על המחשב שלכם לא יספיק. צריך לחשוב במונחים של Data Pipeline.
הארכיטקטורה שאני מעדיף מורכבת מכמה רכיבים: רכיב 'גילוי' (Discovery) שסורק את האתר פעם ביום כדי למצוא קישורים חדשים (למשל, הודעות חברה חדשות או דוחות). רכיב 'איסוף' (Fetcher) שמקבל את רשימת המשימות, מריץ אותן במקביל (עם כלים כמו asyncio בפייתון), ומנהל את לוגיקת הפרוקסי וה-retries. רכיב 'ניתוח' (Parser) שלוקח את ה-HTML/JSON הגולמי ומחלץ את השדות הספציפיים שצריך, כמו שמות מוצרים/מודעות (שמות ניירות ערך) ומחירים (שערי מסחר). ולבסוף, 'אחסון' (Storage) ששומר את הנתונים המובנים בבסיס נתונים (PostgreSQL הוא בחירה מצוינת) או כקבצים ב-S3. כשמפרידים את הלוגיקה לרכיבים נפרדים, קל יותר לתחזק, לשדרג ולנטר כל חלק בנפרד. אם אתם מתמודדים עם אתר המוגן על ידי Cloudflare, כדאי לקרוא את המדריך לעקיפת Cloudflare כדי להבין את המורכבות הנוספת.