Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Just van den Broecke
    @justb4
    Moved Stetl Room from justb4/stetl to geopython/stetl...
    Just van den Broecke
    @justb4
    image.png
    Stetl upgraded from Py2 to Py3-only today. Read upgrade notes here. Thanks, especially @borrob who did most of the hard work, and @sebastic. Stetl v2 (Python3 only) to be released shortly.
    Just van den Broecke
    @justb4
    Was gister op PyAmsterdam virtual Meetup. Erg interessante presentatie van Clayton Bezuidenhout, zie op YouTube na minuut 16: https://youtu.be/Aqu5PE3tzV0?t=998 . In feite iets Stetl-achtigs (basis Pipeline architectuur, gedreven door configuratie) maar elke module is een Thread. Communicatie loopt via Queues. Heb hem gevraagd of hij code wil delen. Celery is soort alternatief maar volgens mij is dat multi-proces met messaging etc, te zwaar. In GeoHealthCheck heb ik goede ervaring met scheduling (package APScheduler) en multi-threading (elke Healthcheck is een thread), erg stabiel. Ik plaats het even hier om het te onthouden...Er zijn wat dringender zaken, bijv BAG v2 NLExtract en afronden NLExtract Py2->Py3 migratie (bijv BRK v4 is nu alleen Py2).
    Just van den Broecke
    @justb4
    Rob van Loon
    @borrob

    Was gister op PyAmsterdam virtual Meetup. Erg interessante presentatie van Clayton Bezuidenhout, zie op YouTube na minuut 16: https://youtu.be/Aqu5PE3tzV0?t=998 . In feite iets Stetl-achtigs (basis Pipeline architectuur, gedreven door configuratie) maar elke module is een Thread. Communicatie loopt via Queues. Heb hem gevraagd of hij code wil delen. Celery is soort alternatief maar volgens mij is dat multi-proces met messaging etc, te zwaar. In GeoHealthCheck heb ik goede ervaring met scheduling (package APScheduler) en multi-threading (elke Healthcheck is een thread), erg stabiel. Ik plaats het even hier om het te onthouden...Er zijn wat dringender zaken, bijv BAG v2 NLExtract en afronden NLExtract Py2->Py3 migratie (bijv BRK v4 is nu alleen Py2).

    Een van de scenario's waar ik wel eens aan heb lopen denken is om Stetl te combineren met Celery (of alternatief) en Flask (of alternatief) om server-side processing in te richten. De eindgebruiker post een stetl-config bestand naar een API endpoint. De API plant de stetl-taak/job in. De gebruiker kan, behalve het config-bestand, ook data aanleveren, verwijzen naar een openbare bron of een databron die al op het systeem aanwezig is (algemeen aanwezig of eerder door de gebruiker geupload). En als de job klaar is, dan kan de gebruiker een mail krijgen met de uitgewerkte resultaten (of een downloadlink).

    Bijvoorbeeld: gebruiker stuurt een job met een polygoon als input en vraag als output om alle BAG-panden binnen die polygoon te krijgen. Misschien is het het beste te omschrijven als een stetl-powered WPS?

    Just van den Broecke
    @justb4
    Ha, moest ook aan WPS denken, toen toen zag ik laatste zin... Toevallig heb ik ooit Stetl aan pyWPS+Flask gekoppeld als PoC, lang geleden 2016 op CodeSprint GeoPython conf met pyWPS team, maar de concepten bleken goed op elkaar te passen. Als ik mij herinner stuurde ik de parameters van een Stetl config bestand via WPS. Dus het config bestand en py-dependencies stonden al op de server. Er is zelfs nog code maar een frisse blik kan geen kwaad.
    Frank Steggink
    @fsteggink
    De beste oplossing voor multithreading/-processing hangt van veel omstandigheden af. V.w.b. Stetl zelf zou ik alleen threads gebruiken, omdat dat veel lichter is. En Stetl zou ik ook alleen inzetten voor een duidelijke taak, met één input en één output. Dus bijv. de BGT in een database inladen. Als je meerdere outputs nodig hebt, bijv. een PostGIS vullen en een Geopackage maken, zou dit neerkomen op meerdere, onafhankelijke Stetl processen. Daar kun je wel task queues als Celery voor gebruiken. Dat werkt prima. En op die manier kun je ook meerdere machines voor verwerking gebruiken.
    Uiteraard zou je ook de BGT kunnen opknippen en via Celery e.d. verwerken, maar als Stetl multithreading ondersteunt, hoef je dat niet te doen. En dan hoef je in principe ook maar één proces uit te voeren voor één taak. Dat scheelt weer veel gedoe met orchestratie, zeker bij afhankelijkheden tussen de verschillende stappen van een taak. Servers zijn tegenwoordig zwaar genoeg dat ze zonder problemen meerdere threads zouden moeten kunnen inzetten voor het laden van bijv. GML data in PostgreSQL.
    Just van den Broecke
    @justb4
    Ja mee eens: Stetl multithreaded. Wat ik wel zie is dat de echt zware processen, als BGT, nog steeds een "tussenfile" genereren dat met ogr2ogr wordt weggeschreven. Echte winst met multihreading zal er dan m.i. niet zijn. Pas als er een "pakket-streaming" van input, via filters naar outputs is kun je bijv delen van die keten aan een thread toewijzen en via queues koppelen, bijv via de Stetl-config. Een native OGROutput zou helpen, howel het lastig zal zijn de performance van ogr2ogr te verslaan (hoewel dat meen ik ook een python script is?). Het gezegde is "als je niet kunt splitsen kun je niet schalen". Je kunt nu al slimme dingen doen door bijv een input file als BGT of andere basisregs de bestanden te verdelen over meerdere mappen en voor iedere map een Stetl proces laten lopen (zonder pre/postprocessing natuurlijk, die moet eenmalig). Verwacht dan wel dat de DB bottleneck zal zijn. Daar valt sowieso nog een hoop te optimaliseren (COPY?).