Oportunidades de Aplicação de Big Data em Saúde: Os Gerentes Assistenciais

primeiro post dessa série, listei os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde, seja ela um hospital ou uma clínica. Quais sejam, os Provedores, a Força de Trabalho, os Pesquisadores, os Pagadores e os Clientes. No post seguinte, analisei brevemente a primeira subpopulação dos Provedores, que é composta pelos Administradores Hospitalares. Nesse post analisaremos rapidamente as oportunidades que se apresentam para outra subpopulação deles: os Gerentes Assistenciais.

Os Gerentes Assistenciais recebem dados que permitem uma tomada de decisão “local” e em pequena escala, sem a necessidade de um processo burocrático na instância superior e que provavelmente servirá para o “melhor cenário” e não contemplará uma miríade de cenários sub-ótimos que são bastante mais frequentes.

Uma das perguntas que pode ser respondida para essa população é: Se um determinado paciente tem a necessidade de coletar um exame específico, qual o melhor momento para fazê-lo? Em um ambiente hospitalar, um paciente que se desloca entre departamentos leva consigo um funcionário (em geral um técnico de enfermagem) que vai “desfalcar” a equipe local. Fazer esse deslocamento no momento errado pode ampliar o tempo necessário para o retorno do funcionário e gerar toda a sorte de ineficiência como consequência. Muito mais efetivo é ter uma alocação dinâmica e disparar o processo de transporte no momento ótimo.

Esses Gerentes ainda podem ter acesso a notificações de processos de que eventualmente estejam responsáveis. Ao invés de ligar para a farmácia diariamente para verificar a disponibilidade de um determinado medicamento ou material, sua interface de trabalho o notifica quando um material necessário chega à farmácia.

Dependendo do grau pretendido de integração das informações, um Gerente Assistencial pode ajudar a alimentar algoritmos de aprendizado de máquina que tornem possível a automatização de diversas tarefas, acabando com a perda de tempo com as rotinas repetitivas e com a possibilidade de que tarefas essenciais sejam esquecidas em prol do “problema da vez”.

Por fim, não podemos esquecer de um sério problema que faz parte do dia a dia dos Gerentes Assistenciais em qualquer organização de saúde de médio ou grande porte: as escalas e as capacidades de cada funcionário. Através da integração com os dados do departamento de pessoal quando da ocorrência de uma falta ou quando da programação de férias, é possível rapidamente saber qual funcionário e de onde ele vai ser deslocado para cobrir a vacância. Não é incomum que esses controles sejam feitos manualmente e executados “na emergência”, muitas vezes resultando em um deslocalmento de um funcionário sem a capacitação adequada para aquele serviço, ou na criação de um novo problema em solução ao anterior. Com a integração desses dados na interface de trabalho dos Gerentes Assistenciais, resolver esses problemas se torna trivial.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para a Força de Trabalho.

]]>

Oportunidades de Aplicação de Big Data em Saúde: A Força de Trabalho

posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e comecei a analisar as oportunidades de aplicação de Big Data para cada um deles, começando com os Provedores. Nesse post analisaremos rapidamente as oportunidades que se apresentam para outro grupo, a Força de Trabalho.

Existem diversas oportunidades que se referem a características básicas do Big Data, especialmente ao seu potencial agregador e pervasivo que podem ser aplicadas pelos e para a Força de Trabalho. Vamos tomar um médico como representante dessa categoria e vejamos, por exemplo, seu fluxo usual em um hipotético round (“round” é como tratamos, em nosso meio, a visita em série aos pacientes internados sob responsabilidade de um médico ou de uma determinada equipe):

  • O médico visita o paciente em seu leito, coleta as informações subjetivas do mesmo, atualiza um ou outro conhecimento a cerca da evolução de sua doença e volta para a sala de prescrição;

  • Na sala de prescrição ele abre o sistema 1 para verificar os últimos exames de laboratório do paciente;

  • A seguir ele abre o sistema 2 para verificar as últimas imagens e/ou seus relatórios;

  • Ato contínuo ele abre o sistema 3 para verificar se o resultado de um procedimento (por exemplo, um exame de patologia) retornou e, caso positivo, qual seu resultado;

  • De posse desse conhecimento, ele abre o sistema de prontuário eletrônico para registrar sua visita e para prescrever os próximos passos ou a continuidade do cuidado;

  • Finalmente o médico retorna para a enfermaria para visitar o paciente ao lado.

