Escolher tipos de dados de coluna

Escolher o tipo de dados correto para cada coluna afeta diretamente a qualidade dos dados, a eficiência de armazenamento e o desempenho da consulta. Quando você seleciona um tipo inadequado, corre o risco de perder precisão, desperdiçar espaço de armazenamento ou bloquear operações que exigem características de tipo específicas. Nesta unidade, você aprenderá a avaliar seus dados e selecionar os tipos de coluna mais apropriados no Azure Databricks.

Entender categorias de tipo de dados

O Azure Databricks organiza tipos de dados em categorias com base em suas características e casos de uso. Entender essas categorias ajuda você a restringir suas opções ao escolher um tipo para uma coluna específica.

Os tipos numéricos lidam com valores matemáticos e cálculos. Você tem várias opções:

Os tipos de data e hora representam dados temporais:

Tipos de texto e binário armazenam caracteres e sequências de bytes:

• STRING para texto de comprimento variável
• BINARY para sequências de bytes brutos

Tipos complexos organizam dados aninhados ou repetidos:

• ARRAY para sequências ordenadas de elementos
• MAP para pares chave-valor
• STRUCT para registros com campos nomeados

Selecione o tipo numérico correto

Os dados numéricos exigem uma seleção de tipo cuidadosa porque diferentes tipos têm diferentes características de precisão, intervalo e armazenamento. Sua escolha afeta a integridade e o desempenho dos dados.

Para números inteiros, corresponda o tipo ao intervalo de valores:

Ao criar tabelas, especifique o tipo apropriado para cada coluna:

CREATE TABLE orders (
    order_id INT,
    status_code TINYINT,
    total_items SMALLINT,
    transaction_id BIGINT
);

Para números decimais, a escolha entre DECIMAL os tipos de ponto flutuante depende de seus requisitos de precisão:

-- DECIMAL(p,s): exact precision for financial calculations
-- p = total digits, s = digits after decimal point
CREATE TABLE transactions (
    transaction_id INT,
    amount DECIMAL(10,2),         -- Exact: up to 99,999,999.99
    tax_rate DECIMAL(5,4)         -- Exact: up to 9.9999
);

-- DOUBLE: approximate, suitable for scientific calculations
CREATE TABLE measurements (
    sensor_id INT,
    temperature DOUBLE,           -- Approximate, large range
    pressure DOUBLE
);

Escolher tipos temporais corretamente

A seleção de tipo de dados temporais depende se você precisa de reconhecimento de fuso horário e de qual nível de precisão seu aplicativo requer.

Use DATE quando precisar apenas de datas de calendário sem componentes de hora:

CREATE TABLE employees (
    employee_id INT,
    hire_date DATE,
    birth_date DATE
);

Para carimbos de data/hora, escolha entre tipos com reconhecimento de fuso horário e tipos sem reconhecimento de fuso horário.

-- TIMESTAMP: normalizes to UTC internally, applies session timezone on read
-- Use when tracking events across time zones
CREATE TABLE audit_log (
    log_id BIGINT,
    event_time TIMESTAMP,
    user_id INT
);

-- TIMESTAMP_NTZ: no timezone conversion
-- Use when the time should remain as entered
CREATE TABLE schedules (
    schedule_id INT,
    local_meeting_time TIMESTAMP_NTZ
);

O TIMESTAMP tipo converte valores em UTC para armazenamento e aplica o fuso horário de sessão ao recuperar valores. Esse comportamento garante uma ordenação consistente entre fusos horários, mas pode causar confusão se você espera que os valores permaneçam inalterados.

Trabalhar com tipos complexos

Tipos complexos permitem armazenar dados estruturados, aninhados ou repetidos em uma única coluna. Eles são úteis quando seus dados não se encaixam em um modelo relacional simples.

Use ARRAY quando tiver vários valores do mesmo tipo:

-- Store a list of tags for each product
CREATE TABLE products (
    product_id INT,
    name STRING,
    tags ARRAY<STRING>
);

-- Query array elements
SELECT product_id, tags[0] AS primary_tag FROM products;

Use MAP para pares chave-valor com chaves dinâmicas:

-- Store flexible attributes as key-value pairs
CREATE TABLE devices (
    device_id INT,
    properties MAP<STRING, STRING>
);

-- Access map values by key
SELECT device_id, properties['firmware_version'] AS firmware FROM devices;

Use STRUCT quando você tiver um conjunto fixo de campos nomeados:

-- Store address as a structured type
CREATE TABLE customers (
    customer_id INT,
    address STRUCT<street: STRING, city: STRING, postal_code: STRING>
);

-- Access struct fields
SELECT customer_id, address.city FROM customers;

Aplicar práticas recomendadas de seleção de tipo

Ao avaliar dados para seleção de tipo, considere estas diretrizes práticas:

Corresponda o tipo à natureza e ao intervalo dos dados. Não use BIGINT para valores que nunca excedam alguns milhares. Os bytes extra se multiplicam em milhões de linhas.

Considere a nulabilidade. Se uma coluna nunca deve conter valores nulos, documente essa restrição. Embora os tipos de dados não imponham a nulidade por padrão, você pode adicionar NOT NULL restrições às definições de tabela.

Validar tipos durante a ingestão. Converta dados de entrada no tipo de destino no início do pipeline para detectar incompatibilidades de tipo antes da sua propagação.

-- Cast during data loading
INSERT INTO target_table
SELECT 
    CAST(raw_id AS INT) AS id,
    CAST(raw_amount AS DECIMAL(10,2)) AS amount,
    CAST(raw_date AS DATE) AS transaction_date
FROM staging_table;

Use conversões explícitas ao converter tipos. As conversões implícitas podem ser bem-sucedidas silenciosamente mesmo quando os dados são perdidos. Conversões explícitas deixam suas intenções claras e ajudam a identificar problemas durante os testes.

Essas práticas ajudam você a criar pipelines em que os tipos de dados servem como uma forma de documentação e validação, capturando erros mais cedo em vez de permitir que eles afetem a análise downstream.