Guia do panorama das ferramentas de dados para desenvolvedores

• Organiza o panorama completo para que desenvolvedores de software que estão entrando na área de dados não apenas decorem nomes de ferramentas, mas entendam o papel de cada uma e como se conectam nas etapas de coleta/armazenamento/processamento/uso dos dados
• As funções na área de dados se dividem, em linhas gerais, em análise/ciência/engenharia/machine learning, lidando com problemas e ferramentas diferentes, de SQL e BI até modelos estatísticos e notebooks, infraestrutura de pipelines e implantação operacional de modelos
• Os repositórios se dividem em data warehouse, que oferece análise rápida e praticidade; data lake, que é barato e flexível; e lakehouse, que adiciona ACID e gerenciamento de esquema em formato de tabela
• O processamento de dados se expande de transformações SQL como dbt para processamento local com pandas e DuckDB, processamento distribuído em lote com Spark e processamento de streams com Kafka e Flink, enquanto orquestradores como Airflow gerenciam a ordem de execução e a recuperação de falhas de tarefas independentes
• Os dados processados são usados não só em dashboards, mas também em operações de vendas/suporte, análises ad hoc, machine learning, recursos analíticos dentro do produto e venda de dados; à medida que a escala cresce, catálogo/camada semântica/linhagem/governança se tornam a base central para manter o significado e a responsabilidade sobre os dados

---

O escopo que desenvolvedores precisam conhecer

• Este é um guia geral para desenvolvedores organizado por um engenheiro de software que entrou em uma empresa de dados sem experiência prévia na área, para entender o propósito das ferramentas e sua interação com notebooks
• Não aborda como criar dashboards, fundamentos de estatística, operação de clusters Spark nem comparações aprofundadas entre produtos da mesma categoria
• Distingue as etapas do ciclo de vida pelas quais cada ferramenta é responsável, acompanhando de onde os dados surgem e como são processados, armazenados e exibidos

Quatro tipos de funções em dados

• Na prática, os limites entre funções podem ser difusos, especialmente em empresas ou equipes pequenas, mas é possível dividi-las em quatro tipos para entender o panorama geral
• O perfil de análise interpreta dados com SQL e planilhas e visualiza insights
  • Data analyst e BI analyst são exemplos representativos, usando Tableau, Excel e afins
  • Um exemplo é consultar dados de clientes, calcular a taxa de churn por região e criar um dashboard no Tableau junto com propostas de campanha de retenção
• O perfil de ciência lida com perguntas mais profundas ou previsões, indo além de relatórios superficiais por meio de estatística, modelos e experimentos
  • Data scientist é o exemplo representativo, usando principalmente Python, pandas, scikit-learn e notebooks
  • Pode explorar fatores de churn, criar um modelo de probabilidade de churn por cliente e depois projetar e analisar um teste A/B de campanha de retenção
• O perfil de engenharia coleta, limpa e padroniza dados de origem para carregá-los em warehouses ou lakes, além de operar ferramentas e bancos de dados de dados
  • Data engineer é o exemplo representativo, usando Python, Apache Spark, bancos de dados, warehouses e nuvem
  • Pode expandir resultados analíticos para um pipeline de reverse ETL executável de forma recorrente, ou integrar dados transacionais de várias fontes e gerenciar esquema, consultas e verificações de qualidade
• O perfil de machine learning cria e opera modelos de IA, de modelos de classificação a LLMs
  • É uma categoria que reúne ML scientist e ML engineer; como o ecossistema de ferramentas separado é amplo, o texto não entra em detalhes
  • Pode montar dados de treino para um modelo de recomendação, treinar e ajustar o modelo, implantá-lo como API e depois monitorar previsões e reentreinar conforme mudanças de comportamento

ETL e ELT