Com algumas variações e com a utilização de notas à beira do leito, os médicos podem otimizar essa rotina, por exemplo, visitando a todos e depois se retirando para “lidar” com os diversos sistemas. Dificilmente, no entanto, vão escapar de interagir com sistemas diferentes e utilizar seu bom senso para integrar os conhecimentos neles contidos. Uma perda de termpo e eficiência injustificada. Sem falar que é fácil negligenciar um desses passos (por exemplo, ao invés de verificar o sistema de patologia por algum resultado adiantado, o médico escolhe esperar os X dias que usualmente são consumidos na análise de uma peça anatômica e perde a oportunidade de tomar uma atitude assim que a informação estiver disponível).

Ora! Tecnologia para agregar todas as informações de diferentes sistemas está disponível há muitos anos e o Big Data não só a tornou acessível como eficiente. E se o médico tiver todas essas informações na mão? Suponha em um tablet ou outro dispositivo de visualização, com uma interface de busca estilo Google, ou mesmo algo mais estruturado, que aglutine todas as informações relevantes ao alcance de um toque. Ao invés de páginas e páginas de exames laboratoriais, gráficos gerados “just-in-time” com a evolução de todos os exames relevantes e com codificação de cores para indicar os que estejam fora do padrão. Da mesma forma que as notificações para os Gerentes Assistenciais, exames que saiam do padrão podem gerar alertas personalizados, que os médicos podem receber em sua interface de trabalho ou em outro dispositivo.

Outra prática onde a agregação que o Big Data é capaz de proporcionar pode ajudar essa população é a interação entre as disciplinas. O mesmo sistema de notificação pode ser utilizado para avisar de interconsultas ou pedidos de consultoria para outras especialidades. Muitos grupos fazem isso utilizando ferramentas públicas, como WhatsApp, ou celulares dedicados a grupos (como o “celular da cirugia”), mas veja que é muito mais fácil e efetivo criar uma notificação no sistema do que entrar em contato com alguém em uma ferramenta terceira e passar um caso para consultoria (ao que o destinatário poderia ter acesso completo e não a apenas uma fração). Ademais, a agregação desses metadados pode ajudar a gerar outros insights: por exemplo, pacientes que têm mais de duas consultorias solicitadas têm prognóstico mais reservado? Ou equipes que têm muitas solicitações de interconsultas têm o número de profissionais adequado?

Áreas de apoio, como patologia e SADTs também se beneficiam. Veja que a rotina intensa de trabalho (fruto da necessidade de produzir resultados cada vez mais rápido) nessas áreas leva muitas vezes a que seus trabalhadores negligenciem as informações que estão disponíveis em outro sistema e se restrinjam aos pequenos bits de informação contidas em uma papeleta que podem ou não ser relevantes e podem ou não ser completos. A qualidade do resultado cai e aumenta muito a chance de erros ou intervenções desnecessárias.

Veja que examinamos majoritariamente o caso do médico, mas praticamente toda a Força de Trabalho assistencial está em maior ou menor grau submetida a isso. Fisioterapeutas, psicólogos, assistentes sociais, todos têm rotinas parecidas e se beneficiariam dos mesmos tipos de ferramentas.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para os Pagadores.

]]>

Oportunidades de Aplicação de Big Data em Saúde: Os Pagadores

posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e passamos a analisar as oportunidades de aplicação de Big Data para cada um deles. Nesse post analisaremos rapidamente as oportunidades que se apresentam para os Pagadores.

A penúltima população que analisamos, os Pagadores, põem-se, muitas vezes, como antagonistas dos Provedores e negam pagamentos a procedimentos já realizados de uma forma rotineira. Mas isso não precisa ser assim.

Quantas auditorias poderiam ser evitadas e quanto tempo perdido poderia ser recuperado caso as informações que fizeram um determinado procedimento ser necessário estivessem a disposição dos Pagadores no momento em que se decide por uma glosa? Ou mesmo, quantos procedimentos repetidos em diversos serviços poderiam ser evitados caso os dados compartilhados de um estivesse disponíveis para outro? Sim… estamos longe disso, mas os primeiros passos já podem ser dados agora e muita coisa pode ser feita em parceria. Nem os Provedores se beneficiam de um Pagador falido, nem os Pagadores se beneficiam de um Provedor ineficiente. Essa posição de antagonismo não precisa ser a regra.

