...
- jpylizer køres i map-skridt af map/reduce-job. Resultatet lægges i DOMS (som datastream) i reduce-skridt.
- Udtræk af histogram køres i map-skridt af map/reduce-job. Resultatet lægges i DOMS i reduce-skridt.
- Generering af formidlingskopi køres i map-skridt af map/reduce-job. Filen skrives direkte til formidlingsstorage. Eventuelle fejl skrives tilbage til DOMS i reduce-skridt.
- Der laves ingen validering i map/reduce-job. Dette foretages som efterbehandling af metadata.
Automatic QA should be runnable by Ninestars
Vi skal afklare hvad Ninestars forventer/hvad vi har lovet.
- Vi forventer at en del komponenter skal findes i 2 udgaver, idet vi i Ninestars udgaven skal skrive til og læse fra fil-system i stedet for DOMS (det er ABR ved at se på en pæn løsning af)
- Vi forventer at i Ninestars udgaven køres QA på et enkelt batch. Altså ikke autonome komponenter og ingen overvågning.
Vi skal under alle omstændigheder afklare nogle af de samme drift-spørgsmål, som vi afklarer med vores egen drift-afdeling
- Hvilket operativ-system skal systemet deployes på?
- Hvor meget temporary storage har systemet brug for?
- Hvordan deployes systemet og hvordan overvåges det?
Vi anbefaler at Ninestars-udgaven af komponenterne ikke benytter Hadoop. Hvis vi alligevel vælger at bruge Hadoop, rejser det nogle Hadoop-specifikke spørgsmål
- Leverer vi en guide eller et script til at sætte Hadoop op, før vores "system" deployes?
- Eller integrerer vi opsætning af Hadoop i vores "system"?
- Eller leverer vi en virtuel maskine, hvor Hadoop og vores "system" er sat op på?
Vi kan forhåbentlig afklare en række af de spørgsmål i løbet af de næste par uger.
Validering af metadata (i DOMS)
...