Tableau 真的適用於零售業嗎？

使用 Excel 進行報告的時間正在迅速消失 - 用於呈現和分析資訊的便利工具的趨勢在所有領域都可見。我們內部一直在討論報告的數位化，並選擇了Tableau視覺化和自助分析系統。 M.Video-Eldorado Group 分析解決方案和報告部門負責人 Alexander Bezugly 談到了建立戰鬥儀表板的經驗和結果。

我馬上說，並不是所有計劃都實現了，但是這次經歷很有趣，我希望它對你也有用。如果有人對如何做得更好有任何想法，我將非常感謝您的建議和想法。

以下是我們遇到的情況和學到的內容。

我們從哪裡開始？

M.Video-Eldorado擁有完善的資料模型：具有所需儲存深度的結構化資訊和大量固定形式的報告（查看更多詳情 這篇文章）。分析人員可以利用這些資料在 Excel 中製作資料透視表或格式化新聞通訊，或為最終使用者製作精美的 PowerPoint 簡報。

大約兩年前，我們開始在 SAP Analysis（一個 Excel 插件，本質上是 OLAP 引擎上的資料透視表）中建立分析報告，而不是固定格式的報告。但這個工具並不能滿足所有使用者的需求；大多數使用者繼續使用經過分析師額外處理的資訊。

我們的最終用戶分為三類：

高層管理人員。要求以清晰易懂的方式提供資訊。

中階管理人員，進階用戶。對資料探索有興趣，如果有工具的話能夠獨立建立報告。他們成為 SAP Analysis 中分析報告的關鍵使用者。

大眾用戶。他們對獨立分析資料不感興趣；他們使用自由度有限的報告，採用時事通訊和 Excel 資料透視表的格式。

我們的想法是滿足所有使用者的需求，並提供他們一個單一、方便的工具。我們決定從高階管理人員開始。他們需要易於使用的儀表板來分析關鍵業務結果。所以，我們從Tableau開始，首先選擇了兩個方向：零售和線上銷售指標，分析深度和廣度有限，這將涵蓋高層要求的大約80%的數據。

由於儀表板的使用者是高階管理人員，因此產品的另一個額外 KPI 出現了—回應速度。沒有人會等待20-30秒資料更新。導航應該在 4-5 秒內完成，或者更好的是立即完成。遺憾的是，我們未能實現這一目標。

這就是我們主儀表板的佈局：

關鍵思想是將主要 KPI 驅動因素（總共 19 個）組合在左側，並在右側按主要屬性呈現其動態和細分。任務看起來很簡單，視覺化是合乎邏輯且易於理解的，直到您深入了解細節。

細節1.數據量

我們的年銷售額主表大約有 300 億行。由於需要反映去年和前年的動態，僅實際銷售的數據量就在1億行左右。有關計劃資料和線上銷售區塊的資訊也單獨儲存。因此，即使我們使用了SAP HANA的列式記憶體資料庫，從目前儲存動態選擇一週內所有指標的查詢速度也約為15-20秒。這個問題的解決方案不言自明——數據的額外物化。但它也有缺陷，以下將詳細介紹。

詳情2.非累加指標

我們的許多關鍵績效指標都與收據數量相關。此指示器表示行數的 COUNT DISTINCT（檢查標題），並根據所選屬性顯示不同的金額。例如，該指標及其導數應如何計算：

為了使您的計算正確，您可以：

• 在儲存中動態計算此類指標；
• 將Tableau中的整個資料量計算，即根據 Tableau 中的請求，根據所選過濾器以收據位置的粒度提供所有資料；
• 建立一個具體化的展示，其中將在所有範例選項中計算所有指標，從而給出不同的非相加結果。

很明顯，在範例中UTE1和UTE2是代表產品層次結構的材質屬性。這不是一個靜態的東西；公司內部的管理是透過它進行的，因為不同的經理負責不同的產品組。當所有層級發生變化時，當關係被修改時，當一個群組從一個節點移動到另一個節點時，我們對這層次結構進行了許多全域修訂。在傳統的報告中，所有這些都是根據材料的屬性即時計算的；在這些數據具體化的情況下，有必要開發一種機制來追蹤此類變化並自動重新加載歷史數據。這是一項非常重要的任務。

細節三、數據對比

這一點與上一點類似。最重要的是，在分析一家公司時，通常會與上一時期進行幾個層次的比較：

