Gå till sidans huvudinnehåll
Kontakt

Regionbloggen

Lyssna

Vilken teknik ska ett datadrivet labb skapa/använda?

Som jag ser det måste vi ha tekniska lösningar för datahantering och dataförädling. Kanske också för prototyping och presentation/gränssnitt? Datahantering När det gäller datahantering som bör vi kunna hantera öppen data som finns i CKAN (PostgreSQL-databaser och CSV- eller XML-filer), vi bör också (tror jag bygga upp en lösning för stora datamängder så att man […]

Som jag ser det måste vi ha tekniska lösningar för datahantering och dataförädling. Kanske också för prototyping och presentation/gränssnitt?

Datahantering

När det gäller datahantering som bör vi kunna hantera öppen data som finns i CKAN (PostgreSQL-databaser och CSV- eller XML-filer), vi bör också (tror jag bygga upp en lösning för stora datamängder så att man enkelt kan skala upp en Big Data-innovation från labbet till driftmiljö. HDFS verkar vara ett vanlig val i dessa sammanhang. Kanske behövs även SQL-databaser utanför CKAN.

IoT-data kan tydligen lagras mycket kostnadseffektivt hos Amazon. Kanske har Elsys också en lösning på hur detta data lagras? Som jag förstår det kan man vi Apache Spark också lagra IoT-data som då lagras i HDFS om jag fatta rätt.

Dataförädling

Jupyter är ett webbaserat anteckningblock där man kan blanda text och kod. Verkar fungera bra när man ska ta fram och testa kod i Python, R och Scala. Genom att man dokumenterar och testar i samma verktyg blir det lätt att dokumentera hur man tänker och sedan koppla den kod som realiserar tankarna till dessa texter. Apache Spark tillsammans med olika programbibliotek för statistisk bearbetning, maskininlärning etc som finns för respektive språk kan användas för dataförädling t ex i form av dataanalys av stora datamängder.

När det gäller prototypingverktyg och presentation/gränssnitt har jag inga idéer här och nu.

En annan intressant sak är att LTU:s projekt sense Smart Region ska ta fram en teknisk plattform för IoT som bygger på FIWARE. Här ingår både datahanterings- och dataförädlingsdelar som jag förstått det. Ska tydligen finnas framme till våren. Man ska även sätta upp Lora-gateways i Skellefteå. Här kan man tänka sig att labbet skulle använda sig av denna plattform på något vis? Men kanske finns det tekniska och/eller byråkratiska problem?

Vad tycker du? Finns det bättre idéer? Finns det faror i det jag beskriver ovan?

Skriv ut

9 december, 2016 | Thomas Kvist

Kommentarer

  • Mikael Nordfeldth

    ”IoT-data kan tydligen lagras mycket kostnadseffektivt hos Amazon.”

    Jag antar nedanför att definitionen av ”Internet of Things-data” är ”jättemycket/många data i form av små filer som ska ha hög tillgänglighet”.

    Lagrar man hos Amazon tenderar det ju att ske genom deras S3-API för tillgång (läs/skriv). Just S3-APIet är inte unikt och det finns flera lagringslösningar som erbjuder detta, ofta på en nivå ovanför filsystemet (dvs Hadoop/HDFS behöver inte i sig stödja S3 utan en separat tjänst körs som sedan lagrar i HDFS-klustret).

    I praktiken alla kod-bibliotek en använder för S3 stöder valfria API-ändpunkter, vilket gör att en kan self-hosta.

    En annan stor-data-lösning med distribuerad lagringsförmåga och enkelt administrationsgränssnitt är Ceph, ursprungligen designat för att kunna köras i en väldigt heterogen miljö med olika lagringslösningar. Finns API för S3 till det och även ”OpenStack Swift” (vilket jag inte själv rört, men OpenStack är ju en stor, bra grej för att bygga egna flufflösningar: https://www.openstack.org/ ).

    Summan av kardemumman är att API:et för S3 finns till en hel radda backend-lösningar och har stöd i många programbibliotek. Hostar en datat själv blir det sjukt mycket mer kostnadseffektivt än med Amazon.

    Eller har jag missuppfattat vad du ovan menar med ”IoT-data”?

    • Thomas Kvist

      Definitionen är på IoT-data som jag använder (rätt eller fel) är ungefär ”små mängder data som kan levereras mycket frekvent från många enheter och som sammantaget skapar stora datamängder som ska kunna kunna förädlas/användas i efterhand och omedelbart”.

      Anledningen till att jag tänker i banor av att ha datat i en egen lösning är att kostnaden för datalagring är verkar låg. När det gäller datat i OpenNorth så är kostnaden för datalagring bara några cent medan server kostar ca 100 USD/mån. Man slipper också bekymmer som t ex backuper, hårdvarustrul mm.

      En annan tanke är att om man labbar i sådan miljö blir det enklare att skala upp en lösning som utvecklas i labbet och som kommer att hantera stora datamängder i drift.

  • Thomas Kvist

    Har haft kontakt med språkdatabanken angående tips om OCR-programvaror för att skörda data från dokument. PDF:er är ju populära inte minst för beslutsprotokoll. De rekommenderar Tesseract om man ska använda Open Source.

    Så här skrev Leif-Jöran:

    Det man direkt kan säga är att av de friprogramvarusystem som finns (och det är det vi använder på Språkbanken) så är Tesseract det ni ska välja om man
    direkt vill kunna köra med grundinställningarna och få ett bra resultat.

    Vill man ha en person som sätter sig in i det ordentligt och ägnar en tid åt att konfigurera så är Ocropus ett alternativ där du får bra
    resultat efter den större insatsen.

    Vi håller, som jag sade tidigare, på med handledande texter i detta då tillgängliggörande är en viktig del i att kunna använda Språkteknologitillämpningar på materialen. Dessa kommer dock bli tillgängliga först under våren. Men Tesseract är som sagt det ni ska använda om ni vill köra igång direkt.

    Skulle inte tro det är värt den större insatsen med Ocropus för er del. Vi har också en tjänst på gång,
    men den är knappt i demokvalitet just nu så den lär inte vara aktuell att publicera innan hösten.

    Oavsett om ni väljer en friprogramvarulösning eller en proprietär lösning så tänk på att även spara strukturella filer, Alto-xml, hOCR,
    och inte bara pdf-filer.