小売業における Tableau って本当ですか?

Excel でレポートを作成する時代は急速に失われつつあり、情報の提示と分析に便利なツールを求める傾向があらゆる分野で見られます。私たちは社内でレポートのデジタル化について長年議論しており、Tableau の視覚化およびセルフサービス分析システムを選択しました。 M.Video-Eldorado Group の分析ソリューションおよびレポート部門の責任者である Alexander Bezugly 氏は、戦闘ダッシュボードの構築の経験と結果について語りました。

計画したことがすべて実現したわけではありませんが、この経験は興味深いものでした。皆さんにとっても役立つことを願っています。また、もっと良くできる方法について何かアイデアをお持ちの方がいらっしゃいましたら、アドバイスやアイデアをいただければ幸いです。

以下のカットは、私たちが遭遇したことと学んだことについてです。

どこから始めたのでしょうか？

M.Video-Eldorado には、十分に開発されたデータ モデルがあります。つまり、必要なストレージ深度を備えた構造化情報と、膨大な数の定型レポートです (詳細を参照) この記事）。これらを基に、アナリストは Excel でピボット テーブルや書式設定されたニュースレターを作成したり、エンド ユーザー向けに美しい PowerPoint プレゼンテーションを作成したりできます。

約 2 年前、固定形式のレポートの代わりに、SAP Analysis (Excel アドオン、本質的​​には OLAP エンジン上のピボット テーブル) で分析レポートの作成を開始しました。しかし、このツールはすべてのユーザーのニーズを満たすことができず、大多数はアナリストによって追加処理された情報を引き続き使用していました。

エンドユーザーは次の 3 つのカテゴリに分類されます。

トップマネジメント。適切に提示され、明確に理解できる方法で情報を要求します。

中間管理職、上級ユーザー。データ探索に興味があり、ツールが利用可能な場合は独自にレポートを作成できる。彼らは、SAP Analysis の分析レポートの主要ユーザーになりました。

マスユーザー。彼らはデータを独自に分析することに興味がなく、ニュースレター形式や Excel のピボット テーブルなど、自由度が限られたレポートを使用しています。

私たちのアイデアは、すべてのユーザーのニーズをカバーし、単一の便利なツールを提供することでした。まずは経営トップから始めることにしました。主要なビジネス結果を分析するために、使いやすいダッシュボードが必要でした。そこで、私たちは Tableau から始めて、最初に 80 つの方向性を選択しました。XNUMX つは、分析の深さと幅が限られている小売業とオンラインの売上指標で、経営トップが要求したデータの約 XNUMX% をカバーするものでした。

ダッシュボードのユーザーは経営トップであったため、製品のもう 20 つの追加 KPI、つまり応答速度が登場しました。データが更新されるまで 30 ～ 4 秒も待つ人はいません。ナビゲーションは 5 ～ XNUMX 秒以内に完了する必要があり、できれば即座に完了する必要があります。そして残念ながら、私たちはこれを達成できませんでした。

メイン ダッシュボードのレイアウトは次のようになります。

重要なアイデアは、合計 19 個ある主要な KPI 推進要因を左側に結合し、そのダイナミクスと主な属性ごとの内訳を右側に表示することです。タスクは単純に見えますが、詳細を確認するまでは、視覚化は論理的で理解しやすいものです。

詳細1. データ量

年間売上高に関するメイン テーブルは約 300 億行を占めます。昨年、一昨年の動向を反映する必要があるため、実売データだけで約1億行のデータ量となります。計画データとオンライン販売ブロックの情報も個別に保存されます。したがって、カラムナ型インメモリ DB SAP HANA を使用したにもかかわらず、現在のストレージから 15 週間分のすべてのインジケーターをオンザフライで選択するクエリの速度は約 20 ～ XNUMX 秒でした。この問題の解決策は、データの追加の実体化であることがわかります。しかし、落とし穴もあります。それについては以下で詳しく説明します。

詳細 2. 非添加インジケーター

当社の KPI の多くはレシートの数に関連付けられています。そして、このインジケーターは行数 (チェックヘッダー) の COUNT DISTINCT を表し、選択した属性に応じて異なる量を示します。たとえば、この指標とその導関数は次のように計算される必要があります。