• ETL (Extract-Transform-Load) é o fluxo geral de extrair dados de origem, limpá-los ou combiná-los com outros dados e depois carregar o resultado no destino
• A ordem das etapas não é fixa e elas podem se repetir ou se sobrepor
• ELT carrega primeiro os dados de origem no warehouse e depois faz as transformações dentro dele, salvando o resultado em tabelas separadas
  • Isso pode aumentar os custos por exigir mais armazenamento e processamento
  • Como os dados originais permanecem, é possível reprocessá-los depois de outra forma

Formatos de arquivo e de memória

• CSV é fácil de compartilhar para dados pequenos e pode ser aberto na maioria dos softwares de escritório, sendo adequado para usuários não técnicos
• Apache Parquet é um formato de arquivo colunar com alta taxa de compressão, capaz de armazenar e transferir grandes volumes de dados com eficiência
  • Como é suportado pela maioria das ferramentas de dados, funciona como formato comum entre elas
  • Apache ORC resolve problemas semelhantes
• Apache Avro é um formato binário orientado a linhas usado para transmitir registros, especialmente em processamento de streams
• Apache Arrow é o padrão de fato para formato em memória, otimizado para processamento e transferência zero-copy
  • Parquet foca em arquivos pequenos e na varredura dos itens necessários, enquanto Arrow foca no cálculo real usando instruções e cache de CPU/GPU
  • Arrow usa mais memória, mas transfere dados de forma eficiente entre ferramentas como pandas e DataFusion, em Rust
  • Pode ser usado como backend opcional do pandas, e Polars e DataFusion foram construídos desde o início com base em Arrow

Data warehouse

• Data warehouse é semelhante a bancos de dados como PostgreSQL e MySQL, mas otimizado para cargas analíticas
• Bancos OLTP como MySQL são adequados para operações como encontrar uma única linha de usuário por ID, enquanto warehouses OLAP são adequados para agregações por coluna, como o total anual de vendas por região
• Tradicionalmente era o repositório final de dados estruturados e limpos, mas em ELT também é usado como primeiro ponto de carga de dados brutos
• Como o formato de armazenamento e o mecanismo de consulta são fortemente acoplados, oferece consultas rápidas para BI e relatórios, mas tem o maior custo entre os três tipos de repositório
• Entre os produtos estão Snowflake, BigQuery e Redshift
• Entre as opções open source e self-hosted estão ClickHouse, Apache Doris e StarRocks
• Para projetos pequenos, um banco de dados tradicional também pode ser suficiente

Data lake

• Data lake é mais próximo de uma grande pasta na nuvem que armazena, com processamento mínimo, dados estruturados, semiestruturados e não estruturados, como CSV, Parquet, JSON, e-mails e imagens
• Pode ser construído armazenando arquivos no Amazon S3, Google Cloud Storage ou Azure Blob Storage, definindo regras de nomenclatura, particionamento e políticas de acesso
• Se não for bem gerenciado, pode virar um pântano de dados (data swamp), difícil de encontrar ou aproveitar
• Entre as opções gerenciadas estão Azure Data Lake e os recursos de data lake da Snowflake
• Para consultar os dados sem pesquisá-los, baixá-los e interpretá-los manualmente, é preciso um catálogo de metadados e um mecanismo de consulta
  • O catálogo registra nomes de tabelas, esquemas e mapeamentos de arquivos
  • O mecanismo de consulta usa esses metadados para ler os arquivos relevantes e executar consultas em SQL ou linguagens semelhantes
• Entre os catálogos estão Hive Metastore, AWS Glue Data Catalog e Unity Catalog
• Entre os mecanismos de consulta estão Apache Spark, Trino e Amazon Athena

Data lakehouse

• Data lakehouse adiciona recursos próximos aos de um warehouse sobre um lake barato e flexível
• O componente central, o formato de tabela, gerencia a forma de armazenamento entre o mecanismo de consulta e os dados brutos
  • Lida com gravações simultâneas, falhas durante a gravação e corrupção de dados com ACID
  • Mesmo dados semiestruturados exigem definição de schema, e dados totalmente não estruturados não aproveitam os benefícios do formato de tabela
  • Suporta evolução de schema e controle de versão
  • Pode acelerar consultas com otimizações de índice e particionamento
  • Algumas implementações oferecem time travel, para consultar snapshots de um ponto específico no tempo