Além disso, uma disciplina bem desenvolvida dentro do Big Data, com algoritmos bem reconhecidos e estudados e com bastante experiência acumulada é o controle de fraudes. Todo esse expertise pode ser importado por um cluster de Big Data a serviço dos Pagadores e, em paralelo com os controles hoje existentes, pode auxiliar na detecção de atividades fraudulentas, constituindo mais uma ferramenta.

Por fim, um diferencial importante para qualquer Pagador é a agilidade com que consultas e procedimentos são autorizados. Com os dados disponíveis e devidamente analisados em tempo real, esse diferencial se transforma em vantagem para seus clientes o que, em última instância, se transforma em receita.

No próximo, e último, post, analisaremos o que se espera de oportunidades do Big Data para os Clientes e os Pesquisadores.

]]>

Oportunidades de Aplicação de Big Data em Saúde: Os Clientes e Os Pesquisadores

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e passamos a analisar as oportunidades de aplicação de Big Data para cada um deles. Concluiremos agora essa série examinando as oportunidades que se apresentam para os Clientes e passando rapidamente por oportunidades para os Pesquisadores.

Os Clientes das organizações de saúde podem ter sua vida bastante facilitada pelos mecanismos de Big Data adotados pelos demais atores. É muito frequente que consultas sejam marcadas para uma data futura contando com a disponibilidade de resultados de exames na tal data. Essas consultas ou são inefetivas ou tornam-se simplesmente uma ausência a mais caso esse exame não esteja disponível. E isso acontece com imagem, com laboratório, com patologia e praticamente com qualquer área de apoio. Ao detectar que um determinado resultado não estará disponível, medidas podem ser tomadas para remarcar a consulta, por exemplo.

Isso é especialmente importante em hospitais terciários, que atendem muitas pessoas que não fazem parte da população local que muitas vezes enfrentaram longos deslocamentos apenas para ver sua intenção malograda pela indisponibilidade de algum dado.

Além disso, ao detectar que um perfil específico de Cliente tem uma necessidade (por exemplo, realização de coletas fora do horário comercial), o sistema pode reorganizar as demais coletas para acomodar aquele perfil, de uma maneira dinâmica, evitando que o Cliente procure outro serviço que tenha a disponibilidade de que necessita.

Propositalmente, não entraremos em detalhes dos benefícios para a população dos Pesquisadores, uma vez que acredito que sejam auto-evidentes: a disponibilidade de dados em múltiplos sistemas e a possibilidade de filtragem uma vez que esses dados estejam disponíveis permite que toda sorte de pesquisa científica seja realizada. Existem grupos coletando dados de pacientes de UTI e alertando para sepse; existem grupos de pesquisa de transplantes alertando para pacientes que desenvolverão rejeição meses antes que ela seja evidente; existem grupos que previnem a re-internação baseado na coleta remota de dados simples.

As possibilidades realmente são muito amplas e a tecnologia permite uma gama de combinações que cientistas de dados podem fazer que simplesmente não tem como ser antecipada.

Para explicar o porquê da adesão ao Big Data no segmento da saúde, preparei uma coletânea de artigos científicos sobre o tema. São 9 materiais entre artigos, casos de uso e relatórios, que exemplificam, de maneira objetiva e sintética, as tendências da “medicina de dados”. Clique no botão abaixo e receba o eBook.

[button link=”http://propus.rds.land/big-data-saude” type=”icon” newwindow=”yes”] [eBook] Entenda o Big Data na área da saúde: aplicações e tendências![/button]

]]>

Oportunidades de Aplicação de Big Data em Saúde: Os Administradores Hospitalares

primeiro post dessa série, listei os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde, seja ela um hospital ou uma clínica. Quais sejam, os Provedores, a Força de Trabalho, os Pesquisadores, os Pagadores e os Clientes. Nesse post analisaremos rapidamente as oportunidades que se apresentam para os Provedores, especialmente para uma subpopulação deles: os Administradores Hospitalares.

