列データ型の選択

各列に適切なデータ型を選択すると、データの品質、ストレージの効率、クエリのパフォーマンスに直接影響します。 不適切な型を選択すると、精度が失われたり、記憶域スペースが無駄になったり、特定の型の特性を必要とする操作がブロックされたりするリスクがあります。 このユニットでは、データを評価し、Azure Databricks で最も適切な列の種類を選択する方法について説明します。

データ型のカテゴリについて

Azure Databricks では、特性とユース ケースに基づいて、データ型がカテゴリに編成されます。 これらのカテゴリを理解すると、特定の列の型を選択するときにオプションを絞り込むのに役立ちます。

数値型 は、数学値と計算を処理します。 いくつかのオプションがあります。

日付/時刻型は、 テンポラル データを表します。

テキスト型とバイナリ型 には、文字シーケンスとバイト シーケンスが格納されます。

• STRING 可変長テキストの場合
• BINARY 生バイト列の場合

複合型は 、入れ子になったデータまたは繰り返しデータを整理します。

• ARRAY 要素の順序付けられたシーケンスの場合
• MAP キーと値のペアの場合
• STRUCT 名前付きフィールドを持つレコードの場合

適切な数値型を選択する

数値データでは、有効桁数、範囲、およびストレージ特性が異なるため、型を慎重に選択する必要があります。 選択すると、データの整合性とパフォーマンスの両方に影響します。

整数の場合は、型を値の範囲と一致させます。

テーブルを作成するときは、各列に適切な型を指定します。

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

10進数の場合、DECIMAL型と浮動小数点型の選択は、精度の必要性によって異なります。

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

テンポラル型を正しく選択する

テンポラル データ型の選択は、タイムゾーン認識が必要かどうか、およびアプリケーションで必要な精度のレベルによって異なります。

DATEは、時刻コンポーネントのないカレンダーの日付のみが必要な場合に使用します。

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

タイムスタンプの場合は、タイムゾーン対応型とタイムゾーンナイーブ型のいずれかを選択します。

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

TIMESTAMP型は、ストレージの値を UTC に変換し、値を取得するときにセッション タイムゾーンを適用します。 この動作により、タイム ゾーン間で一貫した順序付けが保証されますが、値が変更されないと予想される場合は混乱を招く可能性があります。

複合型データの処理

複合型を使用すると、構造化データ、入れ子になったデータ、または繰り返しデータを 1 つの列に格納できます。 これは、データがフラット リレーショナル モデルに適合しない場合に便利です。

同じ型の値が複数ある場合は、 ARRAY を使用します。

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

動的キーを持つキーと値のペアには、 MAP を使用します。

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

名前付きフィールドの固定セットがある場合は、 STRUCT を使用します。

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

型選択のベスト プラクティスを適用する

型選択のデータを評価する場合は、次の実用的なガイドラインを考慮してください。

データの性質と範囲に型を一致させます。 数千を超えない値には BIGINT を使用しないでください。 余分なバイト数は、数百万行にまたがって乗算されます。

null 値の許容を検討してください。 列に null 値を含めてはならない場合は、この制約を文書化します。 データ型では、既定では null 許容は適用されませんが、テーブル定義に NOT NULL 制約を追加できます。

インジェスト中に型を検証します。 パイプラインの早い段階で受信データをターゲット型にキャストして、型の不一致が伝播する前にキャッチします。

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

型を変換するときに明示的なキャストを使用します。 暗黙的な変換は、データが失われた場合でも、暗黙的に成功する可能性があります。 明示的なキャストにより、意図が明確になり、テスト中の問題の特定に役立ちます。

これらのプラクティスは、データ型がドキュメントと検証の形式として機能し、ダウンストリーム分析に影響を与えるのではなく、エラーを早期にキャッチするパイプラインを構築するのに役立ちます。