Tableau 真的可以應用在零售業嗎？

使用 Excel 進行報告的時代正在迅速消逝——使用便捷的工具來呈現和分析資訊的趨勢在各個領域都很明顯。我們內部對報表的數位化進行了長期討論，並選擇了 Tableau 視覺化和自助分析系統。 M.Video-Eldorado集團分析解決方案和報告部負責人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. 非加性指標

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

為了確保計算正確，您可以：

• 在儲存中動態地執行這些指標的計算；
• 對 Tableau 中的整個資料量進行計算，即根據對 Tableau 的請求，按照檢查位置的粒度根據選定的過濾器返回所有資料；
• 建立一個物化展示，其中所有指標將在所有給出不同非加性結果的樣本選項中進行計算。

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

細節3. 數據對比

這一點和上一點類似。重點是，在公司裡，做分析的時候，習慣上會和前期形成幾個層次的比較：

與前期的比較（每日、每週、每月）

此比較假設根據使用者選擇的時間段（例如，一年中的第 33 週），我們應該按第 32 週顯示動態；如果我們選擇一個月的數據，例如五月份，那麼此比較將顯示四月份的動態。

與去年同期相比

這裡的主要細微差別是，當按天和周進行比較時，您不是取前一年同一天，也就是說，您不能只將當前年份減一。您必須查看所比較的星期幾。但比較月份時則相反，需要取與前一年完全相同的日曆日。閏年也存在細微差別。原有儲存中所有資訊都是按天分佈的；沒有針對週、月或年的單獨欄位。因此，為了獲得面板中完整的分析橫斷面，需要計算的不是一段週期，例如一周，而是四周，然後比較這些數據，反映其動態和偏差。因此，這個動態形成比較的邏輯也可以在 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

步驟 1：Tableau 效能分析與快速調優

我們開始分析 Tableau 大部分時間都花在哪裡。並且有一個非常好的工具可以實現這一點，當然，這對 Tableau 來說是一個加分項。我們發現的主要問題是 Tableau 建構的 SQL 查詢非常複雜。它們主要與以下方面相關：

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

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

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

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

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

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

曾是：


變成：


轉置資料庫本身幾乎不需要時間。本週所有指標的請求仍然在大約10秒內處理。但是，基於特定指標建立儀表板的靈活性卻喪失了，即對於儀表板的右側部分，顯示特定指標的動態和詳細分類，展示通常在 1-3 秒內完成，因為請求針對一個指標，但現在 DB 總是選擇所有指標並過濾結果，然後再將結果傳回給 Tableau。

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

其結果是：

1. 5 秒——解析儀表板、視覺化
2. 15-20 秒 — 使用 Tableau 中的預計算準備查詢編譯
3. 35-45 秒－在 Hana 中編譯 SQL 查詢及其平行順序執行
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 查詢以實現基本視覺化（與 p.1 並行運行）
3. 1,5-2秒。 — 渲染、重新計算視覺化
4. 1,3 秒。 — 執行額外的 SQL 查詢以取得相關的篩選值（品牌、部門、城市、商店），解析結果

簡要總結一下

從視覺化的角度來看，我們喜歡 Tableau 工具。在模型階段，我們研究了不同的視覺化元素，並在庫中找到它們，包括複雜的多層分割和多驅動瀑布。

在實施包含關鍵銷售指標的儀表板時，我們遇到了尚未能夠克服的效能挑戰。我們花了兩個多月的時間，收到了一個功能不完整的儀表板，其反應速度勉強可以接受。我們自己得出了結論：

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 中的儀表板架構，以進一步簡化它。如果社區有興趣，我們會告訴你結果。

我們也在等待您關於如何在 Tabeau 中建立針對如此大量資料的快速儀表板的想法或建議，因為我們的網站包含的資料比零售業多得多。

來源： www.habr.com