• Por ser baseado em lake, pode ser mais barato que um warehouse e não fica preso a um mecanismo de consulta específico, mas como é preciso incluir custos computacionais separados, é difícil fazer uma comparação de preço direta
• Os principais formatos de tabela são Apache Iceberg, Delta Lake e Apache Hudi
• Serviços gerenciados incluem Lakehouse for Apache Iceberg do Google, Databricks e IBM watsonx.data

Fontes e ingestão de dados

• Os dados vêm de bancos de dados de aplicações como PostgreSQL e Mongo, APIs externas como Stripe, eventos de analytics no navegador, dispositivos IoT etc.
• Eles podem ser processados logo após a extração, ou, em ELT, o original pode primeiro ser armazenado em lake, lakehouse ou warehouse, dependendo do formato, volume e infraestrutura
• Scripts dedicados são flexíveis, mas exigem reimplementar código de integração repetitivo, como autenticação, paginação e tratamento de erros
• Ferramentas de ingestão de dados lidam com esse trabalho repetitivo ao configurar conectores de origem e destino
  • Como os dados extraídos precisam primeiro ser carregados em algum lugar, elas tendem ao fluxo ELT
  • Produtos representativos incluem Fivetran, Airbyte e dlt
• Change data capture (CDC) captura inserções, alterações e exclusões nos logs de replicação do banco de dados sem consultar repetidamente as tabelas
  • Ferramentas de ingestão o usam internamente para fontes de banco de dados
  • Debezium é amplamente usado como componente open source independente

Linguagens de processamento de dados

• Python é a linguagem padrão de fato para trabalho com dados, com uma grande comunidade e um ecossistema de bibliotecas nativas
  • Mesmo ferramentas criadas em outras linguagens muitas vezes oferecem bindings para Python; o Apache DataFusion, baseado em Rust, é um exemplo
• numpy fornece arrays multidimensionais de alto desempenho e serve de base para várias bibliotecas
• pandas é o padrão de fato, oferecendo Series unidimensionais e DataFrames bidimensionais
  • É possível visualizar dados com seaborn e Plotly e criar apps interativos com streamlit
  • Também é possível fazer consultas SQL com DuckDB ou aplicar técnicas de machine learning do scikit-learn
• R é usado na academia; Java e Scala, em frameworks de big data como Spark; Julia e Rust também são usados em trabalho com dados, mas têm adoção menor que Python
• SQL é amplamente usado em consultas e transformações em warehouses, mas a sintaxe varia um pouco conforme o ambiente de execução

Processamento em lote e em tempo real

• Processamento em lote trata regularmente grandes conjuntos de dados, como o fechamento das vendas do mês passado, e é adequado para tarefas em que se pode esperar horas ou dias pelo resultado
• Processamento em tempo real usa streaming, processando assim que os dados chegam, ou microbatches, como intervalos de 20 segundos
• Pipelines em que a velocidade do resultado é importante, como detecção de bots, usam processamento em tempo real para identificar e bloquear usuários o mais rápido possível

Transformação baseada em SQL

• dbt e SQLMesh definem transformações com instruções SQL select e as compilam para execução no mecanismo de consulta real
• As duas ferramentas não processam dados diretamente; elas cuidam da orquestração de transformações
• Em comparação com scripts Python customizados, elas padronizam a forma de transformar dados e permitem dividir trabalhos complexos em pequenos modelos com dependências
• O ref do dbt referencia modelos em vez de nomes de tabela hardcoded e executa na ordem correta com base no grafo de dependências
• Os resultados normalmente são armazenados no mesmo warehouse, lakehouse ou lake da origem, mas também podem ser enviados a outros destinos conforme a configuração do mecanismo de consulta

DataFrames locais e DuckDB

