İndirilen Censys Verisini Offline Sorgulamak: Biçim, Araçlar ve Pratik Kalıplar

yazar

API veya arayüzden aldığınız çıktıyı diske yazdıktan sonra bir sonraki soru şudur: Bu veriyi tekrar API’ye gitmeden nasıl keserim? Offline sorgulamanın üç temel nedeni vardır: kota ve hız, tekrarlanabilir analiz, ve veriyi mümkün olduğunca kontrollü bir ortamda tutmak.

Aşağıda “hangi dosya → hangi araç” ekseninde ilerliyorum.

1. Dosya biçimini sabitleyin

  • JSON Lines (JSONL / NDJSON): Her satır tek JSON nesnesi. API dump’ları için en pratik format; büyük dosyada satır satır okunabilir.
  • Parquet: Kolonlu ve sıkıştırılmış; analitik ve SQL motorlarıyla iyi çalışır.
  • CSV: Düz alanlar için uygun; iç içe JSON (servis listesi, başlıklar) içeren ham host kayıtları için çoğu zaman kırılgan kalır.

Öneri: Ham export’u JSONL tutup, ihtiyaç halinde Parquet’e dönüştürün.

2. Hızlı kesit: jq (komut satırı)

Tek dosyada alan filtrelemek, sayım veya küçük özet için jq yeterlidir. Genel fikir: her satır bir JSON; jq -c ile pipe’lanabilir çıktı üretilir.

Örnek kalıplar (alan adlarını kendi şemanıza göre değiştirin — export’taki host.ip, services yapısı sürüme göre değişebilir):

# Toplam satır (satır = bir kayıt varsayımıyla)
wc -l export.jsonl


# Belirli bir IP içeren satırları süz (örnek: ip alanı kökteyse)
grep '"ip":"203.0.113.7"' export.jsonl


# jq ile seçili alanları düzleştir (örnek şema: her satırda .ip ve .services)
jq -c '{ip: .ip, services: .services}' export.jsonl | head

 

İç içe listelerde (services[]) filtre için jq güçlüdür; öğrenme eğrisi vardır ama offline işin en hafif ayağıdır.

3. SQL ile: DuckDB (önerilen orta yol)

DuckDB, tek dosya üzerinde SQL çalıştırır; JSONL ve Parquet okumasını iyi destekler. “Büyük CSV mu Excel mi?” ikileminden kurtarır.

JSONL’den okuma fikri (DuckDB sürümünüze göre read_json_auto sözdizimini dokümantasyondan doğrulayın):

SELECT
host.ip,
svc.port,
svc.service_name
FROM read_json_auto('export.jsonl')
LEFT JOIN UNNEST(host.services) AS svc(service)
LIMIT 50;

Not: Gerçek şemanız hits içinden gelen iç içe yapı olabilir; bir kez SELECT * FROM read_json_auto(...) LIMIT 1 ile sütun ağacını görüp sorguyu ona göre yazarsınız.

Parquet’e çevirmek analizi hızlandırır:

COPY (SELECT * FROM read_json_auto('export.jsonl')) TO 'export.parquet' (FORMAT PARQUET);

 

4. Python ekosistemi

  • pandas / polars: JSONL okuma, filtre, groupby, iki dump arası fark. Polars büyük dosyalarda genelde daha verimli.
  • SQLite: “Küçük orta boy” veriyi tek .db dosyasında toplayıp tekrar sorgulamak için; önce düzleştirilmiş tabloya normalize etmek gerekir.

Örnek Polars (satır bazlı JSON):

import polars as pl


df = pl.read_ndjson("export.jsonl")
# Örnek: kökte 'ip' ve 'services' listesi olduğunu varsayarak:
df = df.explode("services").unnest("services")
print(df.head())

Şema farklıysa tek yapmanız gereken: bir print(df.schema) veya df.head(1) ile alan yolunu netleştirmek.

5. “Diff” için anahtar seçimi

Offline’da iki tarihli export karşılaştıracaksanız, önce satır anahtarını sabitleyin. Yaygın güvenli tercihler:

  • ip + port + transport (TCP/UDP)
  • Mümkünse platformdaki stabil host hizmet tanımlayıcısı

Sadece IP ile diff, paylaşımlı barındırmada gürültü üretir; bunu yazıda bilinçli söylemek önemlidir.

6. Güvenlik ve saklama (kısa)

  • Ham export kişisel / kurumsal meta veri içerebilir; disk şifreleme ve erişim sınırlaması düşünün.
  • Süre: “sonsuz arşiv” yerine amaca bağlı saklama süresi belirlemek iyi prensiptir.
  • Paylaşım: Ödev veya rapor için örneklerde anonimleştirme ve kırpma.

7. Pratik öneri: üç katmanlı iş akışı

  1. Ham: JSONL arşiv (audit için).
  2. Çalışma: DuckDB veya Polars ile sorgu.
  3. Özet: Küçük CSV/MD rapor (paylaşılabilir çıktı).

Özet: Offline sorgu, veriyi bir kez disipline edip sonra tekrarlanabilir şekilde kesmektir. Küçük işler için jq, analitik için DuckDB + JSONL/Parquet, özel otomasyon için Polars/Pandas doğal üçlüdür; asıl iş şema keşfini bir kez doğru yapıp anahtarınızı sabitlemektir.

Yorum yapın