Os Administradores Hospitalares devem primar pela prestação de serviços com a melhor qualidade possível dentro do orçamento proposto. Clínicas e hospitais em geral têm departamentos para cuidar da relação com fornecedores e da qualidade de suas compras e embora o Big Data possa ter algum papel aqui, esse já é um caso coberto por ferramentas tradicionais e com processos provavelmente mais bem definidos e aceitos dentro das instituições. Há um papel paralelo para o Big Data nesse caso, quando não houver interesse de fazê-lo protagonista, mas analiso esse caso mais tarde.

Onde o Big Data brilha, nesse caso, é na gama de ferramentas que disponibiliza para avaliação e tomada de decisão em tempo quase real. Um cluster de Big Data pode, por exemplo, através do consumo de dados on-line dos prontuários eletrônicos e de outros sistemas com base no paciente (por exemplo, farmácia), apontar qual o paciente é um potencial risco econômico (pacientes que, por causa do perfil da doença, do tipo do seguro-saúde ou das interações da equipe médica com a prescrição, têm potencial para dar prejuízo ao hospital) e sugerir medidas para mitigar esse risco.

Outra oportunidade para os administradores hospitalares é a monitoração em tempo quase real da ocupação dos serviços e a sugestão, através de algoritmos de aprendizado de máquina e das redes neurais, da alocação ótima de recursos. Por exemplo, se pacientes de um determinado seguro-saúde ou convênio, com uma determinada faixa etária ou com determinados perfis preferem realizar exames de SADT em determinados horários enquanto outros perfis de paciente não têm preferência, será que não é mais custo-efetivo alocar os pacientes com expectativas mais restritas nos horários adequados do que arriscar perdê-los?

Outro exemplo é a otimização das agêndas de consultas ou de realização de exames conforme a sazonalidade ou as condições do tempo (com previsão de chuva posso fazer “overbooking” já que conto com um maior absenteísmo na nossa população?).

Além disso, as ferramentas de Business Inteligence provavelmente já em uso pelos administradores podem tanto se alimentar de dados de um cluster Big Data quando alimentá-lo, oferecendo uma convergência e uma riqueza de dados muito maior para os tomadores de decisão da organização.

Por fim, mas sem a pretenção de esgotar as oportunidades, tudo que envolve a assistência médica pode ter seu pagamento negado a posteriori. Desde internações até procedimentos e medicamentos podem ser “glosados” pelos Pagadores, deixando o Provedor com uma conta “perdida”. Existem algoritmos que empresas estadounidenses utilizam para evitar fraudes que podem ser perfeitamente adaptados para identificar quais são as contas que estão sob risco de glosa. De posse dessa informação em um momento anterior, o Provedor pode tomar medidas que mitiguem o risco econômico ou que até previnam a ocorrência da glosa.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para outra subpopulação dos Provedores, os Gerentes Assistenciais.

]]>

Compactação HBase e Data Locality com o Hadoop

O HBase é um banco de dados distribuído otimizado para o desempenho de leitura. O desempenho ótimo de leitura vem da existência de um arquivo por família de coluna. Nem sempre é possível ter um arquivo por coluna durante uma gravação muito pesada. É por isso que o HBase tenta combinar todos os HFiles em um único HFile maior para reduzir o número máximo de pesquisas no disco necessárias para a leitura. Esse processo é conhecido como compactação. A compactação é um processo pelo qual o HBase se “limpa”. Acontece de duas formas: minor compaction (menor compactação) e major compaction (maior compactação). A menor compactação é o processo de combinar o número configurável de HFiles menores em um HFile grande. Esse processo é muito importante pois, sem ele, a leitura de linhas específicas demandaria muitas leituras de disco e com isso reduziria o desempenho geral.

Data Locality

Os conjuntos de dados no Hadoop estão armazenados no HDFS. São divididos em blocos e armazenados através de nós de dados em um cluster Hadoop. Quando uma tarefa MapReduce é executada no conjunto de dados, os mapeadores individuais irão processar os blocos (splits de entrada ou input splits). Quando os dados não estão disponíveis para o mapeador no mesmo nó, precisam então ser copiados através da rede a partir do nó de dados que possui dados para o nó de dados que está executando a tarefa de mapeador. Isso é conhecido como Data Locality. O Data Locality no Hadoop é dividido em 3 categorias:

Data Local Data Locality

Quando os dados estão localizados no mesmo nó que o mapeador que trabalha sob os dados, são chamados de data local data locality. Neste caso, a proximidade dos dados está muito próxima da computação. Esse é o cenário mais favorável.

Intra-Rack Data Locality

É sempre possível executar o mapeador no mesmo nó que os dados devido a restrições de recursos. Nesses casos, o mapeador é executado em outro nó dentro do mesmo rack que o nó que possui dados. É uma ação conhecida como intra-rack data locality.

Inter-Rack Data Locality

Nem sempre é possível obter o data locality ou o intra-rack locality, devido a restrições de recursos. Nesses casos, o mapeador é executado em nós em racks diferentes e os dados são copiados do nó que têm dados para o nó que executa o mapeador entre racks. É uma ação conhecida como inter-rack data locality. Esse é o cenário mais favorável. Fonte: DZone.com ]]>

Estágios de maturidade em Big Data: seus dados estão prontos para se tornarem um produto?

A ideia de transformar dados de negócios em um produto, também chamada de “dados como produto”, é um conceito já conhecido e bem documentado em whitepapers de organizações especializadas no assunto. É comum as empresas sentirem que, devido à experiência em uma indústria específica ou dos muitos anos em TI, já estão prontas para a introdução do Big Data via arquitetura de data lake. Mas, o quão difícil isso pode ser? Na realidade, a maioria das empresas encontram-se em estágios iniciais de maturidade em Big Data. O mundo dos negócios está inundado de estímulo para uma utopia ou terra prometida onde os dados se tornam seu grande produto. No entanto, entender as etapas que outras organizações tomaram através dos estágios de maturidade de dados ajuda a compreender as próprias aspirações para uma abordagem potencial de dados como produto.

Estágios da maturidade de dados

Inicial

Geralmente representa o estágio no qual a maioria das empresas percebe que precisa de algo além de um data warehouse tradicional. Às vezes, as equipes de TI ou de desenvolvimento podem possuir alguma experiência limitada com o Hadoop. Algumas equipes podem até ter pelo menos um caso de uso em ação, mas geralmente em um sistema de laboratório que não é mais que um protótipo. A maioria dos grupos na fase inicial estão começando a aprender como eliminar silos de dados e data lakes como um conceito com uma meta declarada de auto-serviço de dados. O processamento manual é em grande parte o procedimento padrão do dia. Realisticamente não há conceito de auto-atendimento e a maioria das requisições precisa ser executada pela infraestrutura de suporte de TI para o menor dos casos de uso. Pior ainda, pode levar longos períodos para ser implementada devido a concorrência entre outras tarefas paralelas da equipe. Geralmente, há muito pouca segurança implementada além da integração de autenticação de usuário. O planejamento do ciclo de vida dos dados ainda não é compreendido em sua totalidade e a criação de um “pântano” de dados é muito possível.

Conscientização

Nesta fase, dados externos são combinados com dados da empresa para fornecer algum valor adicional. O despertar mais próximo do Hadoop e longe do RDBMS tradicional começa a permear a organização. A compreensão da natureza mutável das competências requeridas e a disrupção geral dos processos existentes tornam-se evidentes. Nenhum auto-serviço existe formalmente, mas uma infraestrutura de data lake está à disposição e os estágios iniciais de uso do data lake estão ocorrendo. Geralmente, um ou dois casos de uso bem-sucedidos foram implementados. Mas com o sucesso inicial surge também uma avalanche de ideias de outras unidades de negócios buscando fazer uso do novo sistema. A ingestão de dados com algum nível de automação está em operação, alguns silos de dados foram eliminados ou dependência deles foi reduzida. Algum uso adicional de políticas de segurança como criptografia sobre dados correntes, em repouso e possivelmente Kerberos foram implementadas ou estão em processo de implementação. O planejamento do ciclo de vida dos dados está no lugar, mas potencialmente ainda não automatizado nesta fase.

Proficiência