• DataFrame é uma abstração de array bidimensional para lidar com dados tabulares, e, em Python, o pandas é o mais usado
• Outras implementações incluem Polars em Python e Rust, DataFusion em Rust, DataFrames.jl em Julia, data.frame em R e tablesaw em Java
• pandas, data.frame e tablesaw usam o modo eager, em que a operação é executada imediatamente após a chamada
• O LazyFrame do DataFusion e do Polars acumula operações em um plano lógico e as executa em .collect()
  • Como o plano pode ser otimizado antes da execução, há potencial para maior velocidade
• Bibliotecas locais são limitadas por memória e CPU
  • O pandas processa todos os dados em memória, então fica limitado ao tamanho da RAM
  • O streaming do Polars pode lidar com dados maiores que a RAM, mas algumas operações ainda exigem carregar o conjunto de trabalho na memória
• DuckDB é um banco de dados OLAP in-process chamado de “SQLite para analytics”
  • Sem infraestrutura separada, consulta com SQL CSVs locais, Parquet e pandas DataFrames

Processamento distribuído em grande escala

• Ao ultrapassar os limites de uma única máquina, os dados são divididos em várias partes e processados em paralelo em um cluster, com escalabilidade horizontal de acordo com a carga de trabalho
• Apache Hadoop foi uma das principais ferramentas no início, mas hoje é considerado legado e pode aparecer em ambientes antigos
• Apache Spark é hoje o padrão de fato, responsável por carregamento de dados, transformação, paralelização e otimização
  • PySpark oferece a API de DataFrame e uma camada de compatibilidade com pandas
  • SparkR foi descontinuado recentemente, e bindings para Java e Scala também são oferecidos
  • Como pode ler e gravar em vários storages, é usado tanto como mecanismo de consulta para data lakes quanto em trabalhos de transformação em grande escala
• Dask expande código Python para clusters de forma próxima às APIs familiares de pandas e numpy
• Ray é um framework de computação distribuída de uso geral, muito usado especialmente em treinamento de ML
• Apache Flink também processa lotes, mas seu foco principal é streaming

Streaming de eventos e Kafka

• O processamento de streams é adequado para casos em que o resultado é necessário imediatamente, como detecção de fraude em cartão de crédito, ou para validar eventos de análise web na chegada e enriquecê-los com geolocalização de IP antes de enviá-los ao ClickHouse
• Ao processar assim que os dados chegam, pode não ser necessário armazenar separadamente o payload bruto até a próxima execução em batch
• Apache Kafka é uma plataforma distribuída e tolerante a falhas de streaming de eventos que recebe eventos de produtores, os armazena e permite que consumidores os leiam
  • Diferentemente de uma fila de mensagens, os eventos não são apagados quando o consumidor confirma o recebimento, e vários consumidores podem relê-los repetidamente até que a política de retenção expire
  • O próprio Kafka não processa os dados; workers separados fazem isso como consumidores
• Kafka Connect conecta o Kafka a sistemas externos, como bancos de dados
• Kafka Streams é uma biblioteca em Java e Scala para executar transformações com estado, agregações por janela e joins sobre o Kafka
  • Ele roda embutido na aplicação e funciona apenas com Kafka
• Outras plataformas de streaming de eventos incluem Apache Pulsar, Redpanda e AWS Kinesis Data Streams

Motores de processamento de streams

• Apache Flink recebe a definição das fontes de eventos e do fluxo de processamento, e cuida da implantação no cluster, da escalabilidade e da recuperação de falhas
• O pipeline pode incluir filtragem, mapeamento de campos, agregações por janela, remoção de duplicatas e saída para outros tópicos do Kafka ou bancos de dados
• Um job implantado continua processando novos eventos, em vez de terminar como um batch
• Outras opções incluem Spark Structured Streaming, Google Cloud Dataflow e Azure Stream Analytics

Orquestração de jobs

