Açık kaynak crawler seçimi, dört görevi ayırınca kolaylaşır: genel tarama, tarayıcı otomasyonu, zamanlama ve kuyruklar, ayrıştırma ve depolama. Bu yazı her bölümün işini, birleşimdeki yaygın sorunları ve dört pratik ölçütü açıklar.
GitHub'da crawler aradığınızda yüzlerce, hatta binlerce depo görebilirsiniz. Birçok kişi proje seçerken yıldız sayısına bakıp en popüler olanı kullanmaya başlar.
Popülerlik ile ihtiyaca uygunluk aynı şey değildir. Bir proje ne kadar popüler olursa olsun, amacı sizin senaryonuzla örtüşmüyorsa kullanımı daha yorucu hale gelir. Daha kolay başlangıç noktası görevleri ayırmaktır: uzun süre güvenilir çalışacak bir veri toplama sistemi, zaten farklı sorumluluklara sahip birkaç bileşenin birleşimidir. Her parçanın ne yaptığını anlayınca somut uygulamaları karşılaştırmak çok daha kolay olur.
Genel crawler framework'leri: düzenli yapıya sahip sayfalar için
Bu framework'ler istek zamanlamasını, eşzamanlı veri çekmeyi ve veri hatlarını yönetir. Girdi olarak URL kümeleri alır, çıktı olarak yapılandırılmış sonuçlar üretir. Olgun ekosistemler ve middleware mekanizmaları kendi mantığınızı eklemenizi sağlar; büyük ölçekli ve uzun süreli işler de bunlarla güvenilir biçimde yürütülebilir.
JavaScript çalıştıktan sonra içeriği oluşan sayfaları tek başlarına işleyemezler. Böyle bir durumda alınan yanıt yalnızca boş bir kabuktur ve ayrıca bir render motoru gerekir. Liste sayfaları, detay sayfaları ve açık API'ler gibi yapısı kararlı hedefler için uygundurlar.
Tarayıcı otomasyonu: render ve etkileşim gereken sayfalar için
Gerçek render, oturum açılmış durum veya içeriğin görünmesi için birkaç tıklama gereken sayfalar tarayıcı otomasyonuna bırakılmalıdır. Bu araçlar farklı tarayıcı motorlarında çalışabilir, olgun bekleme mekanizmalarına sahiptir ve sayfadaki isteklerle yanıtları doğrudan yönetebilir.
Bunun bedeli, basit HTTP isteklerine göre çok daha yüksek kaynak tüketimidir. Eşzamanlılık üst sınırını büyük ölçüde yerel bellek ve CPU belirler. Ayrıca otomasyon tespit edilebilir izler bırakır ve sıkı kontroller uygulayan siteler bunları fark edebilir.
Zamanlama ve kuyruk bileşenleri: görev sayısı arttığında gerekir
Az sayıda hedef için bir döngü yeterli olabilir. Görev sayısı binlere çıktığında ve istek sıklığı ile yeniden denemeler kontrol edilmek istendiğinde ayrı bir zamanlama katmanı gerekir: görevler nasıl sıraya alınacak, kaç görev aynı anda çalışacak, hata sonrası ne kadar beklenecek ve hangi görevlerden vazgeçilecek? Bu mantığın tümünü crawler framework'üne koymak kodu giderek karmaşıklaştırır.
Bu katmanı kendiniz kurarken yapılan yaygın hata, yalnızca süreç belleğinde yaşayan bir kuyruk kullanmaktır. Süreç yeniden başlarsa bekleyen tüm görevler kaybolur. Kuyruk en azından kalıcı olmalı ve durum sorgulanabilmelidir.
Ayrıştırma ve depolama: verinin doğrudan kullanılabilir olup olmadığını belirler
Geri gelen şey HTML'dir; kullanılacak olan ise alanlardır. Ayrıştırma katmanı çıkarım kurallarını yönetmeli, alanları doğrulamalı, tekrarları kaldırmalı ve veriyi depolamalıdır. Yapısı sık değişen sitelerde, sabit seçiciler yerine sayfa özelliklerine göre veriyi bulan uyarlanabilir çıkarım yöntemleri bakım yükünü azaltabilir.
Depolama tarafında idempotency önemlidir. Yeniden denemeler normaldir; bu nedenle yazma işlemleri benzersiz bir tanımlayıcıya göre tekilleştirilmelidir. Aksi halde yinelenen kayıtlar sonraki analizleri kirletir.
Bileşenler birleştirildiğinde sık görülen sorunlar
Her parça tek başına zor değildir. Sorunlar genellikle aralarındaki bağlantılarda ortaya çıkar.
- Zamanlama katmanı görevi yeniden dener, fakat ayrıştırma katmanı tekilleştirme yapmaz ve yinelenen satırlar oluşur
- Tarayıcı katmanında eşzamanlılık sınırı yoktur, yerel kaynaklar tükenir ve tüm görev grubu çöker
- Ayrıştırma kuralları koda sabitlenmiştir; site değiştiğinde yeni sürüm çıkarmak gerekir
- Bileşenler aynı görev için farklı tanımlayıcılar kullanır, durumlar uyuşmaz ve kaldığı yerden devam etmek mümkün olmaz
Dört değerlendirme ölçütü
Gerekli kategori belirlendikten sonra somut projeleri bu dört ölçütle eleyin.
Bakım etkinliği için toplam yıldız sayısına değil, son birkaç aydaki commit sıklığına ve issue yanıt hızına bakın. Bakımı durmuş bir proje, hedef site değiştiğinde doğrudan çalışmaz hale gelebilir.
Dokümantasyon ve örnekler öğrenme maliyetini belirler. Dokümantasyon belirsizse veya yalnızca en basit örnekleri içeriyorsa, öğrenme süresi çoğu zaman beklenenden uzun olur.
Genişletilebilirlik için hangi bağlantı noktalarının bırakıldığına bakın: proxy değiştirilebiliyor mu, kendi render motorunuz bağlanabiliyor mu, depolama değiştirilebiliyor mu? Açık genişletme noktaları olan projelerde sonraki uyarlamalar kaynak kodu değiştirmeden yapılabilir.
Lisans ve uyumluluk riskleri kolayca atlanır. Ticari kullanımdan önce lisans türünü doğrulayın ve kullanım amacınızla çelişen kısıtlayıcı lisanslardan kaçının. Veri toplama kapsamı, istek sıklığı ve hedef sitenin şartları da birlikte değerlendirilmelidir; bunlar framework'ün teknik kalitesinden bağımsızdır.
Ortam katmanı ayrı bir seviyedir
Framework nasıl veri toplanacağını çözer; kimlik ve ölçek sorunlarını çözmez. Görevler giriş yapmayı, bölgesel ayrımı veya birden fazla hesabın paralel kullanımını gerektirdiğinde her şeyi aynı tarayıcı ortamında çalıştırmak iki sorun yaratır: oturumlar birbirini etkiler, çünkü cookie'ler ve yerel depolama çakışır; hedef site de aslında ilgisiz görevleri aynı ziyaret grubunun parçası olarak görebilir.
Olgun yaklaşım, tarayıcı ortamlarını bağımsız bir kaynak katmanı haline getirmektir. Görevler havuzdan bir ortam alır ve iş bitince serbest bırakır. PurpleMark bu tür mimarilerde bu katmanı sağlar; toplu oluşturulabilen, bağımsız ağ çıkışlarına bağlanabilen ve durumu sorgulanabilen ortam kaynakları sunar.
Uyumluluk sınırları
Hedef sitenin robots kurallarına ve hizmet şartlarına uyun, kişisel bilgi toplamayın, teknik koruma önlemlerini aşmayın ve istek sıklığını hizmetin normal çalışmasını bozmayacak şekilde kontrol edin. Proje seçimi verimlilik sorununu çözer; bu değerlendirmeler ise işlemin yapılıp yapılmaması gerektiğini belirler.
