データ構造（縦持ちと横持ち）とTableauのパフォーマンスの関係
Tableauのデータソースを考える上で、「縦持ち」「横持ち」と呼ばれるデータ構造を検討することがあります。今回は、Tableauのパフォーマンスの観点からは、データ構造をどのように考えればいいのかをまとめたいと思います。
データ構造の縦持ちと横持ちとは
データ構造は、「縦持ち」と「横持ち」と呼ばれる2種類の構造があります。
まずは、Excelなどで人がよく見る下の表のような構造を「横持ち」と呼びます。
| カテゴリー | 2018 | 2019 | 2020 | 2021 |
|---|---|---|---|---|
| 家具 | 150 | 120 | 100 | 200 |
| 家電 | 100 | 140 | 220 | 300 |
このデータ構造は一般的には人がデータを見る場合には見やすい形になっていますが、システムとしては扱いづらい構造です。
一方で、システムが扱いやすいデータ構造とは下の表な「縦持ち」のデータ構造になります。
| カテゴリー | 年 | 売上 |
|---|---|---|
| 家具 | 2018 | 150 |
| 家具 | 2019 | 120 |
| 家具 | 2020 | 100 |
| 家具 | 2021 | 200 |
| 家電 | 2018 | 100 |
| 家電 | 2019 | 140 |
| 家電 | 2020 | 220 |
| 家電 | 2021 | 300 |
Tableauも通常チャートを作成する場合には、「縦持ち」のデータ構造の方が作成しやすいので「縦持ち」のデータ構造でデータソースの設計をします。
データ構造とパフォーマンス
さて本題のパフォーマンスの観点からデータ構造をどう考えればいいかというお話ですが、Tableauのデータソースは行数が少ないほどパフォーマンスがいいので、その観点から言うと「横持ち」の方がパフォーマンスがよくなります。
上のデータ構造の説明を見ていただければわかるように、「横持ち」と「縦持ち」では「縦持ち」の方が行数が多くなりやすいです。たいていは、「縦持ち」は「横持ち」の何倍、何十倍も多くなることがあるので、作りやすさの上では「縦持ち」ですがパフォーマンスを考えると「横持ち」を検討することになります。
一方でTableauの処理の観点で言うと、チャートを作成しやすい「縦持ち」の方が処理がシンプルになりやすく、「横持ち」で同じチャートを作成しようとすると「メジャーバリュー」や「LOD表現」を利用することが多く、処理が重くなりがちです。
パフォーマンスの観点でまとめると
- データ量の観点からは、「横持ち」の方がデータ量が少なくなりパフォーマンスがよい
- データ処理の観点からは、「縦持ち」の方が処理がシンプルになりパフォーマンスがよい
と言えます。
実際にチャートを作成する際には、どう考えればいいか
私がデータ構造を意識してデータソースの作成する場合は、以下のような手順を踏みます。
- まずは、サンプルデータを「縦持ち」の構造をベースに作りやすい形でチャートを作成する。
- 実際のデータ量でデータの「抽出」が可能なのか、抽出後のパフォーマンスが遅くないかを確認する。
- 2でパフォーマンスの改善が必要な場合は、「横持ち」のデータ構造を検討して、同じチャートが作れるか、パフォーマンスがどれぐらい改善するかを確認する。
パフォーマンスよりも作りたいチャートが作れるかが重要なので、少量のデータでチャートを作成した後、パフォーマンスの改善を図る際にデータ構造を含めた最適なデータソースの形を検討するという流れにはなります。
パフォーマンスの観点から「縦持ち」と「横持ち」は一長一短あり、どちらがいいとは言えないので試してみるしかないですが、いろいろ経験していくうちにどの場合はどちらの方がいいかの傾向はつかめるようになるかと思います。
パフォーマンス観点からデータ量とデータ処理のトレードオフ
「縦持ち」と「横持ち」の話で「データ量」と「データ処理」の観点でパフォーマンスのトレードオフの関係がある話をしましたが、データ構造以外でもこの考え方は有効です。
Tableauのチューニング業務をしていて、以下のようなケースはしばしばあります。
- LOD表現や計算フィールドを駆使して複雑な処理をしていたが、データを増やすことで処理がシンプルになり高速化した。
- データで重複部分が多いので、LOD表現や計算フィールドを活用することによりデータ量を縮小でき、それにより高速化できた。
パフォーマンス改善では、データソースの構造という意味では「縦持ち」「横持ち」だけでなく
- データソースを見てみて、重複している部分がないか？計算処理でなんとかできないか？
- 複雑な計算処理をしているところに、データを追加することで計算をシンプルにできないか？
という観点で見直すことが重要です。
個人的にはこの領域は、Tableauのスキルレベルよりも、ある種のひらめきの部分があります。Tableauの機能を熟知した上で、パフォーマンス改善のアイデアをひらめけるかがポイントです。
パフォーマンス改善の業務を行っていると知っている機能を組み合わせることで、新しいアイデアが浮かび、大きなパフォーマンス改善を実現できることがあります。
実現した例は、他の記事で紹介したいと思います。
◆Tableauの別名の3パターンの方法とパフォーマンス
この記事のパフォーマンスチューニングは、データ量とデータ処理のトレードオフの実例で、場合によってはパフォーマンス改善が期待できるアイデアの実例です。
Discussion