Teorias Analíticas Avançadas Tema 1 Conceitos de Data Lake, Data Streaming e análise de dados em tempo real

Prévia do material em texto

DESCRIÇÃO
Conceituação de tecnologias para o armazenamento, a disponibilização e o processamento de grandes
volumes de dados.
PROPÓSITO
Dominar os conceitos de Data Lake e de streaming para seu uso de maneira útil e produtiva e para a
escolha da forma mais adequada de armazenamento, processamento e análise de grandes volumes de
dados é imprescindível em um mundo repleto de informações e dados.
OBJETIVOS
MÓDULO 1
Aplicar boas práticas em projetos de Data Lakes
MÓDULO 2
Reconhecer as técnicas de streaming usadas para o processamento de dados ilimitados
INTRODUÇÃO
Neste conteúdo, aprenderemos o que é um Data Lake, assim como a finalidade e os benefícios do uso
dessa tecnologia. Entenderemos ainda a diferença entre ele e o Data Warehouse, sabendo distinguir os
contextos mais adequados para o emprego de cada uma dessas tecnologias. Também apresentaremos
as boas práticas que precisam nortear os projetos de implementação do Data Lake.
Além disso, conceituaremos o streaming, pontuando os desafios e as eventuais limitações em seu
processamento. Também compreenderemos a diferença entre o processamento de streaming e aquele
feito em batch. Por fim, conheceremos as técnicas usadas no processamento de streaming de dados.
MÓDULO 1
 Aplicar boas práticas em projetos de Data Lakes
BIG DATA
Conforme o mundo muda, as empresas precisam evoluir com o tempo — e isso requer dados. O termo
“big data” começou a ser usado nos anos 1990 pela NASA com o objetivo de descrever conjuntos de
dados grandes demais para serem capturados, processados, analisados e armazenados de maneira
organizada por sistemas tradicionais.
NO CONTEXTO ATUAL DA TECNOLOGIA DA
INFORMAÇÃO (TI), BIG DATA SE REFERE AOS
IMENSOS VOLUMES DE DADOS (ESTRUTURADOS
OU NÃO) GERADOS A CADA SEGUNDO.
Dados são gerados constantemente em cliques em anúncios, reações em mídias sociais,
compartilhamentos, viagens, transações, conteúdos de streaming e muito mais. No infográfico da oitava
edição de Data never sleeps, do Domo, é possível vislumbrar quantos dados foram gerados por minuto
no ano de 2020:
 Infográfico de dados gerados a cada minuto em 2020.
Nesse infográfico, podemos identificar os 3 Vs clássicos de Big Data. Trata-se, afinal, de um grande
volume de dados gerados em alta velocidade e com grande variedade.
DATA LAKES
CONCEITO
Data Lakes são uma das tecnologias utilizadas para lidar com o desafio de Big Data. De acordo com
Nick Heudecker, diretor de pesquisa e analista do grupo Gartner:
EM TERMOS GERAIS, OS DATA LAKES SÃO
COMERCIALIZADOS COMO PLATAFORMAS DE
GERENCIAMENTO DE DADOS CORPORATIVOS PARA
ANALISAR FONTES DÍSPARES DE DADOS EM SEU
FORMATO NATIVO. A IDEIA É SIMPLES: EM VEZ DE
COLOCAR OS DADOS EM UM REPOSITÓRIO DE DADOS
DESENVOLVIDO PARA UM PROPÓSITO ESPECÍFICO, VOCÊ
OS MOVE PARA UM DATA LAKE EM SEU FORMATO
ORIGINAL. ISSO ELIMINA OS CUSTOS INICIAIS DE
INGESTÃO DE DADOS, COMO A TRANSFORMAÇÃO.
DEPOIS QUE OS DADOS SÃO COLOCADOS NO LAGO,
ESTÃO DISPONÍVEIS PARA ANÁLISE POR TODOS NA
ORGANIZAÇÃO.
(GARTNER..., 2014, tradução livre)
Ou, como dito de forma mais precisa por Tamara Dull, da Amazon Web Services, um Data Lake é:
[...] UM REPOSITÓRIO DE ARMAZENAMENTO QUE MANTÉM
UMA GRANDE QUANTIDADE DE DADOS BRUTOS EM SEU
FORMATO NATIVO, INCLUINDO DADOS ESTRUTURADOS,
SEMIESTRUTURADOS E NÃO ESTRUTURADOS, EM QUE A
ESTRUTURA DE DADOS E OS REQUISITOS NÃO SÃO
DEFINIDOS ATÉ QUE OS DADOS SEJAM NECESSÁRIOS.
(DUTRA, 2016)
A PRINCIPAL FINALIDADE DOS DATA LAKES É
TORNAR OS DADOS ACESSÍVEIS DE FORMA RÁPIDA
PARA QUEM PRECISA CONSUMI-LOS. O BIG DATA
TAMBÉM AJUDOU A TORNAR A CIÊNCIA DE DADOS
MAIS VIÁVEL.
Por princípio, essa ciência necessita de muitos dados. Uma quantidade maior deles para treinamento
invariavelmente leva a modelos de aprendizado de máquina melhores.
Em síntese, pode-se dizer que:
QUANTO MAIS DADOS, MELHOR!
Nesse contexto, ter a maior quantidade de dados disponíveis em um único lugar configura uma ideia
extremamente atraente. Essa “fonte”, na qual podemos acessar todos os dados, é justamente a
inspiração da metáfora do Data Lake.
 DICA
Data Lakes se concentram no armazenamento de dados díspares, ignorando como ou por que eles são
usados, controlados, definidos e protegidos.
O conceito de Data Lake espera resolver dois problemas: um antigo e um novo.
O velho problema que ele tenta solucionar são os silos de informações. Em vez de ter dezenas de
coleções de dados gerenciadas de forma independente, pode-se combinar essas fontes no Data Lake
de forma não gerenciada.
Essa consolidação teoricamente resulta em maior uso e compartilhamento de informações, ao mesmo
tempo que pode cortar custos por meio da redução de número de servidores e licenças.

