Como se encontram os conceitos de Governança, Gestão de Dados, MDM e correlatos, no momento nos EUA-Visão 2016-Parte 2

2)Lessons learned from 8 years of using NoSQL-Mike Bowers-Arquiteto principal da LDS Church-Igreja de Jesus Cristo  dos Santos dos Últimos dias.

A organização (Igreja  de Jesus Cristo dos Santos dos últimos dias) tem 15 milhões de membros, com quase 30.000 congregações no mundo, desenvolve assistência humanitária em 185 países, milhares de documentos são publicados em 188 línguas, possui 192 websites e aplicações em produção com bilhões de “views” de páginas anualmente e rodam em centenas de servidores com MarkLogic. O apresentador, com uma aparente altíssima capacidade e domínio técnico sobre a tecnologia NOSQL, independentemente da variedade dos produtos que há, abriu a sessão, oferecendo à plateia a opção pela escolha do assunto que ele falaria. Ela poderia falar sobre qualquer coisa sobre NoSQL, desde descrição de qualquer dos produtos do mercado, ou responder perguntas específicas sobre técnicas de NoSQL. Ao final, houve a preferência por uma exposição aberta , de preferência do apresentador.

A tecnologia NoSQL segundo a apresentação, está no topo da curva de Hype do Gartner Grupo (Inflated expectations) , com Map-Reduce, na curva descendente em direção ao vale da desilusão (disillusionment valley) e os produtos do tipo DB-Appliances e SQL, no platô da produtividade(productivity), ultrapassados o “slope” do encantamento (enlightment). Maiores detalhes, procure uma curva de hype do Gartner.

A organização usa o produto MarkLogic, depois de deixar o Oracle. O produto Marklogic é um NoSQL baseado em Documentos, originalmente em XML e agora também em JSON. Hoje é considerado um “dual” Data Base(trabalha com  documentos XML e JSon) e também com triple store(RDF), que permite o desenvolvimento de redes semânticas. Trabalha com SQL e promete melhorias nesse campo nos próximos releases.

Paradigmas

A apresentação enfatizou o que nós já sabemos: Um shift de paradigma, quando se compara as duas linhas de produtos(relacionais e NoSQL). O modelo relacional se apresenta com suas estruturas fixas de tabelas, centradas em linhas e colunas, índices fixos, definidos na forma de B*tree e com um esquema obrigatório upfront(ou seja eu tenho que definir tudo antes de fazer a primeira inserção de uma linha numa tabela). Já a proposta NoSQL centra a ideia na mudança, flexibilidade e imprevisibilidade estrutural dos dados e dos bancos que vão recebê-los. Pode ser que se tenha que ir alterando o schema do NoSQL várias vezes, de forma iterativa, até alcançar o ponto estrutural desejado. O autor deu muita ênfase ao produto MarkLogic, que pela sua dualidade estrutural (Documentos e Redes semânticas), entra com certa vantagem nesse ranking inicial. Segundo a apresentação, o produto tem indexação poderosa, podendo criar acessos baseados em cada palavra no documento, além de permitir o enriquecimento semântico das estruturas, com tripla(sujeito-predicado-objeto), criando uma espécie de múltiplos “joins”  antecipados nas estruturas de dados. Com documentos JSON , permite estruturas aninhadas complexas, quase que impossíveis de serem obtidas em bancos relacionais. O modelo NoSQL tem escalabilidade horizontal, crescendo ilimitadamente pelo acréscimo de novos clusters. A solução Oracle Rack, uma tentativa Oracle de sair das limitações relacionais da escalabilidade vertical, não conseguiu implementar essa estratégia de forma natural e fácil. Custa muito e é uma solução altamente complexa, conforme confirma Mike Bowers. De qualquer forma, nos próximos anos, as soluções NoSQL deverão descer do pico do entusiasmo, segundo a curva de Hype do Gartner e caminhar para o platô de produtividade, tendo antes passado pelo vale da desilusão. Essa é a sina de todas as tecnologias, sejam disruptivas ou não.

Performance