與上一時期的比較（日與日、週與週、月與月）

在這個比較中，假設根據使用者選擇的週期（例如一年中的第33週），我們應該顯示到第32週的動態；如果我們選擇一個月的數據，例如XNUMX月，那麼這個比較將顯示四月份的動態。

與去年比較

這裡的主要細微差別是，當按天和按週進行比較時，您不會採用去年的同一天，即。您不能只將當前年份減一。您必須查看要比較的星期幾。相反，在比較月份時，您需要採用去年完全相同的日曆日。閏年也有細微差別。在原始儲存庫中，所有資訊均按天分發；沒有單獨的周、月或年欄位。因此，要在面板中獲得完整的分析橫截面，您需要計算的不是一個時期，例如一周，而是4週，然後比較這些數據，反映動態、偏差。因此，這種用於產生動態比較的邏輯也可以在 Tableau 中或在店面側實現。是的，當然我們在設計階段就知道並考慮了這些細節，但很難預測它們對最終儀表板性能的影響。

在實現儀表板時，我們遵循了漫長的敏捷之路。我們的任務是提供一個工作工具，並儘快提供測試所需的數據。因此，我們進行了衝刺，從最小化當前儲存方面的工作開始。

第 1 部分：對 Tableau 的信心

為了簡化 IT 支援並快速實施變更，我們決定在 Tableau 中製定計算非累加指標和比較過去期間的邏輯。

第 1 階段。一切都是即時的，沒有視窗修改。

在此階段，我們將 Tableau 連接到目前店面，並決定查看如何計算一年的收據數量。

其結果是：

答案令人沮喪——20分鐘。透過網路傳輸數據，Tableau 負載較高。我們意識到非相加指標的邏輯需要在HANA上實現。這並沒有讓我們太害怕，我們已經在 BO 和分析方面擁有類似的經驗，我們知道如何在 HANA 中建立快速展示，以產生正確計算的非附加指標。現在剩下的就是將它們調整為 Tableau。

第二階段。我們調整展示櫃，沒有具體化，一切都是動態的。

我們創建了一個單獨的新展示，可以動態產生 TABLEAU 所需的資料。總的來說，我們得到了很好的結果，我們將一周內產生所有指標的時間縮短到了 9-10 秒。老實說，我們預計在 Tableau 中，儀表板的回應時間在第一次開啟時為 20-30 秒，然後由於快取從 10 秒到 12 秒，這通常適合我們。

其結果是：

首次開啟儀表板：4-5 分鐘
任一點擊：3-4分鐘
誰也沒想到店面的工作量會增加這麼多。

第 2 部分：深入了解 Tableau

第一階段.Tableau效能分析與快速調優

我們開始分析 Tableau 大部分時間都花在哪裡。為此有相當好的工具，這當然是 Tableau 的一個優點。我們發現的主要問題是 Tableau 正在建構的非常複雜的 SQL 查詢。它們主要與：

— 資料轉置。由於 Tableau 沒有用於轉置資料集的工具，為了建立包含所有 KPI 詳細表示的儀表板左側，我們必須使用案例建立一個表。資料庫中的 SQL 查詢大小達到 120 個字元。

- 選擇一個時間段。這樣的資料庫層級查詢的編譯時間比執行時間長：

那些。請求處理12秒+執行5秒。

我們決定簡化Tableau端的運算邏輯，將另一部分計算移至店面和資料庫層面。這帶來了良好的結果。

首先，我們動態進行轉置，根據 wiki 上描述的這種方法，我們在 VIEW 計算的最後階段透過完整的外部連接來完成轉置 轉置 - 維基百科，自由的百科全書 и 初等矩陣 - 維基百科，自由的百科全書.

也就是說，我們製作了一個設定表－轉置矩陣（21x21），並依行細分接收所有指標。

曾是：


變成：


幾乎沒有時間花在資料庫轉置本身。本週所有指標的請求繼續在大約 10 秒內處理。但另一方面，根據特定指標建立儀表板則失去了靈活性，即儀表板的右側展示了特定指標的動態和詳細細分，以前展示櫃的工作時間為 1-3 秒，因為該請求基於一個指標，現在資料庫總是選擇所有指標並過濾結果，然後再將結果返回 Tableau。

結果，儀表板的速度下降了近3倍。

其結果是：