計算を正しくするには、次のことができます。

• ストレージ内でそのような指標をその場で計算します。
• Tableau のデータ全体に対して計算を実行します。 Tableau でのリクエストに応じて、受信位置の粒度で選択したフィルターに従ってすべてのデータを提供します。
• すべてのインジケーターが、異なる非加算結果を与えるすべてのサンプル オプションで計算される具体化されたショーケースを作成します。

この例では、UTE1 と UTE2 が製品階層を表すマテリアル属性であることは明らかです。これは静的なものではなく、それを通じて社内の管理が行われるためです。異なるマネージャーが異なる製品グループを担当します。すべてのレベルが変更されたとき、関係が修正されたとき、および XNUMX つのグループがあるノードから別のノードに移動したときに一定のポイントが変更されたとき、この階層のグローバルな改訂が何度も行われました。従来のレポートでは、これらすべてが素材の属性からその場で計算されますが、このデータを具体化する場合、そのような変更を追跡し、履歴データを自動的に再読み込みするメカニズムを開発する必要があります。非常に簡単ではないタスクです。

詳細3. データ比較

この点は前と同様です。肝心なのは、企業を分析する際には、前期との比較をいくつかのレベルで行うのが通例であるということです。

前期との比較（日ごと、週ごと、月ごと）

この比較では、ユーザーが選択した期間 (たとえば、年の 33 週目) に応じて、32 週目までのダイナミクスを表示する必要があると想定しています。たとえば、XNUMX 月などの月のデータを選択した場合、の場合、この比較は XNUMX 月までの動向を示します。

昨年との比較

ここでの主なニュアンスは、日ごとと週ごとに比較する場合、昨年の同じ日を考慮しているわけではないということです。現在の年から 4 を引いた値を入力することはできません。比較する曜日に注目する必要があります。逆に、月を比較する場合は、昨年のまったく同じ暦日を取得する必要があります。うるう年にもニュアンスがあります。元のリポジトリでは、すべての情報が日ごとに分散されており、週、月、年などの個別のフィールドはありません。したがって、パネル内の完全な分析断面を取得するには、XNUMX つの期間 (たとえば XNUMX 週間) ではなく XNUMX 週間をカウントし、これらのデータを比較してダイナミクスや偏差を反映する必要があります。したがって、ダイナミクスで比較を生成するためのこのロジックは、Tableau またはストアフロント側で実装することもできます。はい、もちろん、設計段階ではこれらの詳細を理解し、検討していましたが、最終的なダッシュボードのパフォーマンスへの影響を予測するのは困難でした。

ダッシュボードを実装するとき、私たちは長いアジャイルの道をたどりました。私たちの任務は、テストに必要なデータを備えた実用的なツールをできるだけ早く提供することでした。そのため、私たちはスパートをかけ、現在のストレージ側の作業を最小限に抑えることから始めました。

パート 1: Tableau への信仰

IT サポートを簡素化し、変更を迅速に実装するために、非加算指標を計算し、過去の期間を比較するロジックを Tableau で作成することにしました。

ステージ 1. すべてがライブであり、ウィンドウの変更はありません。

この段階で、Tableau を現在の店頭に接続し、1 年間のレシート数がどのように計算されるかを確認することにしました。

結果：

答えは憂鬱なものでした - 20分でした。ネットワーク経由のデータ転送、Tableau への高負荷。非加算インジケーターを使用したロジックは HANA に実装する必要があることに気付きました。これは私たちをあまり怖がらせませんでした。私たちはすでに BO と分析で同様の経験があり、正しく計算された非加算的指標を生成する高速ショーケースを HANA で構築する方法を知っていました。あとは、Tableau に合わせて調整するだけです。

ステージ 2. ディスプレイ ケースを調整します。具体化はせず、すべてをその場で調整します。

TABLEAU に必要なデータをその場で生成する別の新しいショーケースを作成しました。全体的には良い結果が得られ、9 週間ですべてのインジケーターを生成する時間を 10 ～ 20 秒に短縮しました。そして、Tableau では、ダッシュボードの応答時間は最初に開くときに 30 ～ 10 秒、その後はキャッシュのせいで 12 ～ XNUMX 秒になるだろうと正直に予想していましたが、これは一般的には私たちに適していると考えられます。