Os aspectos de performance, normalmente registrados em transações por segundo foram levantados comparativamente na apresentação de Mike Bowers. As taxas de 100 transações/segundo hoje são “commodities” na maioria dos “engine” de BD. Todos alcançam. O modelo relacional, quando bem “afinado” pode alcançar 1000 transações/segundo, podendo a variante especial Oracle Exadata, alcançar 5000 transações/segundo, porém com alto custo de investimento, segundo Bowers, tangenciando a casa do milhão de dólares. Com a chegada dos BD em Appliances(máquinas de bancos de dados dedicadas, comparadas como uma “geladeira” onde já vem instalados vários processadores, memória em profusão e cpus poderosas), pode-se alcançar um patamar em torno de 5.000 transações/segundo. Nessa cesta entram a solução Exadata(Oracle), a Netezza (IBM) e a Teradata(Teradata). A partir dai, os números começam a montar os seus desafios, tanto no “throughput”, quando no custo. Arranjos em clusters desses “appliances” podem custar muito dinheiro e alcançar limites de 10.000 transações/segundo Bowers. Aqui entram os produtos NoSQL no benchmark. Naturalmente concebidos para a escalabilidade, por genética de arquitetura, esses produtos hoje chegam a limites superiores através da replicação de máquinas commodities baratas. Fazendo um raciocínio simples: Hoje algumas organizações produzem cerca de 8640 GB de dados por dia, que se distribuem por entre 8.640.000.000 transações de 1 KB/dia,  o que dá cerca de 100.000 transações/segundo, patamar desafiador para os SGBDR. Isso somente se consegue com muitos servidores clusterizados, operando os bancos  NoSQL do tipo Documento ou Chave-valor. Para um patamar de 500.000 transações/segundo, restam somente os produtos  KV(Chave-Valor)  ou os Colunares, estes, herdeiros do Big Table, também com múltiplos servidores clusterizados. Os valores desses arranjos devem ser cuidadosamente avaliados. Um NoSQL gira em torno de US4000,00-US32.000,00/servidor, segundo Bowers . O Oracle Exadata, gira em torno de US75.000,00 /core(não por servidor). Um servidor com 24 core(processadores duplos), daria 24 x US$75.000,00, o que representa um investimento significativo, com diferenças abissais em termos de valores a investir. Isso explica, segundo o autor da palestra, a corrida das empresas startups e mesmo das de outro porte, para soluções de bancos de dados NoSQL. Outros pontos, porém devem ser observados.

Escalabilidade

A escalabilidade, grande fator diferencial desses tipos de BD, passa pelo conceito de distribuição dos dados e do processamento em diversas máquinas espalhadas geograficamente. Essas máquinas poderão habitar Data Centers diferentes, em regiões diferentes. Os Data Centers (DC) podem ser divididos, por questão de segurança, em zonas de processamentos independentes. Se uma zona “cair”, a outra segura o funcionamento do DC, garantindo a sua disponibilidade. Dessa forma, os dados NoSQL adotam a estratégia de replicação de dados, normalmente realizada em zonas diferentes de um DC, ou em DC diferentes. O modelo relacional, leia-se Oracle e SQL Server também tentam oferecer opções de descentralização com replicação dos dados. De novo, essas “features” não são baratas quando se fala de soluções como Oracle(Golden Gate), Dell Plex, etc, podendo chegar a US$500.000 por uma implementação pequena  de replicação entre data centers, segundo Bowers. Já os produtos NoSQL não tem custo extra para isso, pois trouxeram do berço, essas características. Um dos desafios desta arquitetura distribuída é o sincronismo entre duas réplicas de dados e se potencializa se estiverem em dois data centers diferentes, diz Bowers. Se a conexão for síncrona, claramente haverá um comprometimento de performance, devido aos rigores do 2PC-Two Phase Commit, conforme aprendemos nas aulas de BD distribuídos. Os bancos NoSQL tem , quase que nativamente, esses mecanismos de replicações assíncronas, que podem ser M-M(Master-Master) ou M-S(Master Slave). No M-M, as atualizações podem ocorrer em todas as cópias(que são consideradas Master) e as atualizações  são enviadas para as outras. No caso M-S, as atualizações ocorrem somente em um nó e as réplicas são enviadas aos outros nós, os quais tem  somente permissão de leitura.

