[hoszak]

#datascience

Hej Mirki, tak sobie dlubie proste ETL w #pandas #numpy #python i glowkuje jak tu skrocic czas ladowania trzech duzych (1GB kazdy 900k x 200) CSV. Jedyne co przychodzi mi jeszcze do glowy to dorzucenie multiprocesingu bo duzo sie dzieje, z %pruna widze ze w tej chwili CPU jest waskim gardlem. Probowalem w prymitywny sposob zaladowac to w multi rozrzucajac kazdy plik na osobny proces ale naturalnie zabraklo RAMu, wiem, ze musze zchunkowac pliki i rozdystrybuowac chunki do workerow, probowalem chunksize= ale cos mi to nie bardzo chce w multi biegac. Bede jeszcze jutro probowal z np.arraysplit.

moj csvread wyglada tak:

paths = os.path.join(VOLUME_CSV, "volume PN FY*.csv")
files = glob.glob(paths)

def csv_reader(file): 
 df = pd.read_csv(file, 
 low_memory=False,
 cache_dates=True,
 thousands=',',
 infer_datetime_format=True,
 parse_dates=["Funded date", "Maturity date"], 
 dtype=col_types,
 true_values=['Y'],
 false_values=['N'],
 na_values=['-'],
 index_col=False
 )
 return df
df = pd.concat(map(csv_reader, files), ignore_index=True).reset_index(drop=True)

Czy macie jakis boiler plate jak to ugrysc, dobre rady, slowo na pocieszenie? Jak to zoptymalizowac. Wrzucilem pytanie na stacka ale narazie cisza:

https://stackoverflow.com/questions/72944450/pandas-chunks-from-multiple-files-to-list-collection-to-process-them-with-mult

Jeszcze jedno, chce to zrobic bez Daska, bede chcial dorzucic tam jeszcze jakies operacje ale generalnie wiekszosc manipulacji mam z uzycie wektoryzacji wiec nie warto ich ruszac.

Z gory dziekuje za pomoc.

[d.....z]

@hoszak: zobacz na rozwiązania w tym wątku: https://stackoverflow.com/questions/6475328/how-can-i-read-large-text-files-line-by-line-without-loading-it-into-memory

[A.....c]

@hoszak: Spróbuj Polars, sporo szybsza biblioteka, wrapper Rust-a.
https://www.pola.rs/

Ewentualnie Pyarrow - https://arrow.apache.org/docs/python/generated/pyarrow.csv.read_csv.html

[hoszak]

@devopsiarz: dzieki, to nie to czego szukam

@Acrylic: Zostaje w Pythonie, kolejne niepowodzenia w napisaniu tego skryptu z multiprocessingiem pchaja mnie w kierunku Dask'a lub PyArrowa, dzieki

[A.....c]

@hoszak: Z ciekawości, czemu nie chcesz używać Dask-a?

Polars jest naprawdę spoko, piszę się w tym jak Pandas, u nas w firmie właśnie migrujemy z Pandas na Polars gdzie się da.

Możesz też użyć Ray lub bardziej high level Modin. Generalnie nie wiem jaki przyrost wydajności cię interesuje, na pewno jakbyś miał pliki w formacie Parquet to byłoby lepiej.

[hoszak]

@Acrylic: Ujme to tak, moja firma jest bardzo konserwatywna pod wzgledem technologii :). W tej chwili przenosze ETL z Power Query do Pandasa, dostalem zgode na Pandasa bo sa na rynku ludzie ktorzy w tym pisza, no i jeszcze jestdzial od ML, tak na wszelki wypadek jak bym chcial sie zawinac. Mialem nie implementowac dodatkowych bibliotek w obawie przed brakiem wsparcia. Tak naprawde najchetniej to co robie zrobilbym na SQLu ale nie ma serwera dedykowanego, a hobbystycznie, lokalnie nie chce tego robic. Jak napisalem, czesc zrodel mam w CSV, czesc w Excelach. Replikuje je w skompresowanych Parquet'ach bo sa czytalne przez PBI. Efekty sa niezle, naturalnie mozna lepiej, na przykladzie jednego zbioru 2,5 gb CSV ktora po ETL i optymalizacjach typow danych etc. wazyla 1.8 gb w excelu, teraz w Parquecie po dodaniu kolejnych pol obliczeniowych zszedlem do 135 mb z wykorzystanie category, plik gotowy do wrzucenia na SQL i skonsumowania przez ekosystem Microsoftu, glownie PBI i Dynamics AX. Dla mnie uzywanie Excela o tych rozmiarach jako kontenera na dane to zbrodnia ale nie mam na to wplywu.