Já os novos problemas endereçados conceitualmente pelos Data Lakes são as iniciativas de Big Data,
cujos projetos requerem uma grande quantidade de informações variadas. Elas são tão variadas que
não fica claro o que são ou quando são recebidas. Restringi-las em algo tão estruturado como um Data
Warehouse ou um sistema de gerenciamento de banco de dados relacional (RDBMS) restringe,
portanto, a própria capacidade de análises futuras.
javascript:void(0)
SILOS DE INFORMAÇÕES
Repositórios que encerram informações desconectadas de outras fora do mesmo repositório.
Data Lakes fornecem a flexibilidade de armazenar qualquer coisa sem haver a necessidade de se
preocupar com a pré-formatação dos dados.
No entanto, essa flexibilidade também gera um novo conjunto de desafios, já que é necessário descobrir
a estrutura subjacente ao ler os dados.
Outro desafio que surge com a enorme quantidade de dados fluindo para as organizações atualmente é
a preocupação sobre quais podem ser acessados pelos funcionários e quais não devem ser
compartilhados. Por vezes, há uma compreensão limitada acerca de sua origem ou sobre o que foi feito
com eles até chegarem ao Data Lake.
DATA LAKES X DATA WAREHOUSES
PRIMEIRAS PALAVRAS
Assim como os Data Warehouses, os Data Lakes são amplamente usados para armazenar grandes
volumes de dados. Esses termos, no entanto, não são intercambiáveis.
Data Lake: Vasto repositório de dados brutos, cuja finalidade ainda não foi definida.
Data Warehouse: Repositório de dados estruturados e filtrados que já foram processados para
uma finalidade específica.
DISTINÇÕES
Os dois tipos de armazenamento de dados costumam ser confundidos, mas eles, como apontamos, são
muito mais diferentes do que semelhantes. A única semelhança real entre ambos é o propósito de alto
nível de armazenamento de dados.
Essa distinção é importante, porque eles servem a propósitos diferentes e exigem abordagens distintas
para serem otimizados de maneira adequada. Tendo isso em vista, examinaremos agora os principais
aspectos pelos quais Data Lakes e Data Warehouses se distinguem:
DADOS BRUTOS X DADOS PROCESSADOS
Dados brutos são aqueles que ainda não foram processados com um propósito específico. A grande
diferença entre Data Lakes e Data Warehouses está na estrutura subjacente dos dados armazenadas
em cada uma dessas tecnologias.
Data Lakes armazenam principalmente dados brutos e não processados, enquanto os Data Warehouses
armazenam aqueles processados e refinados. Pela armazenagem de dados brutos, aqueles tipicamente
necessitam de mais espaço do que estes. Além disso, os dados não processados geralmente são mais
maleáveis, podendo ser analisados para atender a diversos propósitos, e ainda são ideais para a
utilização em tarefas de aprendizado de máquina (machine learning).
Já Data Warehouses, por armazenarem dados processados, economizam espaço de armazenamento
por não manterem dados que podem nunca ser usados. Além disso, os processados podem ser mais
facilmente entendidos por uma quantidade maior de usuários.
PROPÓSITO INDETERMINADO X PROPÓSITO CONHECIDO
A finalidade dos conjuntos de dados específicos em um Data Lake não é fixa. Embora algumas vezes os
dados fluam até ele para um uso específico, essa fluidez por vezes se dá apenas para queeles sejam
armazenados no Data Lake e estejam disponíveis quando necessário.
O Data Warehouse, por sua vez, hospeda apenas dados processados. Por isso, todos os dados que
constam ali são empregados para uma finalidade específica na organização.
USUÁRIOS: CIENTISTAS DE DADOS X PROFISSIONAIS DE
NEGÓCIO
Data Lakes costumam ser difíceis de navegar para quem não está familiarizado com dados não
processados. Dados brutos e não estruturados geralmente requerem as habilidades de um cientista de
dados e ferramentas especializadas para manipulá-los, entendê-los e traduzi-los para qualquer uso
específico.
Já aqueles processados são usados em gráficos, planilhas e tabelas para que a maioria dos
funcionários de uma empresa (senão todos) possa lê-los. Tais dados, assim como os armazenados em
Data Warehouses, requerem apenas que o usuário esteja familiarizado com o tópico representado.
FLEXIBILIDADE
A arquitetura dos Data Lakes não tem estrutura, o que os torna mais fáceis de acessar e alterar. Ainda,
todas as alterações em seus dados podem ser feitas rapidamente, pois os Data Lakes têm
pouquíssimas limitações.
Data Warehouses são, por design, mais estruturados. Um grande benefício da arquitetura deles é que o
processamento e a estrutura dos dados tornam os próprios dados mais fáceis de decifrar. Em
contrapartida, as limitações de sua estrutura tornam os Data Warehouses mais difíceis de manipular.
PALAVRAS FINAIS
Não há escolha certa ou errada entre Data Lakes e Data Warehouses. As organizações geralmente
precisam de ambos.
Os Data Lakes nasceram da necessidade de aproveitar o Big Data e se beneficiar de dados brutos,
granulares, estruturados e não estruturados, principalmente para o aprendizado de máquina, embora
ainda haja a necessidade da criação de Data Warehouses para o uso analítico por usuários de negócio.
Um exemplo dessa adequação do uso de Data Lakes no contexto de Big Data são os dispositivos
conectados e IoT. Tanto os dados produzidos por uma rede de sensores domésticos, como câmeras de
monitoramento e wearables, quanto os produzidos em ambientes industriais — especialmente no que
diz respeito à instrumentação e ao controle de sensores e dispositivos que envolvem as tecnologias de
nuvem — tendem a ser capturados e armazenados em Data Lakes.
Outro exemplo é o uso de Data Lakes no setor de saúde. Mesmo tendo sido utilizados por muitos anos,
os Data Warehouses nunca tiveram muito sucesso nesse setor devido à natureza não estruturada dos
dados dessa área (anotações médicas, dados clínicos, imagens etc.) e à necessidade de insights em
tempo real.
Por permitirem a combinação de dados estruturados e não estruturados, os Data Lakes costumam ser
mais adequados para empresas da área de saúde. Outra área na qual eles apresentam bons resultados
é a indústria de transporte, principalmente no gerenciamento da cadeia de suprimentos.
IOT
Sigla de internet of things, ou seja, objetos conectados à internet, capazes de reunir e transmitir dados.
WEARABLES
Dispositivos “vestíveis” inteligentes, como óculos e relógios.
javascript:void(0)
javascript:void(0)
 EXEMPLO
A capacidade de previsão propiciada por dados flexíveis de um Data Lake no exame de dados de formulários
dentro de uma cadeia de transporte pode trazer benefícios, como a redução de custos.
Em contrapartida, a natureza estruturada de grande parte dos dados do setor financeiro faz com que os
Data Warehouses geralmente sejam o melhor modelo de armazenamento, já que eles podem ser
estruturados para serem acessados por toda a empresa — e não apenas por cientistas de dados.
RISCOS DE SUA ADOÇÃO
As definições mais recentes de Big Data adicionam mais 2 Vs além dos 3 iniciais (volume, velocidade e
variedade):
Veracidade
Valor
Data Lakes endereçam muito bem os 3 Vs iniciais, pois eles foram concebidos justamente para isso. As
plataformas conseguem absorver grandes volumes de dados gerados em alta velocidade.
Além disso, por definição, eles aceitam qualquer dado. Os dados simplesmente são colocados no Data
Lake. No curto prazo, isso traz um benefício para TI, pois não é necessário investir tempo para entender
de antemão como eles serão usados. A obtenção de valor dos dados fica, assim, sob a responsabilidade
dos usuários finais do negócio.
Há tecnologias que podem e devem ser aplicadas ou adicionadas aos Data Lakes, mas, sem haver pelo
menos um esforço mínimo de governança da informação, lagos construídos podem acabar se tornando
pântanos de dados (data swamps): coleções de repositórios de dados desconectados ou silos de
informações em um só lugar.
 ATENÇÃO
Um risco importante é o de haver esforços repetitivos para a obtenção de valor dos dados em função da
incapacidade de determinar a qualidade dos dados ou pela ausência de metadados (especialmente de
linhagem) das descobertas realizadas anteriormente por outros usuários ou analistas que encontraram valor
ao utilizarem os mesmos dados do lago.
Sem metadados descritivos e um mecanismo para mantê-los, o Data Lake corre o risco de se
transformar em um pântano de dados. Sem esses metadados, cada uso subsequente dos dados
significará que os analistas terão de começar do zero.
Outro risco diz respeito à segurança e ao controle de acesso. Geralmente, os dados são colocados no
Data Lake sem uma supervisão de seu conteúdo.
 EXEMPLO
Muitos Data Lakes podem estar sendo usados para armazenar dados cujos requisitos regulatórios e de
privacidade provavelmente representam uma exposição ao risco, especialmente com a entrada em vigor da
Lei Geral de Proteção de Dados Pessoais (LGPD).
Os recursos de segurança das tecnologias de Data Lake ainda são embrionários. Essas questões não
serão abordadas se forem deixadas para o pessoal que não é de TI.
Por fim, os aspectos de desempenho não devem ser negligenciados. Ferramentas e interfaces de dados
simplesmente não podem funcionar no mesmo nível de desempenho em um repositório de uso geral
(Data Lake) que funciona em uma infraestrutura otimizada e construída para um propósito específico
(Data Warehouse).
FUNCIONAMENTO
Agora que já entendemos bem o que são Data Lakes, examinaremos como eles funcionam. Seus dados
seguem um ciclo de vida que pode ser dividido em três fases:

javascript:void(0);
INGESTÃO DE DADOS
Fase inicial em que os dados brutos são extraídos das fontes e armazenados no Data Lake.
ACOMODAÇÃO/ADAPTAÇÃO DOS DADOS
Fase de carga e transformação dos dados em formatos adequados para processamento e uso pelos
usuários.