NoSQL:

Na palestra, Mike Bowers centrou no Marklogic um produto (Document DB) em crescimento, com características completamente opostas aos RDBMS. No Marklogic você pode indexar qualquer dado em qualquer documento. Pode procurar pelo documento com aquela palavra. A pesquisa é precisa, usa a semântica para dar consistência na busca(busca de um texto em um documento). A precisão pode ser por palavra, por frase, etc. O autor mostrou um texto sobre EF Codd, que foi o inventor do modelo relacional.  O produto permite definir cada palavra como pertencente a um certo domínio (pessoa, cliente, etc) dando a elas uma semântica própria. Quando duas palavras são comparadas, embora elas tenham a mesma grafia, o sistema é capaz de diferenciá-las pela semântica. Codd autor do modelo relacional e codd(bacalhau), serão diferenciados, pela semântica introduzida, como riqueza adicional. A modelagem é feita por documentos XML com tags, que injetam um sentido preciso nas palavras. O produto, segundo o consultor, também pode adotar o modelo de Grafos. A modelagem de grafos é rica pois envolve metadados e ontologia. Hoje, há uma série de ontologias disponíveis para diversos assuntos (procure por LOV-Linked Open Vocabularies, que contém uma série dessas classificações, para diversos domínios). A combinação de XML e JSON num banco de dados com Triplas (Grafos), forma um novo paradigma de bancos de dados enriquecidos pela semântica. A pergunta principal que deverá ser respondida com cuidado é o “Porquê” (Why) eu preciso caminhar nessa direção? Antes do entusiasmo natural por soluções de bancos de dados , com taxas espetaculares de transação, arquiteturas distribuídas centradas em HDFS(Hadoop), etc, procure sempre responder isso. Os produtos NoSQL são focados em diversos domínios de resolução de problemas e você deverá analisar se as suas dores serão resolvidas por eles.   

Resumo:

Conforme mostrado na consideração da palestra anteriormente discutida, a ênfase dada pelo técnico ao produto Marklogic, deverá ser cuidadosamente balizada pelo tipo de aplicações que a Igreja Mórmon desenvolve. No caso ilustrado, há nitidamente uma necessidade de se manipular altíssimo volume de documentos e oferecer textos, de forma distribuída para uma grande plateia de consumidores. Os bancos NoSQL não deverão nunca ser considerados como a solução milagrosa(sem duplo sentido aqui), pois estão focados em soluções caracterizadas por alto volume de dados especiais(texto, imagem, etc). São propostas tecnológicas de solução para dados distribuídos, com forte foco nos A e P do teorema CAP(Consistência), A(Disponibilidade) e P(Particionamento), ficando o C(de Consistência) adjetivada pelo eventually do acrônimo BASE. Ela acontecerá, com garantia, porém num tempo adiante. Não sincronamente, como seria demandado num sistema de controle financeiro de “dízimos”, por exemplo. Aqui o protocolo ACID dos velhos RDBMS se mostraria muito melhor.  

Os desafios de dados nas organizações governamentais brasileiras

