diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..9778c55 --- /dev/null +++ b/404.html @@ -0,0 +1,539 @@ + + + +
+ + + + + + + + + + + + + + +É uma engine de processamento em ambiente distribuído
+Imagine vários clusters de computadores trabalhando juntos de forma interconectada e distribuindo seu conjunto de trabalho em vários nós nestas máquinas, com sua CPU e memória compartilhadas com o objetivo de aumentar seu processamento ou disponibilidade do ambiente, resultando em uma ótima escalabilidade
+Usando somente uma máquina, você se limita aos recursos computacionais, o poder de processamento daquela única máquina
+É possível usar o framework do Spark para acessar vários tipos de bancos de dados, em batch e em streaming, com Python até Java, sendo ele extremamente versátil
+ +Diferente do Hadoop, o Spark não trabalha fazendo o processamento em disco, mas sim em memória, aumetando ainda mais o tempo de processamento
+Mas o Hadoop ainda é bastante usado por ter seu file system compartilhado com o HDFS, apesar de seu uso ser mais difícil e somente possuir processamento em batch
+ +Os dados processados pelo Pandas, os dataframes, ficam alocados em uma memória standalone, diferete do Spark que o faz na memória de várias máquinas, tanto em leitura, quanto em escrita
+Formato de dados desenvolvido de forma otimizada a trabalhar com BigData, armazenando seus dados em formato de coluna, os comprimindo, codificando, e criando partições físicas, desenvolvido pela Apache
+ +A consulta é então otimizada pois os tipos de dados estão próximos, e não embaralhados, além de seu armazenamento ser drasticamente reduzido por substituição de redundância, ganhando espaço em disco e tempo de processamento
+ +Essa diferença de performance é imperativa, ainda mais em cloud que o custo é por tempo de processamento, ciclo de CPU e armazenamento em disco
+ +Será usado o Databricks Comunnity, criar conta lá portanto, e como exemplo a base de dados train.csv do Kaggle: Housing Prices
+Deverá ser feito o upload do arquivo ou pela aba Catalog -> Create Table, ou já no arquivo .dbc do Databricks, com File -> Upload data to DBFS...
+A opção header
determinará a primeira linha do dataset como sendo o cabeçalho
A opção inferSchema
fará a inferência dos tipos de dados das colunas automaticamente, fazendo com que seja implementado outro Spark Job somente para este trabalho, deixando este processo inicial um pouco mais lento
Caso opte por passar os tipos das colunas manualmente, ganhando tempo de processamento, é possível utilizar somente a opção schema
É possível acompanhar o processo do cluster Spark na aba Compute -> Spark UI
+Qualquer comando do Spark, mesmo feito em Python, é considerado um código SQL, logo, uma query
+Para traduzir o dataframe, seja formato xlsc ou csv, para o formato parquet, faz-se da seguinte forma (pode demorar um pouco devido a escrita dos metadados):
+O modo overwrite
identifica caso haja outro arquivo parquet com o mesmo nome e o subscreve forçadamente
Para fazer a leitura:
+someday...
+ + + + + + + + + + + + + +O Engenheiro de Dados tem a função de projetar, desenhar, definir e construir sistemas e processos para soluções de dados
+Envolvido na coleta, transformação, entrega, armazenamento, análise e deploy destes dados em escala +Conhecimento da solução de ponta-a-ponta com as data pipelines
+Traçar orçamentos, planejamentos, mais efetivos, envolvido na parte de projetos e negócios
+Cuida mais da parte de BI, ETL e ELT orientados a BigData
+Realizar a montagem de ecossistemas como Data Lakes, Warehouses, Lakehouses, etc
+Cuida mais das soluções com o "back-end", escolhendo a arquitetura da infraestrutura
+Garante que o requisito da aplicação de negócios aconteça
+Define as fontes dos dados, como serão coletados, a frequência em que serão coletados, como eles serão geridos, etc
+Você decide os formatos dos arquivos: JSON, Parquet, CSV, SQL, etc
+Deixamos de trabalhar somente com dados estruturados para trabalhar também com dados semi estruturados e não estruturados, com novos formatos de dados
+Os 3 V's: Velocidade, Volume e Variedade
+É interessante guardar informações de scripts e pipelines - a exemplo de status de ETLs - por meio de logs, erros, tempo de duração, custo do processamento
+Definição de ambientes e arquiteturas, como on-premise e cloud ou híbrido
+Especificar as tecnologias de armazenamento, como Data Lakes e Data Warehouses
+Selecionar as formas de processamento como Streaming ou Clusters
+Definir o monitoramento e padrões de segurança e integração com outros sistemas
+Surgidos em 2011
+Não é uma tecnologia, não é um protocolo, não é um framework, é somente um conceito, algo abstrato. Outra coisa é a sua forma de se implementar
+Um repositório único para armazenar todos os formatos de dados, sendo eles estruturados, semi-estruturados e até não-estruturados
+Mais necessário para a finalidade de testar um modelo de ML, descobrir as features do modelo, necessitando dos formatos estarem brutos, não processados
+Seus dados são transformados apenas quando são necessários para análises, por meio de aplicações de rotinas por exemplo, esta ação chamada de esquema para leitura
+Não é necessário fazer a migração dos dados para outro sistema, sendo a sua geração de relatórios mais uma questão ad hoc
+Pode ser trabalhado com dados em batch ou em streaming
+Seu objetivo é entregar rápidos insights, coma menor burocracia e restrição possível
+O principal usuário é o Cientista de Dados, capaz de tratar e processar os dados não estruturados a bel prazer. Logo, fornece principalmente dados para AI e modelos de Machine Learning
+O modelo de schema é definido no momento de leitura, não existindo uma tabela rígida com campos bem determinados
+Deve-se ter muito cuidado para não virar um Data Swamp, para isso, boas práticas devem ser adotadas, como sistema de controle de acesso, controle de cotas por zona de gerenciamento, como landing zones, process zones, sendo estas, exemplos de uma arquitetura medallion ou multihop, com os dados brutos entrando na zona Bronze os pré-processados no Prata e o dado final no Ouro, estipulação da periodicidade da ingestão de dados, não armazenar dados inúteis, definição de regras de negócios, diversas fontes de dados com diversas pipelines, com fluidez de dados, garantir os metadados (os dados sobre os dados) e etc
+Basicamente, é necessário ter governança e rotinas de limpeza
+Para evitar uma bagunça total dos datasets, é extremamente importante ter a divisão de zonas dentro do Data Lake, cada uma com um propósito (landing -> process - curated)
+ +Importante frizar que todas os seguintes exemplos são soluções e serviços em cloud
+Uma solução para armazenamento de objetos, onde a partir dele, há várias outras soluções integradas para fazer a gestão dos dados
+Escalável, seguro, com um custo viável
+Os Buckets (repositórios) podem ter configurações de região, replicação diferentes, de tags, metadados, etc
+ +Soluções integradas para:
+Solução mais especializada em Data Lakes, sendo um pouco mais completa que o S3, até podendo consumir dados do mesmo, consumindo também de umbanco de dados relacional e não relacionais também
+Pode possuir soluções de crawlers, ETL e preparação de dados integrados, catalogação dos dados, configurações de segurança e controles de acesso
+Podendo também integrar dentro da Amazon Athena (solução de analytics da AWS), Amazon Redshift e Amazon EMR, e etc
+O armazenamento pode até ser feito dentro do Bucket S3, mas sua gestão do Data Lake seria feita dentro do Lake Formation
+Data Lake Store provê soluções de armazenamento para dados estruturados, semi-estruturados e não-estruturados
+Data Lake Analytics para soluções de analytics (pasme) com ampla gama de linguagens de programação como ferramentas disponíveis, tais como R, Python, C#, T-SQL e .NET
+HDInsight para processamento distribuído, com um amplo leque de ferramentas também, como Java e Scala
+Possui serviço de armazenamento, serviços de pipelines com GC Fusion, Big Query para analytics, orquestrações com o Cloud Composer, monitoramento com Logging e Cloud Data Catalog para catalogação dos dados (pasme)
+ +++Geralmente os dados de sensores são não estruturados ou semi-estruturados, por se tratarem de JSON
+
Dados gerados on-premise
+Cloud: Os serviços estão além do seu computador/servidor local, estão na nuvem, sendo gerenciados ou armazenados em um outro local de talvez uma outra empresa, sendo seu custo a exemplo de hardwares, segurança e backups diminuídos pois essa bronca está com a fornecedora da nuvem, com você pagando somente com o que consome
+On-premise: São os sistemas, servidores internos de uma empresa, implantações internas da TI que gerenciam toda a infraestrutura, é o local. Por exemplo, você compraria o hardware do servidor e faria a manutenção dele, onde também configuraria e atualizaria os sistemas operacionais nos quais seu software é executado, além de instalar e atualizar todos os complementos e plug-ins necessários, gastando também com parte elétrica e refrigeração, sendo sua implementação e gerenciamento de infraestrutura um tanto quanto complexos
+SaaS Software as a Service: Todas as responsabilidades do de cima, sendo um software como o nome sugere, passam a ser do prestador do serviço de nuvem, segurança, confidencialidade, manutenção, etc
+O GCP possui também serviços para dados em streaming, batch, gerenciamento do Data Lake por linha de comando com o gsutil, assim como data mining, machine learning, etc, tudo integrado ao seu sistema de armazenamento
+Soluções que podem ser implementadas em seu ambiente on-premise gastando muito menos do que gastaria com uma AWS da vida por causa de suas assinaturas e planos
+Implementa o protocolo S3 da AWS, podendo ser orquestrado também com Kubernetes
+Solução excelente para cloud híbrida
+Pode ser integrado também com diversas outras soluções e protocolos
+Faz a gestão do versionamento do Data Lake a nível de código
+Famoso HDFS
+Não recomendável usar somente ele pois perde soluções como sistema de controle de acesso, controle de cotas por zona, etc
+ + + + + + + + + + + + + +Surgidos em 2020 devido a alta demanda de algoritmos de IA e Machine Learning para dados não-estruturados
+O que era mais usado era o uso de vários DW e um DL , sendo dificultoso manter diferentes soluções para vários ambientes
+Uma junção do Data Lake (baixo custo) com Data Warehouse (alta gestão), com um ambiente flexível e com confiabilidade
+ + + + + + + + + + + + + +São soluções mais especializadas e condensadas de determinadas áreas e setores no formato de Data Warehouses só que em miniatura, sendo eles mais um subconjunto de dados em vez de dados corporativos completos, com o propósito de atender às necessidades de unidades de negócios, funções ou departamentos muito específicos
+Reduz portanto o risco de perda de dados, bem como os custos e o tempo de implementação, sendo bem eficazes para fornecer suporte de decisão rápido e consistente para uma Decision Support System DSS (Sitema de Suporte à Decisão)
+Podem estar presentes tanto em DW, quanto em DL
+ + + + + + + + + + + + + + +Surgidos no final da década de 80
+São CAROS, LENTOS e COMPLEXOS pois trabalham com bases de dados massivas, feitos para queries escaláveis
+No levantamento de requisitos da modelagem de um DW, já é definido antecipadamente qual assunto o DW vai tratar
+Diferentes dos Data Lakes, os Data Warehouses são soluções mais controladas e confiáveis, uma "única fonte de verdade de dados", com os mesmos sendo bem estruturados pelas modificações do processo de ETL e não voláteis
+Sua principal ideia é reduzir o trabalho manual para que seja facilitado o foco nas pesquisas e consultas, reaproveitando o processamento e assim melhorando a performance para a geração de BI e relatórios. Logo, seus principais usuários são da área de BI, gestores, gerentes
+Muito utilizado devido a suas transações ACID
+Seus schemas são feitos no momento de escrita definidos com antecedência, sendo necessário o conhecimento das tabelas, para otimizar as consultas SQL
+Todos os conceitos de uma DW são válidos para a construção de uma arquitetura mais moderna como um Data Lakehouse
+É melhor não fazer um DW de tudo e disponibilizar as visualizações, mas sim, disponibilizar os dados através de Data Marts
+O DW não chega a ser somente uma "vitrine" do banco de dados pois dentro dele será feita a limpeza e cálculo de KPIs que podem até nem existir em um DM, necessitando da junção de mais de um, como por exemplo o de marketing e de produto. Não é só expôr o dado de uma maneira melhor, mas gerar ainda mais informação
+Chega na sua empresa e pergunta pro analista quais produtos foram vendidos no dia anterior e para quais clientes estes mesmos foram vendidos, dependendo da dificuldade de responder, urge a necessidade de um DW
+Já pensou participar de uma reunião com os times de vendas, cada um com um valor de quanto vendeu ontem, marketing, financeiro, comercial, etc
+Para quê eu preciso disso? Não seria melhor só conectar diretamente no sistema?
+ +É um sistema transacional rápido, não foi feito para consultas analíticas
+Sem um DW então, será extraído de um sistema ERP uma planilha de vendas para que então possa ser visualizado o relatório do dia anterior, fazendo gráficos, procv, etc
+ +E se precisar escalar e não ter de fazer somente com o sistema ERP, mas também o de CRM? E se o relatório ao invés de ser em um dia, precisar ser feito em uma hora? E se a venda de Ecommerce for um outro sistema com JSON, e o outro ERP for legado com XML?
+ERP Enterprise Resourse Planning: O Planejamento dos Recursos da Empresa
+CRM Customer Relationship Management: O Sistema Integrado de Gestão Empresarial
+Só as empresas que crescem possuem volume e faturamento para precisar de um DW, para conseguir automatizar, profissionalizar e diminuir o número de falhas com processos de ETL, tudo com o intuito de unir os sistemas em um lugar para os analistas consumirem
+A pior maneira de começar um projeto de DW é conectando todas as fontes de dados da empresa. O que dá dinheiro não é integrar, é gerar os relatórios, as análises
+A grande questão da modelagem é que quem vai usar o seu modelo, não é você, é o usuário final, se não foi feito algo fácil, seu projeto vai desmoronar
+ + + + + + + + + + + + + +Solução em cloud com o objetivo de processar clusters de máquinas Spark, com diversar soluções proprietárias (apesar da maioria serem pagas)
+Grandes empresas que usam clouds DEVEM se tornar parceiras do Databricks, como o Google, AWS, Azure, etc
+Usa do DBFS (Databricks File System) para armazenamento interno
+ + + + + + + + + + + + + +São um conceito de passo-a-passo a se seguirem conforme uma solução de dados é proposta na necessidade do seu negócio
+E significa Extract (Extrair), é a etapa de obtenção dos dados
+T significa Transform (Transformar), é a etapa de processamento, aplicação de rotinas
+L significa Load (Carregar), é a etapa de armazenar os dados obtidos em uma fonte de dados
+O processo de ELT tem tudo a ver com os Data Lakes, visto que armazenam dados semi e não estruturados, podendo ou não serem processados depois
+Já o processo de ETL é correspondente com as Data Warehouses, pois necessitam dos seus dados tratados, logo, estruturados
+ + + + + + + + + + + + + +Um pipeline de dados, ou datapipeline, é uma série de etapas de processamento de dados. Sendo que, cada etapa fornece uma saída que é a entrada para a próxima etapa. Isso vai acontecendo até que o pipeline seja concluído. Além disso, também podem existir etapas independentes a serem executadas em paralelo
+A maioria dos pipelines possuem três elementos principais: a origem, uma ou mais etapas de processamento e o destino. Mas os pipelines de dados podem ser arquitetados de várias maneiras diferentes e tudo vai depender do caso de uso por meio das DAGs, orquestração de pipeline e VMs
+Directed Acyclic Graph DAG (Gráfico Acíclico Direcionado): Define as regras do que será efetivamente orquestrado no seu pipeline, refletindo suas relações e dependências, sendo sua sigla: Grafos para a conexão dos nós; Direcionado indicando que o fluxo de trabalho se dá apenas em uma direção; e Acíclico: significa que a execução não entrará em um laço de repetição
+Virtual Machine VM:
+Será necessário definir
+Ferramenta open source, escrita em Python, criada pelo Airbnb em 2014 e atualmente faz parte da Apache Software Foundation. Trata-se de um orquestrador de fluxos, ou seja, nos permite decidir em qual momento e em quais condições nosso programa irá rodar. É utilizada principalmente para criação, monitoramento e agendamento de pipeline de dados de forma programática
+Contém algumas bibliotecas que só funcionam no Linux. Dessa forma, soluções alternativas para usuários(as) de Windows, como máquinas virtuais ou Docker, são necessárias para uso totalmente funcional dessa ferramenta
+O Airflow possui 4 componentes principais que devem estar em execução para que ele funcione corretamente:
+Um exemplo de componente situacional seria:
+Solução paga para orquestração de data pipelines da Microsoft, estando integrada com seus outros serviços
+Integrado também com as soluções da Amazon
+