CONSUMO DE DADOS
Etapa em que os dados presentes no Data Lake são finalmente consumidos de diversas formas.
Analisaremos detalhadamente cada uma dessas fases a seguir:
INGESTÃO DE DADOS
Nesta fase, ocorre a captura dos dados com algum processamento a fim de que eles estejam prontos
para serem processados na fase posterior. Além disso, já nessa etapa, é necessário tomar algumas
ações de governança de dados (data governance) e cuidados para preservar a segurança deles.
GOVERNANÇA DE DADOS (DATA GOVERNANCE)
javascript:void(0)
Processos que, baseados em padrões e políticas internas, são implementados pelas organizações para
garantir a qualidade dos dados por todo o ciclo de vida deles.
CAPTURA DE DADOS
Ela deve considerar alguns aspectos, como, por exemplo:
CONECTIVIDADE ABRANGENTE
Conecta fontes de dados internas (on premises) e externas à organização, híbridas ou na nuvem.
PROCESSAMENTO EM BATCH OU STREAMING
Lida tanto com dados históricos quanto com aqueles em tempo real, além de processar os fluxos de
dados assim que eles chegam ao Data Lake, inclusive para uso em análises avançadas e ciência de
dados.
ESCALAR COM VOLUME E VARIEDADE
Rapidamente adiciona novas fontes de dados, como o fluxo de cliques na web, de mídias sociais e
smartphones, por exemplo.
POSSÍVEIS PROBLEMAS
Em contrapartida, é importante evitar alguns problemas que podem vir a ocorrer na fase de captura de
dados. Elencaremos alguns deles a seguir:
FERRAMENTAS FRAGMENTADAS
Ouso de muitas ferramentas pode levar à criação de novos silos.
CODIFICAÇÃO MANUAL (HAND CODING)
Essa codificação reduz a capacidade de escalar e de adicionar novas fontes na velocidade adequada
para as necessidades de negócio.
TAREFAS DE LIMPEZA
Antes de serem armazenados de forma persistente, os dados têm de ser limpos e validados. A limpeza
deles é uma das atividades que consome mais tempo, mas é essencial que dados com falhas sejam
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
removidos e que os faltantes sejam tratados, sendo preferencialmente preenchidos.
As tarefas de limpeza incluem:
Remoção de dados estranhos (ruídos).
Preenchimento de dados ausentes.
Adequação dos dados conforme os padrões de dados.
Mascaramento de dados sensíveis/privados.
ARMAZENAMENTO
Uma vez limpos, os dados precisam ser validados por meio de testes antes de serem armazenados de
forma persistente no Data Lake. Há diversas tecnologias que realizam o armazenamento deles de
variadas maneiras.
De forma resumida, descreveremos as seguintes tecnologias:
BANCOS DE DADOS “TRADICIONAIS”
Entre tais bancos, estão:
Linha: Sistemas Gerenciadores de Bancos de Dados (SGBDs) relacionais, como Oracle, MS SQL
Server e My SQL.
Colunar: Similares aos SGBDs tradicionais, mas otimizados para colunas, como SnowFlake, Redshift e
Infobright.
NO-SQL (NOT ONLY SQL)
Bancos não relacionais com consistência eventual e escalabilidade horizontal, como MongoDB,
Cassandra e Riak.
HADOOP
Framework para processamento de dados distribuído e capacidade de lidar com dados com grande
volume, velocidade e variedade.
GRAFOS
Armazenamento em triplas (sujeito-predicado-objeto) baseado na teoria dos grafos, como Neo4J e
AlegroGraph.
javascript:void(0)
FILE SYSTEM (SISTEMA DE ARQUIVOS)
Possibilidade de armazenar arquivos de qualquer formato.
TEORIA DOS GRAFOS
Teoria matemática com relações entre os elementos de determinado conjunto.
ACOMODAÇÃO/ADAPTAÇÃO DOS DADOS
Esta é a etapa na qual é feita uma junção abrangente e inteligente dos dados que, capturados na etapa
anterior, formarão um conjunto “orgânico” capaz de, visando à extração de valor, ser consumido na
etapa seguinte.
Ocorre essencialmente o armazenamento de dados brutos no menor nível de granularidade. Ele poderá
ser processado depois para atender a necessidades específicas.
Duas atividades de processamento típicas dessa etapa são:
TRANSFORMAÇÃO DE DADOS
Atualiza o formato ou os valores para chegar a um resultado bem definido ou para tornar os dados mais
facilmente compreendidos por um público mais amplo.
ENRIQUECIMENTO DOS DADOS
Adiciona e conecta os dados a outras informações relacionadas para fornecer novas perspectivas e
insights.
 ATENÇÃO
É importante automatizar o máximo possível o processamento dos dados. Para isso, é necessário empregar
metadados confiáveis. E não conseguimos gerenciá-los de forma efetiva sem a governança de dados.
javascript:void(0)
javascript:void(0)
CONSUMO DOS DADOS
Esta etapa corresponde à extração de valor dos dados. O ciclo da extração de valor dos dados é
descrito, informa Rowley (2007, p. 163-180), na pirâmide DIKW:
DATA (DADOS) → INFORMATION (INFORMAÇÃO) →
KNOWLEDGE (CONHECIMENTO) → WISDOM
(SABEDORIA)
Há diversas formas de gerar valor a partir do consumo de dados. Algumas delas são exemplificadas a
seguir:
Agregações de dados (indicadores de processo/KPIs e métricas) em ferramentas de business
intelligence (BI).
Visualização em painéis e relatórios.
Descoberta de tendências e previsões nas ferramentas analíticas (analytics).
Uso em aprendizado de máquina (machine learning) e ciência de dados (data science).
Alimentação de feeds de dados.
IMPLEMENTAÇÃO
Veremos agora três aspectos importantes para a implementação de Data Lakes:
ESTRUTURAS DE ARMAZENAMENTO
Uma abordagem interessante para lidar com os 5 Vs (volume, velocidade, variedade, veracidade e valor)
em implementações de Data Lakes é ter uma arquitetura com pelo menos duas camadas (ou zonas) de
armazenamento, embora haja — como veremos a seguir — outras cuja aplicação é possível e até
recomendável.
PRIMEIRA CAMADA
Ela funciona com uma área de aterrissagem (landing zone ou staging area) na qual os dados são
armazenados inicialmente na etapa de ingestão de dados. Por ter de lidar mais diretamente com os três
primeiros Vs (volume, velocidade e variedade), a dupla Hadoop + HDFS costuma ser uma escolha
adequada para a implementação da landing zone.
SEGUNDA CAMADA
Também conhecida como golden layer, ela contém os dados prontos para consumo. Para chegar a essa
camada, é preciso considerar 2 Vs (velocidade e valor).
Os dados precisam ser confiáveis para que:
Seu consumo seja efetivo.
A tomada de decisão não seja prejudicada.
HDFS
Sigla de Hadoop distributed file system ou sistema de arquivos distribuído do Hadoop.
Para que os dados nessa camada tenham essas duas qualidades, é preciso haver uma governança de
dados. O gerenciamento de metadados é uma parte fundamental dessa governança, a qual, por sua
vez, precisa ser observada nas implementações de Data Lakes.
Há três tipos essenciais de metadados a considerar:
Esquemáticos: Mantêm metadados sobre as estruturas dos dados.
Semânticos: Mantêm metadados sobre o significado dos dados.
Linhagem dos dados: Ela mantém os metadados relativos à origem e às transformações
processadas nos dados, mantendo ainda a capacidade de auditá-los e permitindo consultas
“atuais” e “retroativas”.
OUTRAS CAMADAS
Além dessas duas camadas, outras podem ser acrescentadas na organização do Data Lake. A
arquitetura de referência para Data Lakes de Zaloni recomenda a adoção de quatro zonas (camadas)
javascript:void(0)
javascript:void(0)
mais uma sandbox, como podemos ver na imagem a seguir:
Imagem: Sharma, 2018, p. 16.
 Arquitetura de referência de Data Lake de Zaloni.