Imagine a quantidade de dados de um Ministério, tipo do Planejamento. Ou do Ministério da Saúde, Transporte,etc. Ou de qualquer outra organização governamental do Brasil. Imagine a complexidade de suas estruturas, a duplicidade de informações interorganizacionais ou talvez a leniência histórica e colonial com o seu controle. Imagine os diversos dados redundados e replicados por inúmeras áreas de TI dessas organizações todas, com suas consequências. Agora imagine os problemas advindo desse “estado” de dados não controlado e da perda de eficiência da máquina pública, que em última análise, precisa de dados e informações corretas para rodar suas engrenagens. Pois bem, esse é o grande desafio deste trabalho brilhante chamado FACIN-Framework de Arquitetura Corporativa para (Interoperabilidade no) apoio à Governança. Capitaneado pelo Serpro, esse trabalho de Hércules, em desenvolvimento já há alguns anos, pretende botar certa ordem no caos de dados existente nas organizações públicas, e que existe também hoje nas organizações privadas. Intenciona mostrar caminhos e propor referências, com sugestão para adoção, que visem ao melhor controle desses recursos tão valiosos e para os quais, somente agora, as organizações abrem os olhos. É a chegada da Governança de dados nas instâncias dos organismos do Governo federal. O projeto, perfeito nos seus ingredientes e desafiador nos seus alcances, oferece um conjunto de elementos que descreve modelos genéricos, que poderão ser ajustados à realidade de cada organização. O grande objetivo é fomentar um alinhamento intra e interorganizacional, que deverá desaguar na oferta de melhores dados, serviços e qualidade de atendimento nas esferas do Governo Federal. Empacotado no conceito moderno de Governo eletrônico, com iniciativas de melhorias nas interações Governo-Governo, Governo-Negócio e Governo-Cidadão, o projeto foca, dentre outros vetores, em aspectos fundamentais da integração de dados e processos, cujos detalhes podem ser obtidos no link colocado ao final destas linhas. Na área de dados, foco deste Blog, o projeto apresenta um detalhado Modelo de Referência (de dados), de cuja discussão, tive o prazer de participar neste início de setembro de 2016, a convite do Serpro. O modelo tem, na sua composição, todos os elementos necessários a uma governança de dados, capaz de estabelecer os primeiros controles fundamentais e evoluir para patamares futuros de gestão desses ativos, intra e interorganizações. Oferece diretrizes e um conjunto dos P´s da boa Governança de Dados, como Políticas, Princípios, Papeis, Patrocínio, Padrões, etc, num conjunto muito bem costurado técnica e conceitualmente. Dois grandes desafios se interpõem num projeto dessa magnitude e complexidade. O primeiro, a necessidade de se estabelecer uma visão supra organizacional que acompanhe o andamento e a adoção dessas práticas por entre as diversas áreas do governo. Nos projetos de GD, de que participamos, verificamos essas dificuldades latentes, dentro de uma única organização, visando o envolvimento das diversas LOB(Linhas de negócios) que utilizam os dados organizacionais. Agora transportemos esse cenário para diversas organizações governamentais, num ecossistema complexo. Desafio puro. O outro ponto a se considerar é o momento político de transição, quando teremos novos gestores, líderes, etc. E nesse nosso país, sabemos que, coisas boas, feitas por governos anteriores, podem desaparecer no buraco negro das diferenças políticas ou na indiferença daqueles que não percebem a importância dos grandes projetos, que não foram da sua lavra. E esse é um deles...

Obs: Se você é estudante de Computação, Sistemas de Informação, etc, trabalha com TI, ou gosta do assunto Dados, Integração e Interoperabilidade não deixe de acessar o link abaixo.

https://www.facebook.com/governancaeinteroperabilidade 

Simpósio Mineiro de Sistemas de Informação-Puc Minas-30-agosto-2016-Palestra de abertura

Governança, Gestão, MDM e correlatos-Uma Visão do EDW-2016-San Diego-Parte I

Como se encontram os conceitos de Governança, Gestão de Dados, MDM e correlatos, no momento nos EUA-Visão 2016-Parte I

Evento: EDW-2016-San Diego-California, entre 17 e 22 de Abril

Embora o Blog do Barbi não pôde ter comparecido pessoalmente, tive acesso a todas os vídeos de todas as palestras. A análise cuidadosa de todas as palestras, permite essa visão simplificada do estado da GD, Bancos NOSQL, Gestão de dados e temas correlatos nos EUA, e de certa forma, reflete a situação no mundo. Fica até mais confortável, pela possibilidade de se ouvir várias vezes, o que o listening do meu  inglês “Joel Santana” dificulta de primeira....Enjoy..

A)Palestras sobre NOSQL:

O tema foi bastante discutido em várias 13 palestras, que variaram de visões mais gerais sobre o conceito e outros mais específicos sobre certos produtos, passando per aplicações dessa tecnologia em projetos muito interessantes. Vamos comentar algumas: 

1)Health Care Analytics with na Enterprise Data Lake-Parsa Mirhaji-CTO do Montefiore Health System e Jans Aasman, CTO  da FranzInc, criadora do Allegrograph