Nesta fase, as equipes estão obtendo ao menos o valor interno do negócio a partir dos dados. Pode haver algum uso inicial de relatórios de autoatendimento e possível transformação de dados. Toda engenharia de dados está bem definida e padronizada. Os sistemas agora estão ingerindo dados facilmente. Esse processo é maduro e inclui metadados automatizados, dados de qualidade e transformações. Os sistemas RDBMS tradicionais foram adequadamente dimensionados ou eliminados completamente. Aditamentos de novos conjuntos de dados no framework são feitos através de um procedimento operacional padrão, e levam menos de uma semana. A segurança é totalmente implementada com autenticação robusta, autorização e administração geral muito bem definidas. O resultado desses processos encontra-se agora no cerne da organização e é considerado crítico para os negócios.

Mature Data Processes/Data Driven

Esta é a fase final em que os dados agora representam um produto que pode ser vendido para outras organizações. Isso pode incluir múltiplos clusters Hadoop geograficamente dispersos funcionando em uníssono via processos automatizados para agregar e transformar dados em commodity. Muitas vezes esse estágio também pode incluir o uso de virtualização ou camadas de nuvem. Essa estratégia também pode incluir uma camada de apresentação de autoatendimento externa como parte da estratégia de nuvem. Este é o estágio mais altamente refinado, alavancando processos bem compreendidos e codificados em uma pilha de tecnologia reutilizável e confiável. E que inclui subsídio e alinhamento de visão em toda a organização, combinado com um plano executivo no intervalo de 3 a 5 anos para expansão e planejamento do ciclo de vida. O ciclo de vida dos dados e a política de retenção estão no estado mais maduro. O ciclo de vida dos dados é totalmente automatizado.

Avalie a saúde da sua estratégia de Big Data

Chegar ao estágio mais maduro do Big Data é mais do que uma escolha de tecnologia. É preciso também entender o estado atual de maturidade em várias áreas funcionais. O alinhamento executivo como empresa para uma visão de Big Data também é fundamental para o sucesso de projetos de Big Data. Considere também quantos projetos subsidiados de dados e de desenvolvimento de TI podem ser considerados substanciais, quando talvez não sejam mais que extensas provas de conceito. Há também questões de maturidade de infraestrutura, de pessoal e de processos de negócios que se fundem para fornecer uma imagem de onde se encontra a organização no processo como um todo. Entender esses conceitos faz a diferença entre projetos de modernização eficazes e falhas absolutas. É importante usar a tecnologia certa e o parceiro ideal para ajudar a orientar projetos em um crescente e incipiente cenário de tecnologia orientada por análises de grandes volumes de dados. Fonte: DZone.com]]>

Usando o Hadoop no desenvolvimento de aplicativos mobile

As empresas consideram o suporte à mobilidade e o aumento da produtividade para profissionais trabalhando remotamente como prioridade máxima em uma nova categoria de aplicação, de acordo com uma pesquisa recente realizada pela consultoria norte-americana CIMI Corp. Isso significa que a maioria das empresas que adotaram ou estão adotando o Hadoop provavelmente terão que integrar o framework a aplicativos móveis. O processo de integração do Hadoop e aplicativos móveis pode ser dividido em 3 segmentos:

  • Reconhecer as limitações inerentes ao Hadoop no uso mobile
  • Criar frameworks realistas de aplicação Hadoop
  • Suporte e resolução de problemas (troubleshooting) do Hadoop em aplicativos móveis
O Hadoop é uma implementação aberta do modelo MapReduce, desenvolvido para lidar com grandes bases de dados distribuídas. Como tem sido associado à nuvem e à implementação de nuvem, a maioria das pessoas ignora o fato de que contempla atributos que não se alinham com as necessidades da empresa em geral, e a aplicações móveis em particular. Algumas dessas características incluem: – O valor do Hadoop é ótimo para bancos de dados que são de 10 a 1.000 vezes maiores do que os bancos de dados típicos usados por aplicativos móveis. Para muitos outros, no entanto, o Hadoop pode ser um exagero – O Hadoop inclui configuração significativa e sobrecarga de processamento. Uma tarefa no Hadoop pode levar vários minutos, mesmo se a quantidade de dados correlacionados for modesta – O Hadoop não é particularmente bom no suporte a estruturas de dados que possuem um contexto multi-dimensional. Por exemplo, um registro que define o valor de variáveis para uma determinada geografia, e em seguida faz o link verticalmente para definir o valor ao longo do tempo requer uma representação mais complexa de relações de dados do que o simples chave-valor usado no Hadoop – O Hadoop não ajuda muito para problemas que precisem ser vistos de forma iterativa – como várias etapas sequenciais dependentes. Como os pontos acima mencionados indicam, aplicativos móveis geralmente não devem ser concebidos como uma nova aplicação Hadoop. Adaptar o Hadoop para atender às necessidades de aplicativos móveis implica explorar os aplicativos Hadoop existentes através de conexões móveis.