ARQUITETURA DE REFERÊNCIA
Estrutura à qual as organizações podem se referir para:
1. Entender as práticas recomendadas da indústria.
2. Rastrear um processo e as etapas necessárias.
3. Derivar um modelo para solução.
4. Compreender os componentes e as tecnologias envolvidos.
ZONA TRANSITÓRIA (TRANSIENT ZONE)
Trata-se de uma zona de aterrissagem das medidas de segurança que podem ser aplicadas antes de os
dados serem armazenados ou acessados, atendendo, assim, aos requisitos de conformidade com as
regulamentações de proteção deles.
ZONA DE DADOS BRUTOS (RAW DATA)
Depois que as verificações de qualidade e as transformações de segurança foram realizadas na zona
transitória, os dados são carregados na zona de dados brutos para armazenamento. No entanto, em
algumas situações, a transitória não se faz necessária; assim, a de dados brutos é o início da jornada do
Data Lake.
Dentro dessa zona, os dados podem ser mascarados ou tokenizados conforme necessário, sendo
adicionados a catálogos e aprimorados com metadados. Como são armazenados nela em caráter
permanente e em sua forma original, eles são conhecidos como “fonte única da verdade”.
CIENTISTAS DE DADOS E ANALISTAS DE NEGÓCIO
PODEM MERGULHAR NESSA ZONA PARA
DESCOBRIR CONJUNTOS DE DADOS.
ZONA REFINADA (REFINED DATA)
Nessa zona, os dados passam por suas últimas etapas antes de serem usados para derivar insights,
sendo integrados em um formato comum para a facilidade de uso. Além disso, os dados passam por:
Uma possível detokenização.
Verificações de qualidade adicionais.
Gerenciamento do ciclo de vida.
Isso garante que eles estejam em um formato a partir do qual possam ser facilmente usados para a
criação de modelos. Os dados frequentemente são transformados para atender às necessidades de
negócio específicas nessa zona.
ZONA CONFIÁVEL (TRUSTED DATA)
Ela importa dados da zona de dados brutos. É nessa zona que eles são alterados para que estejam em
conformidade com todas as políticas governamentais e da indústria, bem como verificados quanto à sua
qualidade.
As organizações executam aqui métodos de limpeza e validaçãode dados padrão. A zona confiável é
baseada em dados brutos (oriundos da zona de dados brutos), que são transformados para se adequar
às necessidades de negócio.
Frequentemente, os dados dessa zona são conhecidos como uma "versão única da verdade". Tal
repositório confiável pode conter dados mestre e dados de referência.
Uma organização precisa garantir que os dados mantidos na zona confiável estejam atualizados,
usando, para tal, mecanismos de change data capture (CDC).
javascript:void(0)
javascript:void(0)
javascript:void(0)
SANDBOX
Essa é parte integrante de um Data Lake, porque permite que cientistas e gerentes de dados criem
casos de uso exploratórios ad hoc sem a necessidade de envolver o departamento de TI ou de dedicar
fundos para criar ambientes adequados nos quais se testam os dados.
Os dados podem ser importados para a sandbox de qualquer uma das zonas, bem como diretamente da
fonte. Isso permite que as empresas explorem como certas variáveis podem afetar os resultados de
negócio, podendo, portanto, obter mais insights para ajudá-las a tomar decisões de gestão de negócio.
Alguns desses insights podem ser enviados diretamente de volta para a zona de dados brutos,
permitindo que os dados derivados atuem como dados de origem e, assim, fornecendo mais subsídios
para os cientistas de dados e analistas de negócio.
DADOS MESTRE
Compilação dos conjuntos de dados básicos limpos e validados.
DADOS DE REFERÊNCIA
Versão única da verdade para conjuntos de dados combinados mais complexos.
MECANISMOS DE CHANGE DATA CAPTURE (CDC)
Mecanismos que monitoram as alterações dos dados nas fontes e viabilizam a replicação dessas
alterações para outros ambientes.
SEGURANÇA DE DADOS
Assim como os demais ativos de dados corporativos, Data Lakes também devem garantir que os dados
sensíveis e pessoais estejam seguros. Com a entrada em vigor das leis de proteção de dados (LGPD no
Brasil), é preciso garantir também que os dados pessoais possam ser removidos (desabilitados) ou
atualizados mediante solicitação.
A proteção de dados requer:
Políticas de acesso.
Efetiva aplicação dessas políticas.
Criptografia.
Técnicas de manutenção de registros.
Existem três estados de dados a serem considerados:
DADOS EM REPOUSO
Dados armazenados em algum componente, estando prontos para uso durante todo o ciclo de vida do
Data Lake.
DADOS EM MOVIMENTO
Eles se movem por meio do próprio ciclo de vida do Data Lake.
DADOS EM USO
Talvez o estado mais crítico, ele contempla os dados nos elementos voltados para o usuário do ciclo de
vida do Data Lake.
 ATENÇÃO
Em todos os estados, é preciso garantir que os dados estejam seguros.
BOAS PRÁTICAS EM PROJETOS DE DATA LAKE
Há algumas boas práticas, tanto tecnológicas quanto de gestão, que podem — e devem — ser
consideradas para aumentar a chance de sucesso em Data Lakes.
Veremos duas delas a seguir:
javascript:void(0)
javascript:void(0)
javascript:void(0)
BOAS PRÁTICAS TECNOLÓGICAS
Trata-se das características técnicas necessárias em um projeto desse tipo. Um Data Lake deve:
Ser adaptável
Servir apenas para inserção
Ser capaz de prover opções escaláveis
Permitir automação de tarefas
Prover dados histórico auditáveis
SER ADAPTÁVEL
É importante que novas fontes de dados possam ser adicionadas ao modelo de dados existente sem
muito impacto.
SERVIR APENAS PARA INSERÇÃO
Isso vale especialmente para tecnologias de Big Data cujas atualizações e remoções de dados são
custosas.
SER CAPAZ DE PROVER OPÇÕES ESCALÁVEIS
As infraestruturas híbridas podem oferecer recursos mais abrangentes.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
PERMITIR AUTOMAÇÃO DE TAREFAS
Os metadados podem, em vários aspectos, conduzir à automação da movimentação dos dados.
PROVER DADOS HISTÓRICO AUDITÁVEIS
Esse é um ponto-chave da linhagem de dados.
Como vimos, a ideia central em um Data Lake é ter um único local para armazenar todos os dados da
organização, desde os brutos até os transformados, para que eles sejam então usados a fim de atender
a várias necessidades de negócio, como relatórios, visualizações, analytics e aprendizado de máquina,
por exemplo.
Adquirir uma plataforma na nuvem e colocar todos os dados (brutos) da organização nela não é a parte
difícil. O mais complicado é fazer com que eles estejam corretos e sejam efetivamente usados para
atender às necessidades do negócio.
 SAIBA MAIS
Em 2016, o grupo Gartner estimou que 60% dos projetos de Big Data falham. Um ano depois, de acordo com
Nick Heudecker, essa estimativa havia sido muito conservadora. E qual era a taxa de falha real?
“Aproximadamente 85%”, disse Nick (ASAY, 2021).
BOAS PRÁTICAS DE GESTÃO
Não podemos deixar de mencionar a importância da governança de dados. A falta dessa governança
pode limitar o uso dos Data Lakes.
 EXEMPLO
Se forem armazenados dados sensíveis sem o devido tratamento, o acesso ao Data Lake será concedido
apenas a um pequeno grupo de usuários autorizados. Em contrapartida, se os dados nele não forem
confiáveis, poucos usuários terão interesse em acessá-los. O uso limitado dos Data Lakes também diminui
seus benefícios, impactando negativamente o retorno do investimento.
Listaremos agora os cinco pontos que devem ser considerados para a utilização adequada deles:
1
USAR METADADOS
Metadados são fundamentais para o entendimento dos dados e de sua linhagem.
OTIMIZAR A QUALIDADE DOS DADOS COM CURADORIA,
LIMPEZA E HARMONIZAÇÃO
É preciso empreender esforços em qualidade de dados, assim como em tarefas, por exemplo, limpeza e
harmonização. Para isso, deve-se usar ferramentas adequadas e envolver pessoas com perfil
apropriado, inclusive gestores de dados.
2
3
USAR UM PROCESSO DE GOVERNANÇA DE DADOS
COLABORATIVO
Não é novidade que, para ter dados com qualidade, é necessário haver o engajamento tanto do pessoal
de TI quanto do negócio. Ambos, enfim, precisam trabalhar em parceria.
De acordo com Nuage (2016, tradução livre), “uma abordagem de cima para baixo (top down) para a
governança de dados nunca funciona bem para o engajamento dos usuários. Em vez disso, uma bottom
up, cujos usuários podem modelar os dados à vontade e na qual a TI ainda certifica, protege e os
controla, [tem mais chances de ser efetiva]”.
PROMOVER A GESTÃO DE DADOS UNIFICADA
É importante ter uma estrutura orquestrada para as tarefas de gerenciamento e qualidade de dados com
uma operacionalização consistente e, preferencialmente, uma plataforma única para todos os casos de
uso e papéis envolvidos na gestão de dados (NUAGE, 2016).
4
5
TORNAR OS DADOS ACESSÍVEIS
Para que o Data Lake atinja plenamente seu potencial, é preciso colocar os dados nas mãos de mais
usuários, tornando-os acessíveis. Deve-se ainda implantar ferramentas levando em consideração os
perfis de usuários de negócio com a menor proficiência em tecnologia para que eles consigam:
Acessar o Data Lake de maneira mais fácil e segura.
Usar os dados em seus processos de tomada de decisão.
 DICA
Além de tudo isso, é imprescindível estar preparado para mudanças. O ritmo de crescimento do volume e da
diversidade de dados tende a acelerar. Esse contexto de Big Data demanda uma plataforma que seja capaz
de fornecer dados para uma tomada de decisões de forma tempestiva.
BOAS PRÁTICAS DE IMPLEMENTAÇÃO DE
DATA LAKES
O especialista fará uma descrição de boas práticas a serem adotadas e comentários sobre a arquitetura
de referência.
VERIFICANDO O APRENDIZADO
MÓDULO 2
 Reconhecer as técnicas de streaming usadas para o processamento de dados ilimitados
