Kapittel 8 Sporbarhet, tilbakekall, kvalitet og sikkerhet

Tipicamente, os processos ETL estão bem definidos antes do sistema entrar em produ- ção. Consistindo estes num conjunto de extrações estáveis ao longo do ciclo de execução do sistema. Neste contexto, sempre que é necessário atualizar este processo, é necessário passar por uma fase de desenvolvimento e testes, o que representa um custo significativo. Neste repositório, os metamodelos são dinâmicos, e portanto é importante que existam mecanismos que simplifiquem o processo de acrescentar extrações, reduzindo o custo e aumentando a extensibilidade. Para este efeito, foi desenvolvida uma linguagem declara- tiva de especificação do pré-processamento.

Tal como na especificação do metamodelo (Secção 3.4.1), esta também é definida hierarquicamente. Ou seja, para além das extrações especificadas ao nível do tipo de produto, são herdadas todas as de níveis superiores. Explicitando, às extrações definidas ao nível do Sentinel-2 nível 2 são acrescentadas as herdadas ao nível do Sentinel-2, e assim sucessivamente.

Concretizando, para cada uma das extrações são declarados um conjunto de atributos, dos quais uns são obrigatórios e outros opcionais. Estes serão aqui apresentados, estando os obrigatórios assinalados a negrito:

(i) Nome: identificador único da extração;

(ii) Tipo de resultado: tem como possíveis instanciações: univalor; multivalor; ficheiro e pasta. No caso do univalor e mulivalor, estes são mapeados diretamente para o metamodelo. Já no caso do ficheiro e pasta, o que estará presente no metamodelo são apontadores para dados presentes no sistema de ficheiros. De referir que caso seja pasta todos os atributos referidos a seguir não são aplicáveis, exceto o contexto, formato do contexto e mapeamento no metamodelo;

(iii) Tipo de dados: trata-se do tipo em concreto. No caso dos univalor e multivalor, as possíveis atribuições são: objeto, inteiro, booleano, data, string ou decimal. O objeto é uma estrutura de dados na qual podem estar embebidos múltiplos campos do tipo univalor ou multivalor. A título de exemplo, uma extração que obtenha os dados de uma pessoa terá incluídos múltiplos campos. No caso do ficheiro, o tipo de dados trata-se do formato do mesmo (e.g. XML ou JSON);

(iv) Contexto: este atributo identifica qual o contexto em que é executada a extração. Nomeadamente, se for uma extração de um campo presente num certo ficheiro, o contexto é o identificador do próprio ficheiro. Caso a extração corresponda à totalidade do ficheiro, o contexto é o próprio ficheiro. Por outro lado, se for uma pasta, é necessário um ficheiro manifesto que descreva a organização das pastas, sendo que este representa o contexto;

(v) Formato do contexto: corresponde ao formato do ficheiro no qual é executada a extração. Tipicamente, o formato é XML ou JSON;

(vi) Query: tendo sido o ficheiro descarregado, é necessário aplicar a extração. Para este efeito, recorre-se a uma linguagem de consulta em ficheiros (e.g. XPath, JSON-

Path, ...). Se se tratar da extração de um ficheiro na sua totalidade, aplica-se aquery

que corresponde à raiz. Por outro lado, é também possível extrair um fragmento e armazená-lo como ficheiro;

(vii) Tipo de pós-transformação: após executar a extração, opcionalmente, passa-se a uma fase de transformação. É importante, muitas das vezes, aplicar algum tipo de pré-processamento, nomeadamente, devido à normalização de sintaxe e formatos.

3 . 4 . M E TA M O D E L O

De realçar que esta especificação não é feita de forma declarativa, sendo necessário programar cada uma das transformações. Ainda assim, é necessário especificar o tipo de dados após a transformação, mapeando o resultado da mesma no metamodelo (descrito no ponto mais abaixo - Metamodelo) ;

(viii) Formato da data: este trata-se de um campo que apenas necessita de ser declarado caso o tipo do resultado seja data e se deseje aplicar um pré-processamento à mesma. A verdade é que se pode declarar esta particularidade como sendo um detalhe de implementação;

(ix) Metamodelo: por fim, chega-se à fase deload dos típicos processos ETL. Após todo o

processamento descrito até aqui, o elemento é carregado no metamodelo, sendo para isso necessário indicar qual o nome do atributo do metamodelo no qual é mapeado. Para este efeito, existe uma conexão com o SGBD, e é inserido o resultado deste pré- processamento no atributo declarado. No caso de ser um ficheiro ou uma pasta, os dados são armazenados no sistema de ficheiros, enquanto os apontadores respetivos são carregados no metamodelo.

Tabela 3.1: Tabela de possíveis instanciações de especificação de ETL para diferentes atributos. Omissão das expressões dasqueries por serem demasiado extensas.

Exemplo 1 Exemplo 2 Exemplo 3 Exemplo 4

i cobEspacialExt diaAnoAqInícioExt máscNuvensExt máscExt

ii univalor univalor ficheiro pasta

iii string data XML XML

iv copernicusMD earthexplorerMD copernicusManif copernicusManif

