當我們遇見數字報表卡死的情況，該如何解決？而作為一名產品設計，如何在設計時避免出現這一問題？本篇文章將以四個設計原則為主，對數據報表設計提供一些參考思路，希望能對你有所啟發。

最近，同樣從事產品經理工作的朋友跟我抱怨，說在最近的一次例會上又跟開發吵起來了，原因是數據報表的頁面又卡死了。

• 開始，前端說是后端的鍋，因為數據太多了；
• 后來，后端說是前端的鍋，因為渲染太慢了；
• 最后，前后端得出一致的結論：是產品的鍋，因為數據報表的設計不合理。

他給我看了一下他們產品的數據報表，全部平鋪在一個頁面上，打開報表的時候，需要一次性將所有數據都加載出來，難怪會卡死。

我因為他這段“悲傷”的經歷，專門整理了這篇文章，來說一說數據報表應該怎么設計。

導致數據報表卡死的“原罪”

雪崩時，沒有一片雪花是無辜的，導致數據報表卡死的三大“原罪”，就是設計不合理、后端查詢數據量太大以及前端渲染太久，而設計不合理，正是三大“原罪”之首。

我在之前的文章《那些被迫妥協的產品設計背后的技術原因》中分享過，如果一次性請求或處理的數據量過大，后臺可能處理超時、響應過程可能失真、前端渲染可能卡死。

在《4個數據庫語句，帶你了解產品數據的增刪改查應該怎么設計》中我也提到過，數據的查詢效率跟數據表數量、字段數量以及數據數量有關。

因此，要解決這個問題，就要從設計上先進行優化，這里分享數據報表設計的四個“也許”法則，希望對你有所幫助。

一、也許你并不需要這個數據

產品經理在做數據報表的設計時，有時候會拿不準某個數據到底有沒有必要，索性就加進去了，后來發現用不上就隱藏，結果冗余的數據越來越多，查詢的性能越來越差。

由于數據報表往往牽涉大量數據的查詢和統計，因此對每個數據都應該慎之又慎，誰也保證不了最新添加的一個數據會不會成為壓垮數據報表的“最后一根稻草”。

因此，數據報表應該只統計有價值的數據，那么，如何才能評判一個數據是有價值的呢？

1）對業務具有總結意義

比如過去一周的用戶增長數據、交易流水數據之類可以總結業務的發展與健康狀況的數據。

2）對運營具有指導意義

比如輪播圖點擊率數據、產品轉化率數據之類可以指導下一步運營重點和策略的數據。

3）對產品迭代具有參考意義

比如AB測試數據、埋點數據之類可以參考接下來產品迭代方向的數據。

當你不確定一個數據是否必要的時候，不妨看看這個數據是否符合上面的一個或多個條件。

二、也許你并不需要最新的數據

舉個例子，如果我想通過數據報表來統計近一個星期的用戶增長曲線，像這樣的數據報表一般是這樣設計的：

• 在用戶數據表中統計近一周每天注冊的用戶總數。
• 統計完成后，后端將數據傳遞給前端。
• 前端繪制數據曲線。

但像這樣的設計有個問題：每名用戶的每次查詢都需要實時進行統計，但其實每次統計到的結果并沒有不同。

因此，要想對這個數據報表的設計進行優化，得先知道，這個數據報表實際上具有兩個特點：

1）當天的數據是不要的

今天還沒結束，數據會受各種因素影響而產生變化或波動，比如雙十一之類節日活動的時候，數據量幾乎都是在活動開始的一瞬間爆發，在當天結束前，最終數據都是未知的。

因此對于統計近一個星期用戶增長曲線的需求，應該摒除當天的數據，從昨天開始往前一周進行統計。

2）過去的數據是不變的

如果只是單純摒除當天的數據，對于數據統計的優化是非常有限的，但從這個需求我們可以知道，過去一周的用戶增長數據已經是一個歷史數據，是一個固定值。

無論后面的數據怎么變化，都不會影響之前的數據，利用這個特性，我們可以對這個數據報表的設計進行優化：

• 系統在每天0點過后跑一次統計算法，將過去一周每天注冊的用戶數進行統計并記錄在另外一張數據表里。
• 后端將已經統計完成的數據傳遞給前端。
• 前端繪制數據曲線。

這樣說也許你的感知還不是很強烈，但須知在整個數據報表呈現的過程中，最耗費時間的就是統計過程。

優化前，每名用戶的每次訪問都需要統計一次，而優化后總共只需要統計一次，每名用戶的每次訪問都是直接從已經完成統計的數據表里拿到統計結果，你可以想象這兩者在查詢速度上的區別。

為了讓你更清晰地了解這個需求的報表設計優化前后的不同，我簡單畫了一張圖。

三、也許你并不需要同時查看所有數據

我在之前的文章《那些被迫妥協的產品設計背后的技術原因》中分享過，要解決單次處理數據量過大導致出現的各種問題，可以對數據進行“分割”，也就是分頁或分步瀏覽，這種設計在數據報表中同樣適用。

如下圖的報表，如果你的業務只有5個渠道還好說，但如果你有50個渠道，一輪查詢下來，不卡死可能也過去幾十秒了，而且報表本身的作用是使數據更易讀。

但如果在一個報表中展示50條數據曲線，數據報表也就失去了它應有的作用。

但也許你并不需要同時查看50個渠道的數據，你可能只是關注資源總量前5的渠道，或者只是想看一下剛開拓的幾個新渠道的資源總量曲線。

這種情況下，完全不用去統計所有渠道的數據，可以設計一個渠道的選擇器，在選擇了渠道之后，才去統計對應渠道的數據。對于沒有選擇的渠道，則無需統計，這樣的設計也可以有效降低系統處理數據的壓力。

四、也許你并不需要馬上拿到數據

前面的3個法則主要是針對數據報表的設計和查詢，而這個法則，主要是針對數據的導出和下載。

我們知道，有時候為了在各個地方使用系統的數據，數據報表有時會設計一些導出或下載的功能，但是當需要導出或下載的數據量極大的情況下，系統處理的時間可能會非常長，而且最后不一定能導出或下載成功。

類似這樣的導出或下載數據報表的功能設計，想要避免系統處理時間過長導致卡死或導出失敗，一般有兩種優化設計方案。

1）告訴我你需要哪個時間段的數據

在用戶操作導出或下載功能時，詢問用戶需要哪個時間段的數據，而不是將所有數據全都導出來，在限制了時間段之后，可以有效控制導出的數據量，降低導出失敗的風險。

2）沒問題，但請你過一會再回來拿數據

按照方案1設計之后，還是存在一種可能的風險，就是用戶選擇了從平臺上線至今的時間段，這樣還是等同于導出了系統的全部數據，還是會有卡死的風險，那怎么辦呢？

這種情況下，有兩種處理方案。

• 限制選擇的時間段長度，比如最多只能選擇3個月。
• 把導出和下載的功能分開，用戶導出時，在服務器進行數據處理，在此期間，用戶可以離開系統或操作系統的其他的功能，服務器處理完成后，生成可以提供給用戶下載的文件，如 Excel 表格等，并通知用戶，當用戶回到數據報表頁面點擊下載時，直接將文件從服務器下載到本地即可。

數據報表設計時，遵循以上四個“也許”法則，也許下一次數據報表再次卡死時，開發就很難將鍋甩到你的身上。

以上便是本文的全部內容，感謝閱讀。