Dlaczego personalnie nie chce w tej chwili juz przejsc na Dask'a, chociaz dalej sie nad tym zastanawiam. CSV ktore mam sa syfiaste, ladujac je przez pandasa uzywam bardzo wielu parametrow (oznaczenie false/true values, znak dziesietny, parsowanie daty, navalues), metoda readcsv Pandasa zalatwia za mnie sporo rzeczy i nie chce mi sie tego teraz odtwarzac bo ani Dask, ani PyArrow nie maja az tak rozbudowanego interfejsu ladowania CSV, wszystko trzeba zaladowac w stringu i potem zrobic czyszczenie. Zbior z ktorym pracuje ma ponad 200 kolumn z mix typam. Generalnie jest jeszcze taka sytuacja, ze w sumie osiagnalem juz tak duzy skok wydajnosciowy, ze to juz bardziej dla sportu z tym walcze. Proces oparty o PowerQuery mielil 2 godziny, oczywiscie wszystko zwalnialo przez zle zarzadzanie RAMem ale PQ nie uzywa wektoryzacji. Dane maja duplikaty po normalizacji wiec nie zrobisz uppera na category, lecisz po calym series, kolumn na ktorych mialem to zrobic jest 139 z wysoka kardynalnoscia. To konsumuje duzo zasobow. Tak czy siak z 2 godzin zszedlem ponizej 5 minut. Wiem, ze Pandas i Numpy nie sa stworzone do takich celow ale na moje potrzeby, na ten moment wystacza oferujac spory bump wydajnosciowy.

Generalnie, gdyby to ode mnie zalezalo juz dawno caly dataset wyladowal by na SQL w chmurze, ale u mnie sie

[hoszak]

@Acrylic: siema, pobawilem sie troche Polarisem, chodzi piekielnie szybko, bardzo obiecujace. Ale czasem tracebacki wali takie, ze nie wiadomo o co chodzi, trzeba debugowac. Widac, ze jeszcze troche brakuje dojrzalosci. Nie wiem czy to przypadlosci pythonowego API czy w Ruscie daje te same tracebacki ale brak wskaznika jakiegokolwiek odnosnie kolumny, nr kolumny czy jakiegokolwiek wskazania o ktora chodzi konczy sie debugowaniem albo szukaniem igly w stogu siana. Mam 50 kolumn bool.

Tak czy siak, dzieki za podrzucenie Polarisa, bede jeszcze to rozmasowywal az zacznie dzialac :)

[pejczi]

@hoszak: A nie mozesz tego przemigrowac na Databricksy/innego Sparka?

[hoszak]

@pejczi: To jest troche taka rada jak, "a czemu tego nie napiszesz w C?" :). Ja nawet chetnie bym powalczyl z Databricks czy Sparkiem, ale to nie ja tutaj ustalam zasady, umowilismy sie, ze bedzie w Pandasie bo on oferuje stosunkowo niski prog wejscia i duze wsparcie. Troche poeksperymentowalem z Polarsem bo on jest blizniaczo podobny do Pandasa. Spark na pewno jest ciekawa alternatywa ale nie bedzie na to zgody,

[pejczi]

@hoszak: Predzej znajdziesz ludzi od ETLa w Sparku/Databricks niz pandasie ( ͡° ͜ʖ ͡°)

[hoszak]

@pejczi: mysle, ze firma w ktorej pracuje bardziej patrzy kategoriami: "predzej ktos z Excela/PowerQuery przysposobi sie do Pandasa niz my bedziemy chcieli zaplacic za eksperta w Sparku" :)

[pejczi]

@hoszak: na koniec dnia i tak wydadza pol banki na consulting bo wywali im sie projekt :)

[hoszak]

@pejczi: uczciwie powiem, ze dla mnie to jest porazka bo to wszystko po prostu powinno siedziec na SQLu i do tych potrzeb wydaje sie to byc najrozsadniejsze rozwiazanie. Z niejasnych dla mnie przyczyn nie chca tego zrobic. Na consulting poszlo, podejrzewam juz duzo wiecej.

[pejczi]

@hoszak: @hoszak: To dziwie sie, ze consulting nie wywalil tego do gory nogami i nie dal sensownej rekomendacji jak to zrobic koszernie.