• Quando transformações em dbt, jobs em Spark e scripts customizados aumentam, um orquestrador combina as etapas individuais em um único pipeline
• Ao definir cada job e suas dependências em código, geralmente em Python, cria-se um DAG, um grafo acíclico direcionado
• O orquestrador não processa os dados diretamente; ele coordena a execução de scripts Spark, chamadas de transformações dbt, requisições HTTP etc.
• É possível usar agendamentos, eventos do Kafka, execuções manuais pela UI, requisições HTTP e triggers criados por plugins
• Ele pode executar jobs independentes em paralelo, repetir apenas as etapas que falharam e retomar a partir desse ponto
• Como é voltado para processamento em batch, com execução do início ao fim, não se encaixa bem em pipelines de stream que ficam sempre ativos; nesses casos, depende-se do próprio motor de processamento, como o Flink
• Os principais produtos são Apache Airflow, Dagster, Prefect e Luigi
  • Luigi é mais antigo e hoje é menos popular

Observabilidade e monitoramento de qualidade

• A observabilidade de dados se divide em estado do pipeline e qualidade dos próprios dados
  • O monitoramento do pipeline verifica se houve execução, falhas e tempo gasto
  • O monitoramento dos dados verifica atualidade, anomalias no volume de dados e mudanças de schema não anunciadas
• Para pipelines, podem ser usadas ferramentas gerais de observabilidade de aplicações como Prometheus, Grafana e ELK, além dos recursos do próprio orquestrador
• Verificações de qualidade de dados podem ser implementadas com Great Expectations, definindo diretamente os formatos esperados, e com dbt tests
• Produtos automatizados aprendem padrões normais dos dados e depois detectam anomalias; exemplos incluem Monte Carlo, Bigeye e Metaplane

Cargas repetidas no pipeline

• O destino final de carga de um ETL é um warehouse, lake ou lakehouse, mas os dados não são salvos apenas uma vez no fim do pipeline: eles são armazenados várias vezes em diferentes formas
• A arquitetura medallion divide o nível de refinamento dentro do mesmo armazenamento em três camadas
  • Bronze é o dado bruto que entra diretamente da origem
  • Silver é o dado limpo e padronizado após correção de tipos, remoção de duplicatas, junção de fontes etc.
  • Gold é o dado agregado e modelado para um objetivo específico, como dashboards ou relatórios
• Analistas consultam principalmente tabelas Gold, enquanto engenheiros podem descer até Bronze para depurar o pipeline

Modelagem dimensional

• Se a estrutura medallion representa o nível de refinamento dos dados, a modelagem dimensional define o formato das tabelas do warehouse
• Popularizada por Ralph Kimball em The Data Warehouse Toolkit, ela separa tabelas fato e tabelas dimensão
• A tabela fato armazena um evento ou medição por linha, como pedido, pagamento ou visualização de página
  • Ela tende a ser longa e estreita, com muitos números e chaves estrangeiras para tabelas dimensão, e continua crescendo
• A tabela dimensão armazena o contexto em que o evento ocorreu, como cliente, produto ou data
  • Ela é mais larga e muda de forma relativamente lenta
• Quando as tabelas dimensão cercam a tabela fato central, forma-se um star schema
  • Também existe o snowflake schema, mais normalizado, sem relação com o produto Snowflake
• O grain define se uma linha representa um pedido, um item de pedido ou um pedido diário por cliente
• Um data mart é uma parte do warehouse voltada para um time ou tema específico, como marketing ou finanças, e geralmente fica na camada Gold
• Nem todas as equipes seguem isso à risca; aproveitando warehouses modernos rápidos e armazenamento barato, às vezes criam uma grande tabela única amplamente desnormalizada para cada objetivo

OLAP em tempo real para aplicações

• Para dashboards internos, as tabelas Gold do warehouse costumam ser suficientes, mas ao servir muitos usuários com latência de milissegundos, a demora das queries e o custo por consulta podem não ser adequados
• Dados que exigem alta concorrência e resposta rápida, como analytics voltado ao usuário, monitoramento interno em tempo real, leaderboards, itens populares e medição de uso, são movidos para um banco de dados OLAP em tempo real
• Apache Druid, Apache Pinot, ClickHouse e Apache Doris se enquadram nisso, e o ClickHouse é amplamente usado