結果：

最初にダッシュボードを開く: 4 ～ 5 分
任意のクリック: 3 ～ 4 分
店頭の仕事がこれほど増えるとは誰も予想していませんでした。

パート 2. Tableau を詳しく見る

ステージ 1. Tableau のパフォーマンス分析とクイックチューニング

私たちは、Tableau が最も多くの時間を費やしている場所の分析を開始しました。そして、これには非常に優れたツールがあり、これはもちろん Tableau の利点です。私たちが特定した主な問題は、Tableau が構築している非常に複雑な SQL クエリでした。それらは主に以下に関連していました。

— データの転置。 Tableau にはデータセットを転置するツールがないため、すべての KPI を詳細に表現したダッシュボードの左側を構築するには、ケースを使用してテーブルを作成する必要がありました。データベース内の SQL クエリのサイズが 120 文字に達しました。

- 期間の選択。データベース レベルでのこのようなクエリは、実行よりもコンパイルに時間がかかりました。

それらの。リクエスト処理 12 秒 + 実行 5 秒。

Tableau 側の計算ロジックを簡素化し、計算の別の部分をストアフロント レベルとデータベース レベルに移動することにしました。これは良い結果をもたらしました。

まず、ウィキで説明されているこのアプローチに従って、VIEW 計算の最終段階で完全外部結合を通じて転置を実行中に行いました。 移調 - Wikipedia、フリー百科事典 и 元素行列 - フリー百科事典『ウィキペディア（Wikipedia）』.

つまり、設定テーブル、つまり転置行列 (21x21) を作成し、すべてのインジケーターを行ごとに分類して受け取りました。

それは次のとおりです。


それは次のようになりました。


データベースの転置自体にはほとんど時間はかかりません。その週のすべてのインジケーターのリクエストは、約 10 秒で処理され続けました。しかしその一方で、特定の指標に基づいてダッシュボードを構築するという点では柔軟性が失われています。ダッシュボードの右側では、特定のインジケーターのダイナミクスと詳細な内訳が表示されます。以前は、ディスプレイケースは 1 ～ 3 秒で動作していました。リクエストは XNUMX つのインジケーターに基づいていましたが、データベースは常にすべてのインジケーターを選択し、結果を Tableau に返す前に結果をフィルター処理するようになりました。

その結果、ダッシュボードの速度はほぼ 3 倍に低下しました。

結果：

1. 5 秒 – ダッシュボード、ビジュアライゼーションの解析
2. 15 ～ 20 秒 - Tableau で事前計算を実行してクエリをコンパイルする準備
3. 35 ～ 45 秒 - SQL クエリのコンパイルと Hana での並列逐次実行
4. 5 秒 – Tableau での結果の処理、並べ替え、視覚化の再計算
5. もちろん、そのような結果はビジネスに適合しないため、最適化を続けました。

ステージ 2. Tableau の最小限のロジック、完全な具体化

私たちは、10 秒間実行されるストアフロントで数秒の応答時間を持つダッシュボードを構築することは不可能であることを理解し、必要なダッシュボードに特化してデータベース側でデータを具体化するオプションを検討しました。しかし、私たちは上記のような世界的な問題、つまり非加算的指標に遭遇しました。フィルターやドリルダウンを変更するときに、Tableau がさまざまなストアフロントと、さまざまな製品階層向けに事前に設計されたレベルを柔軟に切り替えているかどうかを確認できませんでした (例では、UTE を使用せず、UTE1 と UTE2 を使用した XNUMX つのクエリが異なる結果を生成します)。したがって、ダッシュボードを簡素化し、ダッシュボード内の製品階層を放棄し、簡略化されたバージョンでどれだけ高速になるかを確認することにしました。

そのため、この最後の段階で、すべての KPI を転置形式で追加する別のリポジトリを作成しました。データベース側では、このようなストレージへのリクエストは 0,1 ～ 0,3 秒で処理されます。ダッシュボードには次の結果が表示されました。

最初の開口部：8〜10秒
任意のクリック: 6 ～ 7 秒

Tableau に費やされる時間は次のとおりです。

