​
Conjuntos de Dados (Datasets)

​
Camadas de Consumos

​
Datasets organizados em camadas lógicas

Os dados em nosso BigQuery são organizado seguindo o padrão de design de dados conhecido como Arquitetura Medalhão. Este padrão consiste em organizar logicamente os dados em um Data Lake, com o objetivo de melhorar incremental e progressivamente a estrutura e qualidade dos dados à medida que eles fluem por cada camada da arquitetura (isto é, entre as tabelas da camada Bronze ⇒ Prata ⇒ Ouro):

  • Bronze ou Dados Brutos: É onde depositamos todos os dados dos sistemas de origem externos. As estruturas de tabela nesta camada correspondem às estruturas de tabela do sistema de origem “como estão”, juntamente com quaisquer colunas de metadados adicionais que capturem a data/hora de carga, o ID do processo, etc.
  • Prata ou Dados Mestres: Nesta camada os dados da camada Bronze são correspondidos, unificados, padronizados e limpos (“o suficiente”) para que a camada Prata possa fornecer uma “visão Institucional” de todas as suas principais entidades, conceitos e transações. Ela serve como uma fonte para os desenvolvedores criarem projetos e análises adicionais para resolver problemas de suas áreas.
  • Ouro ou Casos de Uso: Os dados na camada Ouro geralmente são organizados em bancos de dados “específicos do projeto”, prontos para o consumo. A camada Ouro é para relatórios ou dashboards, e utiliza modelos de dados mais desnormalizados (tabelões) e otimizados para leitura, com menos junções (joins).

​
Nomenclatura

CamadaNomenclaturaComentário
Bronze ou Raw Staging
brutos_<data_source>_staging
Bronze ou Raw
brutos_<data_source>
Prata ou Core
iplan_dados_mestres

iplan_<tema>
Reservado para dimensões tranversais à Prefeitura
Ouro ou Marts
app_<tema>


gerenciamento_<tema>

projeto_<tema>
Reservado para execução e controle de processos e aplicações internas

Reservado para integrações com aplicações

Reservado para uso em BI e Data Science

​
Camadas intermediárias de dados

Camadas intermediárias de dados, utilizadas exclusivamente para cálculos ou agregações que sejam um passo na construção das tabelas das camadas prata ou ouro.

Datasets intermediários são proibidos de serem materializadas no ambiente de Prodção. Para isso, usar o recurso de materialização efêmera do dbt.

​
Camada de Marts

​
App

Reservada para integrações com aplicações, onde os dados são consumidos diretamente por sistemas ou serviços específicos. Os datasets desta camada devem ser nomeados seguindo o padrão abaixo:

  • app_<tema>

O termo temadeve indicar claramente a aplicação ou o domínio de uso dos dados, facilitando a identificação do proposito do dataset.

​
Gerenciamento

Reservada para controlar a execução de aplicações e processos internos (ex. dbt, reprocessamento, …) e persistir resultados relacionados à execução ou situação dos processos internos do Data Lake (ingestão dos dados, disponibilidade da infraestrutura, …). Esta camada reserva o prefixo gerenciamento. Nesta camada os datasets deve ser nomeados seguindo um dos padrões abaixo

  • gerenciamento_<ferramenta>
  • gerenciamento_<finalidade>

Em casos específicos, onde uma ferramenta tem diversas finalidades, o dataset pode ser quebrado por finalidade:

  • gerenciamento_<ferramenta>_<finalidade>

​
Projeto

Reservada para organizar dados relacionados a projetos específicos, geralmente voltados para análises, relatórios ou dashboards de um determinado tema ou área. Os datasets desta camada devem ser nomeados seguindo o padrão abaixo:

  • projeto_<tema>

O termo tema deve ser substituido pelo assunto principal do projeto, de forma clara e objetiva.

​
Tabelas

Nomear tabelas é algo menos estruturado e, por isso, requer bom senso. Mas temos algumas regras:

  • Se houver tabelas para diferentes entidades dentro do mesmo dataset, incluir a entidade no começo do nome. Exemplo: episodio_assistencial_diagnostico, farmacia_estoque.
  • Não incluir a unidade temporal no nome. Exemplo: nomear farmacia_estoque, e não farmacia_estoque_diario.
  • Deixar nomes no singular. Exemplo: chamado, e não chamados.

​
Restrições Gerais de nomeação

Para mantermos uma consistência nas nomeações, são necessárias algumas restrições:

  • Ter sempre 2 níveis de identificação do dado: dataset_id (nome do conjunto) + table_id (nome da tabela). Exemplo saude_estoque.movimentacao
  • Ter todas letras minúsculas (inclusive siglas), sem acentos, conectados por _
  • Não incluir conectores como de, da, dos, e, a, em, etc.
  • o sufixo _serie_historica é reservado para as tabelas que contenham a série histórica. Nos casos das tabelas onde essa característica não é explicitada no nome, o entendimento é que a tabela representa a situação atual.
  • Não deve ser utilizado termos vagos como “Outros…”. Caso a categoria do seu conjunto não se encaixe em nenhuma das opções já existentes, é permitida a sugestão de novos termos.
  • Nenhuma palavra deve ser repetida no dataset_id ou table_id (ex: saude_estoque.posicao deve ser usado, e não saude_estoque.estoque_posicao)
  • O dataset_id pode ser ser nomeado como saude_dados_mestres, caso a tabela em questão seja uma dimensão referência para diversos temas no Data Lake.

​
Referências