FONTES DE DADOS
Mesmo fora do ambiente de TI, grande parte das pessoas atualmente já deve ter ouvido falar de
streaming. A popularização de serviços de áudio e de plataformas de vídeo mudou tanto a forma como
consumimos música e vídeo quanto o próprio negócio de distribuição desses serviços.
Por serem grandes produtores (fontes) de dados, tais plataformas fazem parte do contexto de Big Data.Isso é possível de se constatar no infográfico do módulo 1 denominado Dados gerados a cada minuto
em 2020.
Akidau, Chernyak e Lax (2017) consideram estas as principais razões para que as organizações
invistam em streaming de dados:
Devido à necessidade de ter dados cada vez mais recentes, mudar para o streaming é uma boa
maneira de obter uma latência mais baixa.
Os enormes volumes dos conjuntos de dados ilimitados são mais bem endereçados por sistemas
projetados com essa finalidade.
Ao processar dados rapidamente, assim que eles chegam, a distribuição da carga de trabalho fica
mais uniforme ao longo do tempo, o que torna o consumo de recursos mais uniforme e previsível.
STREAMING DE DADOS
CONCEITO
Mas o que é exatamente um streaming? Vamos descobrir isso neste módulo. Porém, para
compreendermos melhor seu conceito, primeiramente precisamos entender o significado do
processamento de dados em batch (lote).
Tarefas computacionais (jobs) podem ser executadas em processos ou threads. Quando a execução
pode ser feita sem a interação do usuário final ou agendada, ela é chamada de batch. Por exemplo, é o
caso quando um programa que lê um ou mais arquivos grandes e gera um relatório.
Antes de obtermos a uma definição mais precisa acerca do streaming de dados, examinaremos um
pouco melhor como a distribuição de música evoluiu nas últimas décadas:
javascript:void(0)
THREADS
Divisão de um processo em duas ou mais atividades que podem ser realizadas ao mesmo tempo.

ANOS 1990
A música era basicamente distribuída em compact disk (CD). Todas as faixas de álbum eram gravadas
em um único CD e, em seguida, distribuídas.
ANOS 2000
As plataformas peer-to-peer se tornaram populares: a distribuição de música não estava mais amarrada
ao suporte físico (CD) nem ao conceito de álbum. Ela acontecia por faixa/música.


ANOS 2010
As plataformas de streaming de música se popularizaram. Uma diferença crucial do consumo via
streaming é que os dados (músicas) não precisam ser totalmente baixados antes que se possa começar
a processá-los (consumi-los).
O streaming se trata, portanto, de outra forma de processar conjuntos de dados (datasets). Em seu
processamento de dados, não existe uma noção de fim. A ideia é que os dados continuarão chegando
indefinidamente.
 ATENÇÃO
O streaming não é melhor que o batch. Eles são apenas duas formas diferentes de processar dados. Cada
uma delas possui suas particularidades e aplicações.
Podemos aproveitar, portanto, a definição de streaming tecida por Akidau (2015, tradução livre): “um
tipo de motor de processamento de dados projetado para tratar conjuntos de dados infinitos”.
TEMPO DO PROCESSAMENTO X TEMPO DO EVENTO
Para entender o processamento de dados ilimitados, deve-se estabelecer dois domínios de tempos
fundamentais (AKIDAU, 2015):
TEMPO DE EVENTO
“Tempo do evento (event time) – momento em que os eventos realmente ocorreram”.
TEMPO DE PROCESSAMENTO
“Tempo do processamento (processing time) – momento em que os eventos são observados no
sistema”.
 ATENÇÃO
É preciso tomar cuidado para que o termo “tempo de processamento” não seja mal interpretado, sendo visto
como o tempo gasto no processamento de um evento. O tempo de processamento se refere, na verdade, ao
tempo (horário) em que o evento é percebido pelo sistema.
Há inúmeros casos de uso cujos horários dos eventos são fundamentais, tais como:
Sistemas de transações financeiras em geral (a operação em Bolsa de Valores).
javascript:void(0)
javascript:void(0)
Sistemas de transações comerciais (pagamentos por cartão de crédito).
Sistemas de monitoramento industrial (baseados em dados de sensores).
Sistemas de monitoramento de comportamento de usuários (baseados em suas interações).
Idealmente, os eventos seriam processados assim que ocorressem, não havendo uma diferença entre o
tempo do evento e o de processamento. Entretanto, isso não é possível.
SEMPRE EXISTE UMA DIFERENÇA (ATRASO) DO
TEMPO DE PROCESSAMENTO EM RELAÇÃO AO
TEMPO DO EVENTO. PIOR AINDA: NA MAIORIA DOS
CASOS, ESSA DIFERENÇA NÃO É CONSTANTE, O
QUE TORNA O PROCESSAMENTO MAIS COMPLEXO.
Diversas causas podem acarretar essa diferença entre ambos. Elas podem estar relacionadas às
seguintes questões:
Uso de um recurso compartilhado, como memória, CPU ou rede, por exemplo.
As características dos próprios dados, como a taxa de transferência dos dados, dados de usuários
que estiveram off-line por algum tempo e se reconectaram ou gargalos decorrentes do aumento
incomum no volume de dados.
O gráfico adiante ilustra o progresso do tempo de evento em relação ao de processamento em um
sistema do mundo real:
 Gráfico: Mapeamento do domínio de tempo.
Extraído de: Akidau, 2015, oreilly.com, adaptado por Herbet de Souza Cunha.
A linha cinza tracejada representa o que ocorreria em um mundo ideal: o tempo do processamento e o
do evento seriam iguais, ou seja, os eventos seriam processados no momento em que ocorressem.
Nesse gráfico, o sistema fica um pouco atrasado no início e aproxima-se do ideal no meio, ocorrendo um
atraso maior próximo ao final.
A diferença entre o tempo do processamento e o do evento, a discrepância, representada no gráfico
pela distância horizontal entre o ideal (linha tracejada) e a realidade (linha vermelha), é basicamente o
atraso introduzido pelo pipeline de processamento.

Nos casos em que o processamento deve considerar os tempos dos eventos, os dados não podem ser
analisados apenas no contexto em que são observados, tendo como base, portanto, os tempos de
processamento. Isso não deve ser feito, pois não é possível mapear diretamente o tempo do evento a
partir do tempo do processamento.

A forma usual de lidar com a natureza infinita dos dados ilimitados é dividindo-os em pedaços finitos de
tempo (também conhecidos como janelas). Entretanto, há algumas limitações no uso delas.
Não é possível definir as janelas pelo tempo do processamento para analisar dados no contexto dos
tempos de evento. Isso só seria possível se houvesse uma correlação consistente entre os dois tempos.
A alternativa é usar janelas por tempo do evento.
A desordem e a variação na discrepância, comuns no contexto de dados ilimitados, levam ao problema
da completude: a impossibilidade de estabelecer quando todos os dados para determinado tempo de
evento foram observados.
Defendida por Akidau, Chernyak e Lax, uma abordagem mais realista atesta que:
DEVEMOS PROJETAR FERRAMENTAS QUE NOS PERMITAM
VIVER NO MUNDO DE INCERTEZAS IMPOSTO POR ESSES
CONJUNTOS DE DADOS COMPLEXOS EM VEZ DE TENTAR
TRANSFORMAR DADOS ILIMITADOS EM LOTES FINITOS DE
INFORMAÇÕES QUE EVENTUALMENTE SE TORNAM
COMPLETAS.
(AKIDAU; CHERNYAK; LAX, 2017, tradução livre)
A completude, portanto, pode ser vista como otimização — e não como necessidade.
DADOS ILIMITADOS (UNBOUNDED DATA) X
PROCESSAMENTO DE DADOS ILIMITADOS X
STREAMING
CONCEITOS FUNDAMENTAIS
Antes de se aprofundar nos padrões de processamento de dados, é importante que você entenda a
diferença entre alguns conceitos:
DADOS ILIMITADOS
Para Akidau (2016, tradução livre), eles são:
“[...] conjuntos de dados virtualmente infinitos cujo final não é conhecido. Mais dados continuarão a
chegar indefinidamente. É comum esses tipos de dados serem chamados de ‘dados streaming’
(streaming data), embora não sejam a mesma coisa. Streamings, assim como lote, são mecanismos
para processamento de dados que não caracterizam os dados em si”.
PROCESSAMENTO DE DADOS ILIMITADOS
Trata-se de uma forma contínua de processar dados ilimitados. Isso pode ser feito tanto por um
mecanismo de streaming quanto pelo uso de mecanismos de lote (executados repetidas vezes).
STREAMING
Para Akidau (2015, tradução livre), ele é o “motor de execução projetado para processar conjuntos de
dados ilimitados”.
PADRÕES DE PROCESSAMENTO DE DADOS
A seguir, conheceremos detalhadamente os padrões de processamento de dados:
DADOS LIMITADOS
Processar dados limitados é mais simples em comparação com os ilimitados.No diagrama adiante, o conjunto de dados desorganizados (à esquerda) é submetido a um mecanismo
de processamento de dados (MapReduce) para a obtenção de um conjunto daqueles organizados com
maior valor (menor entropia).
 Processamento de dados limitados com um batch engine clássico.