1. 0,3秒— ダッシュボードの SQL クエリの解析とコンパイル
2. 1,5～3秒— メインの視覚化のための Hana での SQL クエリの実行 (ステップ 1 と並行して実行)
3. 1,5～2秒— レンダリング、ビジュアライゼーションの再計算
4. 1,3秒— 関連するフィルター値 (ブランド、部門、都市、店舗) を取得するための追加の SQL クエリの実行、結果の解析

簡単にまとめると

視覚化の観点からは、Tableau ツールが気に入りました。プロトタイピングの段階で、複雑なマルチレベルのセグメンテーションやマルチドライバー ウォーターフォールなど、さまざまな視覚化要素を検討し、それらはすべてライブラリで見つかりました。

主要な販売指標を含むダッシュボードを実装しているときに、まだ克服できていないパフォーマンスの問題に遭遇しました。 2 か月以上かかりましたが、機能的には不完全なダッシュボードを受け取りましたが、その応答速度は許容範囲に達しています。そして私たちは自分自身で次の結論を導き出しました。

1. Tableau は大量のデータを扱うことができません。元のデータ モデルに 10 GB (約 200 億 X 50 行) を超えるデータがある場合、ダッシュボードの速度が大幅に低下し、クリックごとに 10 秒から数分かかります。ライブ接続と抽出の両方を実験しました。動作速度は同等です。
2. 複数のストレージ (データセット) を使用する場合の制限事項。標準的な手段を使用してデータセット間の関係を示す方法はありません。回避策を使用してデータセットを接続すると、パフォーマンスに大きな影響を与えます。私たちの場合、必要なビュー セクションごとにデータを実体化し、以前に選択したフィルターを保持しながら、実体化されたデータセットに切り替えを行うオプションを検討しましたが、これは Tableau では不可能であることが判明しました。
3. Tableau では動的パラメーターを作成することはできません。抽出中またはライブ接続中にデータセットをフィルタリングするために使用されるパラメータには、データセットからの別の選択の結果や別の SQL クエリの結果を入力することはできません。ネイティブ ユーザー入力または定数のみを入力できます。
4. OLAP|ピボットテーブル要素を使用したダッシュボードの構築に関連する制限。
   MSTR、SAP SAC、SAP Analysis では、データセットをレポートに追加すると、そのデータセット上のすべてのオブジェクトがデフォルトで相互に関連付けられます。 Tableau にはこれがないため、接続を手動で構成する必要があります。これはおそらくより柔軟ですが、すべてのダッシュボードにとって、これは要素の必須要件であるため、追加の人件費がかかります。さらに、たとえば地域をフィルタリングするときに、都市のリストがこの地域の都市のみに制限されるように関連フィルターを作成すると、ただちにデータベースまたは抽出に対する連続したクエリが発生し、処理速度が著しく低下します。ダッシュボード。
5. 機能の制限。一括変換は、抽出に対しても、特に Live-connecta からのデータセットに対しても実行できません。これは Tableau Prep を通じて実行できますが、追加作業が必要であり、学習および保守が必要な別のツールです。たとえば、データを転置したり、データ自体と結合したりすることはできません。個々の列またはフィールドの変換によって閉じられるものは、case または if によって選択する必要があり、これにより非常に複雑な SQL クエリが生成され、データベースはクエリ テキストのコンパイルにほとんどの時間を費やします。このようなツールの柔軟性の低さはショーケース レベルで解決する必要があり、これによりストレージがより複雑になり、追加のダウンロードと変換が必要になります。

私たちは Tableau を諦めたわけではありません。しかし、私たちは Tableau を産業用ダッシュボードを構築できるツールや、企業の企業報告システム全体を置き換えてデジタル化するツールとは考えていません。

現在、別のツールで同様のダッシュボードを積極的に開発しており、同時に Tableau のダッシュボード アーキテクチャをさらに簡素化するために改訂しようとしています。コミュニティが興味を持っていただければ、結果についてお知らせします。

また、小売店よりもはるかに多くのデータが存在する Web サイトを持っているため、Tabeau でこのような大量のデータを基に迅速なダッシュボードを構築する方法に関するアイデアやアドバイスもお待ちしています。

出所： habr.com