[Bitrepository-devel] Forslag til BitRepository massprocessing

Eld Zierau elzi at kb.dk
Mon Sep 3 11:08:49 CEST 2012


Hej

Nåh ja, jeg glemte også lige at kommentere på singleprocessing
De use-cases der er skrevet er

-          Streaming

-          Checksum på del af fil
Altså noget som kun er ment for en fil ad gangen, hvor cheksumseksemplet, især giver mening for store filer som man ikke har lyst til at overføre for at lave beregningen.

Mvh. Eld

Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Kåre Fiedler Christiansen
Sendt: 3. september 2012 09:33
Til: 'List for the Bitrepositorys developers'
Emne: Re: [Bitrepository-devel] Forslag til BitRepository massprocessing

Hej alle,

Jeg synes det er et fremragende forslag.

Jeg har faktisk i længere tid været skeptisk overfor at det gav mening at lave mass processing som en generisk service på bitmagasinet, men "guldægget" i denne løsnning som jeg ser det er at afkoble deployment, og henvise til det pr. id. Med den løsning synes jeg faktisk det giver værdi. Det er muligt det er en gammel indsigt, jeg har ikke fulgt udviklingen på Bitmagasinet et stykke tid :)

Et ekstra input er at prøve at sætte løsningen op overfor helt konkrete use cases - jeg tror der kan trækkes nogen ud af det oprindelige strategiprojekt.
Her er et par eksempler man kunne tage udgangspunkt i:

·         Man har et arkiv af videofiler. Man ønsker at levere en videofil i et andet format (det er det prototypiske eksempel på single file processing)

·         Man har et arkiv af html-filer. Man ønsker at lave frekvensanalyse af ord i html-filerne.

·         Man har et arkiv af TIFF-filer. Man ønsker at lave et JPG-preview af alle filer

·         Man har et arkiv af WordPerfect 5.1-filer. Man ønsker at migrere dem til PDF.

Single vs. mass-processing har primært været beskrevet separate fordi der er nogle karakteristika ved hver, som er nemmest at se hvis man adskiller dem. I mit single file processing-eksempel ovenfor kan det f.eks. være svært at se hvordan det samme job skulle fungere på en enkelt og mange filer. Ved en enkelt fil skal den transformerede fil leveres til resultat-URL'en. Hvad skal der ske hvis jeg angiver to filer? Skal jeg blot konkatenere dem efter hinanden? Skal jeg lave en TAR eller ZIP fil? Skal jeg bare generere en fejl?

Jeg tror jeres forslag fint kan dække de fleste use-cases ovenfor. Det nederste er dog et interessant tilfælde, hvor resultatet faktisk skal gemmes i bitmagasinet. Det kan overvejes om man ønsker at lave understøttelse for det direkte i protokollen.

Hilsen
  Kåre

From: bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org> [mailto:bitrepository-devel-bounces at ml.sbforge.org] On Behalf Of Jonas Lindberg Frellesen
Sent: Friday, August 31, 2012 11:41 AM
To: List for the Bitrepositorys developers
Subject: [Bitrepository-devel] Forslag til BitRepository massprocessing

Kære Alle

På baggrund af vores diskussion i onsdags er Asser og jeg kommet frem til følgende forslag vedrørende massprocessing.
Dette forslag er baseret på de umiddelbare problemstillinger og behov, så det vil være rigtigt godt med noget input, især fra arkitekterne (Kåre, Eld og Bolette) og nogen fra SA.



Der vil være fordelagtigt at opdele massprocessing i to selvstændig faser. En fase til at deployere et det ProcessingJob, som skal afvikles, og en fase til at eksekvere jobbet.
Selve deployeringen af ProcessingJob vælger vi at udskyde i først omgang. Dette må derfor foregå manuelt, og så må vi på et senere tidspunkt analysere om, om der er brug for en automatisk deployering af ProcessingJobs, samt dertilhørende protokol udvidelser.


Hele processen med at få en pillar til at afvikle et ProcessingJob skal gøre så agnostisk som muligt i forhold til platform, infrastruktur og arkitektur af de pågældende pillars.
Alt vedrørende data-sikkerhed i forhold til et ProcessingJob må en pillar selv stå for (f.eks. at køre det pågældende ProcessingJob fra en sandkasse).