Como podemos conhecer todo o conjunto de dados, já que eles são limitados, o processamento, de
forma geral, é simples. Os ilimitados podem ser processados com motores de execução batch
tradicionais ou de streaming (projetados para dados ilimitados).
DADOS ILIMITADOS – BATCH
Embora não sejam projetados para dados ilimitados, batch engines também são usados para processar
tais dados. Nesse tipo de abordagem, os ilimitados são divididos em vários conjuntos de dados limitados
para serem processados em lote.
Para isso, os dados de entrada geralmente são divididos em janelas de tamanho fixo, simulando, assim,
um conjunto daqueles limitados e processados por meio de execuções sucessivas em batch.
 ATENÇÃO
As janelas fixas dividem o tempo em partes de tamanho fixo. Quando essas partes são aplicadas de maneira
uniforme a todo o conjunto de dados, obtém-se um exemplo de janelas alinhadas. Elas poderão ser
desalinhadas se desejarmos aplicar as fixas a diferentes subconjuntos dos dados, como, por exemplo, por
chave. Essa estratégia pode ser adotada para distribuir a carga de conclusão da janela de maneira mais
uniforme ao longo do tempo (AKIDAU, 2015).
Para alguns conjuntos de dados, essa divisão pode ser simples em virtude da maneira como os dados
são produzidos. É o caso de logs, por exemplo, cujos dados dos eventos podem ser armazenados em
diretórios e arquivos que reflitam as janelas de tempo correspondentes à ocorrência desses eventos.
Entretanto, ainda poderá haver problemas de completude se a gravação dos logs atrasar devido aos
recursos utilizados, como partição de rede, ou devido às próprias fontes dos dados, por exemplo, se os
eventos vierem de dispositivos móveis.
 Processamento de dados ilimitado por meio de janelas fixas ad hoc com um mecanismo de lote
clássico.
SESSÕES (SESSIONS)
Sessões são janelas de processamento definidas por períodos de atividade encerrados por um intervalo
de inatividade. Essa abordagem é mais adequada para o processamento por um mecanismo de
streaming.
 DICA
As sessões são um tipo de janela dinâmica. Elas são definidas por uma sequência de eventos encerrada
após um intervalo de inatividade (no qual novos eventos não são observados) superior a algum limite de
tempo estabelecido previamente.
Esse tipo de janela é muito utilizado para analisar o comportamento de usuário, agrupando uma série de
eventos relacionados ao longo do tempo, como uma sequência de cliques em uma mesma sessão, por
exemplo. O comprimento da sessão não é definido a priori, pois depende dos dados envolvidos.
O uso de mecanismo batch para processar dados ilimitados por sessões pode incorrer na divisão de
uma sessão em lotes diferentes, conforme indicam as marcas vermelhas do diagrama a seguir:
 Processamento de dados ilimitado em sessões por meio de janelas fixas ad hoc com um mecanismo
de lote clássico.
A redução no número de divisões pelo aumento do tamanho dos lotes implica uma maior latência. A
alternativa de juntar as partes de uma sessão em lotes diferentes aumenta a complexidade do
processamento (AKIDAU, 2015).
DADOS ILIMITADOS – STREAMING
Uma característica dos conjuntos de dados ilimitados é que eles raramente são observados na mesma
ordem de seus tempos de eventos. Além disso, a discrepância dos tempos dos eventos em relação aos
dos processamentos é variante.
Desse modo, para analisá-los no contexto em que ocorreram, é preciso reorganizá-los a fim de que eles
reflitam a ordem de seus tempos de evento. De acordo com Akidau (2015, tradução livre), “as
abordagens de processamento para lidar com esses dados podem ser caracterizadas em quatro
grupos:
1. Processamento agnóstico em relação ao tempo.
2. Algoritmos de aproximação.
3. Janelas por tempo do processamento (windowing by processing time).
4. Janelas por tempo do evento (windowing by event time)”.
Versaremos a seguir sobre cada um desses grupos. No caso dos dois últimos, precisaremos explorar
antes o conceito de janelas (windowing).
1 - PROCESSAMENTO AGNÓSTICO EM RELAÇÃO AO
TEMPO
Na abordagem de processamento agnóstico em relação ao tempo, toda a lógica de processamento é
feita em função dos próprios dados independentemente de seus tempos de evento, os quais, nesses
casos, são irrelevantes.
Nessa abordagem, tanto mecanismos de streaming quanto mecanismos batch podem ser utilizados. No
uso de batch, os dados ilimitados são divididos em uma sequência arbitrária de conjuntos de dados
limitados e processados de forma independente.
São exemplos de processamento agnóstico em relação ao tempo:
FILTRAGEM DE DADOS
Imagine uma análise de logs de tráfego na web em que se deseja filtrar apenas o tráfego de
determinados domínios ou de certas regiões (com base nos endereços IP). Os dados serão filtrados
com base em um atributo que não depende do tempo do evento nem da ordem em que eles são
percebidos. O resultado da filtragem é o mesmo.
JUNÇÕES INTERNAS (INNER-JOINS)
No caso das inner-joins de duas fontes de dados ilimitadas, o resultado da junção só é calculado quando
um elemento das duas fontes é observado. O valor percebido de uma fonte pode ser persistido em
buffer até que o da outra seja observado, etapa em que a inner-join será processada e o resultado,
emitido. Pode ser necessário algum mecanismo de coleta de lixo para junções parciais não concluídas,
o que acaba dependendo indiretamente do tempo.
JUNÇÕES EXTERNAS (OUTER-JOINS)
Aqui reaparece o problema da completude: após o valor de um elemento ser observado de uma das
fontes, não sabemos se ele também será observado da outra fonte. Nesse caso, podemos introduzir um
tempo limite (time out) para o processamento, ou seja, um elemento de tempo.
2 - ALGORITMOS DE APROXIMAÇÃO
Alguns algoritmos de aproximação, como Top-N e K-means, por exemplo, têm baixa sobrecarga e
podem ser usados para dados ilimitados. Eles processam esses dados de determinada fonte, gerando
uma saída aproximada da esperada/desejada.
Esses algoritmos possuem algum elemento de tempo em seu design, como o decaimento. Como os
dados são processados à medida que são observados, esse elemento, em geral, é baseado no tempo
de processamento.
 Computando aproximações em dados ilimitados.
3 - JANELAS POR TEMPO DO PROCESSAMENTO
(WINDOWING BY PROCESSING TIME)
Como pontuamos acima, precisamos destrinchar alguns conceitos relativos às janelas (windowing). As
outras abordagens para o processamento de dados ilimitados são variações de janelas.
Janelas são divisões de uma fonte de dados (limitada ou ilimitada) em pedaços finitos para o
processamento. Baseadas em limites temporais, elas podem ser aplicadas no domínio do tempo de:
Processamento.
Evento.
O diagrama a seguir ilustra três tipos de janelas:
 Estratégias baseadas em janelas (windowing).
Já falamos sobre duas delas anteriormente (janelas fixas e sessões). Quanto às janelas deslizantes
(sliding), podemos dizer que elas são uma generalização das fixas, sendo definidas por um tamanho e
um período fixo.
Caso o período seja menor que a duração, haverá uma sobreposição das janelas, como no exemplo das
deslizantes da imagem anterior. Já na hipótese de o período ser maior do que a duração, obtém-se uma
janela de amostragem capaz de observar apenas um subconjunto dos dados ao longo do tempo,
deixando alguns “buracos” sem observação. Quando o período for igual ao comprimento, será um caso
de janelas fixas.
“JANELAS DESLIZANTES SÃO NORMALMENTE
ALINHADAS, EMBORA POSSAM SER
DESALINHADAS COMO UMA OTIMIZAÇÃO DE
DESEMPENHO EM CERTOS CASOS DE USO”,
DESTACA AKIDAU (2015, TRADUÇÃO LIVRE).
Usar janelas por tempo de processamento significa basicamente armazenar os dados durante o tempo
de processamento correspondenteao tamanho da janela.
 EXEMPLO
Ao utilizar janelas fixas de um minuto, o sistema armazena em um buffer os dados observados por um minuto
(tamanho da janela). Ao final desse tempo, os dados são enviados para processamento.
 Uso de janelas fixas por tempo do processamento.
As janelas por tempo de processamento apresentam algumas vantagens. Sua implementação é
bastante simples: trata-se de armazenar os elementos em um buffer conforme eles chegam e enviá-los
para o processamento quando a janela fechar. Isso constitui uma estratégia perfeita caso se deseje
inferir informações sobre a fonte à medida que ela é observada.
 EXEMPLO
