{"id":14729,"date":"2023-05-18T14:37:07","date_gmt":"2023-05-18T17:37:07","guid":{"rendered":"https:\/\/kb.elipse.com.br\/?p=14729"},"modified":"2023-05-18T14:43:11","modified_gmt":"2023-05-18T17:43:11","slug":"historiadores-pims-data-lakes-e-data-hubs-na-transformacao-digital-industrial","status":"publish","type":"post","link":"https:\/\/kb.elipse.com.br\/en\/historiadores-pims-data-lakes-e-data-hubs-na-transformacao-digital-industrial\/","title":{"rendered":"Historiadores (PIMS), Data Lakes e Data Hubs na Transforma\u00e7\u00e3o Digital Industrial."},"content":{"rendered":"

Qual a rela\u00e7\u00e3o entre Data Historians (PIMS)<\/a>, Data Lakes e Data Hubs no contexto da Industria 4.0 e Transforma\u00e7\u00e3o Digital Industrial (IX)? Para que servem e como podemos utiliz\u00e1-los da melhor forma?<\/em><\/p>\n

\"\"
Vista do lago Titicaca, Bol\u00edvia Por Anthony Lacoste – Obra do pr\u00f3prio, CC BY 3.0, https:\/\/commons.wikimedia.org\/w\/index.php?curid=3119549<\/figcaption><\/figure>\n

 <\/p>\n

Quais as tecnologias dispon\u00edveis para a gest\u00e3o de dados na Transforma\u00e7\u00e3o Digital Industrial (IX) da minha empresa? Qual o papel de cada sistema?<\/p><\/blockquote>\n

Estas perguntas s\u00e3o recorrentes quando falamos sobre o valor e o potencial uso dos dados industriais. Uma simples busca na internet por gest\u00e3o de Big Data<\/em> \u00e9 o suficiente para retornar um grande n\u00famero de ofertas e solu\u00e7\u00f5es. Isso pode nos causar uma certa confus\u00e3o: afinal, quais s\u00e3o os tipos de tecnologias de dados existentes? Qual o papel que cada sistema pode desempenhar, dentro de um contexto de Transforma\u00e7\u00e3o Digital, mais especificamente dentro do ambiente industrial?<\/p>\n

Este artigo n\u00e3o tem por objetivo, de forma alguma, esgotar este assunto. Pretendemos, no entanto, jogar uma luz sobre as principais tecnologias e como podemos aproveitar o que cada uma oferece de melhor. Al\u00e9m disso, propomos arquiteturas que promovem o melhor uso poss\u00edvel desses dados.<\/p>\n

Mas antes, \u00e9 importante fazer uma pequena revis\u00e3o sobre as tecnologias de armazenamento de dados e sistemas relacionados. Dessa forma,\u00a0 conseguiremos compreender melhor o papel de cada um.<\/p>\n

Bancos de Dados<\/h2>\n

A hist\u00f3ria dos bancos de dados se confunde com os prim\u00f3rdios da hist\u00f3ria da evolu\u00e7\u00e3o da pr\u00f3pria computac\u00e3o: h\u00e1 registros de bancos de dados em funcionamento ainda na d\u00e9cada de 1960.\u00a0 Hoje, s\u00e3o duas as principais tecnologias de bancos de dados: bancos baseados no padr\u00e3o SQL<\/strong>, como o PostgreSQL, MySQL e Microsoft SQL Server, e bancos baseados no padr\u00e3o No-SQL<\/strong>, como o MongoDB ou Apache Cassandra.<\/p>\n

Continuamos utilizando bancos de dados hoje em dia pelos mesmos motivos que os utiliz\u00e1vamos nos anos 60: para escrever e ler dados diversas vezes. Para isso, utilizamos as opera\u00e7\u00f5es CRUD (Create, Read, Update, Delete<\/em>) e transa\u00e7\u00f5es ACID<\/a> (quando suportadas), dadas as restri\u00e7\u00f5es do teorema CAP<\/a> \u2013 onde, em um sistema de armazenamento distribu\u00eddo, uma vez que \u00e9 necess\u00e1rio o particionamento (P), o sistema deve sempre escolher entre disponibilidade (A) e consist\u00eancia (C).<\/p>\n

Cada banco de dados possui suas particularidades, inclusive a maneira como se prop\u00f5e a resolver estes problemas. Mas, de forma geral, eles est\u00e3o aqui para ficar – por pelo menos uma boa e importante raz\u00e3o: s\u00e3o capazes de atualizar registros de uma forma eficiente e, tamb\u00e9m, de forma consistente e\/ou dispon\u00edvel.<\/p>\n

S\u00e9ries Temporais<\/h2>\n

Posteriormente, a necessidade de armazenar e processar dados de sensores, estados, sinais e vari\u00e1veis advindas dos processos industriais com base no instante de sua gera\u00e7\u00e3o impulsionou a cria\u00e7\u00e3o de uma categoria espec\u00edfica de banco de dados. S\u00e3o os chamados bancos de dados de \u201cs\u00e9ries temporais\u201d; \u00e9 poss\u00edvel implementar este conceito tanto em bancos SQL quanto em No-SQL.<\/p>\n

O principal \u00edndice de consultas de um\u00a0 banco de dados temporal \u00e9 o hor\u00e1rio (Timestamp<\/em>). Isso otimiza a velocidade de resposta com base em um instante espec\u00edfico ou intervalo de datas.<\/p>\n

Entretanto, um Banco de Dados de s\u00e9ries temporais sozinho n\u00e3o resolve todos os problemas de processamento de dados em um ambiente industrial. \u00c9 necess\u00e1rio coletar, processar, exibir, alertar, controlar, al\u00e9m de armazenar e consultar as informa\u00e7\u00f5es, dentre outras fun\u00e7\u00f5es.<\/p>\n

SCADA e PIMS<\/h2>\n

Concomitantemente \u00e0 hist\u00f3ria dos bancos de dados, ocorria a ado\u00e7\u00e3o dos sistemas SCADA pela ind\u00fastria. A utiliza\u00e7\u00e3o de computadores neste ambiente ocorria em diferentes frentes, com diferentes necessidades.<\/p>\n

O SCADA permitia a comunica\u00e7\u00e3o com sensores e CLPs, realizava o monitoramento de alarmes\/eventos e armazenamento b\u00e1sico de dados (alguns em arquivos propriet\u00e1rios ou bancos SQL), mas estava (e ainda est\u00e1) voltado, principalmente, \u00e0 opera\u00e7\u00e3o das plantas.<\/p>\n

A necessidade de analisar os dados coletados com maior profundidade para a obten\u00e7\u00e3o de indicadores e aux\u00edlio no planejamento deu origem ao Historiadores de Dados Industriais ou PIMS (Plant Information <\/em>Management System<\/em>). Por defini\u00e7\u00e3o, os PIMS possuem um engine<\/em> de s\u00e9ries temporais em seu n\u00facleo, mas tamb\u00e9m realizam diversas outras fun\u00e7\u00f5es. Dentre elas, est\u00e3o a contextualiza\u00e7\u00e3o da informa\u00e7\u00e3o, controle de permiss\u00f5es sobre os dados, execu\u00e7\u00e3o de c\u00e1lculos e exibi\u00e7\u00e3o dos dados em diferentes formatos e para diferentes perfis de colaboradores, sem as restri\u00e7\u00f5es operacionais associadas ao SCADA.<\/p>\n

\"\"
Dashboard no Elipse Plant Manager<\/figcaption><\/figure>\n

Nos dias de hoje, os Historiadores continuam desempenhando um papel extremamente relevante na organiza\u00e7\u00e3o dos dados operacionais na ind\u00fastria. Em especial, ao tornar estes dados acess\u00edveis pelo padr\u00e3o OPC UA, eles permitem que diversos sistemas e atores possam colaborar de forma consistente e organizada.<\/p>\n

Desafios da Transforma\u00e7\u00e3o Industrial (IX)<\/h2>\n

O cen\u00e1rio atual se caracteriza pela necessidade de redu\u00e7\u00e3o de custos, integra\u00e7\u00e3o dos diversos n\u00edveis hier\u00e1rquicos, rapidez na inova\u00e7\u00e3o e maior customiza\u00e7\u00e3o. Para isso, precisamos utilizar dados de diversas fontes como insumo, a fim de buscar as melhores alternativas no contexto de cada departamento e processo.<\/p>\n

Comparamos o custo e disponibilidade das tecnologias versus<\/em> os benef\u00edcios e ganhos decorrentes das a\u00e7\u00f5es implementadas com base em an\u00e1lises sobre os dados. Dessa forma, conclu\u00edmos que o desafio de coletar, organizar e processar dados e transform\u00e1-los em informa\u00e7\u00e3o pr\u00e1tica pode valer muito a pena. Isso porque hoje \u00e9 poss\u00edvel processar bilh\u00f5es de registros com recursos computacionais pagos proporcionalmente pelo uso e, com base nas informa\u00e7\u00f5es obtidas, realizar a\u00e7\u00f5es que podem render lucros ou redu\u00e7\u00f5es de custos muito superiores.<\/p>\n

Isto n\u00e3o significa, entretanto, que maior quantidade de dados \u00e9 sin\u00f4nimo de maior qualidade nos resultados. N\u00e3o se trata disso; discutiremos este assunto em um pr\u00f3ximo artigo.<\/p>\n

Outra discuss\u00e3o que cabe neste momento \u00e9 sobre dados: quais deles podemos (ou devemos) processar localmente (edge computing<\/em>), dentro da empresa, e quais deles devemos levar para a nuvem (hybrid<\/em> e\/ou cloud computing<\/em>), considerando os aspectos de velocidade, abrang\u00eancia, custos e seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n

Mesclando Dados<\/h2>\n

Eis que para atender as demandas da Transforma\u00e7\u00e3o Digital, precisamos unir diversos tipos de dados, com diferentes contextos e natureza, para diferentes perfis de colaboradores.<\/p>\n

Dentro do ambiente industrial, podemos ter esses dados sob a forma de s\u00e9ries temporais, ou ainda tabelas relacionais (SQL), bancos No-SQL, arquivos (Logs, JSON, XML), informa\u00e7\u00f5es estruturadas ou n\u00e3o estruturadas. E quais s\u00e3o os caminhos ou formas para gerir estes dados?<\/p>\n

Bem, um caminho mais tradicional seria escalar o Banco de Dados. Eles podem, de fato, crescer em tamanho individual (scale-up<\/em>) e tamb\u00e9m serem distribu\u00eddos (scale-out<\/em>), mas a um custo alto. Isto est\u00e1 relacionado ao fato de que o poder de processamento e de armazenamento est\u00e3o intimamente ligados entre si em um Banco de Dados.<\/p>\n

De forma geral, um banco de dados tem o prop\u00f3sito de armazenar, atualizar e deletar dados \u201cquentes\u201d, de forma a otimizar o armazenamento, recupera\u00e7\u00e3o e atualiza\u00e7\u00e3o, em troca de uma complexidade adicional e custo computacional.<\/p>\n

Mas, e quando falamos da necessidade de processar dezenas ou centenas de terabytes, quais s\u00e3o as op\u00e7\u00f5es?<\/p>\n

Data Warehouse<\/h2>\n

Em um passado n\u00e3o t\u00e3o distante, quando uma grande quantidade de dados necessitavam passar por an\u00e1lises, a tecnologia mais usual baseava-se na cria\u00e7\u00e3o de um grande reposit\u00f3rio local. Este reposit\u00f3rio permitia a ingest\u00e3o de dados de diferentes sistemas via scripts ETL (Extract, Transform, Load<\/em>). Ap\u00f3s um extenso trabalho de consultoria por parte de especialistas, estes scripts eram capaz de produzir relat\u00f3rios para a alta ger\u00eancia. Al\u00e9m de custoso, este sistema trabalhava com dados que ficavam rapidamente obsoletos, dada a necessidade das empresas de agir cada vez mais no tempo real.<\/p>\n

Hadoop e HDFS<\/h2>\n

O Hadoop surgiu em 2005 como uma alternativa open-source<\/em> ao Data Warehouse. Basicamente, ao inv\u00e9s de storages<\/em> e servidores propriet\u00e1rios com chips de alto desempenho, o Hadoop propunha o uso de diversos computadores comuns em paralelo, utilizando a tecnologia Map-Reduce<\/em> e o armazenamento dos dados de forma distribu\u00edda e escal\u00e1vel via HDFS (Hadoop Distributed File System<\/em>). Os dados n\u00e3o eram t\u00e3o f\u00e1ceis de consultar quanto as consultas preparadas em ETL do Data Warehouse, mas era poss\u00edvel obter resultados similares a um custo muito mais baixo.<\/p>\n

Hoje em dia ainda existem muitas solu\u00e7\u00f5es de Big Dat<\/em>a baseadas em Hadoop (por exemplo: Cloudera, HortonWorks e IBM). No entanto, a manuten\u00e7\u00e3o de um ambiente Hadoop tamb\u00e9m \u00e9 complexa e custosa, dada a variedade de componentes e administra\u00e7\u00e3o do cluster.<\/p>\n

Outro ponto a considerar \u00e9 que o Hadoop n\u00e3o \u00e9 compat\u00edvel com a arquitetura Kubernetes (Containers<\/em>). Isso, em si s\u00f3, n\u00e3o \u00e9 um grande problema. Por\u00e9m, \u00e9 importante notar que o uso de containers \u00e9 a tecnologia de computa\u00e7\u00e3o mais escal\u00e1vel atualmente: ao dividir um grande sistema em componentes menores (micro servi\u00e7os), cada um executado em um container, podemos construir e testar um grande sistema em miniatura, semelhantemente a um ambiente de produ\u00e7\u00e3o. A chave aqui est\u00e1 na simplicidade, flexibilidade e redu\u00e7\u00e3o de custos.<\/p>\n

Data Lake<\/h2>\n

O avan\u00e7o da computa\u00e7\u00e3o em nuvem trouxe mais uma tecnologia para modificar esse panorama: o Object Storage<\/em>. Este servi\u00e7o est\u00e1 dispon\u00edvel em todos principais players de nuvem com diferentes nomes (ex: Amazon S3, Azure Blob Storage, Google Cloud Storage). Basicamente, ele consiste em uma REST API onde voc\u00ea escreve e l\u00ea dados quaisquer a partir de uma chave. Qualquer outra l\u00f3gica sobre os dados deve ser realizada por uma aplica\u00e7\u00e3o.<\/p>\n

Estes servi\u00e7os s\u00e3o serverless<\/em> (isto \u00e9, n\u00e3o \u00e9 necess\u00e1rio contratar um servidor ou inst\u00e2ncia de VM), e s\u00e3o extremamente confi\u00e1veis e dur\u00e1veis. Por\u00e9m, com eles n\u00e3o h\u00e1 um intervalo garantido para consist\u00eancia local ou entre diferentes regi\u00f5es, e por isso s\u00e3o baratos, em compara\u00e7\u00e3o \u00e0 um banco de dados tradicional.<\/p>\n

Este cen\u00e1rio (dados armazenados livremente a baixo custo, mass sem um formato pr\u00e9-estabelecido) foi chamado\u00a0 por James Dixon em 2010<\/a> de Data Lake.<\/p>\n

“Ent\u00e3o, isso quer dizer que o Data Lake nada mais \u00e9 do que um reposit\u00f3rio na nuvem?” Sim. “Mas e se eu quiser usar isso localmente?” Nestes casos, \u00e9 poss\u00edvel utilizar, por exemplo, o Ceph.io<\/a> ou o Min.io<\/a>, que proveem o mesmo tipo de servi\u00e7o tanto na nuvem como localmente.<\/p>\n

Formato de Arquivos no Data Lake<\/h2>\n

Existem formatos, ao contr\u00e1rio de arquivos de texto simples como o XML ou o JSON, que podem melhorar o armazenamento de dados no Data Lake. Esses formatos podem conter metadados que ajudam na interpreta\u00e7\u00e3o da informa\u00e7\u00e3o, al\u00e9m de aumentar bastante a sua velocidade do processamento.<\/p>\n

Um desses formatos \u00e9 o Parquet<\/a>. Introduzido em 2013, ele \u00e9 orientado a colunas, contendo funcionalidades nativas para compress\u00e3o de dados. \u00c9 poss\u00edvel consult\u00e1-lo diretamente pela maioria das plataformas de Big Data<\/em>, incluindo linguagens de programa\u00e7\u00e3o como C++, C# e Python.<\/p>\n

\"\"
Organiza\u00e7\u00e3o interna de um arquivo Parquet<\/figcaption><\/figure>\n

 <\/p>\n

Data Lakehouse<\/h2>\n

Um Data Lakehouse nada mais \u00e9 do que um Data Warehouse constru\u00eddo sobre um Data Lake. Desse modo, \u00e9 poss\u00edvel armazenar os dados como um Data Lake, mas consult\u00e1-los como um SQL.<\/p>\n

Uma das formas de se fazer isso \u00e9 utilizar um banco de dados relacional para armazenar os metadados, isto \u00e9, a descri\u00e7\u00e3o dos dados (como nome de colunas etc.), bem como o nome da chave onde o arquivo com os dados pode ser obtido no Data Lake. \u00c9 necess\u00e1rio tamb\u00e9m utilizar algum engine<\/em> SQL que seja capaz de fazer o parse<\/em> da sintaxe SQL e distribuir o pedido entre os diferentes nodos, e tamb\u00e9m obter os dados no Data Lake.<\/p>\n

Esta abordagem \u00e9 indicada quando a preocupa\u00e7\u00e3o principal \u00e9 a performance, ou seja, quando os dados n\u00e3o precisam ser alterados. Por\u00e9m, esta op\u00e7\u00e3o \u00e9 bastante trabalhosa (para n\u00e3o dizer n\u00e3o suportada) na situa\u00e7\u00e3o oposta.<\/p>\n

Alguns exemplos de engines<\/em> e solu\u00e7\u00f5es que se prop\u00f5e a esta tarefa s\u00e3o o Trino (ex-Presto SQL), Dremio e Snowflake.<\/p>\n

Data Hub<\/h2>\n

Nas se\u00e7\u00f5es anteriores, vimos que um Data Lake funciona como um grande reposit\u00f3rio, com dados para toda a organiza\u00e7\u00e3o. Ele permite armazenar dados de forma simples e f\u00e1cil, embora n\u00e3o seja exatamente acess\u00edvel para a realiza\u00e7\u00e3o de consultas.<\/p>\n

De acordo com Hossein Rahnama, professor do MIT, uma das maiores dificuldades na implementa\u00e7\u00e3o de um Data Lake est\u00e1 na cria\u00e7\u00e3o de uma camada interativa sobre os dados, de forma que os usu\u00e1rios que n\u00e3o possuem o conhecimento de TI possam obter e gerar novos significados. E neste ponto, os Data Lakehouses podem ser uma parte da solu\u00e7\u00e3o, a depender do tipo de utiliza\u00e7\u00e3o.<\/p>\n

Por\u00e9m, quando lidamos com dados industriais, em especial dados mais pr\u00f3ximos do tempo real, o conceito de Data Hub<\/em> pode ser o mais indicado.<\/p>\n

O Data Hub \u00e9 um reposit\u00f3rio central em formato estrela (hub-and-spoke<\/em>) onde os dados s\u00e3o coletados e reindexados em um novo sistema. Isto permite que se tenha dados muito mais estruturados, de forma que diversos tipos de usu\u00e1rios podem acessar a informa\u00e7\u00e3o de que precisam mais rapidamente que em um Data Lake.<\/p>\n

\"\"
Comparativo entre arquitetura Ponto a Ponto e Estrela<\/figcaption><\/figure>\n

Data Hubs s\u00e3o geralmente criados por um esfor\u00e7o conjunto entre diferentes \u00e1reas, sendo que cada bra\u00e7o dessa estrutura pode ter o acesso controlado a uma parte dos dados. Note por\u00e9m que um Data Hub pode ou n\u00e3o utilizar um Data Lake, dependendo da arquitetura e do uso desejado.<\/p>\n

Modelagem e Contextualiza\u00e7\u00e3o<\/h2>\n

Dentro do ambiente industrial, precisamos trabalhar com dados de diversos tipos: estruturados, n\u00e3o estruturados e semi-estruturados, com as s\u00e9ries temporais se enquadrando nesta \u00faltima. Al\u00e9m disso, dados industriais podem conter ru\u00eddos, m\u00faltiplas dimensionalidades e outros problemas que podem tornar a extra\u00e7\u00e3o de valor bastante desafiadora.<\/p>\n

A maneira com que podemos adicionar e manter o valor ao longo do tempo para estes dados est\u00e1 na aplica\u00e7\u00e3o de modelagens e contextualiza\u00e7\u00e3o.<\/p>\n

Na ci\u00eancia da computa\u00e7\u00e3o, contextualiza\u00e7\u00e3o \u00e9 o processo de identificar dados relevantes para uma entidade (i.e., uma pessoa, objeto, local ou processo) baseada na informa\u00e7\u00e3o contextual da entidade, de forma que outras aplica\u00e7\u00f5es possam consumi-los.<\/p>\n

Por que os Historiadores n\u00e3o podem ser Data Hubs?<\/h2>\n

A resposta \u00e9 porque muitos dados de interesse para a Transforma\u00e7\u00e3o Digital podem n\u00e3o estar no historiador, mas presentes em v\u00e1rios outros sistemas, como ERP, MES e GIS, dentre outros. Al\u00e9m disto, o Historiador n\u00e3o possui ferramentas nativas suficientes, com performance e escalabilidade, para modelar todos estes dados. Por\u00e9m, essa tarefa pode ser realizada em conjunto com um Data Hub, de forma a explorar o melhor potencial de cada ferramenta.<\/p>\n

De acordo com artigo<\/a> publicado no blog da empresa LNS Research, um Data Hub industrial deve possuir seis funcionalidades b\u00e1sicas, que s\u00e3o o Processamento, Condicionamento, Sincroniza\u00e7\u00e3o, Contextualiza\u00e7\u00e3o, Persist\u00eancia e Acessibilidade. Isso significa prover acesso aos consumidores no formato que eles necessitam \u2013 inclusive suportando um fluxo bi-direcional entre os clientes, o Data Hub e os sistemas de origem.<\/p>\n

V\u00e1rias destas fun\u00e7\u00f5es est\u00e3o presentes em Historiadores que, conforme podemos ver no diagrama conceitual a seguir, ocupam um lugar central na arquitetura.<\/p>\n

Este diagrama prop\u00f5e a cria\u00e7\u00e3o de um \u201cData Lake Operacional\u201d que alimenta o Data Hub a partir de dados de um Historiador Master, bem como de outros poss\u00edveis sistemas. Da mesma forma, o Data Hub tamb\u00e9m pode obter dados de outros Data Lakes corporativos.<\/p>\n

\"\"<\/p>\n

O Data Hub na pr\u00e1tica<\/h2>\n

N\u00e3o existe uma forma \u00fanica de se obter um Data Hub. \u00c9 poss\u00edvel desenvolv\u00ea-lo internamente, a partir de componentes open-source<\/em> e servi\u00e7os dos provedores de nuvem. Tamb\u00e9m \u00e9 poss\u00edvel desenvolv\u00ea-lo adquirindo ferramentas de mercado; no entanto, grande parte delas ainda est\u00e3o em seus est\u00e1gios iniciais e pouco adaptadas \u00e0s necessidades do ambiente industrial.<\/p>\n

Aqui na Elipse Software, acreditamos que o historiador pode auxiliar, e muito, na cria\u00e7\u00e3o de um Data Hub. Ao introduzir conceitos de DataOps <\/em>(metodologia \u00e1gil para a entrega de informa\u00e7\u00e3o de qualidade), \u00e9 poss\u00edvel prover, por exemplo, as seguintes funcionalidades:<\/p>\n