Usando aplicativos Hadoop existentes

A maneira mais óbvia de se adaptar dados Hadoop a aplicativos móveis é criar um banco de dados front-end que é derivado do Hadoop, mas é apresentado de forma tradicional. Pense em aplicativos móveis no Hadoop como um Hadoop sendo executado de forma programada, que em seguida cria outro banco de dados – com um deles usando um sistema de gerenciamento de banco de dados relacional, por exemplo – que um aplicativo móvel pode consultar. Este modelo normalmente não requer alterações à forma como o Hadoop é usado porque a maioria dos usos atuais do framework estão em modo batch (de lote). O resultado é uma base de dados menor e uma organização de informações adequada aos requisitos de tempo de resposta do celular. Smartphone communication conceptFazer o Hadoop funcionar para aplicativos móveis é uma tarefa para arquitetos de software e banco de dados aliados a um profissional da área de negócios. Não apenas os dados no Hadoop precisam ser pré-digeridos para se ajustar em um formato mais responsivo – talvez usando agregação, chaves múltiplas etc. – mas fontes de dados fora de aplicações Hadoop também devem ser examinadas para verificar se outras informações devem ser adicionadas para melhorar a usabilidade mobile. Isso envolve um trabalho de bastidores, a partir necessidades dos usuários móveis para as capacidades do Hadoop e conteúdo da informação. Os arquitetos devem preencher as lacunas com outras fontes para obter uma representação eficiente e completa das necessidades dos usuários de dispositivos móveis. Aqueles que usam o Hadoop para aplicações em tempo real e desejam disponibilizar os dados para uma ampla gama de usuários, provavelmente sabe que sem alguma sobreposição Hadoop, é difícil torná-lo parte integrante de qualquer operação de TI. A fim de maximizar a quantidade de informação a partir do Hadoop, os usuários que contemplam o uso do framework para aplicativos móveis devem reestruturar o uso do Hadoop como um projeto Hive Hive é um projeto Apache que automatiza o processo de conversão de queries a partir de fontes SQL tradicionais em algo com que o Hadoop possa trabalhar. O sistema de data warehouse cria índices adicionais e fornece ferramentas para acesso em tempo real ao Hadoop. O Hive não é um substituto completo para uma hierarquia de banco de dados eficaz construída para inserir resumos ou abstrações em tempo real entre o Hadoop e os usuários. Pense no Hive como uma ferramenta para estruturação de um repositório centrado no Hadoop ou no warehouse, mas não uma solução completa para problemas envolvendo dispositivos móveis em tempo real.

Concentre-se nos pontos fortes dos aplicativos Hadoop

Outra sugestão para conectar o Hadoop a aplicativos móveis é pensar em engenharia reversa como parte integrante do projeto. Comece perguntando: “No que o Hadoop é excepcionalmente bom?” A resposta é que o Hadoop é excepcionalmente bom em tarefas agendadas que são executadas diariamente, e destinam-se a dados não estruturados ou semi-estruturados, cuja informação pode ser representada como uma série de bancos de dados tradicionais que são efetivamente abstrações dos dados brutos. Para usuários que realmente precisam do Hadoop, essa combinação de forças já deve ter sido a base para o projeto. Onde Hadoop não é a fundação, é recomendável rever a estrutura do projeto e fazer acomodações, mesmo sem a necessidade de suportar aplicativos móveis. Há casos em que as recomendações acima mencionadas não irão funcionar. O poder do Hadoop reside na sua capacidade de executar uma série de tarefas difíceis em tipos específicos de dados em determinados níveis de volume e distribuição. Quando quaisquer desses atributos não estão presentes, o Hadoop pode não ajudar muito, dado o esforço necessário para implementá-lo e sustentá-lo. Outro ponto de vista em nível corporativo sobre este tema pode ser acessado no link da CIOReview (em inglês).  Fonte: TechTarget ]]>