Toto nemusí být váš přesný problém - nahrávání 100 milionů prvků do hosted feature service v ArcGIS Online - ale téma zde je nahrávání velkých dat do hosted feature service v Online, 100 milionů je měřítko, o kterém mluvím.<\/P>
Zde je, jak vypadá 100 000 000 prvků při hustotě, se kterou pracuji.<\/P>
Rozsah přibližně přes městský blok:<\/P>
Vrstva není viditelná<\/span><\/span><\/P>Poté zapnutí viditelnosti vrstvy:<\/P>
Vrstva je viditelná<\/span><\/span><\/P>Data jsou tak velká, že Pro 2.9 se nepokusí zobrazit je v měřítcích menších než 1:500.<\/P>Zde je pozadí příběhu. Jeden z týmů Esri, se kterými spolupracuji, občas řeší velká data určená pro hosted feature service v Online. Web je takový, jaký je, velmi velké transakce sdílení mohou selhat kvůli síťovým nebo jiným problémům, a pak musíte situaci obnovit tam, kde došlo k přerušení<\/EM> nebo znovu spustit celý proces sdílení<\/EM>. Chtěli proces, který funguje spolehlivě a má mechanismus obnovy pro jakýkoli neúspěch. Směřovali k Python cestě, což je v pořádku pro Pythonisty, ale já jsem v kanceláři ten bez kódu (řekněme zotavující se programátor, který občas sklouzne). ArcGIS Data Interoperability na pomoc!<\/STRONG><\/P>Moje testovací data jsou CSV soubor s 143 751 910<\/STRONG> řádky.<\/P>
Získat počet<\/span><\/span><\/P> <\/P>Odebral jsem shora 100 milionů řádků jen jako pěkné kulaté číslo. Data mají hodnoty latitudy/longitudy, takže ETL aspekt je jednoduché prostorové povolení pro vytvoření bodových prvků. Teď jak je poslat do bodové vrstvy prvků?<\/P>Předběžným krokem bylo vzít vzorek dat do file geodatabase a vytvořit z něj feature service, to jen inicializuje cílovou vrstvu. Pak je problém dále dvousečný:<\/P>Nahrát data co nejvýkonněji<\/LI>Použít metodiku podporující obnovu po selhání<\/LI><\/UL>Tým Online navrhl „sweet spot“ pro nahrávání dat tohoto rozsahu použitím Append endpointu pro feature service s dávkami po 500 tisících záznamech ve dvou současných procesech a spustit to „po pracovní době“ podle času USA. Žádný problém, zde jsou moje pracovní prostory:<\/P>
LoadTaxis<\/span><\/span><\/P>LoadTaxis<\/STRONG> vytváří zipované file geodatabases sad po 500 tisících záznamech<\/STRONG>, pak předává cestu k datům LoadTaxisWorker<\/STRONG> ve maximálně dvou asynchronně běžících procesech. Zjistil jsem, že čas potřebný na přípravu dat dobře odpovídá době, kterou Online potřebuje k jejich zpracování, něco málo pod 2 minuty na dávku během hodin nízké zátěže. Při sledování logu bylo několik případů, kdy LoadTaxis<\/STRONG> čekal na uvolnění slotu procesu, ale obvykle byl Online připraven na další dávku, takže věci fungovaly tak rychle, jak můj ETL mohl běžet.<\/P> <\/P>
LoadTaxisWorker<\/span><\/span><\/P>LoadTaxisWorker<\/STRONG> nahraje každý zipovaný file geodatabase do Online a pak zavolá službu Append endpoint, čímž spustí nahrávání z nového file geodatabase itemu. To spustí úlohu v Online. Smyčkový vlastní transformátor kontroluje dokončení úlohy každých 5 sekund (s maximálním počtem kontrol
Ve skutečnosti dávám přednost spuštění nástroje LoadTaxisWorker v režimu úprav (tj. ve Workbench), abych mohl dělat věci jako zapnutí Emailers, abych mohl podrobně sledovat akci. Je tu také tento problém, na který je třeba dávat pozor, který vložím do spoiler tagu:
SpoilerVarování: Volání Append nástrojem LoadTaxisWorker může trvat mnohem déle, než se očekávalo (hodiny, ne minuty), pokud je spuštěno v rušné době pro Online - Append je sdílený zdroj a může být zařazen do fronty. V takovém případě vám Emailer oznámí, že uplynulo 210 sekund (nebo vaše preferovaná doba vypršení) bez dokončení Append; stále se to nakonec dokončí, ale operace úklidu se nespustí. S tímto jsem se setkal a povolil jsem Emailer, který odesílá URL úlohy, abych ji mohl sledovat ručně.
Každopádně po ručním spuštění vašich neúspěšných úloh budete mít ve své službě 100 milionů prvků!
Hurá, mých 100 milionů prvků je načteno!
Jak těžké to bylo?
Nástroje ETL jsou v post download. Použil jsem ArcGIS Pro 2.9 & Data Interoperability extension.