Reverse ETL

• Reverse ETL envia de volta para ferramentas operacionais, como um CRM, os dados processados no warehouse
• Se você calcular o valor do tempo de vida do cliente com dados do Stripe e colocá-lo no HubSpot, a equipe de vendas pode identificar imediatamente clientes de alto valor
• Ferramentas dedicadas conectam tabelas e colunas aos campos de destino e lidam com falhas, tentativas de repetição, rate limits, alertas e sincronização incremental
• Entre as opções estão Airbyte Data Activation, Fivetran Activations, Hightouch e RudderStack
  • Fivetran Activations se chamava Census antes da aquisição

Catálogo de dados e camada semântica

• O catálogo de dados para pessoas guarda a origem dos dados, proprietários, políticas de acesso e informações de busca, dando contexto de negócio a tabelas e colunas
  • Tem um propósito diferente do metastore para mecanismos de consulta
  • Unity Catalog, DataHub e OpenMetadata são exemplos representativos
• A camada semântica armazena definições padrão de entidades de negócio, relacionamentos e métricas
  • Ela padroniza de quais tabelas e colunas vem o modelo de cliente, quais mercados pertencem à EMEA, se reembolsos são excluídos da receita etc.
  • Ao escolher as entidades e métricas corretas em uma ferramenta de BI ou agente de IA, ela converte isso na consulta necessária ou fornece as informações necessárias para gerar a consulta
• LookML do Looker, Cube, dbt Semantic Layer e os recursos semânticos do Unity Catalog são exemplos

Linhagem de dados

• Linhagem de dados (data lineage) rastreia como os dados foram transformados ao longo do pipeline
• Ela pode ser coletada automaticamente a partir do DAG do orquestrador, da análise do SQL de transformação e de eventos e metadados emitidos pelos jobs de processamento
• No nível de tabela, registra relações como gold.orders ter sido criada a partir de silver.orders e silver.customers
• No nível de coluna, rastreia até relações como customers.life_time_value ter sido calculada a partir de orders.total e subscription_payments.amount
• É usada para avaliar o impacto downstream da remoção de colunas, analisar a causa raiz de métricas incorretas e garantir conformidade no uso de informações de identificação pessoal
• Unity Catalog, DataHub e OpenMetadata oferecem visualização de linhagem, mas todo o pipeline precisa fornecer dados de rastreamento por conectores ou eventos manuais
• Em vez de formatos específicos de cada fornecedor, é possível usar o padrão OpenLineage, suportado por vários catálogos e ferramentas de processamento

Dashboards e relatórios de BI

• Dashboards e relatórios são o destino de consumo mais comum dos pipelines de dados e, em empresas pequenas, podem ser praticamente o único caso de uso
• Ferramentas de BI se conectam a warehouse, lakehouse e bancos de dados de aplicação para permitir a criação de gráficos e dashboards sem escrever código
• O ponto central é o self-service, em que usuários não técnicos criam gráficos ou exploram dados diretamente na interface, sem precisar pedir ajuda a analistas toda vez
• É possível enviar relatórios agendados por e-mail ou Slack, ou gerar alertas quando uma métrica ultrapassa um limite
• Tableau e Power BI são amplamente usados em grandes empresas e focam em visualizações poderosas e flexíveis
• Looker é voltado para organizações técnicas, com foco na camada semântica LookML
• Metabase pode ser configurado rapidamente, inclusive com self-hosting, e é acessível para usuários não técnicos
• Looker Studio é um produto separado, não usa LookML, tem menos recursos que o Looker e recentemente voltou a se chamar Data Studio

Análise operacional

