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

最近，同樣從事產(chǎn)品經(jīng)理工作的朋友跟我抱怨，說在最近的一次例會上又跟開發(fā)吵起來了，原因是數(shù)據(jù)報表的頁面又卡死了。

• 開始，前端說是后端的鍋，因為數(shù)據(jù)太多了；
• 后來，后端說是前端的鍋，因為渲染太慢了；
• 最后，前后端得出一致的結(jié)論：是產(chǎn)品的鍋，因為數(shù)據(jù)報表的設(shè)計不合理。

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

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

導(dǎo)致數(shù)據(jù)報表卡死的“原罪”

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

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

在《4個數(shù)據(jù)庫語句，帶你了解產(chǎn)品數(shù)據(jù)的增刪改查應(yīng)該怎么設(shè)計》中我也提到過，數(shù)據(jù)的查詢效率跟數(shù)據(jù)表數(shù)量、字段數(shù)量以及數(shù)據(jù)數(shù)量有關(guān)。

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

一、也許你并不需要這個數(shù)據(jù)

產(chǎn)品經(jīng)理在做數(shù)據(jù)報表的設(shè)計時，有時候會拿不準某個數(shù)據(jù)到底有沒有必要，索性就加進去了，后來發(fā)現(xiàn)用不上就隱藏，結(jié)果冗余的數(shù)據(jù)越來越多，查詢的性能越來越差。

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

因此，數(shù)據(jù)報表應(yīng)該只統(tǒng)計有價值的數(shù)據(jù)，那么，如何才能評判一個數(shù)據(jù)是有價值的呢？

1）對業(yè)務(wù)具有總結(jié)意義

比如過去一周的用戶增長數(shù)據(jù)、交易流水數(shù)據(jù)之類可以總結(jié)業(yè)務(wù)的發(fā)展與健康狀況的數(shù)據(jù)。

2）對運營具有指導(dǎo)意義

比如輪播圖點擊率數(shù)據(jù)、產(chǎn)品轉(zhuǎn)化率數(shù)據(jù)之類可以指導(dǎo)下一步運營重點和策略的數(shù)據(jù)。

3）對產(chǎn)品迭代具有參考意義

比如AB測試數(shù)據(jù)、埋點數(shù)據(jù)之類可以參考接下來產(chǎn)品迭代方向的數(shù)據(jù)。

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

二、也許你并不需要最新的數(shù)據(jù)

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

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

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

因此，要想對這個數(shù)據(jù)報表的設(shè)計進行優(yōu)化，得先知道，這個數(shù)據(jù)報表實際上具有兩個特點：

1）當天的數(shù)據(jù)是不要的

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

因此對于統(tǒng)計近一個星期用戶增長曲線的需求，應(yīng)該摒除當天的數(shù)據(jù)，從昨天開始往前一周進行統(tǒng)計。

2）過去的數(shù)據(jù)是不變的

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

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

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

這樣說也許你的感知還不是很強烈，但須知在整個數(shù)據(jù)報表呈現(xiàn)的過程中，最耗費時間的就是統(tǒng)計過程。

優(yōu)化前，每名用戶的每次訪問都需要統(tǒng)計一次，而優(yōu)化后總共只需要統(tǒng)計一次，每名用戶的每次訪問都是直接從已經(jīng)完成統(tǒng)計的數(shù)據(jù)表里拿到統(tǒng)計結(jié)果，你可以想象這兩者在查詢速度上的區(qū)別。

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

三、也許你并不需要同時查看所有數(shù)據(jù)

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

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

但如果在一個報表中展示50條數(shù)據(jù)曲線，數(shù)據(jù)報表也就失去了它應(yīng)有的作用。

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

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

四、也許你并不需要馬上拿到數(shù)據(jù)

前面的3個法則主要是針對數(shù)據(jù)報表的設(shè)計和查詢，而這個法則，主要是針對數(shù)據(jù)的導(dǎo)出和下載。

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

類似這樣的導(dǎo)出或下載數(shù)據(jù)報表的功能設(shè)計，想要避免系統(tǒng)處理時間過長導(dǎo)致卡死或?qū)С鍪。话阌袃煞N優(yōu)化設(shè)計方案。

1）告訴我你需要哪個時間段的數(shù)據(jù)

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

2）沒問題，但請你過一會再回來拿數(shù)據(jù)

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

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

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

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

以上便是本文的全部內(nèi)容，感謝閱讀。