Skip to content

2. Data Lake

Conforme definido pela AWS, um Data Lake (Lago de Dados) é um repositório centralizado que permite armazenar todos os seus dados estruturados e não estruturados em qualquer escala. A ideia de um Data Lake é poder armazenar os dados como estão, sem precisar primeiro estruturá-los e executar diferentes tipos de análise, desde painéis e visualizações até processamento de big data, análise em tempo real e machine learning para orientar melhores decisões.

Diagrama mostrando o Data Lake centralizado e tendo seus dados consumidos por aplicações de Mahine Learning, Analytics, etc.

2.1 Tipos de Dados

Os dados podem ser classificados em três tipos:

  • Não estruturados: são dados que não possuem uma estrutura bem definida e nem um padrão pré-estabelecido, conforme descrito por TreinaWeb. São dados que não podem ser representados em formato de tabela. Alguns exemplos deste tipo de dado são: arquivos de texto, imagem, vídeo, etc.

  • Semiestruturados: são dados que possuem algumas características definidas, sendo parcialmente estruturados, mas não se limitam a uma estrutura rígida, conforme definido por TreinaWeb. Nesses dados, existe uma definição das colunas, porém elas podem aparecer ou não. Alguns exemplos deste tipo de dado são: arquivos JSON, XML, etc.

  • Estruturados: são dados em que o schema é pré-estabelecido, ou seja, as colunas são bem definidas e estão sempre presentes. Alguns exemplos deste tipo de dado são: arquivos CSV, banco de dados, etc.

2.2 Data Lake vs Data Warehouse

Diferentemente de um Data Warehouse, que é um banco de dados otimizado para analisar dados relacionais provenientes de sistemas transacionais, com um Data Lake é possível armazenar os três tipos de dados: não estruturados, semiestruturados e estruturados. A ideia de um Data Lake é primeiro armazenar os dados, sem antes pensar em como os dados serão processados. Já em um Data Warehouse, é necessário ter o schema dos dados definidos antes de poder armazená-los. A tabela abaixo, extraída da AWS, realiza o comparativo entre Data Lake e Data Warehouse para seis características.

Características Data warehouse Data lake
Dados Relacionais de sistemas transacionais, bancos de dados operacionais e aplicações de linha de negócios Não relacionais e relacionais de dispositivos de IoT, sites, aplicações móveis, mídia social e aplicações corporativas
Esquema Definido antes da implementação do DW (esquema na gravação) Gravado no momento da análise (esquema na leitura)
Preço/performance Resultados de consulta mais rápidos, usando armazenamento de maior custo Resultados de consulta ficando mais rápidos, usando armazenamento de menor custo
Qualidade dos dados
 Dados altamente selecionados, que representam a versão central da verdade Quaisquer dados, selecionados ou não (ou seja, dados brutos)
Usuários Analistas de negócios Cientistas de dados, desenvolvedores de dados e analistas de negócios (usando dados selecionados)
Análises Geração de relatórios em lote, BI e visualizações Machine learning, análises preditivas, descoberta de dados e criação de perfis

2.3 Camadas e Subcamadas

Um Data Lake possui uma ou mais camadas, onde cada camada indica o estado dos dados. Apesar de variar de empresa para empresa, uma abordagem muito utilizada é criar três camadas, onde a primeira camada armazena os dados brutos, a segunda camada armazena os dados tratados e a terceira camada armazena os dados para consumo. Essas camadas são criadas como objetos de serviços de armazenamento em nuvem. Os serviços de armazenamento mais utilizados para um Data Lake são: AWS Simple Storage Service (S3), Microsoft Azure Blob Storage e Google Cloud Storage.

No Planfy, é utilizado o AWS S3 para o armazenamento do Data Lake. No AWS S3, as camadas são chamadas de buckets. A seguir, detalha-se as três camadas do Data Lake do Planfy e suas respectivas regras de utilização:

2.3.1 planfy-datalake-raw

Camada (ou bucket) onde são armazenados os dados brutos vindos dos serviços de ingestão. Para mais informações em como ingerir dados na camada raw, veja a Seção 2.4.