• Análise operacional entrega dados dentro dos aplicativos usados diariamente por áreas não analíticas, e não em relatórios executivos
• Exemplos de uso incluem:
  • Sincronizar métricas de uso com o HubSpot para que a equipe de vendas faça upsell para os clientes certos
  • Sincronizar pedidos recentes, tickets de suporte e plano contratado com o Zendesk para que a equipe de suporte veja o contexto do cliente
  • Criar um aplicativo interno que mostre o status de adoção do produto por cliente para a equipe de customer success
• Reverse ETL é um método de entrega representativo, mas aplicativos internos de Customer 360 que consultam diretamente o warehouse também entram em análise operacional

Análise ad hoc, exploratória e notebooks

• Análise ad hoc (ad-hoc analysis) investiga, com os dados existentes, perguntas pontuais como a causa da queda nas inscrições ou quais coortes geraram reembolsos
• Análise exploratória examina os dados sem uma pergunta pré-definida para encontrar insights
• Como as próximas operações mudam conforme os resultados e costumam ser mais complexas que filtros e agregações simples, ferramentas comuns de relatório podem não ser suficientes
• É possível usar Python com pandas e Polars, interfaces SQL do warehouse, Spyder, RStudio etc.
• Notebooks combinam células de Markdown, código e SQL em um único arquivo e colocam saídas como imagens, gráficos interativos e tabelas ao lado do código
  • São bons para explorar passo a passo vendo os resultados da execução e para apresentar os achados
  • Jupyter, Google Colab, Deepnote e marimo são exemplos representativos
  • Plataformas como Databricks e Snowflake também oferecem seus próprios notebooks

Consumo de dados em machine learning

• ML é uma área separada, com feature store, treinamento, rastreamento e ferramentas de deploy, mas é um dos principais consumidores de dados
• Além de LLMs, existem modelos especializados como previsão de churn, recomendação, previsão de demanda e segmentação de clientes, e eles exigem dados de treinamento limpos antes de entrar em produção
• Data scientists ou ML engineers extraem do warehouse features como número de pedidos nos últimos 30 dias ou dias desde o último login para treinar e implantar modelos
• Os resultados das previsões voltam a ser usados em análise operacional, como score de churn no CRM, ou em recomendações de produto para usuários

Analytics embutido

• Analytics embutido oferece, dentro do aplicativo, análises como produtos populares, regiões dos clientes e ranking de busca para vendedores de um marketplace
• Se forem apenas cinco gráficos predefinidos e filtros limitados, é possível implementar diretamente as consultas, a UI e a biblioteca de gráficos
• Se os usuários precisarem fazer consultas complexas, é possível usar ferramentas de BI como Metabase, Looker e Tableau, ou produtos focados em embed como Sisense e Luzmo
• O aplicativo host cuida de autenticação e autorização, enquanto a ferramenta embutida lida com a UI de consulta e a renderização dos gráficos

Vender os próprios dados como produto

• Os dados podem ir além de matéria-prima para funcionalidades e se tornar o próprio produto
• É possível coletar, transformar e indexar dados de várias blockchains de criptomoedas para vender acesso a analistas, ou coletar resultados de busca do Google para vender a especialistas em SEO
• Para vender dados e acesso para consulta, é preciso ter pipelines robustos de coleta no tempo certo e recursos de consulta de alto desempenho

Governança de dados

• Governança de dados gerencia quem pode acessar dados sensíveis, como informações de identificação pessoal e dados de saúde, e os registros de acesso
• Também inclui propriedade dos dados, tratamento de privacidade como o direito ao esquecimento, local físico de armazenamento e período de retenção
• Isso pode ser apoiado por tecnologias como controle de papéis e acesso no warehouse, informações de propriedade no catálogo e rastreamento do uso de PII por meio da linhagem
• Não é apenas uma questão técnica; pessoas e processos têm grande peso, e o tema está fortemente ligado às áreas jurídica, de compliance e de segurança
• Todo o panorama de dados pode ser visto como um fluxo que coleta dados da origem, armazena, processa e usa esses dados, e sob cada categoria continuam surgindo mais ferramentas e opções detalhadas