1.データベース、データマートの運用・管理に関心のある方
2.データエンジニア、アナリストなどのデータ関連職種の方
3.効果的なデータ収集や管理に関心のある方
こんにちは、Analytics EngineerのJadenです。
今回は、データマート(DM)で広く活用されているWide-Datasetについて詳しく説明したいと思います。
Wide-Datasetとは何か、どのような特徴があるのか、DMでWide-Datasetを活用する際のメリットとデメリット、そしてWide-DatasetがDMで好まれている理由について、順に説明する予定です。
企業の全社的なすべてのデータを格納するデータウェアハウス(DWH)とは異なり、特定のテーマや部署に特化したデータのみを収集・格納するシステムです。 詳細な説明は「データアーキテクチャ(Data Architecture)とは？ わかりやすく解説」の記事でご確認ください。
Wide-DatasetとLong-Format Dataset
Wide-Datasetはデータを表形式で表現する際に、列(Column)の数を最大限に増やしてデータを幅広く格納する方式です。1つのテーブルにできるだけ多くの属性を含めてデータを格納することがその核心です。
これと対比される概念としてLong-Format Datasetがあります。Long-Format Datasetは行(Row)の数を増やしてデータを長く格納する方式で、データを正規化して冗長性を最小限に抑えるために主に用いられます。
分かりやすく説明するために、オンラインのショッピングモールの顧客の購入履歴データを例に挙げてみます。
Wide-Datasetの例
| 顧客ID | 名前 | Eメール | 購入総額 | 購入回数 | 購入商品カテゴリ | 最終購入日 | 初回購入日 | 平均購入サイクル(日) |
|---|---|---|---|---|---|---|---|---|
| 1 | A | a@email.com | 1,500,000 | 15 | 衣類、雑貨、食品 | 2023-04-15 | 2022-01-10 | 45 |
| 2 | B | b@email.com | 2,000,000 | 20 | 電子機器、本、食品 | 2023-04-10 | 2021-12-15 | 30 |
Long-Format Datasetの例
| 顧客ID | プロパティ | 値 |
|---|---|---|
| 1 | 名前 | A |
| 1 | Eメール | mailto:a@email.com |
| 1 | 購入総額 | 1,500,000 |
| 1 | 購入回数 | 15 |
| 1 | 購入商品カテゴリ | 衣類 |
| 1 | 購入商品カテゴリ | 雑貨 |
| 1 | 購入商品カテゴリ | 食品 |
| 1 | 最終購入日 | 2023-04-15 |
| 1 | 初回購入日 | 2022-01-10 |
| 1 | 平均購入サイクル (日) | 45 |
| 2 | 名前 | B |
| 2 | Eメール | mailto:b@email.com |
| 2 | 購入総額 | 2,000,000 |
| 2 | 購入回数 | 20 |
| 2 | 購入商品カテゴリ | 電子機器 |
| 2 | 購入商品カテゴリ | 本 |
| 2 | 購入商品カテゴリ | 食品 |
| 2 | 最終購入日 | 2023-04-10 |
| 2 | 初回購入日 | 2021-12-15 |
| 2 | 平均購入サイクル (日) | 30 |
Wide-Datasetは、1つのテーブルに多くの情報を格納するため、データ検索とクエリは高速ですが、データの冗長性とストレージ効率の低下の可能性があります。
一方、Long-Format Datasetはデータの正規化により重複を減らし、一貫性を維持するのに適していますが、照会時には複雑なクエリや結合が必要なため、パフォーマンスが低下する可能性があります。
データマートで Wide-Dataset が多く使われる理由
では、なぜデータマート(DM)ではWide-Datasetが好まれるのでしょうか。これには大きく3つの理由があります。
1.クエリパフォーマンスの向上
DMは特定の部署もしくはビジネスドメインに特化したデータストアであるため、その分野で頻繁に使われるデータを中心に構成されます。その際に Wide-Datasetを活用すれば、必要なデータをすべて1つのテーブルから照会することができ、複雑な結合操作を減らすことができます。
例えば、マーケティング部門のDMを構築するとします。
マーケティング活動に必要な顧客情報、購買履歴、キャンペーン反応データなどを1つのWide-Datasetで構成すれば、マーケティングチームで必要なデータをすばやく照会することができます。
SELECT
customer_name,
email,
total_purchase,
purchase_count,
product_category,
campaign_response
FROM
marketing_datamart
WHERE
campaign_name = 'Summer Promotion 2023';上記のクエリのように、1つのテーブルから必要なデータをすべて抽出できるため、クエリのパフォーマンスが向上します。結合(join)操作が無いため、SQLもシンプルになり、開発生産性も向上します。
2.分析の容易さの向上
DMの主な目的の一つは、ビジネス上の意思決定を支援することです。そのためには、データを様々な角度から迅速に分析できる必要がありますが、Wide-Datasetはこの分析の容易さを大幅に向上させます。
Wide-Datasetは、分析に必要な様々な属性を1つのテーブルに集約しているため、別途のデータ加工をすることなく、すぐに分析に活用することができます。また、BIツールやデータ視覚化ツールとの連携も良好で、分析プロセスがはるかに簡単になります。
例えば、営業部門のDMに顧客別売上データを合わせて、顧客ランク、地域、商品カテゴリなどの情報をWide-Datasetで構成したとします。
| 顧客ID | 顧客名 | 売上高 | 顧客評価 | 地域 | 購入商品カテゴリ |
|---|---|---|---|---|---|
| 1 | A会社 | 10,000,000 | Gold | 東京 | 家電、家具 |
| 2 | Bショップ | 5,000,000 | Silver | 大阪 | 食品、雑貨 |
| 3 | C企業 | 15,000,000 | Platinum | 東京 | 家電、家具、食品 |
このような構造であれば、売上を様々な基準で簡単に分析することができますか？
顧客のランク別、地域別、商品カテゴリ別の売上状況と推移を把握し、新たなインサイトを導き出すことがはるかに容易になります。
別途のデータ変換や加工なしで、元のデータをそのまま活用できるため、分析のスピードと効率が大幅に向上するのです。
3.業務に合わせたデータ構造
DMは、特定の部署やビジネスドメインに最適化されたデータ構造を持つことが特徴です。
そのため、その業務でよく使われるデータをWide-Datasetの形で構成することで、業務効率とユーザの利便性を高めることができます。
例えば、カスタマーサービス部門のDMを構築する場合、エージェントが問い合わせを処理する際に必要な情報を1つのテーブルにまとめておくことができます。顧客情報、問い合わせ履歴、注文履歴、配送状況などを1つのWide-Datasetで構成すれば、問い合わせ業務がずっと楽になりますよね。
| 問い合わせID | 顧客名 | 問い合わせ | 問い合わせタイプ | 注文番号 | 注文日 | 注文商品 | 配送状況 |
|---|---|---|---|---|---|---|---|
| 1 | A | 010-1234-5678 | 商品問い合わせ | 20230415-001 | 2023-04-15 | A商品 | 配送準備中 |
| 2 | B | 010-9876-5432 | 配送問い合わせ | 20230410-002 | 2023-04-10 | B商品 | 配達完了 |
| 3 | A | 010-1234-5678 | 返品問い合わせ | 20230415-001 | 2023-04-15 | A商品 | 配送準備中 |
このようにWide-Datasetを活用することで、エージェントが問い合わせ処理に必要なすべての情報を一目で把握することができます。顧客の問い合わせ内容と一緒に注文情報、配送状況などをすぐに確認することができ、迅速かつ正確な応対が可能になります。
また、Wide-Datasetは業務に特化したデータ構造であるため、該当部署のKPI(Key Performance Indicator)管理にも効果的です。
例えば、カスタマーサービス部門の主要KPIが「平均問い合わせ処理時間」であれば、Wide-Datasetに問い合わせ受付時刻と処理完了時刻を一緒に格納することで、簡単にKPIを測定し、モニタリングすることができます。
| 問い合わせID | 顧客名 | 問い合わせタイプ | 受付時刻 | 処理完了時刻 | 処理所要時間 (分) |
|---|---|---|---|---|---|
| 1 | A | 商品問い合わせ | 2023-04-15 10:30 | 2023-04-15 10:55 | 25 |
| 2 | B | 配送問い合わせ | 2023-04-15 11:10 | 2023-04-15 11:20 | 10 |
| 3 | A | 返品問い合わせ | 2023-04-15 13:40 | 2023-04-15 14:00 | 20 |
このようにWide-Datasetを構成すると、部署のパフォーマンス指標をリアルタイムで把握し、業務プロセスの改善に必要なインサイトを得ることができます。
このように、DMでWide-Datasetを活用すれば、業務に最適化されたデータ構造を実現することができます。これは単純にデータ照会のパフォーマンスを向上させるだけでなく、業務効率の向上やKPI管理の強化など、実質的なビジネス価値の創出につながる可能性があります。
部署ごとの業務特性を深く理解し、それに合わせたWide-Datasetを設計することがDM構築の重要なポイントと言えるでしょう。
Wide-Datasetのデメリット: データの冗長性と一貫性の維持の難しさ
Wide-Datasetはデータマートで多くの利点を提供しますが、いくつかの欠点もあります。最も大きな問題は、データの冗長性と一貫性を維持するのが難しいことです。
1.データの重複によるストレージ領域の浪費
Wide-Datasetでは1つのテーブルに多くの属性を含むため、データの重複が発生する可能性が高くなります。特に複数のテーブルで共通で使用される属性の場合、Wide-Datasetで重複して格納される可能性があります。
例えば、eコマース会社のDMを構築するとします。注文情報を含むWide-Datasetを以下のように構成した場合、
| 注文ID | 注文日 | 顧客名 | 顧客メール | 商品名 | 商品価格 | 購入数量 | 総注文額 | 配送先住所 | 配送状況 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 2023-04-01 | A | mailto:a@email.com | A商品 | 10,000 | 2 | 20,000 | 東京都千代田区 | 配達完了 |
| 2 | 2023-04-03 | B | mailto:b@email.com | B商品 | 20,000 | 1 | 20,000 | 大阪府大阪市 | 配送中 |
| 3 | 2023-04-05 | A | mailto:a@email.com | C商品 | 15,000 | 3 | 45,000 | 東京都千代田区 | 配送準備中 |
顧客名、顧客メールアドレス、配送先住所などの情報が重複して格納されていることが確認できます。このような重複データは、ストレージ領域を非効率に使用することになります。
特に、大容量データを扱う場合、重複データによるストレージ領域の浪費はさらに深刻になる可能性があります。データが増えれば増えるほど重複データも増えるため、ストレージコストと管理負担の増大につながる可能性があります。
2.データ変更時の一貫性維持の難しさ
Wide-Datasetのもう一つの欠点は、データ変更時に一貫性を維持するのが難しいということです。
Wide-Datasetでは、複数の属性が1つのテーブルに一緒に存在するため、特定の属性の値が変更されると、その属性を含むすべてのレコードに同じ変更が反映されなければなりません。
先ほど例に挙げた注文情報の Wide-Datasetで、もし顧客「A」のメールアドレスが変更されたらどうなるでしょうか？
| 注文ID | 注文日 | 顧客名 | 顧客メール | 商品名 | 商品価格 | 購入数量 | 総注文額 | 配送先住所 | 配送状況 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 2023-04-01 | A | mailto:a@email.com | A商品 | 10,000 | 2 | 20,000 | 東京都千代田区 | 配達完了 |
| 2 | 2023-04-03 | B | mailto:b@email.com | B商品 | 20,000 | 1 | 20,000 | 大阪府大阪市 | 配送中 |
| 3 | 2023-04-05 | A | mailto:a@newemail.com | C商品 | 15,000 | 3 | 45,000 | 東京都千代田区 | 配送準備中 |
顧客「A」のすべての注文レコードに対してメールアドレスを一括更新する必要があります。
簡単な例ではあまり問題がないように見えますが、実際のビジネス環境では数十から数百万件のレコードを扱う場合がよくあります。
このような場合、データ変更操作が非常に複雑になり、エラー発生のリスクも高くなります。
また、データ変更の過程で一貫性を確保するために、複雑な更新ロジックとトランザクション管理が必要です。関連するすべてのレコードに対する変更は同時に正確に行われなければならないため、データ管理の観点から多くの注意と努力が必要です。
それでもデータマートでWide-Datasetを使うのはなぜですか？
データの冗長性と一貫性維持の問題という欠点にもかかわらず、DMでWide-Datasetを使用する理由は、OLTP (Online Transaction Processing)とOLAP (Online Analytical Processing)の役割の違いにあります。
この2つの概念は、データベースシステムの利用目的と方式によって区別されます。それぞれの特性を理解することは Wide-Datasetの活用状況を把握するのに役立つでしょう。
OLTP: リアルタイムトランザクション処理に最適化されたシステム
OLTP (Online Transaction Processing)とは、ビジネスの運用過程で発生するトランザクションをリアルタイムで処理するシステムのことです。
トランザクションとは、データベースの状態を変化させる1つの論理的な作業単位です。例えば、eコマースプラットフォームでの顧客の注文、支払、配送などがすべてトランザクションに該当します。
OLTPシステムは、このようなトランザクションを迅速かつ確実に処理することに重点を置いています。顧客がWebサイトからプラットフォームに注文を入れると、在庫管理、支払承認、配送依頼などの後続のプロセスも迅速に行われなければなりません。
したがって、OLTPシステムには、短い応答時間、高い同時処理能力、そしてデータ整合性の保証が重要な要件となります。
この目的のため、一般的にOLTPシステムでは正規化されたデータモデルを使用します。正規化とは、データの冗長性を最小限に抑えて独立性を高めるデータ構造化プロセスで、複数の関連するテーブルにデータを分散格納することが特徴です。
これは、データの一貫性を維持するのに有利であり、ストレージ領域も効率的に使用できますが、複雑な結合操作によりクエリのパフォーマンスが低下する可能性があるという欠点があります。
ただし、OLTPシステムでは単純な構造のクエリがほとんどで、データの整合性が非常に重要であるため、正規化されたデータモデルが適しています。
例えば、顧客情報をCustomerテーブルに、注文情報をOrderテーブルに、商品情報をProductテーブルに別々に分けて格納し、各テーブル間の関係をキー(Key)で定義するのが一般的なOLTPデータモデリング方法です。
OLAP: 大量データ分析に最適化されたシステム
一方、OLAPとは、意思決定支援のために大量のデータを様々な角度から迅速に分析するシステムのことです。DWH (Data Warehouse)やDM (Data Mart)がOLAPシステムの代表的な例で、複数の運用システム(OLTP)のデータを抽出、変換、ロード(ETL)して分析しやすい形で格納します。
OLAPシステムの主な目的は、経営陣やビジネスユーザがデータドリブンの戦略的意思決定を行うことができるように支援することです。このため、売上推移分析、顧客セグメンテーション、商品選好度分析など様々な分析クエリを実行することになりますが、その場合は大量のデータを複雑な条件で照会して集計することが一般的です。
したがって、OLAPシステムでは、クエリのパフォーマンスとユーザの利便性が最も重要な考慮事項です。数億、数十億件のデータを対象に複雑な分析クエリを実行しなければならないため、速い応答速度とユーザフレンドリーなデータ構造が不可欠です。
この目的のため、OLAPシステムでは主に非正規化されたデータモデル、特にスタースキーマ(Star Schema)やスノーフレークスキーマ(Snowflake Schema)などの多次元モデルを使用します。
多次元モデルはファクト(Fact)テーブルとディメンション(Dimension)テーブルで構成されます。ファクトテーブルは測定可能な数値データを含み、ディメンションテーブルはファクトを説明する属性情報を含みます。この2つを結合して様々な分析クエリを実行することになりますが、その場合、Wide-Datasetを活用すれば、クエリのパフォーマンスを大幅に向上させることができます。
Wide-Datasetは、ファクトテーブルとディメンションテーブルを事前に結合して1つの幅の広いテーブルに構成したものです。これにより、分析クエリを実行する際にテーブル間の結合操作を減らすことができ、クエリを高速化することができます。
例えば、売上分析のための多次元モデルを考えてみましょう。ファクトテーブルであるSalesには、製品、顧客、地域、時間などの各ディメンション(次元)に対する外部キーと売上高、数量などの測定値が格納されます。
[ファクトテーブル]
Sales:
| sales_id | product_id | customer_id | region_id | date_id | sales_amount | quantity |
|---|---|---|---|---|---|---|
| 1 | 101 | 1001 | 201 | 20230101 | 1000 | 10 |
| 2 | 102 | 1002 | 202 | 20230101 | 1500 | 15 |
| 3 | 101 | 1003 | 201 | 20230102 | 2000 | 20 |
[ディメンションテーブル]
Product:
| product_id | product_name | category | price |
|---|---|---|---|
| 101 | 商品A | カテゴリ1 | 100 |
| 102 | 商品B | カテゴリ2 | 150 |
Customer:
| customer_id | customer_name | age | gender |
|---|---|---|---|
| 1001 | 顧客1 | 25 | 男 |
| 1002 | 顧客2 | 30 | 女 |
| 1003 | 顧客3 | 40 | 男 |
Region:
| region_id | region_name |
|---|---|
| 201 | 東京 |
| 202 | 大阪 |
Date:
| date_id | year | month | day |
|---|---|---|---|
| 20230101 | 2023 | 1 | 1 |
| 20230102 | 2023 | 1 | 2 |
では、「2023年1月の地域別、カテゴリ別の売上合計」を求めるクエリを考えてみましょう。
SELECT
r.region_name,
p.category,
SUM(s.sales_amount) AS total_sales
FROM
Sales s
JOIN Product p ON s.product_id = p.product_id
JOIN Region r ON s.region_id = r.region_id
JOIN Date d ON s.date_id = d.date_id
WHERE
d.year = 2023 AND d.month = 1
GROUP BY
r.region_name,
p.category;上のクエリは4つのテーブル(Sales、Product、Region、Date)を結合しています。データ量が大きいほど、結合(join)による負荷が増大し、クエリのパフォーマンスが低下する可能性があります。
この時、Wide-Datasetを活用すれば、このような問題を解決することができます。ファクトテーブルとすべてのディメンションテーブルを事前に結合して、1つのWide-Datasetを作成しておくことです。
[Wide-Dataset]
Sales_Wide:
| sales_id | product_id | product_name | category | price | customer_id | customer_name | age | gender | region_id | region_name | date_id | year | month | day | sales_amount | quantity |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 101 | 商品A | カテゴリ1 | 100 | 1001 | 顧客1 | 25 | 男 | 201 | 東京 | 20230101 | 2023 | 1 | 1 | 1000 | 10 |
| 2 | 102 | 商品B | カテゴリ2 | 150 | 1002 | 顧客2 | 30 | 女 | 202 | 大阪 | 20230101 | 2023 | 1 | 1 | 1500 | 15 |
| 3 | 101 | 商品A | カテゴリ1 | 100 | 1003 | 顧客3 | 40 | 男 | 201 | 東京 | 20230102 | 2023 | 1 | 2 | 2000 | 20 |
Sales_Wideテーブルを使用すると、結合(join)無しで簡単なクエリで結果を取得することができます。
SELECT
region_name,
category,
SUM(sales_amount) AS total_sales
FROM
Sales_Wide
WHERE
year = 2023 AND month = 1
GROUP BY
region_name,
category;実行計画を見ると、結合(join)がなくなり、クエリが高速になったことを確認することができます。特に、大容量データを扱う場合、Wide-Datasetのパフォーマンス改善効果はより顕著です。
まとめ
OLAPシステムでは、Wide-Datasetはアドホック分析とダッシュボード構築において非常に便利で効果的なデータ構造です。特に、ビジネスユーザーがデータを探索し、即座にインサイトを得るアドホック分析シナリオではWide-Datasetの真価が最大限に発揮されます。
アドホック(Ad-hoc)分析とは、事前に定義されたクエリやレポートではなく、ユーザの自発的な問いに基づいてその都度データを探索して分析する方法を指します。この場合、分析対象や視点が随時変化するため、データ構造の柔軟性とクエリの簡潔性が非常に重要な要素となります。
この点で、Wide-Datasetの利点が浮上します。Wide-Datasetは、特定のテーマ領域のすべての主要情報を1つのテーブルにまとめているため、ユーザは複雑な結合を行うことなく、さまざまな角度からデータを簡単に探索することができます。関心のあるメジャーやディメンジョンを選択して簡単なフィルタリングと集計を行うだけで、必要な情報を即座に抽出できます。このため、アドホック分析の敏捷性と柔軟性が大幅に向上します。
また、Wide-Datasetはビジネス用語ベースの列構造を持つため、ユーザはデータの意味を直感的に理解することができます。これは、アドホック分析の過程でユーザの自律性と参加度を高める要因として作用します。データに対する理解度が高くなるほど、ユーザはより多様で深みのある質問を投げかけるようになり、すぐに新たなインサイト発見につながる可能性があります。
Analytics Engineer (関連記事参照)は、このようなWide-Datasetの設計と実装を担当します。ビジネス要件とユーザの視点を深く理解し、それをデータ構造に反映させることが重要な役割です。さらに、構築されたWide-Datasetを活用して実際の分析を行い、ダッシュボードに実装する全てのプロセスを主導します。そのため、Analytics Engineerにはデータ分析と視覚化能力の両方が求められます。