1. 5 秒 – 解析儀表板、視覺化
2. 15-20 秒 - 準備編譯查詢並在 Tableau 中執行預計算
3. 35-45 秒 - SQL 查詢的編譯及其在 Hana 中的平行順序執行
4. 5 秒 – 在 Tableau 中處理結果、排序、重新計算視覺化
5. 當然這樣的結果不適合業務，我們繼續優化。

第 2 階段：Tableau 中的最低邏輯，完全具體化

我們知道，在運行 10 秒的店面上建立響應時間為幾秒鐘的儀表板是不可能的，因此我們考慮了在資料庫端專門針對所需儀表板具體化資料的選項。但我們遇到了上面描述的一個全球性問題——非累加性指標。我們無法確保在更改篩選器或向下鑽取時，Tableau 能夠在針對不同產品層次結構預先設計的不同店面和級別之間靈活切換（在示例中，不帶UTE 的三個查詢，使用UTE1 和UTE2會產生不同的結果）。因此，我們決定簡化儀表板，放棄儀表板中的產品層次結構，看看簡化版本能有多快。

因此，在最後階段，我們組裝了一個單獨的儲存庫，在其中以轉置形式添加了所有 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 查詢以取得相關篩選值（Brand、Division、City、Store），解析結果

簡單總結一下

從視覺化的角度來看，我們喜歡 Tableau 工具。在原型設計階段，我們考慮了各種視覺化元素，並在庫中找到了它們，包括複雜的多層分割和多驅動瀑布。

在實施具有關鍵銷售指標的儀表板時，我們遇到了尚未能夠克服的效能困難。我們花了兩個多月的時間，收到了一個功能不完整的儀表板，其響應速度處於可接受的邊緣。我們自己得出結論：

1. Tableau 無法處理大量資料。如果在原始資料模型中您有超過 10 GB 的資料（大約 200 億 X 50 行），那麼儀表板將嚴重變慢 - 每次點擊從 10 秒到幾分鐘。我們嘗試了即時連接和提取。運行速度相當。
2. 使用多個儲存（資料集）時的限制。無法使用標準方法來指示資料集之間的關係。如果您使用變通辦法來連接資料集，這將極大地影響效能。在我們的案例中，我們考慮了在每個所需視圖部分中具體化資料並在這些具體化資料集上進行切換，同時保留先前選擇的過濾器的選項- 事實證明，這在Tableau 中是不可能做到的。
3. 無法在 Tableau 中建立動態參數。您無法在資料擷取中或在即時連接期間填入用於過濾資料集的參數，該參數只能使用資料集中的另一個選擇的結果或另一個SQL 查詢的結果，只能是本機使用者輸入或常數。
4. 與使用 OLAP|資料透視表元素建立儀表板相關的限制。
   在 MSTR、SAP SAC、SAP Analysis 中，如果將資料集新增至報表中，則預設其上的所有物件都是相互關聯的。 Tableau 沒有此功能；必須手動設定連線。這可能更靈活，但對於我們所有的儀表板來說，這是對元素的強制性要求 - 因此這是額外的勞動力成本。而且，如果你做了相關的過濾器，例如過濾某個地區時，城市列表僅限於該地區的城市，那麼你會立即連續查詢資料庫或Extract，這會明顯減慢查詢速度。儀表板。
5. 功能上的限制。批量轉換無法在萃取物上完成，尤其是在 Live-connecta 的資料集上。這可以透過 Tableau Prep 來完成，但這是額外的工作，也是另一個需要學習和維護的工具。例如，您不能轉置資料或將其與其自身連接。透過對各個列或欄位進行轉換來關閉什麼，這些欄位或欄位必須透過 case 或 if 來選擇，這會產生非常複雜的 SQL 查詢，其中資料庫花費大部分時間來編譯查詢文字。該工具的這些不靈活性必須在展示層級解決，這會導致更複雜的儲存、額外的下載和轉換。

我們沒有放棄 Tableau。但我們不認為 Tableau 是一個能夠建立工業儀表板的工具，也不認為是一個可以用來取代和數位化公司整個企業報表系統的工具。

我們現在正在另一個工具中積極開發類似的儀表板，同時嘗試修改 Tableau 中的儀表板架構，以進一步簡化它。如果社區感興趣，我們將告訴您結果。

我們也在等待您對如何在 Tabeau 中為如此大量的數據建立快速儀表板的想法或建議，因為我們的網站上的數據比零售業的數據多得多。

來源： www.habr.com