For at skelne mellem forskellige typer af processerings jobs, så vil der blive indført en 'ProcessingJobType'.
En ProcessingJobType skal referere til den måde at afvikle de dertilhørende ProcessingJobs (f.eks. om det er et Java-program, C#-program, et Perl-script, eller noget der skal afvikles på en Hadoop platform).
Det er dog vigtigt, at der til hver ProcessingJobType er et værktøj til at afvikle de dertilhørende ProcessingJobs manuelt (f.eks. via scripts af en pillar administrator(?) ).
Det vil være at foretrække, hvis et sådanne værktøj også kan bruges som et plugin til en pillar, så ProcessingJobs af den pågældende type kan afvikles automatisk, men det er ikke nær så vigtigt som at kunne afvikle ProcessingJobs manuelt.

I først omgang vil det kun blive tale om en enkel ProcessingJobType, hvilket vil være til at eksekvere Java-baserede ProcessingJobs i lighed med BatchJobs fra NetarchiveSuite.
Det skal laves som et selvstændigt modul. Det vil være bedst, hvis modulet er uafhængigt at reference koden (altså på niveau med 'CollectionSettings' og 'Message-XML' modulerne).

I forhold til protokolen skal de forskellige ProcessingJobTypes defineres i en enumerator. Der skal dog være ubetingede og ubegrænsede udvidelsesmuligheder, så det bliver gjort ligesom med checksums algoritmerne, hvor der laves en 'OTHERTYPE', som kan blive defineret ved en streng.


Oprindeligt blev der skelnet mellem SingleFileProcessing og MassProcessing. Dette kombineres til en 'ProcessingFiles' operation, hvor man skal specificere om et ProcessingJob skal afvikles på et specifikt fil id eller alle fil id'er (i form af vores FileIDs objekt).


Det skal der være muligt at kunne specificere afviklingen af et ProcessingJob via nogle parametre/argumenter.
Det kan være parametre i forbindelse med at bruge værktøjet til at afvikle det pågældende ProcessingJob, eller argumenter til selve ProcessingJobbet.


Resultatet fra et ProcessingJob bør kunne returnere direkte via beskeden eller oploades til en URL (på samme måde som f.eks. GetChecksums resultaterne).
Selve resultatet afhænger af det pågældende ProcessingJob og bør returneres som en klump rå data.
Hvis det returneres i beskeden vil det være en streng. Det kan dog være, at den evt. skal indkodes ligesom checksummer eller lignende, for at undgå XML fejl.


I forbindelse med at eksekvere et ProcessingJob er her et forslag til hvilke beskeder, som protokolen bør udvides med:

IdentifyPillarsForProcessingFilesRequest

-       Default IdentifyRequest.

-       Beskrive af processerings jobbet (type, name, other).

-       FileIDs

IdentifyPillarsForProcessingFilesResponse

-       Default IdentifyResponse.

ProcessingFilesRequest

-       Default Request

-       Beskrive af processerings jobbet (type, name, other).

-       FileIDs

-       Parametre til at køre processerings jobbet

-       En URL til aflevering af resultaterne (valgfri)

ProcessingFilesProgressResponse

-       Default ProgressResponse

ProcessingFilesFinalResponse

-       Default FinalResponse

-       Skal kunne indkapsle resultaterne(enten direkte i en tekst streng, eller indirekte ved at have en resultats URL)


En pillar skal selvfølge svare negativt på identifikationen, hvis den f.eks. ikke supportere den pågældende type ProcessingJob, ikke har fået deployeret et ProcessingJob med det givne navn, eller lignende.

Da massprocessing godt kan tage lang tid, især på store datamængder, så vil der være nogle problemstillinger vedrørende OperationTimeouts, som der skal kigges på (f.eks. at en pillar sender en 'ProgressResponse' med et givent interval indtil, at den er færdig med jobbet).


Med venlig hilsen
Asser og Jonas

[http://support.kb.dk/images/kb_logo.jpg]

Det Kongelige Bibliotek
Nationalbibliotek og Københavns Universitetsbibliotek

Jonas Lindberg Frellesen
Softwareudvikler | Software Developer

Det Kongelige Bibliotek | The Royal Library
Afdelingen for Digital Bevaring | Digital Preservation
P.O. Box 2149 | DK-1016 København K
tel +45 3347 4691 | Fax +45 3393 2218 | jolf at kb.dk<mailto:jolf at kb.dk> | www.kb.dk<http://www.kb.dk>

Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 København K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20120903/7ff9844e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20120903/7ff9844e/attachment-0001.jpg>


More information about the Bitrepository-devel mailing list