v XML JSON GML -

vi <expressão> <expressão> - -

vii objeto inteiro JPEG2000 -

viii - YYYY/MM/dd - -

ix coberturaEspacial diaAnoAqInício máscaraNuvens máscaras Antes de iterar sobre cada um dos exemplos presentes na Tabela3.1, importa referir algo que é transversal a todos que é o facto de existir umlog para cada uma das extrações.

Sendo que este apresenta dois conjuntos de atributos, os relativos à obtenção do recurso e outro de descrição do resultado. Relativamente ao primeiro, é guardado o URL, o nome da extração, a data da obtenção, a query aplicada, e a informação sobre o contexto. Já

em relação ao resultado, é armazenado o valor após pré-processamento. A vantagem da existência destelog de todas as extrações é permitir certificar a origem dos metadados e,

por outro lado, executar verificações de integridade periódicas. De facto, este mecanismo contribui para a auditabilidade do sistema.

De notar que, naturalmente, as extrações que incidem sobre o mesmo ficheiro são agrupadas de forma a evitar descarregar o mesmo mais do que uma vez.

Outro ponto que importa abordar é o facto de existir a necessidade de normalizar a especificação, isto é, recorrer apenas a uma linguagem de extração, em vez de usar uma para cada formato de documento. Para este efeito, é selecionado um formato de documento no qual todos serão mapeados, sendo esta uma decisão de implementação. Ilustrando o que foi referido anteriormente, ao escolher traduzir para XML qualquer documento JSON será mapeado para XML, sendo que a linguagem de extração passa a ser, por exemplo, XPath. No entanto, é importante garantir que o método de tradução não resulta em perda de informação, ou seja, deverá ser reversível. Caso contrário é importante armazenar o documento original, por uma questão de rastreabilidade. Para mais detalhes relativos às particularidades desta tradução, consultar Secção4.2.4.

Exemplo 1. Este consiste na extração da cobertura espacial de qualquer tipo de produto Sentinel. O tipo de resultado é univalor, mais concretamente uma string. Esta cobertura está representada em WKT [128] - que se trata de um formato textual de representação vetorial. Relativamente ao contexto na qual é executada esta extração, quando se identifica a existência deste produto através da API de catalogação, é fornecido um ficheiro em XML com um resumo dos metadados do mesmo.

De notar que o documento poderá ter de ser traduzido, dependendo da implementa- ção. De seguida, é aplicada a extração, através daquery. Em relação ao pré-processamento

do valor obtido, o objetivo deste passa por unificar o formato com o de outros fornecedo- res. Para este efeito, existe uma conversão de WKT para GeoJSON. Para finalizar, o objeto, representado neste último formato referido, é mapeado no atributo coberturaEspacial do metamodelo.

Exemplo 2. Passando ao segundo exemplo, este trata-se da extração do dia do ano do início da aquisição de um certo produto. A motivação desta extração passa por adicionar uma maior expressividade temporal às interrogações. Sendo que, neste caso, o contexto é o ficheiro de metadados do EarthExplorer. O procedimento é semelhante ao do Exemplo 1, mas a principal diferença é na fase de transformação.

Tratando-se do pré-processamento de uma data, é obrigatório declarar qual o formato da extração, de forma a que a biblioteca usada consiga fazer o parse. Seguidamente, é

fácil extrair do dia do ano, já que existem múltiplas bibliotecas que fornecem esta fun- cionalidade. De notar que pode considerar-se que a necessidade deste procedimento é um detalhe de implementação, ainda assim, este é um problema transversal a qualquer solução prática. Finalmente, após a transformação, passa-se ao passo sempre presente de mapeamento do metamodelo.

Exemplo 3. Passando agora para uma extração do tipo ficheiro, esta refere-se à máscara de nuvens em formato GML, fornecida em produtos Sentinel-2. Relativamente ao contexto em que esta é extraída, é através do ficheiro manifesto (XML) fornecido para produtos Sentinel, que se obtém a localização deste recurso.

3 . 5 . A P I

No que toca ao pré-processamento, neste caso está representada uma transformação de um ficheiro vetorial (GML) pararaster (JPEG2000). Sendo que este poderá enquadrar-

se melhor em algum tipo de processamento a realizar pelos utilizadores. Finalmente, o ficheiro será armazenado no sistema de ficheiros, e será guardado um apontador no atributo do metamodelo designado máscaraNuvens.

Exemplo 4. Para finalizar o conjunto de exemplificações, aborda-se agora uma extração por extensão, ou seja, da totalidade de uma pasta. Neste caso em concreto trata-se de uma pasta presente nos produtos Sentinel-2, na qual estão incluídas alguns indicadores de qualidade como máscaras de nuvens, de defeitos ou de ausência de dados. Sendo que é através do ficheiro manifesto que se localiza todos os ficheiros presentes numa certa pasta da estrutura do produto. Desta forma, estes ficheiros serão todos ingeridos na plataforma, reconstruindo, no sistema de ficheiros, a pasta correspondente. Por fim, no metamodelo é registado o apontador para essa mesma pasta.