Organização

  • 1º nível: Schema ou Database (fonte dos dados).
  • 2º nível: Tabela.
  • 3º nível: Partição pela data de extração.
  • 4º nível: Arquivos (os dados propriamente ditos).

Regras de utilização

  • Os dados devem ser mantidos e preservados em seu formato original (JSON, CSV, etc.).
  • Se o schema dos dados for conhecido, pode-se salvar em formato otimizado (ex: Parquet).
  • Os dados devem ser particionados por data de extração preferencialmente (ex: extracted_at=2023-07-07).
  • Nunca sobrescrever os dados, apenas anexar.

Quem utiliza

  • Engenheiros de Dados
  • Jobs Spark

Exemplo

Exemplo de estrutura das subcamadas da camada raw.

2.3.2 planfy-datalake-stage

Camada (ou bucket) onde são armazenados os dados resultantes de transformação dos dados brutos da camada planfy-datalake-raw.

Organização

  • 1º nível: Schema ou Database (fonte dos dados).
  • 2º nível: Tabela.
  • 3º nível: Partição pela coluna relevante.
  • 4º nível: Arquivos (os dados propriamente ditos).

Regras de utilização

  • Os dados devem ser essencialmente os mesmos dos dados brutos.
    • Podem conter algumas informações a mais, como o timestamp do processamento.
  • Os dados devem ser salvos em formato otimizado, como Parquet, ORC ou Avro, sendo preferível o formato Parquet, quando possível.
  • No caso do Databricks, os dados devem ser salvos em formato Delta.
  • Os dados devem ser particionados por uma coluna comumente utilizada em agrupamentos ou filtros, ou seja, uma coluna relevante.
    • Uma coluna comumente utilizada é a data em que o registro foi criado.

Quem utiliza

  • Cientistas de Dados
  • Jobs Spark
  • DBT
  • AWS Athena
  • etc.

Exemplo

Exemplo de estrutura das subcamadas da camada stage.

2.3.3 planfy-datalake-analytics

Camada (ou bucket) onde são armazenados os dados que foram transformados e organizados, a partir dos dados da camada planfy-datalake-stage, para usos específicos. São os dados acessados pelos stakeholders.

Organização

  • 1º nível: Schema ou Database (caso de uso).
  • 2º nível: Tabela.
  • 3º nível: Partição pela coluna relevante.
  • 4º nível: Arquivos (os dados propriamente ditos).

Regras de utilização

  • Os dados devem ser salvos em formato otimizado, como Parquet, ORC ou Avro, sendo preferível o formato Parquet, quando possível.
  • No caso do Databricks, os dados devem ser salvos em formato Delta.
  • Os dados devem ser particionados por casos de uso específicos.

Quem utiliza

  • Analistas de Dados
  • Cientistas de Dados
  • Data Warehouse
  • Ferramentas de BI
  • etc.

Exemplo

Exemplo de estrutura das subcamadas da camada analytics.

2.4 Ingestão de Dados

Em Fontes de Dados, viu-se que existem diversas fontes de dados da empresa em diversos lugares. Entretanto, se estes dados estiverem apenas na fonte, não há utilidade neles. Além disso, corre-se o risco de, em algum momento, esses dados não estarem mais disponíveis na fonte. Por isso, é necessário ter um sistema de ingestão desses dados brutos direto no Data Lake, mais especificamente na camada planfy-datalake-raw, mesmo sem saber como estes dados serão utilizados.

Sistema de ingestão em um Data Lake.

Existem diversas ferramentas que são capazes de realizar a ingestão de dados em um Data Lake. A escolha da melhor ferramenta irá depender de cada caso, onde devem ser levados em conta alguns aspectos, como a fonte de dados, o destino dos dados, custos, complexidade, etc. Segue abaixo apenas algumas das várias ferramentas disponíveis para realizar a ingestão de dados:

Pode-se ingerir os dados direto no Lakehouse também, porém não são todas as tecnologias atualmente que são capazes de inserir dados no formato do Lakehouse. Segue abaixo algumas que são capazes:

A seguir, podem ser vistos todos os sistemas de ingestão já desenvolvidos.

2.4.1 Migração do db-asset para o Data Lake via AWS DMS

A ser feito.