X

Saiba como a nuvem e as novas tecnologias habilitam a transformação nos negócios e na sociedade.

Data Lake — usar ou não usar?

This is a syndicated post, view the original post here

Conheça os principais princípios de arquitetura e elementos do ecossistema do Oracle Data Warehouse.

Por Peter Heller*

Todos conhecemos o velho ditado que diz "Para quem só sabe usar o martelo, todo problema é um prego".  No mundo do gerenciamento de dados, somos mais uma vez confrontados com o próximo martelo. Vamos até a sala de ferramentas e vejamos quantos martelos já recolhemos.

Cada uma dessas inovações de big data representou um avanço na economia, proporcionado currículos melhores e um vocabulário insípido, porém divertido!  Para atualizá-los sobre o assunto, nós começamos colocando dados em reservatórios e oceanos; em seguida, rios afluíram para lagos ou, quando mal feitos, pântanos. 

Mais recentemente, córregos distribuídos estão formando uma malha. Depois disso, nós mergulhamos e preparamos os dados. Excelente!

-Leia mais: Consolidação de banco de dados: por que e como fazer?

Ter domínio sobre o volume de dados, a variedade, a velocidade (e uma dúzia de outros "Vs") ainda é um enorme desafio técnico e de negócios. Nos laboratórios de dados que trabalham com big data, o objetivo de encontrar valor em um oceano de valores desconhecidos tornou-se uma missão de machine learning e uma paixão para cientistas de dados do mundo todo.  

Mas esse desafio não se reserva apenas ao big data.  Provavelmente, essas avançadas técnicas terão um impacto transformador também nos negócios, no que refere-se aos dados corporativos que alimentam nossas organizações todos os dias — os sistemas de registro e os sistemas de envolvimento.

Neste blog post, quero compartilhar alguns dos principais princípios de arquitetura e elementos do ecossistema do Oracle Data Warehouse.  Particularmente, tratarei de como você pode aplicar avançadas técnicas analíticas sobre dados corporativos em seus sistemas transacionais e data warehouses — tanto de forma independente quanto coordenada com data lakes.  Se você usa plataforma Oracle hoje, as principais funcionalidades analíticas já estão implementadas e prontas para serem usadas.

O objetivo de negócios: Análises que Inspiram e Aspiram

Vamos aproveitar o entusiasmo em torno das análises modernas, ou seja, a predição do futuro.  Imagine uma empresa que sofria com o alto grau de atrito entre seus melhores funcionários.

 

Essa empresa estava determinada a compreender e resolver o problema.  Eles começaram com a criação de um painel de visualização contendo informações de atrito e ganharam visibilidade de centenas de fatos úteis:  motivos, número de ocorrências e tendências de atrito, avaliações de desempenho e até mesmo o grau de ligação entre funcionários. 

A experiência investigativa que possuíam lhes permitiu descer no nível de detalhe de cada dado para tentar compor a história de atrito — e depois inferir ou tirar conclusões e tomar ações.

Além de ter sido um exercício divertido (quem não gosta de explorar gráficos coloridos interativamente?), eles acabaram aprendendo sobre o poder da análise preditiva. 

Ao combinar seus dados corporativos de HCM e modelos de machine learning, eles permitiram que os dados falassem por si mesmos — sem a influência de intuições ou vieses não intencionais. Para cada demissão de funcionário da empresa, eles conseguiram predizer quem, quando, por que e onde.

Em seguida, eles não apenas poderiam testar a acurácia dessas predições, como também testar se suas ações de mitigação eram eficazes.

Decisões analíticas de gerenciamento de dados
Esse painel exibe o resultado positivo dos negócios, mas, para chegar lá, os arquitetos de TI se imbuíram de determinação para encontrar uma arquitetura sustentável e acessível que estivesse intimamente alinhada às suas necessidades de negócios. 

Estas eram suas condições de negócios na época:

-Uma cadeia de restaurantes com 25 mil lojas e 240 mil funcionários.

-Rotatividade anual de funcionários de 130%.  Isso significava que eles perdiam 100% da força de trabalho e, em seguida, 30% das substituições!

-A gerência pediu painéis em tempo real, alta precisão nas predições e disponibilidade do sistema 24 horas por dia, 7 dias por semana.

A estratégia de TI para RH
A TI aprendeu que, para serem eficazes e responsivos, eles precisavam de uma arquitetura integrada em vez de componentes independentes.

Eles haviam conversado com um engenheiro de dados de uma empresa Fortune 500 que lamentou sua falta de visão ao comprar componentes de data warehouse em vez de uma arquitetura abrangente: "Você precisa usar ferramentas de ETL de terceiros e ferramentas de BI de terceiros para extrair insights.  Além disso, você também tem um relacionamento separado com provedores de infraestrutura de nuvem.  O custo de propriedade não diminui até você chegar à fase de implementação."1

Em busca de orientação, eles entraram em contato com a Forrester Research, que explicou as conclusões da sua plataforma translítica de dados.  Simplificar o pipeline de análise combinando o processamento transacional com recursos analíticos e eliminar processos de ETL parecia ser exatamente a arquitetura que eles estavam procurando. Assim, a jornada deles começou com a criação de uma arquitetura de informação unificada e otimizada.

