Import job parallelization

[ondrejhlavacek]

ref https://github.com/keboola/output-mapping/issues/15

• Paralelní uploadování slicovanýho souboru máme vyřešený.
• Nemáme vyřešený, že by mohlo běžet víc importních jobů zároveň (a to se dělí na upload do S3 a Storage job). Zrychlení by mohlo spočívat v tom, že se bude uploadovat všechno naráz a pak se do Storage fronty zapíšou všechny importní joby a bude se jen hromadně pollovat jejich výsledek. Řízení vytížení fronty zůstává na Storage.

Může bejt víc variant, jak to implementovat

Tenkej klient

V podstatě by klient zůstal jak je, s pár drobnejma změnama, a celou paralelizaci by se řešila na straně integrace klienta (input/output mapping v docker runneru). Volání fcí klienta (upload do S3, založení tabulky) úplně snadno paralelizovat nejde (možná se pletu?) a nejsem si jistej, jestli je to úplně optimální řešení.

Tlustej klient

Veškerá paralelizace by se udělala na straně klienta. Vznikla by série metod, který by přijímaly pole (Client::createTablesAsync, Client::writeTablesAsync, Client::uploadSlicedFiles, Client::uploadFiles apod.). Zároveň by asi bylo dobrý sjednotit interface pro slicovaný a neslicovaný soubory, který se řeší každej jinak

https://github.com/keboola/output-mapping/blob/42ac0739d1497ea94b4e468aba2dd61deaeddf4b/Writer/Writer.php#L506-L513

Wrapper

Totéž jako tlustej klient, ale v jiný classe, ale nejsem si jistej, jestli nebude potřebovat přistupovat k nějakým private/protected metodám klienta. Ale zase by se tím vyřešilo sjednocení toho interface.

---

Podobně by pak šla implementovat i paralelizace exportů.

[odinuv]

tj. za me tlustej klient https://keboola.slack.com/archives/C03JBGZDG/p1532950831000114 klidne v jiny classe, soucasne by se s tim daly vyhodit array options

[ondrejhlavacek]

jde to proti konceptu config rows - musel by se dělat deferred import - importovat až na konci všech rows a data mezi tím někde skladovat. je to řešitelný, ale pokud něco zapisuje do stejný tabulky, mohl by tam bejt konflikt (ten by se teda mimochodem musel řešit i bez config rows)

[odinuv]

to ze runner dela importy po kazdym config row je sideeffect implementace a ne nejaky designovy rozhodnuti (dokonce si jeste ani nejsme uplne jisti, jestli je to pozitivni nebo negativni sideeffect), takze zrovna timhle bych se neomezoval

[Halama]

data by nebylo potřeba nikde skladovat, mohlo by je to házet normálně do files. A nakonci pak jenom odpálit paralelně importy.

[ondrejhlavacek]

Jo, to by asi šlo, otázka je, jestli hromadným uploadem všeho do S3 naráz taky nezískáme nějakej čas navíc (ty uploady by taky mohly jít paralelizovat), ale proti importním jobům to může bejt zanedbatelnej bonus.

[Halama]

Teď jsme se ještě bavili o tom že nejlepší by bylo paralelizovat celé config rows.