A apresentação mostrou uma interessante aplicação na qual um importante Centro Clínico  americano está montando um grande Data Lake semântico. Data Lake é um conceito emergente para designar um grande depósito de informações, de natureza variada, com   dados de  pacientes,  de famílias de pacientes, dados de imagens, prescrições, medicamentos,  especificidades sobre doenças e tratamentos, “devices” , planos de seguros dos pacientes, etc. Algumas informações complementares também entram como os dados sócio geográficos de pacientes(onde moram, como moram, etc) e informações genéticas sobre eles. É na realidade o que chamávamos, nos anos 80 e 90, de ODS-Operational Data Store, agora amplificado por Big Data e dados não estruturados, formando uma espécie de repositório gigantesco, um  “sopão” de informações gerais, de onde podem ser extraídos conjuntos de dados para tratamentos informacionais específicos, via outras plataformas. A ideia central é ter um conjunto plural de dados, capaz de, rapidamente, produzir informações precisas e conectadas, por meio de  uma camada NOSQL que aplique estruturas de grafos e relacionamentos semânticos.

Maturidade em tratamento de dados de saúde

A apresentação mostrou um interessante modelo de maturidade em “Analytics” para á área de saúde, com 9 níveis(de zero a 8), evidenciando os tipos de degraus que a empresa pode trilhar em direção a um patamar mais maduro no tratamento de informações médicas. Vai, por exemplo do nível zero, onde as soluções de informações se baseiam em fontes de dados(data points) fragmentados, subindo para um EDW-Data Warehouse Empresarial (nível 1), alcançando registros padronizados e glossário de termos(nível 2). Continua com a automatização de relatórios internos(nível 3) e de  relatórios externos(nível 4). Sobe um degrau para contemplar  a gerência sobre  redução do resíduo hospitalar(nível 5), chegando na camada de  Gerência de saúde da população, com “analytics” sugestivo e inferencial de potenciais problemas(nível 6). Cresce para o próximo nível analisando riscos clínicos de intervenções com análise preditiva(nível 7), até alcançar a camada de medicina personalizada e prescritiva(nível 8). Baseados em sistemas de aprendizado centrados em evidências clínicas, os níveis 0 e 1, estão fundamentados em relatórios, dashboards, Data Marts, etc. Os níveis  de 2 a 5 se concentram na melhoria dos EMR(Eletronic Medical records) , com acesso ubíquo a qualquer informação, aspectos regulatórios, informações de colaboração e parceiros. Os níveis(6 e 7) focam em ACO-Accountable Care Organization, no fundo uma organização de provedores de serviços de saúde com um modelo de entrega(de serviços) e de pagamentos (de fornecedores) que procura definir com rigor os reembolsos centrados em métricas de qualidade e de redução no custo total para um tipo definido de população de pacientes. Isso evidencia a forte associação que os  provedores de serviços de saúde tem com os dados e sua gerência, compondo o conceito forte de HIS-Health Information Systems. Esse modelo claramente , na medida em que evolui nos degraus descritos, demandará um volume maior de dados, além de, muito importante, os metadados mais presentes e elaborados. Não esqueçamos que essa dupla(dados e metadados) são os pilares para se alcançar uma sólida Gerência de Conhecimento, que no fundo a indústria da saúde americana procura sistematizar, evidenciada neste trabalho apresentado.

Data Lake Semântico e suas camadas