A estratégia de pipeline de análise de RH
Seus principais aplicativos de RH e de geração de relatórios básicos já eram executados sobre um único banco de dados Oracle no Oracle Exadata, de forma que eles acreditavam já ter dois dos componentes em funcionamento. 

Eles haviam até tomado uma decisão prévia de evitar a implantação de um data warehouse convencional, pois pensavam que as transferências de dados adicionais apenas atrasariam seus relatórios.  Além disso, eles queriam eliminar o custo, as interrupções e as tarefas administrativas necessárias para gerenciar, manter e proteger um sistema adicional de grande escala e alta disponibilidade.  

Sua principal conquista em termos de gerenciamento de dados até o momento tinha sido mover as análises para onde os dados estão.  Agora, porém, os cientistas e analistas de dados precisavam de dados que estavam fora do sistema principal.  Na verdade, esses dados estavam em bancos de dados não Oracle e na nuvem da Microsoft.  

Então, como deveria ser o pipeline analítico?  Seriam necessárias plataformas de dados adicionais, como um data warehouse e/ou um data lake, para manter os dados em um só lugar?  E — uma grande preocupação — que atrasos de tempo seriam incorridos para mover, transformar, analisar e, por fim, publicar os resultados?

Responder a essas perguntas e chegar a uma arquitetura analítica preditiva ideal os levou a considerar três áreas cruciais:   fontes de dados, acesso a dados e análises in-loco.

Conjuntos de dados analíticos
Estas são suas fontes de dados, repositórios de dados e locais de implantação:

Sistemas de registro
O aplicativo de HCM principal usa o Oracle Database.  E, para economizar dinheiro em armazenamento Exadata, eles arquivam automaticamente os dados em um repositório de objetos na nuvem.  No entanto, com tanta rotatividade, a análise precisava incluir dados históricos dos funcionários.  A boa notícia era que eles já estavam usando o particionamento híbrido da Oracle como forma de arquivamento ativo.  Ainda que os dados sejam movidos fisicamente, eles podem ser acessados de forma transparente, e seus metadados, controles de segurança e trilhas de auditoria são mantidos.  Isso torna os dados históricos facilmente acessíveis. Saiba mais aqui.

Sistemas de envolvimento
Os dados sociais e de interações móveis de HCM podem revelar a extensão do envolvimento dos funcionários uns com os outros. Esses dados são armazenados em uma base de dados NoSQL.  

O repositório de dados de pesquisas corporativas armazena dados cruciais da entrevista de saída.  Esse aplicativo corporativo publica resultados de pesquisas em arquivos JSON, no repositório de objetos do Microsoft Azure Cloud.

Unificando todos os dados
Os cientistas de dados adicionaram duas novas fontes de dados para uso em nossa análise:  dados móveis em uma base de dados NoSQL e dados de pesquisas em um repositório de objetos JSON.  Com essas duas fontes fora do banco de dados, eles precisavam determinar se poderiam permanecer fiéis ao seu princípio de gerenciamento de dados de mover as análises para onde os dados estão.  Estas são as opções que eles consideraram:

A opção 1 faz uma cópia dos dois novos conjuntos de dados no sistema transacional.  A opção 2 copia as transações em um data lake, que também inclui a cópia dos outros dois conjuntos de dados.  Isso é mais complicado do que parece, uma vez que os metadados de campo precisam ser derivados e enriquecidos; a linhagem, capturada; a qualidade dos dados, avaliada; e as regras de segurança, aplicadas.  A opção 3 consiste em deixar os dados no local de origem e lê-los de forma segura a partir do sistema transacional, conforme necessário.  

Devido à condição de urgência nos negócios, a consideração primordial para acesso às informações era ter um serviço de autoatendimento simples e rápido.  Assim, o cenário ideal era filtrar e transferir informações apenas quando necessário — opção 3. 

O benefício comercial intuitivo era que um único conjunto de dados estaria sempre atualizado e disponível em tempo hábil.  Por outro lado, isso também significava que eles poderiam evitar longos períodos de reprocessamento de conjuntos de dados e os prováveis encargos de rede e armazenamento associados.

As funcionalidades de consulta do Oracle Big Data SQL e do Oracle Cloud SQL permitem acessar o Hadoop, o Kafka e o NoSQL nos seus diversos data centers e repositórios de objetos em nuvem pública a partir de ambiente Oracle, Microsoft Azure e Amazon Web Services.  Além disso, a conexão direta de alta velocidade entre data centers Oracle e Microsoft permite transferências de dados de baixa latência e alta largura de banda.

Ciência de dados in-loco
O laboratório de dados centrado no Oracle Database
O aspecto mais importante do nosso pipeline analítico é a análise propriamente dita.   Onde o laboratório de dados deve ficar? Quais são as ferramentas necessárias? 

