Baseado no modelo proposto nesta tese, que tem uma func¸˜ao concei- tual como j´a mencionado, nesta sec¸˜ao ser´a exposta uma arquitetura que foi desenvolvida para representar o modelo. Na Figura 30 ´e poss´ıvel visualizar a arquitetura proposta para esta tese. Ela foi divida em trˆes camadas, sendo elas: Entrada de Dados (1), Tratamento de Dados (2) e Armazenamento de Dados (3). Estas camadas e suas funcionalidades, componentes e respectivas caracter´ısticas ser˜ao expostas nesta sec¸˜ao.
Na camada de Entrada de Dados (1), s˜ao retratados os usu´arios, hos- pitais e o servidores de imagens m´edicas DICOM. Esta camada representa o modelo tradicional de operac¸˜ao de arquiteturas convencionais de persistˆencia de dados. ´E poss´ıvel visualizar usu´arios, que podem ser pacientes, t´ecnicos, m´edicos, residentes, entre outros, se relacionando com o hospital. Este relaci- onamento esta figurado nas modalidades de exames que podem ser realizadas, como por exemplo ressonˆancia magn´etica, raio-X digital, ultrassonografia, tomografia computadorizada, entre outros.
Ap´os o processo de realizac¸˜ao dos exames m´edicos baseado em ima- gem, nos respectivos equipamentos, h´a uma interface de comunicac¸˜ao que intermedia as operac¸˜oes de manipulac¸˜ao do exame em uma workstation ra- diol´ogica ou o processo de gravac¸˜ao do exame na bridge DICOM. A bridge DICOM ir´a efetuar o envio via redes de comunicac¸˜oes de forma s´ıncrona ou ass´ıncrona, dependendo do tipo de ambiente a qual a arquitetura estiver ope- rando. Foi abstra´ıdo desta arquitetura tratamentos de qualidade e garantia de linksde comunicac¸˜ao entre os hospitais e o servidor de imagens, visto que isto esta fora do escopo desta proposta de modelo.
Ap´os o envio por parte da bridge DICOM, o servidor DICOM recebe estes exames e efetua a desconstruc¸˜ao das imagens DICOM, extraindo to-
dos os metadados e as respectivas imagens (pixel data). Com as imagens do exame, desconstru´ıdas, h´a-se a necessidade de model´a-las de acordo com o modelo de dados desejado para o sistema de persistˆencia de dados. Os tipos de persistˆencia de dados suportados s˜ao os sistemas gerenciadores de bancos de dados relacionais (MySQL, PostgreSQL, SQLite e Oracle), formatos de dados cient´ıficos, como o NetCDF ou HDF5 e at´e estruturas de persistˆencias baseadas no formato XML.
No caso da arquitetura aqui apresentada, o sistema de persistˆencia defi- nido para hierarquizac¸˜ao dos dados foi o HDF5, pelas raz˜oes j´a apresentadas. Desta forma, os exames passar˜ao pela fase de modelagem de dados, onde os dados ser˜ao definidos e a informac¸˜ao passada para a camada inferior. Na camada de Tratamento dos Dados (2) receber´a os dados j´a desconstru´ıdos e modelados e enviar´a para o H5Wrap. O H5Wrap ´e um componente de soft- ware que tem a func¸˜ao de invocar os m´etodos da API do HDF5, preparando os dados para a hierarquizac¸˜ao, criando os grupos, definindo os datasets, ti- pos de dados, entre outras caracter´ısticas. Os dados j´a modelados e definidos s˜ao passados para a biblioteca do HDF5, onde os m´etodos ser˜ao executados na API e os dados passados para a camada virtual de arquivos do HDF5, onde ser´a definido o mecanismo de persistˆencia que ser´a utilizado.
Por fim o arquivo de fato ser´a gerado, ou ainda, integrado a uma hie- rarquia j´a existente, contendo os metadados enviados, juntamente com sua respectiva imagem. Nesta fase ainda, o mecanismo de indexac¸˜ao de da- dos, implementado usando ´ındice invertidos usando o sistema CLucene, este ir´a capturar as tags propostas para indexac¸˜ao, que s˜ao: StudyInstanceUID, PatientsName, PatientsID, PatientsBirthDate, PatientsBirthTime, PatientSex, StudyDate, StudyTime, AccessionNumber, StudyID, SeriesInstanceUID, Mo- dality, SeriesNumber, SOPInstanceUIDe InstanceNumber. N˜ao esta contido a indexac¸˜ao do pixeldata, visto que isso causaria uma sobrecarga no sistema, e ainda, n˜ao h´a a necessidade, pois a func¸˜ao do indexador ´e proporcionar localizac¸˜ao dos dados, para posterior recuperac¸˜ao.
Terminada a fase de envio dos dados e posterior tratamento dos mesmo, com estes j´a hierarquizados em uma estrutura HDF5 e com os metadados j´a indexados usando ´ındice invertidos pelos mecanismos do CLucene, os dados de fato comec¸am a ser persistidos. Uma importante observac¸˜ao sobre a ar- quitetura proposta ´e que os dados ser˜ao criados em tempo real j´a no backend selecionado, no caso um sistema de arquivos distribu´ıdos. Com isto, ganha-se desempenho, pois n˜ao h´a uma etapa preliminar onde os dados j´a contidos em um arquivo HDF5 tenham obrigatoriamente que ser migrados para os servi- dores de dados remotos.
A camada de Armazenamento de Dados (3) tem a func¸˜ao de rece- ber as chamadas da camada superior onde j´a vem com definic¸˜oes de tipo de
m´etodo de armazenamento que ser´a utilizado para persistir os dados. Este m´etodos podem ser de forma paralela, onde processos concorrentes s˜ao cria- dos para aumentar a vaz˜ao do processo e assim, ganhar desempenho e ainda, pode ser de forma serial, onde somente um processo ´e acionado e este grava sequencialmente os dados no backend a ser utilizado. No caso desta arqui- tetura foi definida a utilizac¸˜ao do MPI-IO para o m´etodo paralelo, pois este ´e um m´etodo amplamente suportado nos m´ultiplos sistemas de arquivos dis- tribu´ıdos. Entretanto, pode-se utilizar outro m´etodos de paralelizac¸˜ao, como o MPICH ou ainda o OpenMPI, que est˜ao fora do escopo deste trabalho.
Passada a fase de selec¸˜ao do m´etodo de gravac¸˜ao dos dados, o fluxo ´e direcionado para a fase de distribuic¸˜ao de dados. Nesta etapa, m´ultiplos sistemas de arquivos distribu´ıdos podem ser integrados a arquitetura, para ha- bilitar opc¸˜oes de persistˆencia distintas. Para esta arquitetura, foram definidas e implementadas a arquitetura os seguintes sistemas: PVFS, HDFS, CEPH, FhGFS e o Lustre. Os m´etodos de gravac¸˜ao, tando de forma paralela, quanto serial foram integradas aos middlewares de operac¸˜ao destes sistemas de ar- quivos para fornecer um maior n´ıvel de transparˆencia para o processo.
Selecionados o m´etodo de gravac¸˜ao dos dados, e posteriormente o sis- tema de arquivos distribu´ıdos que ir´a persistir os exames, os dados s˜ao passa- dos para o sistema de escalonamento e armazenamento dos dados, onde estes ser˜ao divididos e alocados nos servidores de dados e nos servidores de meta- dados. Cada um sistemas de arquivos tˆem comportamentos distintos quanto a divis˜ao, distribuic¸˜ao, armazenamento e recuperac¸˜ao dos dados. Em suma, todos eles dividem os arquivos em partes e armazenam eles e para efeitos de localizac¸˜ao e redundˆancia, usam os servidores de metadados. Uma impor- tante informac¸˜ao aqui ´e que estes metadados n˜ao tem relac¸˜ao com os me- tadados do das imagens DICOM, pois estes j´a foram hierarquizados e est˜ao contidos em um arquivo bin´ario que ser´a armazenado.
Ainda, nesta camada, pode haver cen´arios onde a distribuic¸˜ao dos da- dos n˜ao ´e um requisito do sistema, em que o hospital necessita ou opta por armazenar os arquivos localmente, em servidores locais. Como opc¸˜ao, esta arquitetura prevˆe este comportamento e desta forma, o processo de armaze- namento dos exames encerra-se com os dados nos discos locais do servidor. Como adendo, ´e importante salientar que este n˜ao ´e o comportamento padr˜ao da arquitetura, mas sim mais uma opc¸˜ao de armazenamento que busca pro- porcionar maiores n´ıveis de adaptabilidade a arquiteturas tradicionais j´a exis- tentes.
Para todas as trˆes camadas da arquitetura, ´e poss´ıvel visualizar interfa- ces de comunicac¸˜ao e interoperabilidade com o mundo externo `a arquitetura. No caso da interface da camada de entrada de dados, esta faz relac¸˜ao a co- nex˜ao com componentes externos a arquitetura, tanto de entrada, como de
sa´ıda, como por exemplo conex˜ao com bancos de dados relacionais, descri- tores XML, etc. Na camada de tratamento de dados, a interface se faz pre- sente para receber solicitac¸˜oes externas de componentes que necessitam de um exame e desta forma, v˜ao conectar ao indexador e solicitar a informac¸˜ao. Por fim, na camada de armazenamento de dados, a interface esta presente para administrac¸˜ao dos dados, por parte de administradores do agregado computa- cional que estar´a suportando os dados.
4.4.1 Workflow da Arquitetura Proposta
De forma pr´atica, a arquitetura proposta pode ser vista, na forma de fluxo de funcionamento (workflow) na Figura 31. Nesta figura ´e poss´ıvel visu- alizar que o processo de forma completa. O processo inicia com a realizac¸˜ao de um exame m´edico em um equipamento m´edico–hospitalar o qual gera ima- gens no formato DICOM. Estes dados s˜ao enviados via redes de comunicac¸˜ao baseadas na pilha de protocolos TCP/IP, para o servidor de imagens DICOM.
Figura 31: WorkFlow da Arquitetura Proposta para o Modelo. O servidor de imagens ir´a receber a imagem e desconstru´ı-la, sepa- rando os metadados que descrevem a imagem ou o conjunto delas, da figura (pixel data). Os metadados segmentados e modelados ser˜ao enviados para a camada de hierarquizac¸˜ao que executa o H5Wrap, invocando os m´etodos de criac¸˜ao do arquivo hierarquizado, na API do HDF5. O arquivo ser´a criado e indexado, j´a solicitando um m´etodo de escrita (ou leitura), no caso do work-
flowapresentado aqui, de forma paralela. Desta forma, o MPI-IO ir´a disparar os m´ultiplos processos de escrita (ou leitura) para o agregado computacional.
4.4.2 Design do Arquivo no Formato HDF5
Em relac¸˜ao ao design do arquivo criado, ele esta de fato hierarquizado, no formato HDF5. Todas os exames, estudos, s´eries e respectivas imagens est˜ao armazenadas em formato bin´ario, em um ´unico arquivo. Esta foi uma decis˜ao de arquitetura tomada visando proporcionar um maior desempenho, visto que dividir o arquivo, em arquivos menores, causa um problema de ge- renciamento de dados e ainda, um overhead desnecess´ario ao sistema. A tarefa de divis˜ao do arquivo foi empregada aos middlewares dos sistemas de arquivos distribu´ıdos, que ir˜ao dividir o arquivo criado, em m´ultiplos servido- res de dados, com a redundˆancia necess´aria, para caso de falhas de hardware ou software. A interac¸˜ao com este container de dados poder´a ser realizada naturalmente pela arquitetura desenvolvida, ou ainda, usando as ferramentas de administrac¸˜ao do pr´oprio HDF5.
Para ilustrar, na pr´atica, como uma imagem DICOM ´e representada dentro do container de dados HDF5, na Figura 32 ´e poss´ıvel visualizar parte de uma imagem DICOM no formato HDF5, onde somente um pequeno tre- cho do cabec¸alho foi exposto, e ´e poss´ıvel ver alguns dos metadados, como por exemplo o PatientID e o PatientsName. A imagem DICOM no formato proposto n˜ao foi exposta por completo, pois uma imagem desta natureza, com todos seus metadados e o pixeldata ´e representada no formato HDF5 dentro da m´edia de 300.000 (trezentas mil) linhas de texto.
`
A primeira vista, isto pode parecer ter um alto custo computacional, se comparada a modelo tradicionais, pois processar uma quantidade signifi- cativa de texto, em tempo real, pode causar um overhead nos sistemas de per- sistˆencia. Entretanto vale ressaltar novamente que o arquivo ´e constru´ıdo em formato bin´ario, buscando assim um maior desempenho. A Figura 32 a qual foi recuperada usando ferramentas de extrac¸˜ao do pr´oprio conjunto de ferra- mentas do HDF5, onde ela efetuou um dump do arquivo bin´ario, extraindo assim os dados solicitados em formato texto.
4.5 CONSIDERAC¸ ˜OES FINAIS DO CAP´ITULO
Neste cap´ıtulo foi apresentado o modelo proposto para armazenamento hier´arquico de imagens m´edicas no formato HDF5. Foram apresentados o modelo conceitual do STT/RCTM, usado atualmente e sua arquitetura rela-
cionada, que implementa o modelo. Al´em disto, foram descritos todos os pontos de relacionamento entre os componentes desta arquitetura, buscando proporcionar um melhor entendimento do modo de operac¸˜ao atual do objeto de estudo de caso.
Em seguida, foi apresentado o modelo conceitual da proposta, que ´e composto pelas camadas de hierarquizac¸˜ao, indexac¸˜ao, virtual de arquivos, paralelizac¸˜ao, serializac¸˜ao, distribuic¸˜ao de dados, virtual de acesso e por fim, a camada de armazenamento de dados. Este modelo conceitual foi desen- volvido buscando abstrair tecnologias, e focando em componentes que um modelo desta natureza deve ter. Ainda, foi apresentado o modelo de dados hierarquizados no formato HDF5 e o modelo de indexac¸˜ao usando ´ındices invertidos, por meio do CLucene.
Adiante, foi apresentada a arquitetura proposta para implementar o modelo conceitual proposto nesta tese. Esta arquitetura foi dividida em trˆes camadas, sendo elas a camada de entrada de dados - que trata do recebimento dos dados no sistema, a camada de tratamento dos dados - que tem a func¸˜ao de tratar os dados e convertˆe-los para o formato proposto, e por ´ultimo a camada de armazenamento de dados, onde de fato os processos de armazenamento s˜ao disparados, definindo o m´etodo de armazenamento e seu respectivo backend.
5 AMBIENTE E RESULTADOS EXPERIMENTAIS
Neste cap´ıtulo s˜ao apresentados os experimentos baseados no modelo proposto e em sua arquitetura. ´E explicada a metodologia procedural de testes para avaliac¸˜ao do modelo, bem como a arquitetura computacional utilizada nos testes. Em outra palavras, s˜ao mostradas as configurac¸˜oes dos computa- dores e os pacotes de software utilizados no prot´otipo. Finaliza-se o cap´ıtulo com considerac¸˜oes gerais relacionadas a esta fase da pesquisa.