Mali filter je lako napraviti dok se cijeli fajl može otvoriti u Excelu.

Problem se mijenja kada se ulaz mjeri u gigabajtima. Učitati CSV od 20 ili 200 GB u memoriju nije razuman početni pristup, a ni tražiti od netehničkog korisnika da piše upite u terminalu ne rješava operativni problem.

Napravio sam javni Python projekat da istražim taj prostor između.

Problem

Zamislimo fajl sa zapisima o gradovima. Korisniku trebaju redovi u kojima naziv grada sadrži „New York“ ili je jednak „Chicago“, a rezultat treba izvesti za naredni korak.

Pravilo filtriranja je jednostavno. Teži dijelovi su:

  • izvor možda ne može stati u memoriju;
  • korisnik i dalje mora definisati i pregledati uslov;
  • identifikatori i vrijednosti moraju ostati nepromijenjeni;
  • izlaz mora biti razumljiv i izvan Pythona.

Obrada fajla u blokovima

Originalni projekat koristi pandas chunking.

Umjesto učitavanja cijelog CSV-a, Python čita blok razumne veličine, primijeni uslov, sačuva odgovarajuće redove i nastavi na sljedeći blok. Maksimalna potrošnja memorije tada zavisi od veličine bloka, a ne od cijelog izvornog fajla.

Osnovni oblik je jednostavan:

for chunk in pandas.read_csv(path, chunksize=chunk_size):
    matches = chunk.query(filter_expression)
    write_or_collect(matches)

Stvarni kod zahtijeva više pažnje. Tipovi kolona, delimiteri, encoding, neispravni redovi i način pisanja izlaza moraju biti eksplicitne odluke.

Malo sučelje za netehničkog korisnika

Za desktop interfejs koristio sam Tkinter.

Cilj nije bio napraviti ispoliranu komercijalnu aplikaciju. Cilj je bio omogućiti korisniku da izabere fajl, definiše uslove filtriranja i izveze CSV ili XLSX rezultat bez izmjene Python koda.

Takav izbor je donio i korisno dizajnersko ograničenje: ako se pravilo filtriranja ne može jasno objasniti u interfejsu, vjerovatno nije dovoljno jasno ni u implementaciji.

Šta bih danas promijenio

Projekat i dalje dobro pokazuje osnovnu ideju, ali bih danas jasnije razdvojio dijelove:

  1. sloj za parsiranje i validaciju;
  2. filtering engine s imenovanim pravilima;
  3. writer izlaza s brojem redova i provjerama;
  4. tanko korisničko sučelje iznad svega toga.

Zavisno od fajla i okruženja, razmotrio bih DuckDB, Polars ili stvarnu bazu podataka umjesto pretpostavke da je pandas uvijek pravi engine.

Važna nije omiljena biblioteka. Važno je učiniti ograničenja memorije, tipove podataka, logiku filtera i validaciju izlaza vidljivim.

Šta je provjereno

Ovo je samostalni javni projekat, a ne klijentski slučaj s izmjerenim poslovnim rezultatom.

Kod demonstrira čitanje u blokovima, korisnički definisano filtriranje i CSV/XLSX izlaz. Pokazuje ponovljiv pristup problemu koji bi inače lako postao niz ručnih ekstrakcija.

Ne tvrdim da svaki fajl od 200 GB treba obrađivati ovim desktop alatom. Na toj skali profilisanje stvarnog fajla i izbor odgovarajućeg enginea postaju dio zadatka.

Izvor

Projekat je dostupan na GitHubu. Originalni kratki članak objavio sam i na Mediumu.

Šira lekcija i dalje vrijedi: „filtriraj ovaj fajl“ nije samo upit. To je mali data workflow kojem trebaju eksplicitna pravila, jasna ograničenja resursa i način da se rezultat provjeri.

Mehmed Kadrić Osnivač, MESH Data Solutions

Pišem o konkretnim problemima s podacima i softverom: šta nije radilo, šta je napravljeno i šta bih sljedeći put promijenio.

TREBAJU VAM DOKAZI IZ VLASTITIH PODATAKA?

Pretvorite listu provjera u fokusirani audit.

Zatražite reviziju