Existe uma máxima de 80/20 com relação às análises e à ciência de dados. 80% do tempo é gasto na preparação dos dados; 20%, nas análises.  A empresa logo percebeu que manter os dados em um banco de dados Oracle poderia ajudar a eliminar esses 80% do tempo que é gasto na preparação dos dados.

A primeira etapa convencional para a análise preditiva é criar subconjuntos de dados a partir de conjuntos maiores. No Oracle, os dados permanecem no banco de dados, mas podem ser divididos logicamente em subconjuntos por usuários, projetos e dados.  Essa estratégia de cópia única mantém os dados consistentes e atualizados em todos os subconjuntos, ao mesmo tempo que elimina reconciliações onerosas. Os repositórios de objetos não oferecem essa funcionalidade.

A segunda etapa convencional é mover o subconjunto de dados para um ambiente de processamento analítico.  No Oracle, o ambiente de machine learning já está presente e integrado em muitos recursos do mecanismo de banco de dados, como o processamento de alto desempenho em memória. 

Essa arquitetura de análise embutida elimina totalmente a etapa de movimentação de dados. Os data lakes também não oferecem essa funcionalidade intrínseca.

Por fim, as próprias ferramentas analíticas são embutidas e otimizadas na arquitetura. Os resultados acabaram por ter um desempenho excepcional devido às muitas funcionalidades otimizadas de hardware e software, como otimização de algoritmos na memória, na CPU e no armazenamento, particionamento de dados, ajuste automatizado, para citar alguns. 

A infraestrutura de data lake é limitada ao gerenciamento do armazenamento de objetos e não oferece nenhuma funcionalidade analítica embutida.   

Dito isso, eles chegaram a encontrar ferramentas de machine learning e BI usando data lakes como forma de armazenamento na nuvem.  Mas essa abordagem não era adequada aos seus objetivos de arquitetura integrada. 

Partir para uma solução centrada em data lakes significava que eles teriam que montar e manter toda uma plataforma de maneira personalizada. Além do mais, isso envolveria muita movimentação de dados.

Talvez já não seja mais surpresa, mas a escolha deles foi construir um laboratório de dados in-loco centrado no banco de dados.  Com todo um pipeline "in-loco", eles tinham uma arquitetura para cumprir seu objetivo de análise quase em tempo real.

O Zagrebačka Bank usa o Oracle Database como um repositório de dados para múltiplas cargas de trabalho, consolidando dados transacionais de 130 agências e 850 bancos de dados distribuídos (caixas eletrônicos) e realizando análises de machine learning in-loco a serem usadas quase em tempo real pelos agentes de empréstimos.

A arquitetura do pipeline analítico
No final, eles adotaram o ecossistema Oracle Data Warehouse para atender às suas necessidades de pipeline analítico. Seu pipeline era mais simples, mais integrado e minimizava a movimentação de dados, tanto para a geração de relatórios em tempo real quanto para a modelagem e o treinamento de análises preditivas.

Com essa arquitetura, os aplicativos têm acesso imediato aos dados — sem necessidade de movimentação ou transformação dos dados.  Usando o Oracle Big Data SQL, os diferentes repositórios de dados e plataformas de dados são unificados em uma única visualização segura, acessível por todos os usuários, funções analíticas e aplicativos. 

A função de análise preditiva pode ser executada diretamente no banco de dados, e esses resultados podem ser combinados com as fontes de dados originais para gerar os relatórios e predições necessários.

Resumo
Hoje, os data lakes são uma alternativa econômica valiosa que satisfaz de forma robusta as necessidades de alguns aspectos da TI e da ciência de dados, no entanto, eles são menos adequados para dados corporativos, a menos que os metadados ainda sejam controlados e protegidos pelo banco de dados.  E, para esses sistemas de registro, os data lakes são úteis como uma forma de arquivo ativo e ajudam a economizar em custos de armazenamento. 

De outra forma, há muitos custos não tão ocultos para converter dados estruturados em não estruturados ou semiestruturados — porque, no final das contas, se você quiser usá-los, terá que adicionar a estrutura de volta.

Grande parte da lógica analítica para usar um data lake pode ser realizada dentro do Oracle Database e do ecossistema Oracle Data Warehouse. Não deixe de ver a pesquisa da Forrester que classifica plataformas de dados translíticos.

Para muitos casos de uso, simplesmente faz sentido gerenciar e analisar os dados in loco. Os data warehouses Oracle são a solução certa, especialmente quando eles coexistem com seus sistemas transacionais — compartilhando funcionalidades de desempenho, disponibilidade e segurança.  O ecossistema Oracle Data Warehouse permite a adoção de todas as melhores práticas de gerenciamento de dados.

Experimente estes dois poderosos recursos "gratuitos":  cargas de trabalho múltiplas e machine learning.  Todas essas funcionalidades de banco de dados estão disponíveis onde quer que você execute um banco de dados Oracle — seja on-premises ou na nuvem.

O ecossistema Oracle Data Warehouse é mais potente do que você imagina. Experimente na Oracle Cloud usando créditos gratuitos.

*Peter Heller é Diretor Sênior de Marketing na Oracle

Be the first to comment

Comentários ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.