Noções básicas sobre os formatos de arquivo e a estrutura de um data warehouse moderno
Quando você carrega dados no seu data warehouse, os tipos de arquivos e os métodos usados para ingerir os dados variam de acordo com a origem. Por exemplo, carregar dados de sistemas de arquivos locais, armazenamentos de dados relacionais ou fontes de dados de streaming exigem abordagens diferentes da ingestão para o data lake ou do armazenamento de dados intermediário para colocar os dados refinados na camada de serviço. É importante entender os diferentes tipos de arquivo e qual deles deve ser usado para armazenamento bruto em relação às versões refinadas para consultas analíticas. Outras considerações sobre design incluem estruturas hierárquicas para otimizar as consultas e as atividades de carregamento de dados. Esta unidade descreve os tipos de arquivos e os casos de uso ideais e a melhor maneira de organizá-los no data lake.
Formatos de arquivo com suporte para ingerir dados brutos em lote
Na engenharia de dados, tendemos a descrever a velocidade do carregamento de dados como uma das três latências:
- Lote: consultas ou programas que levam dezenas de minutos, horas ou dias para serem concluídos. As atividades podem incluir estruturação inicial de dados, pipeline de ETL completo ou preparação para análise downstream.
- Interactive Query: consulta de dados em lote em velocidades interativas "humanas"que, com a geração atual de tecnologias, significa que os resultados estão prontos em intervalos de tempo medidos de segundos a minutos.
- Em tempo real/quase em tempo real: o processamento de um fluxo normalmente infinito de dados de entrada (fluxo), cujo tempo até que os resultados fiquem prontos é curto, medido em milissegundos ou segundos nos casos mais longos.
Quando se trata de ingerir dados brutos em lote de novas fontes de dados, esses formatos de dados têm suporte nativo no Azure Synapse:
- CSV
- Parquet
- ORC
- JSON
No entanto, se você usar o Apache Spark com notebooks do Azure Synapse, poderá explorar e processar mais tipos de arquivos para seus dados brutos.
Ingerir dados de streaming em pools de SQL dedicados do Azure Synapse
O processamento de dados que chega na terceira latência (em tempo real/quase em tempo real) também é conhecido como processamento de dados de streaming. As fontes de dados de streaming podem incluir dispositivos IoT e sensores, transações financeiras, dados de sequência de cliques da Web, fábricas e dispositivos médicos, para citar alguns.
O Azure oferece serviços de ingestão de fluxo de uso específico, como o Hub IoT do Azure e os Hubs de Eventos do Azure (com ou sem o suporte do Kafka), que são robustos, comprovados e apresentam bom desempenho. No seu pipeline de dados, você precisa coletar mensagens desses ou de serviços semelhantes e processá-los usando o Azure Stream Analytics, o Azure Functions, o Azure Databricks ou outros serviços que permitem ingerir e processar dados de streaming.
Sua meta pode ser colocar esses dados no seu data lake, como a conta do ADLS (Azure Data Lake Storage) Gen2 associada ao workspace do Synapse Analytics e usar notebooks do Synapse Spark ou consultas T-SQL com um pool de SQL sem servidor para explorar e transformar os dados. Nesse caso, provavelmente, você salvará esses dados em um dos formatos brutos, como CSV ou JSON. O Azure Stream Analytics simplifica essa tarefa conectando-se ao Hub IoT ou aos Hubs de Eventos como uma fonte de entrada e gerando arquivos para a conta de armazenamento do ADLS Gen2 como uma saída. Você pode especificar um padrão de caminho que ajudará você a estruturar seus dados para cargas de trabalho analíticas ideais por meio da remoção de dados baseada em caminho. Por exemplo, defina o seguinte padrão de caminho na saída do ADLS Gen2: tran/sensor/{datetime:yyyy}/{datetime:MM}/{datetime:dd}. Outras opções permitem que você defina a serialização, como JSON, a codificação, como UTF-8, o número mínimo de linhas por arquivo, como 100 etc.
No entanto, se você quiser colocar os dados de streaming em um pool de SQL dedicado, algumas opções que você poderá escolher são primeiro processar e armazenar os dados no data lake, conforme descrito acima. Em seguida, carregue os dados em um pool de SQL dedicado por meio de uma das várias técnicas de carregamento de dados, como pipelines do Azure Synapse, pools do Synapse Spark ou instruções COPY. Isso permite que você use o data lake como uma área de preparo ou mantenha o formato bruto no data lake, além de uma versão mais refinada dos dados no pool de SQL dedicado.
Outra opção é usar o Azure Stream Analytics com o Azure Synapse Analytics (pool de SQL dedicado) como um coletor de saída para a ingestão de dados de alta taxa de transferência com trabalhos do Azure Stream Analytics.
Depois de criar a saída do Synapse Analytics, você pode defini-la como o destino na consulta do Stream Analytics. No exemplo abaixo, temos uma entrada dos Hubs de Eventos chamada CallStream e uma saída do Synapse Analytics chamada sqlpool-demo-asaoutput. A consulta SQL simplesmente grava todos os dados de entrada diretamente no pool de SQL dedicado. Como alternativa, você pode selecionar apenas propriedades específicas e transformar os tipos de dados do fluxo de entrada e usar uma das funções de janela para agregar dados antes de gravá-los no pool de SQL dedicado.
O uso do Stream Analytics com o Synapse Analytics dessa maneira permite que você selecione o banco de dados do pool de SQL dedicado e a tabela na qual a consulta do Stream Analytics gravará os dados de streaming. Essa ingestão de fluxo nativa é otimizada para gravar rapidamente os dados diretamente no pool de SQL dedicado sem precisar primeiro colocar os dados em outro lugar.
Tipos de arquivos recomendados
Dados brutos
Para dados brutos, recomendamos que os dados sejam armazenados no formato nativo. Normalmente, os dados de bancos de dados relacionais devem ser armazenados no formato CSV. Esse é o formato com suporte na maioria dos sistemas fornecendo, portanto, a maior flexibilidade.
Para dados de APIs Web e bancos de dados NoSQL, o JSON é o formato recomendado.
Versões refinadas para dados
Quando se trata de armazenar versões refinadas dos dados para possíveis consultas, o formato de dados recomendado é Parquet.
Há um alinhamento do setor em relação ao formato Parquet para o compartilhamento de dados na camada de armazenamento (por exemplo, em cenários de mecanismos Hadoop, Databricks e SQL Engine). Parquet é um formato de alto desempenho orientado por coluna, otimizado para cenários de Big Data.
Os formatos de coluna como Parquet oferecem benefícios de armazenamento e desempenho. Os valores são clusterizados por coluna para que a compactação seja mais eficiente (para reduzir o volume de armazenamento), e um mecanismo de consulta pode reduzir as projeções de coluna (a fim de reduzir a E/S de leitura da rede e do disco ignorando as colunas indesejadas), também conhecido como remoção de colunas. Os tipos de dados semelhantes (para uma coluna) são armazenados juntos em arquivos Parquet, resultando em uma compactação de dados e esquemas de codificação eficientes.
O Parquet armazena o esquema de arquivo nos metadados do arquivo. Os arquivos CSV não armazenam metadados do arquivo e, portanto, os leitores precisam receber o esquema ou o esquema precisa ser inferido. O fornecimento de um esquema é entediante, e a inferência de um esquema é cara e propensa a erros.
Organizar a estrutura de arquivos para consultas analíticas
A primeira coisa que você deve considerar ao ingerir dados no data lake é como estruturar ou organizar os dados nele. Use o ADLS (Azure Data Lake Storage) Gen2 (no portal do Azure, essa é uma conta de armazenamento do Azure com um namespace hierárquico habilitado).
Um mecanismo chave do ADLS Gen2 para fornecer desempenho do sistema de arquivos com os preços e na escala do armazenamento de objetos, além de um namespace hierárquico. Isso permite que a coleta de objetos / arquivos em uma conta seja organizada em uma hierarquia de diretórios e subdiretórios aninhados, da mesma forma que o sistema de arquivos do computador é organizado. Com um namespace hierárquico habilitado, uma conta de armazenamento se torna capaz de fornecer a escalabilidade e a relação custo-benefício do armazenamento de objetos, com semântica do sistema de arquivos que são conhecidas para os mecanismos e estruturas de análise.
No ADLS Gen2, é uma melhor prática ter uma conta de armazenamento dedicada para produção e uma conta de armazenamento separada para cargas de trabalho de desenvolvimento e teste. Isso garantirá que as cargas de trabalho de desenvolvimento ou teste nunca interfiram na produção.
Um método comum para estruturar pastas dentro de um data lake é organizar os dados em pastas separadas pelo grau de refinamento. Por exemplo, uma pasta bronze pode conter dados brutos, silver contém os dados limpos, preparados e integrados e gold contém dados prontos para dar suporte à análise, o que pode incluir refinamentos finais, como agregações previamente computadas. Se mais níveis de refinamento forem necessários, essa estrutura poderá ser modificada, conforme necessário, para incluir mais pastas.
Ao trabalhar com o Data Lake Storage Gen2, o seguinte deve ser considerado:
- Quando os dados são armazenados no Data Lake Storage Gen2, o tamanho do arquivo, o número de arquivos e a estrutura da pasta afetam o desempenho.
- Se você armazenar os dados como vários arquivos pequenos, isso poderá afetar negativamente o desempenho. Em geral, organize seus dados em arquivos de tamanho maior para obter um melhor desempenho (256 MB a 100 GB de tamanho).
- Alguns mecanismos e aplicativos podem ter problemas para processar com eficiência arquivos maiores que 100 GB.
- Às vezes, os pipelines de dados têm controle limitado sobre os dados brutos, que têm muitos arquivos pequenos. Recomenda-se ter um processo de "cooking" que gere arquivos maiores para usar em aplicativos downstream.