O cálculo das taxas de solicitações para detectar interrupções em determinado serviço.
A grande desvantagem das janelas por tempo de processamento ocorre nos casos em que os tempos
dos eventos são relevantes e os dados chegam fora da ordem desses tempos. Em fontes de dados
distribuídas no mundo real, é bastante comum que os dados sejam observados em uma ordem diferente
daquela observada em seus tempos de eventos.
Isso é habitual com aplicativos móveis. Os dispositivos móveis podem ficar off-line por diversos motivos.
Elencaremos três possibilidades a seguir:
Fora da área de cobertura.
Em modo avião.
Desligados.
Os dados registrados nesse período só serão observados quando os dispositivos se reconectarem,
podendo haver, com isso, um atraso de horas ou até de dias. Nesses casos, as inferências baseadas
nos tempos de processamento serão inúteis.
Outro problema para as janelas por tempo de processamento ocorre quando a discrepância (diferença
entre o tempo de evento e o de processamento) varia de forma irregular. Isso pode ocorrer por diversos
motivos.
 EXEMPLO
Diminuição da largura de banda ou aumento da latência em uma linha de transmissão.
Nesse caso, as janelas por tempo de processamento observarão uma mistura de dados antigos e atuais
conforme eles forem chegando ao pipeline de processamento. A solução para isso é usar janelas que
sejam robustas em relação aos tempos e à ordem de chegada dos eventos, ou seja, janelas por tempo
do evento.
4 - JANELAS POR TEMPO DO EVENTO (WINDOWING BY
EVENT TIME)
De acordo com Akidau (2015, tradução livre), as “janelas por tempo do evento são usadas para observar
uma fonte de dados em partes finitas que reflitam os tempos em que esses eventos realmente
aconteceram. É o padrão ouro das janelas”.
No exemplo das janelas fixas por tempo do evento (diagrama ao lado), foram usadas janelas de uma
hora. Ele ilustra o caso de dois dados (setas pretas) que chegaram às janelas de tempo de
processamento diferentes das janelas de tempos de eventos às quais eles pertenciam.
 Janelas fixas em janelas por hora do evento.
