UNLOAD to S3

[ErikZigo]

Redshift umoznuje UNLOAD dat do S3. https://docs.aws.amazon.com/redshift/latest/dg/r_UNLOAD.html

Tim by se daly zrychlit redshift extractory, protoze bysme nemuseli fetchovat data po radcich.

Asi by to znamenalo, ze aplikace extractoru by musela mit vlastni S3 bucket kam by se data unlodovali a pro Redshift generovat credentials pro zapis pouze do urcite cesty.

[ondrejhlavacek]

Co kdyby tomu S3 založil Docker Runner? Bude to tady běh na dlouhou trať ale dokážu si představit, že komponenta, která má config rows (tj. má na výstupu pouze jednu tabulku), ti do configu injectne S3 credentials do našeho stagingu, kam unloadneš soubory a pak tam vytvoříš manifest (nebo ten manifest můžeme taky vyrobit my?). Pak by se to rovnou naimportovalo do Storage.

[Halama]

tohle si představuju že sconfig rows bude celkem jednoduchý. Připraví tomu jedny credentias.

[ErikZigo]

Kdyby to umel docke runner, tak by to bylo nejlepsi!

[Halama]

další S3 bych tam nevkládal

[ErikZigo]

Ja jsem urcite pro. V budoucnu se to muze hodit i nekde jinde.

[ondrejhlavacek]

Nemaj ty credentials nějakou omezenou platnost? Nebo se dá nastavit? Asi jedinej zádrhel teďka vidím s manifestem, ale ten by imho měl sestavit output mapping, takže by se komponenta nemusela o nic starat.

[ErikZigo]

Ta platnost se da nastavit a maximalni je 36 hodin. Takze to by melo bejt v pohode. https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

[Halama]

teď máme default 12h

[pivnicek]

dobry napad. cesta do config rows je sem https://github.com/keboola/db-extractor-redshift/issues/16. neni to hodnej prace. hodim ho na svoj queue

[ondrejhlavacek]

I těch 12 bohatě stačí. Super by bylo, kdyby to docker runner uměl zamknout

On Wed, Dec 5, 2018, 1:08 PM Marc <notifications@github.com wrote:

dobry napad. cesta do config rows je sem #16 https://github.com/keboola/db-extractor-redshift/issues/16. neni to hodnej prace. hodim ho na svoj queue

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keboola/db-extractor-redshift/issues/20#issuecomment-444463758, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeYC3zalbgJKnWf7Aw5CTuuNbnCud-Eks5u17dWgaJpZM4YxAa0 .

[Halama]

Co myslíš tím zamčením?

[odinuv]

ale ten by imho měl sestavit output mapping,

a jak do nej ta komponenta neco dotlaci (pk, metadata ?)

[pivnicek]

pres manifest, ne?

[ondrejhlavacek]

Zamčení - aby tam někdo později nemohl donahrát/upravit/smazat nějaký slice. Chránit se před nějakým async jobem - rozbil by se tím audit trail. PK, Metadata - přes manifest bych taky řekl.

[Halama]

Tomu zamčení pořád úplně nerozumím. Write credentials pro jeden file jdou vygenerovat pouze jednou a nemají jiné oprávnění než s3:PutObject a s3:PutObjectAcl. Bojíš se tedy že by někdo v té komponentě vzal ty credentials poslal si je bokem a potom než vyexpirují tam něco donahrál nebo přepsal?

[ErikZigo]

@Halama Ty myslis jako ze by to bylo ve file uploadech a docker runner by jen zavolal https://keboola.docs.apiary.io/#reference/files/upload-file/create-file-resource pro ziskani tech credentials?

[Halama]

jo jasně tak to myslel už najloš, nedává smysl tam mít další S3. Byla by to obdoba S3 input mappingu. Před config rows jsme nevěděli jak to vyřešit kvůli nejednoznačnému počtu souborů v OM ale u config row to můžeme smrksnout na to že bude prostě jeden.

Taky pak nepůjde použít processory ale zrovna pro use case db extractorů které podporují unload do S3 v rozumném CSV by to nevadilo.

[ondrejhlavacek]

https://github.com/keboola/db-extractor-redshift/issues/20#issuecomment-444784328

Jj, přesně, aby si to někdo někam nemohl odlít bokem a pak tam dodatečně něco dosypat. Může mít na druhý straně třeba nějakej async job, kterej mu tam dosype něco později. Samo o sobě mi to zas tak nevadí, ale rozbila by se tím vazba mezi importním jobem a souborem.

A s procesorama se počítá, že nepůjdou, stejně tak nejdou v inputu do S3.

[Halama]

jo jasně, tak to nevím jak řešit. Ty credentials nejdou zrušit myslím. Ale pokud tam bude manifest nahrávat docker runner tak tím tak trochu zafixuje co se bude importovat.

[ondrejhlavacek]

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html

Tady podle toho to prej jde - nemazat, ale odstranit všechna oprávnění.

[Halama]

Tu variantu kdy se to omezí uživateli který ty credentials použít nemůžeme protože by to zablokovalo všechny přístupy. Ta druhá kdy se to obezí pomocí resource policy nad bucketem asi také ne protože bucket může mít tu policy jenom jednu takže by se to tam muselo nějak appendovat a tam by se mohlo narazit na přepisování apod.

[Halama]

Mě tahle situace ale nepřijde jako problém. Už teď může nastat když si to někdo bude skriptovat sám a bude dělat něco podobného jak jsi popisoval.

[ondrejhlavacek]

Jo, to je vlastně pravda. A pomocí access logů by šlo dohledat, jestli tam byl nějakej pozdější zápis. Připomínu stahuju! :-)

[pivnicek]

chtel jsem jen linkovat sami issue v snowflake-ex https://github.com/keboola/db-extractor-snowflake/issues/1