A base conceitual da arquitetura é o Data Lake Semântico, plataforma composta por  uma camada em “analytics”  de Big data e computação Cognitiva(uma forma de processamento de dados que tenta simular a capacidade de pensamento do ser humano). A camada básica  de software é formada pelo Hadoop(HDFS), com Spark , uma proposta que vem de encontro ao MapReduce, com uma intenção de maior performance, focando em  processamento em memória e com o mesmo objetivo básico de processar uma imensidão de dados distribuídos em diversos clusters de processadores. Processa comandos SQL e dados “in-stream” , com fluxos constantes. Além disso, o sistema aplica os conceitos de Redes Semânticas, procurando uma estruturação de dados, baseada em triplas(sujeito-predicado-objeto), como (Barbieri=sujeito), (operou=predicado), (a tiroide=objeto). Essa estruturação, no estilo de grafos, se ajusta perfeitamente na montagem de pedaços de conhecimentos, ligando via nós e arcos, os átomos de informação e seus relacionamentos. Para tal, os  conceitos de metadados e ontologia são usados e complementam a formação em direção a uma melhor produção de conhecimento. A Ontologia é aquela parte que formaliza as classificações de “coisas”, no caso aqui classificações de medicamentos, de doenças, de tipos de atendimento, de tipos de pacientes, etc, que acabam compondo a camada final de metadados, fundamental para a  codificação e a cristalização do conhecimento. Parte de repositórios ontológicos já existentes são usados como o  NCI-Thesaurus(National Cancer Institute),   GO-Gene Ontology, para descrições de termos e conceitos de genéticas, etc. Aproximadamente 183 bases de conhecimento, ontologias e termos são usados no sistema, formando o Knowledgebase do sistema.  

O NOSQL usado neste projeto é o AllegroGraph e Hive(solução de DW que roda sobre o Hadoop e foi desenvolvido inicialmente pelo FB e hoje atende ao Netflix). O Datalake, em si, é armazenado no Hive (DW) e os dados são tratados, na forma de redes semânticas, via o Allegrograph , um BD NoSQL do tipo grafo. Usam o SPARQL, uma  linguagem espécie de SQL like para buscar informações de nós e arcos. O Allegrographo forma com o Neo4J, a dupla de destaque dos produtos NOSQL da categoria BD de Grafos.

Objetivo final:

No fundo, o que o sistema busca, de forma reduzida e simplificada, é melhorar as ações de diagnósticos, cruzando instantaneamente sintomas de um certo paciente  e procurando similaridades com outros pacientes que já manifestaram o mesmo problema, onde um conjunto gigantesco de informações já coletadas, poderá produzir e melhorar as inferências sobre aquele caso em análise. Foi citado o caso grave de um garoto internado com alergia a amendoim e que por correlações não diretas descobriu-se que tinha asma, detectado por uma rede de conhecimento entre alergia a amendoim, dermatite e asma.  O sistema também poderia responder query do tipo: Quantos pacientes com um diagnóstico relacionado com dores abdominais (X) , no espaço de 30 dias, retornaram com um diagnóstico relacionado a pedras na vesícula (Y), depois de 10 dias ?  O desenvolvimento da Ciência de dados , numa ambiente deste tipo, poderá trazer respostas para previsões em torno de possíveis doenças(a acontecer); a probabilidade de readmissão(reincidência da doença dentro de x dias), a efetividade dos procedimentos e dos medicamentos usados; o que poderia ser melhor para um certo paciente, dado o conjunto particular de doenças e seus aspectos genéticos, a efetividade e a eficiência dos provedores envolvidos(médicos, enfermeiras, departamentos, etc), etc  Os algoritmos de similaridade entre pacientes são possíveis pelos links definidos no sistema entre ontologias diversas. O conceito de “data provenance” e “data lineage” são considerados fundamentais nesse contexto, rastreando-se a origem dos dados (provenance), considerando todos os passos intermediários por onde o dado transitou (lineage), podendo analisar a sua qualidade e possíveis erros. Tudo isso é fator fundamental quando se fala de dados sobre saúde e vida.   

Resumo da ópera:

A palestra foi focada especificamente em Health Information System, onde dados são importantes pelo papel que representam na saúde e na vida da população. Foi feita, na sua primeira parte pelo Chief Technical Officer (CTO) da organização médica que desenvolve o sistema, num centro de excelência em Nova York, A palestra deixou algumas dúvidas, justo pela alta especialização do tema Na segunda parte falou o CTO da empresa que oferece o produto(Allegrograph), numa simbiose comum nesses eventos. O entusiasmo de quem usa e o produtor daquilo que é usado como “tool”, sempre produzem palestras com visão muito otimista, onde problemas e restrições naturais de qualquer solução não são trazidas para os PPT´s. Assim, todo filtro é cuidadoso e sugerido..