CASO OS TEMPOS DOS EVENTOS FOSSEM
RELEVANTES E O PROCESSAMENTO OCORRESSE
NAS JANELAS DE TEMPO A QUE PERTENCIAM, OS
RESULTADOS CALCULADOS ESTARIAM
INCORRETOS.
As janelas de tempo de evento podem durar mais que o tamanho da própria janela, o que traz algumas
desvantagens. A necessidade de mais armazenamento em buffer é uma delas, o que não chega a ser
um grande problema devido ao baixo custo relativo. Outra desvantagem mais séria diz respeito à
completude: na maioria dos casos, não é possível saber com certeza quando todos os dados já foram
vistos, e os resultados disso podem ser materializados.
USO DE JANELAS POR TEMPO DE EVENTO
O especialista irá apresentar animações com exemplos do uso de janelas por tempo de evento.
MAIS CONCEITOS DE STREAMING
Há ainda mais quatro conceitos relevantes em streaming que devem ser explorados:
WATEMARKS (MARCAS D'ÁGUA)
Marcas d´água são conceitos relacionados à completude da entrada de dados em função dos tempos do
evento. Elas representam uma forma de medir o progresso a partir da observação da chegada de dados
de uma fonte ilimitada (e sem fim conhecido).
“Uma marca d'água com um valor de tempo X equivale à declaração: todos os dados de entrada com
tempos de evento menores que X foram observados”, afirma Akidau (2016, tradução livre).
As marcas d’água podem ser classificadas em dois tipos:
MARCAS D'ÁGUA PERFEITAS
Seria possível construir marcas d´água perfeitas em um mundo ideal com o completo conhecimento de
todos os dados de entrada. Nesse contexto ideal, não existiriam dados atrasados.
MARCAS D'ÁGUA HEURÍSTICAS
No mundo real, não podemos ter o conhecimento completo de todos os dados de entrada, o que torna
impossível a construção de marcas d´água perfeitas. Nesse caso, usamos as heurísticas.
AS MARCAS D'ÁGUA HEURÍSTICAS PODEM USAR TODAS
AS INFORMAÇÕES DISPONÍVEIS SOBRE AS ENTRADAS
(PARTIÇÕES, ORDENAÇÃO DENTRO DAS PARTIÇÕES, SE
javascript:void(0)
javascript:void(0)
HOUVER, TAXAS DE CRESCIMENTO DOS ARQUIVOS ETC.)
PARA FORNECER UMA ESTIMATIVA DO PROGRESSO DA
FORMA MAIS PRECISA POSSÍVEL. EM MUITOS CASOS,
ESSAS MARCAS D'ÁGUA PODEM SER NOTAVELMENTE
PRECISAS EM SUAS PREVISÕES. MESMO ASSIM, O USO
DE UMA MARCA D'ÁGUA HEURÍSTICA IMPLICA A
POSSIBILIDADE DE OCORRER ERROS, O QUE LEVARÁ A
DADOS ATRASADOS.
(AKIDAU, 2016, tradução livre)
TRIGGERS (GATILHOS)
“TRIGGERS SÃO UM MECANISMO PARA DECLARAR
DADOS QUANDO A SAÍDA DE UMA JANELA DEVE
SER MATERIALIZADA EM RELAÇÃO A ALGUM SINAL
EXTERNO”, AFIRMA AKIDAU (2016, TRADUÇÃO
LIVRE).
Eles funcionam em complemento às marcas d´água, adicionando uma flexibilidade na escolha do
momento em que os resultados devem ser materializados.
Seu emprego também possibilita a materialização dos resultados mais de uma vez, de acordo com a
evolução da janela, o que pode ser usado para fornecer resultados especulativos que vão sendo
refinados com a chegada de novos dados, como cálculo de taxas e médias, por exemplo. Cada
materialização de resultados emitida é chamada de painel da janela.
Os triggers também ajudam a lidar com:
Atrasos dos dados em relação à marca d´água (quando um novo resultado pode ser
materializado).
Revisões (de previsões anteriores) que sejam necessárias com a chegada de novos dados.
Embora os triggers declarem quando um resultado deve ser materializado no tempo do processamento,
essa decisão pode ser tomada com base em acontecimentos em outros domínios, como é o caso do
progresso de marcas d´água no tempo do evento.
Para Akidau (2016), os sinais mais comuns usados para o acionamento dos triggers são:
PROGRESSO DA MARCA D'ÁGUA
Esse acionamento baseado no progresso do tempo do evento pode ser usado para materializar
resultados quando a marca d´agua ultrapassa o final da janela. Ele também pode ser aplicado para
acionar a coleta de lixo sempre que o tempo de vida de uma janela exceder algum limite predefinido.
PROGRESSO DO TEMPO DE PROCESSAMENTO
Como o tempo de processamento progride de forma regular ao contrário do tempo de evento, esse tipo
de acionamento é usado para fornecer atualizações periódicas e regulares, como, por exemplo, a cada
cinco minutos.
CONTAGENS DE ELEMENTOS
Aciona a materialização dos resultados quando uma quantidade finita de elementos é observada em
uma janela.
PONTUAÇÕES
Um tipo de acionamento que depende de alguma característica dos dados. Quando um registro ou
atributo é observado (como um elemento EOF, por exemplo), a materialização dos resultados é
acionada.
EOF
Sigla de End Of File, EOF é uma designação que sinaliza o fim do arquivo ou fonte de dados. É uma
condição que, ao ser atingida, indica que não há mais dados a serem lidos de uma dataset.
“Além de triggers simples, que disparam com base em sinais concretos, também existem triggers
compostos, que permitem a criação de uma lógica mais sofisticada, como repetições, conjunções,
disjunções e sequências”, completa Akidau (2016, tradução livre).
javascript:void(0)
 COMENTÁRIO
Em muitos casos nos quais, ao longo do tempo, os triggers produzem vários painéis de uma mesma janela,
surge a necessidade de relacionar os resultados desses painéis. Exploraremos mais à frente as formas de
relacioná-los.
ACUMULAÇÃO
“Um modo de acumulação especifica a relação entre vários resultados observados namesma janela”,
pontua Akidau (2016, tradução livre). Aqueles observados em uma mesma janela podem ser
completamente independentes entre si, assim como pode haver uma sobreposição entre eles.
Dos diferentes modos de acumulação, destacaremos os seguintes:
DESCARTE
No modo de descarte, todos os estados correntes armazenados são descartados a cada materialização
de painel (resultados parciais em uma janela). O resultado de cada painel é independente dos painéis
anteriores. Esse modo de acumulação será útil quando os dados puderem ser enviados a um
consumidor cujo objetivo final possa ser calculado de forma cumulativa, como na contagem de
elementos ou somatório de valores, por exemplo.
ACÚMULO
No modo de acúmulo, os estados armazenados são retidos, enquanto novos dados são acumulados nos
estados existentes, ou seja, cada painel depende de painéis anteriores. Esse modo é útil nos casos em
que os resultados passados podem ser refinados e substituídos pelos posteriores.
ACÚMULO E REVISÃO
Esse modo é uma ampliação do acúmulo no qual, ao se materializar um novo painel, são produzidas,
com as acumulações, revisões independentes dos painéis anteriores.
REVISÕES (COMBINADAS COM O NOVO RESULTADO
ACUMULADO) SÃO ESSENCIALMENTE UMA FORMA
javascript:void(0)
javascript:void(0)
javascript:void(0)
EXPLÍCITA DE AFIRMAR: “EU JÁ DISSE QUE O RESULTADO
ERA X, MAS ESTAVA ERRADO. LIVRE-SE DO X QUE EU
DISSE DA ÚLTIMA VEZ E SUBSTITUA-O POR Y”.
(AKIDAU, 2016, tradução livre)
ARQUITETURA LAMBDA
A vantagem de se adotar a arquitetura Lambda é ter o melhor dos dois mundos: a baixa latência de
sistemas streaming com a corretude dos sistemas bacth. A desvantagem é que ela gera a necessidade
de construir, implantar e manter dois pipelines de processamento independentes. Além disso, os
resultados de ambos precisam ser mesclados no final.
A IDEIA BÁSICA DA ARQUITETURA LAMBDA É EXECUTAR
UM SISTEMA DE STREAMING AO LADO DE UM SISTEMA
BATCH, AMBOS EXECUTANDO ESSENCIALMENTE O
MESMO CÁLCULO. O DE STREAMING OFERECE
RESULTADOS IMPRECISOS E DE BAIXA LATÊNCIA (SEJA
POR CAUSA DO USO DE UM ALGORITMO DE
APROXIMAÇÃO, SEJA PORQUE O PRÓPRIO SISTEMA DE
STREAMING NÃO FORNECE CORREÇÃO), MAS, ALGUM
TEMPO DEPOIS, UM BATCH EXECUTA E FORNECE A SAÍDA
CORRETA.
(AKIDAU, 2015, tradução livre)
REVISITANDO OS CONCEITOS
Para sedimentar nosso entendimento, revisitaremos os conceitos apresentados neste material. Eles
serão pontuados na forma de respostas a quatro perguntas essenciais relacionadas aos problemas de
processamento de dados ilimitados (AKIDAU, 2016):
QUE RESULTADOS SÃO MATERIALIZADOS?
RESPOSTA
QUE RESULTADOS SÃO MATERIALIZADOS?
Diversos tipos de transformações podem ser feitos no pipeline de processamento, como calcular somas,
construir histogramas e treinar modelos de aprendizado de máquina, por exemplo. A pergunta também
se aplica ao processamento batch.
ONDE (NA LINHA DO TEMPO DO EVENTO) OS
RESULTADOS SÃO CALCULADOS?
RESPOSTA
ONDE (NA LINHA DO TEMPO DO EVENTO) OS
RESULTADOS SÃO CALCULADOS?
Nas janelas (fixas, deslizantes e sessões) de tempo de evento dentro do pipeline de processamento. É
possível calculá-los também nas situações em que a utilização delas não é necessária (processamento
agnóstico em relação do tempo e processamento batch clássico).
“Também poderão ser incluídas janelas de tempo de processamento se forem atribuídos tempos de
entrada como tempos de evento para registros conforme chegam ao sistema. Há ainda outros tipos mais
complexos de janelas, como leilões por tempo limitado.” (AKIDAU, 2016, tradução livre).
javascript:void(0)
javascript:void(0)
QUANDO OS RESULTADOS SÃO MATERIALIZADOS?
RESPOSTA
QUANDO OS RESULTADOS SÃO MATERIALIZADOS?
Os resultados são materializados por meio de marcas d'água e triggers.
“Existem infinitas variações sobre esse assunto, mas o padrão mais comum usa a marca d'água para
delinear quando a entrada para determinada janela está completa, com acionadores que permitem a
especificação de resultados iniciais (para especulativos, resultados parciais emitidos antes que a janela
seja concluída) e tardios (para casos em que a marca d'água é apenas uma estimativa de completude, e
mais dados de entrada podem chegar depois que a marca d'água declara que a entrada para
determinada janela está concluída).” (AKIDAU, 2016, tradução livre).
COMO OS REFINAMENTOS DOS RESULTADOS SÃO
FEITOS?
RESPOSTA
COMO OS REFINAMENTOS DOS RESULTADOS SÃO
FEITOS?
Eles são realizados de acordo com o tipo de acumulação usado:
Descarte: os resultados dos painéis são todos independentes entre si.
Acúmulo: os resultados posteriores são construídos com base nos anteriores.
Acúmulo e revisão: são emitidos o valor acumulado e uma revisão para o(s) valor(es)
materializado(s) anteriormente.
javascript:void(0)
javascript:void(0)
VERIFICANDO O APRENDIZADO
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Como vimos neste conteúdo, os Data Lakes surgiram para dar conta dos desafios do contexto de Big
Data. Além de lidar com dados com grande volume, variedade e velocidades, é fundamental garantir que
eles sejam disponibilizados para o consumo de forma correta.
Para isso, além dos aspectos tecnológicos envolvidos, observamos quão importante é implementar
ações de governança e de segurança de dados, sem as quais as chances de sucesso dos Data Lakes
são bastante reduzidas. Delineamos também o conceito de streamings, apontando as diferenças
importantes entre o tempo do evento e o de processamento, assim como as dificuldades que tais
diferenças impõem na análise dos dados no contexto de sua ocorrência.
Analisamos ainda as principais abordagens de processamento de dados em uso para dados limitados e
ilimitados por meio de mecanismos de lote e streaming. Por fim, exploramos os principais conceitos no
processamento por janela de tempo de evento: marcas d’agua, triggers e acumulação.
 PODCAST
Agora, a(o) especialista encerra o tema com um resumo geral abordando os principais pontos do
assunto.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
AKIDAU, T. Streaming 101: the world beyond batch. O'Reilly. Publicado em: 5 ago. 2015. Consultado na
internet em: 21 jul. 2021.
AKIDAU, T. Streaming 102: the world beyond batch. The what, where, when, and how of unbounded
data processing. O'Reilly. Publicado em: 20 jan. 2016. Consultado na internet em: 21 jul. 2021.
AKIDAU, T.; CHERNYAK, S.; LAX, R. Streaming systems: the what, where, when, & how of large-scale
data processing. Farnham: O’Reilly Media, 2017.
ANDERSON, D. Introduction to the agile Data Lake. Talend. Publicado em: 18 out. 2018. Consultado
na internet em: 21 jul. 2021.
ASAY, M. 85% of Big Data projects fail, but your developers can help yours succeed. TechRepublic.
Consultado na internet em: 21 jul. 2021.
DUTRA, R. N. Data Lake x Data Warehouse: suas principais diferenças. LinkedIn. Publicado em: 2 set.
2016. Consultado na internet em: 21 jul. 2021.
GARTNER says beware of the Data Lake fallacy. Gartner, Stamford. Publicado em: 28 jul. 2014.
Consultado na internet em: 21. jul. 2021.
NUAGE, I. Your ‘resolution list’ for 2017: 5 best practices for unleashing the power of your Data Lakes.
Talend. Publicado em: 21 dez. 2016. Consultado na internet em: 21 jul. 2021.
ORAM, A. Managing the Data Lake. Farnham: O’Reilly Media, 2015.
ROWLEY, J. The wisdom hierarchy: representations of the DIKW hierarchy. Journal of information and
communication science, v. 33. n. 2, p. 163–180, 2007.
SARFIN, R. L. Streaming data pipelines: what are they and how to build one. Precisely. Publicado em:
9 abr. 2021. Consultado na internet em: 21 jul. 2021.
SHARMA, B. Architecting Data Lakes. Farnham: O’Reilly Media, 2018.
TALEND. Definitive guide to cloud Data Warehouses and cloud Data Lakes. Consultado na internet
em: 21 jul. 2021.
EXPLORE+
Conheça na página de Zaloni, uma variação (mais simples) da arquitetura de referência apresentada
neste conteúdo: a EndZone Governance.
Visite o site do Databricks para saber mais sobre a arquitetura Lambda.
CONTEUDISTA
Herbetde Souza Cunha