Dit is misschien niet precies jouw probleem - 100 miljoen features laden in een hosted feature service in ArcGIS Online - maar het onderwerp hier is het laden van big data in een hosted feature service in Online, 100 miljoen is de schaal waar ik het over heb.<\/P>
Hier zie je hoe 100.000.000 features eruitzien bij de dichtheid waarmee ik werk.<\/P>
Een extent ongeveer zo groot als een stadsblok:<\/P>
Laag niet zichtbaar<\/span><\/span><\/P>Dan de laagzichtbaarheid aanzetten:<\/P>
Laag zichtbaar<\/span><\/span><\/P>De data is zo groot dat Pro 2.9 niet zal proberen het weer te geven op schalen kleiner dan 1:500.<\/P>Hier is het achtergrondverhaal. Een van de Esri-teams waar ik mee werk pakt af en toe big data aan die bestemd is voor een hosted feature service in Online. Het web is wat het is, zeer grote deeltransacties kunnen mislukken door netwerk- of andere problemen, waarna je de situatie moet herstellen waar het misging<\/EM> of het hele deelproces opnieuw moet uitvoeren<\/EM>. Ze wilden een proces dat betrouwbaar werkt en met een herstelmechanisme voor elke fout. Ze gingen de Python-route op, wat prima is voor Pythonisten maar ik ben de no-code man op kantoor (laten we zeggen een herstellende coder die af en toe terugvalt). ArcGIS Data Interoperability to the rescue!<\/STRONG><\/P>Mijn testdata is een CSV-bestand van 143.751.910<\/STRONG> rijen.<\/P>
Aantal ophalen<\/span><\/span><\/P> <\/P>Ik nam 100 miljoen rijen van bovenaf als een mooi rond getal. De data heeft latitudinale en longitudinale waarden dus het ETL-aspect is een eenvoudige ruimtelijke inschakeling om puntfeatures te maken. Nu hoe stuur je deze naar een point feature layer? <\/P>Een voorlopige stap was om een steekproef van de data naar file geodatabase te nemen en er een feature service van te maken, dit initialiseert gewoon de doel-laag. Dan is het downstream probleem tweeledig:<\/P>Laad de data zo performant mogelijk<\/LI>Gebruik een methode die herstel bij falen ondersteunt<\/LI><\/UL>Het Online-team stelde voor dat een 'sweet spot' voor het laden van data op deze schaal het gebruik van de Append-endpoint voor de feature service zou zijn met batches van 500K records in twee gelijktijdige processen, en voer dit uit 'na werktijd' US tijd. Geen probleem, hier zijn mijn workspaces:<\/P>
LoadTaxis<\/span><\/span><\/P>LoadTaxis<\/STRONG> maakt gezipte file geodatabases van sets van 500K records<\/STRONG> en geeft dan het datapad door aan LoadTaxisWorker<\/STRONG> in maximaal twee processen die asynchroon draaien. Ik ontdekte dat de tijd die nodig is om de data te verwerken goed aansluit bij hoe lang Online nodig heeft om het te verwerken, iets minder dan 2 minuten per batch tijdens uren met lage belasting. Terwijl ik het logbestand bekeek, waren er enkele gevallen waarin LoadTaxis<\/STRONG> pauzeerde om te wachten tot er een processlot beschikbaar kwam, maar meestal was Online klaar voor de volgende batch, dus dingen werkten zo snel als mijn ETL kon draaien.<\/P> <\/P>
LoadTaxisWorker<\/span><\/span><\/P>LoadTaxisWorker<\/STRONG> uploadt elke gezipte file geodatabase naar Online en roept dan de service Append-endpoint aan, waardoor een laadproces wordt gestart vanuit het nieuwe file geodatabase-item. Dit start een job in Online. Een looping custom transformer controleert elke 5 seconden of de job voltooid is (met een maximum aantal controles van 42). Let op dat HTTPCaller in de custom transformer een concurrency-instelling van 1 nodig heeft om in een lus te werken. Bij succesvolle voltooiing wordt het file geodatabase-item verwijderd en wordt vervolgens een tweede child workspace - LoadTaxisCleanerUpper<\/STRONG> - aangeroepen om het input gezipte file geodatabase-bestand in een apart proces te verwijderen (anders blokkeren bestandsbehandelaars verwijdering).<\/P>
LoadTaxisCleanerUpper<\ /span ><\ /span ><\ /P >< P > Je zult zien dat ik in < STRONG > LoadTaxisWorker < \ / STRONG > een paar Emailer transformers heb (uitgeschakeld in de download) en dat WorkspaceRunner die het cleanup-proces aanroept ruimte laat voor meer child-processen zodat dingen niet vastlopen.< \ / P >< P > Nu, omdat dit het web is, kun je fouten krijgen zelfs als je best practices volgt, maar als dat gebeurt, is er een papieren spoor ingebouwd in de methode.& nbsp ; De file geodatabases die gemaakt zijn voor upload worden niet verwijderd van schijf of als Online-items zoals ze wel worden bij succesvolle jobs - je kunt alle mislukte data zien:< \ / P >< P >< span class = " lia-inline-image-display-wrapper lia-image-align-inline " image-alt = "File geodatabases niet verwijderd " style = " width: 999px ;">< img src = " https : \ / \ / us.v-cdn.net \ /6038851 \ /uploads \ /images \ /29698i1C051EF46F6BBD31 \ /Explorer.jpg " role = " button " title = " Explorer.jpg " alt = " File geodatabases niet verwijderd " \/ >< span class = " lia-inline-image-caption " onclick = " event.preventDefault(); "> File geodatabases niet verwijderd < \ / span >< \ / span >< \ / P >< P > En hier zijn file geodatabase-items gerelateerd aan mislukte Append-jobs - ook niet verwijderd.< \ / P >< P >< span class = " lia-inline-image-display-wrapper lia-image-align-inline " image-alt = "File geodatabase items niet verwijderd " style = " width: 999px ;">< img src = " https : \ / \ / us.v-cdn.net \ /6038851 \ /uploads \ /images \ /29699i33A3367D99C4347E \ /Content1.jpg " role = " button " title = " Content1.jpg " alt = " File geodatabase items niet verwijderd " \/ >< span class = " lia-inline-image-caption " onclick = " event.preventDefault(); "> File geodatabase items niet verwijderd < \ / span >< \ / span >< \ / P >< P > Als je echter kijkt naar HTTPCaller die Append aanroept, zul je zien dat ik rollback bij falen heb ingesteld op < STRONG > true < \ / STRONG > zodat alles wat we hoeven te doen is:< \ / P >< UL >< LI > Handmatig de mislukte file geodatabase-items verwijderen uit Online content < \ / LI >< LI > Handmatig LoadTaxisWorker uitvoeren met de mislukte file geodatabase zipbestanden en batch-ID's als invoerparameters < \ / LI >< \ / UL >< P > Dus na mijn handsfree run van de 100 miljoen features voert het gereedschap uit zonder fout...< \ / P >< P >< span class = " lia-inline-image-display-wrapper lia-image-align-inline " image-alt = "LoadTaxis werkte goed " style = " width: 975px ;">< img src = " https : \ / \ / us.v-cdn.net \ /6038851 \ /uploads \ /images \ /29700iBA899EFF708D2B18 \ /Details.jpg " role = " button " title = " Details.jpg " alt = " LoadTaxis werkte goed " \/ >< span class = " lia-inline-image-caption " onclick = " event.preventDefault(); "> LoadTaxis werkte goed < \ / span >< \ / span >< \ / p >< p > ...< STRONG > maar < \ / STRONG > het geladen aantal features is lager vanwege de mislukte jobs:< \ p >< p >< span class = LoadTaxisWorker handmatig laden
Ik geef er eigenlijk de voorkeur aan om de LoadTaxisWorker-tool in bewerkingsmodus uit te voeren (d.w.z. in Workbench) zodat ik dingen kan doen zoals het inschakelen van de Emailers om de actie in detail te volgen. Er is ook dit probleem om op te letten, dat ik in een spoiler-tag zal zetten:
SpoilerWaarschuwing: Append aangeroepen door LoadTaxisWorker kan veel langer duren dan verwacht (uren, niet minuten) als het wordt uitgevoerd op een druk moment voor Online - Append is een gedeelde bron en kan in de wachtrij komen. In dit geval zal de Emailer je vertellen dat er 210 seconden (of je voorkeurs-timeout) zijn verstreken zonder dat Append klaar was; het zal uiteindelijk nog steeds voltooien maar de opruimoperaties zullen niet worden geactiveerd. Ik heb dit ervaren en heb de Emailer ingeschakeld die de job-URL verzendt zodat ik het handmatig kon volgen.
Hoe dan ook, nadat je je mislukte taken handmatig hebt uitgevoerd, heb je 100 miljoen features in je service!
Jippie, mijn 100 miljoen features zijn geladen!
Hoe moeilijk was dat?
De ETL-tools staan in de post-download. Ik gebruikte ArcGIS Pro 2.9 & Data Interoperability-extensie.
