Scegliere i tipi di dati delle colonne

La scelta del tipo di dati corretto per ogni colonna influisce direttamente sulla qualità dei dati, sull'efficienza di archiviazione e sulle prestazioni delle query. Quando si seleziona un tipo inappropriato, si rischia di perdere precisione, sprecare spazio di archiviazione o bloccare operazioni che richiedono caratteristiche specifiche del tipo. In questa unità si apprenderà come valutare i dati e selezionare i tipi di colonna più appropriati in Azure Databricks.

Informazioni sulle categorie dei tipi di dati

Azure Databricks organizza i tipi di dati in categorie in base alle caratteristiche e ai casi d'uso. Comprendere queste categorie consente di restringere le opzioni quando si sceglie un tipo per una colonna specifica.

I tipi numerici gestiscono valori matematici e calcoli. Sono disponibili diverse opzioni:

I tipi di data e ora rappresentano i dati temporali:

I tipi di testo e binari archiviano sequenze di caratteri e byte:

• STRING per il testo a lunghezza variabile
• BINARY per sequenze di byte grezze

I tipi complessi organizzano i dati annidati o ripetuti:

• ARRAY per sequenze ordinate di elementi
• MAP per coppie chiave-valore
• STRUCT per i record con campi denominati

Selezionare il tipo numerico corretto

I dati numerici richiedono un'attenta selezione dei tipi perché tipi diversi hanno caratteristiche di precisione, intervallo e archiviazione diverse. La scelta influisce sia sull'integrità dei dati che sulle prestazioni.

Per i numeri interi, associare il tipo all'intervallo di valori:

Quando si creano tabelle, specificare il tipo appropriato per ogni colonna:

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

Per i numeri decimali, la scelta tra DECIMAL i tipi a virgola mobile dipende dai requisiti di precisione:

-- 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
);

Scegliere correttamente i tipi temporali

La selezione del tipo di dati temporale dipende dal fatto che sia necessaria la consapevolezza del fuso orario e il livello di precisione richiesto dall'applicazione.

Usare DATE quando sono necessarie solo date di calendario senza componenti di ora:

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

Per i timestamp, scegliere tra i tipi timezone-aware e timezone-naïve:

-- 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
);

Il TIMESTAMP tipo converte i valori in UTC per l'archiviazione e applica il fuso orario della sessione durante il recupero dei valori. Questo comportamento garantisce un ordinamento coerente tra fusi orari, ma può causare confusione se si prevede che i valori rimangano invariati.

Usare tipi complessi

I tipi complessi consentono di archiviare dati strutturati, annidati o ripetuti all'interno di una singola colonna. Sono utili quando i dati non rientrano in un modello relazionale flat.

Usare ARRAY quando si hanno più valori dello stesso 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;

Usare MAP per coppie chiave-valore con chiavi dinamiche:

-- 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;

Usare STRUCT quando si dispone di un set fisso di campi denominati:

-- 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;

Applicare le procedure consigliate per la selezione dei tipi

Quando si valutano i dati per la selezione dei tipi, tenere presenti queste linee guida pratiche:

Trova la corrispondenza del tipo con la natura e l'intervallo dei dati. Non usare BIGINT per i valori che non superano mai alcune migliaia. I byte aggiuntivi si moltiplicano tra milioni di righe.

Considerare la nullabilità. Se una colonna non deve mai contenere valori Null, documentare questo vincolo. Sebbene i tipi di dati non impongano la nullabilità di default, è possibile aggiungere NOT NULL vincoli alle definizioni di tabella.

Convalidare i tipi durante l'inserimento. Effettuare il cast dei dati in arrivo nel tipo di destinazione all'inizio della pipeline per intercettare errori di tipo prima della propagazione.

-- 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;

Usare cast espliciti durante la conversione dei tipi. Le conversioni implicite possono avere esito positivo in modo invisibile all'utente anche quando i dati vengono persi. I casting espliciti rendono chiare le tue intenzioni e aiutano a identificare problemi nei test.

Queste procedure consentono di creare pipeline in cui i tipi di dati fungono da forma di documentazione e convalida, rilevando gli errori in anticipo anziché consentendo loro di influire sull'analisi downstream.