編輯導讀：當你說你要做一個産品，你需要的是建設一套系統能力。産品上線後，要持續地提供用戶可以依賴的确定性，才能讓人留戀和依賴。本文作者以數據可視化産品為例，分析其系統能力與确定性，一起來看看吧。

接着梁甯系列課程的思考，這節課講的是産品的系統能力，在課後她留的作業是：

• 挑選一個你最熟悉的産品，說說它應該給用戶提供怎樣的确定性滿足？這個産品做到了嗎？如果沒有，你覺得問題在哪？
• 持續的滿足就會依賴，不确定的感覺就是傷害。你可以說說，你有沒有确定性被傷害的時候？

在寫作業之前，我們先學習一下梁甯在這節課的名詞解釋：

• 當你說你要做一個産品，你需要的是建設一套系統能力；
• 确定性很重要。人生如此不确定，所以當你看到有一個東西非常确定的時候，是讓人留戀與依賴的。持續地提供用戶可以依賴的确定性，這個是關鍵；

今天我們圍繞着梁甯布置的作業，那就從“系統能力”、“确定性”兩個方面來探讨一下數據可視化産品（更确切的說是“數據可視化服務”）。

一、如何進行數據服務？數據可視化産品的系統能力

其實在《數據可視化如何實現？》一文中就介紹過數據産品的系統，主要分為：數據存儲層、數據計算層、數據展示層（如下圖所示）。當時僅對系統的各個層級進行了名詞解釋，但作為一個整體的系統各個層級之間又是怎麼工作來進行數據服務呢？

作為業務人員，數據可視化産品對他們最直觀的服務就是數據的圖表化展示，我們單從字面的意思來看，整個系統由兩部分組成：用于業務場景的數據 将數據圖表化的能力。

1. 用于業務場景的數據

在企業實際的工作場景中，數據分散在不同的存儲中，比如日志數據、埋點數據、服務端數據等。但這些數據如果不經過加工，幾乎不可能滿足業務的需要，所以這裡就要提到數據倉庫。在BI工具中，可視化的數據來源于數據集（你可以理解為一張滿足業務方一處分析需求，涵蓋其所有指标、維度的數據表），而數據集就是直接引用或聚合計算數據倉庫内的數據表。

再說一說數據倉庫内的數據表，或許你也聽過ods、dwd、dws、adm這些數倉層級結構，其實除了這些技術性的内容，數據倉庫還有一點需要了解：其需要數據倉庫工程師按照業務結構創建。而在企業的實際工作場景下，工程師創建數據倉庫則依賴于數據産品整理的數據映射表（又稱datamapping，即将某業務中指标[含指标定義]、維度[指标按照該字段聚合查看]關聯的表格）通過系統已有的數據整理并建模（數據映射表裡的指标可能需要通過多張表的字段，通過複雜的數學計算得到），完成一張或多張滿足分析需求的數據表存儲在數據倉庫裡。

2. 将數據圖表化的能力

這裡我們數據可視化産品來制作儀表盤的實現方式為例，這裡能力有兩部分：一部分是後端能力，另一部分是前端能力。體驗過 Tableau 或者相似産品的朋友應該清楚創建儀表盤的整個過程：

通過該過程就可以明顯的看出“數據連接”、“生成數據集”就是後端能力的一部分，數據連接，即通過 JDBC 等接口将數據庫（含數據倉庫）與我們的數據可視化産品連接起來，這是生成數據集的前提條件。生成數據集，即為了滿足後面的可視化需要，通過數據查詢語言（一般是 sql 語言）将連接的數據庫内的一張或多張數據表聚合生成一張大寬表（裡面包含分析需要的指标、維度，與數據産品之前整理的數據映射表字段一緻，或者是其子集）。既然需要創建儀表盤，一定是業務經常需要的查看的，所以這裡的數據一定要保證能夠随着時間而進行周期性的更新，這裡就得提到調度模塊了。所謂調度，就是通過任務執行的定時設置，來實現數據集的定時更新。

“創建圖表和儀表盤”就是前端能力了，即将後端傳來的數據在圖标上展示出來。一些大公司或者專業的可視化系統企業會自己開發自己的圖表組件，如 Tableau 。而國内的百度（Echart）、阿裡（AntV）也開源了自己的圖表組件，前端同學可以此二次開發實現可視化展示。

二、如何更好的數據服務？數據可視化産品的确定性

1. 加載速率

數據産品與那些諸如 C 端、系統後台産品等在數據側的最大不同點就是數據量的多少，有時候一張數據看闆需要查詢的數據就可能有上億條數據。用戶願意等多久才不會躁動？數據查詢執行時間是否超出公司系統的限制？這時候數據加載的時長就要受到用戶、甚至系統的限制了。

為了提升加載速率，第一步通常是跟業務側的同學溝通，把沒有的分析砍掉來減少初始的數據量，如按日方式的細粒度查詢方式能否改成按周/月的高彙總度的查詢，來減少數據存儲（不過，通過這種方式成功的可能性也不高）。第二步就得從數據側入手了，如果非點查詢而是彙總查詢（舉個例子，有10w用戶，我需要随機展示單個用戶的标簽信息，這就是點查詢。如果我隻看這10w用戶整體的标簽信息分布，這就是彙總查詢），那我們可以把數據存儲在 clickhouse裡，在彙總查詢下速率會更快。那如果是點查詢，可以将 Spark 替換 MR 來操作數據集，這樣查詢效率更快但是内存消耗也越大，所以财大氣粗的公司可以多買一些計算資源。第三步就要從看闆設計側入手了，比如在時間篩選器中限制日期的跨度選擇，也可以将一張儀表盤的圖表數量減少，來降低單張看闆查詢的時間（後面有機會再單獨介紹一下單張看闆的設計）。

2. 數據準确性

經常看一些數據報告的朋友應該清楚，比結論更重要的就是數據準确定，如果數據都不準确那得到的結論就一點價值都沒了，數據可視化産品亦要遵守此規則。這裡的數據準确性并非僅狹義裡指的數據是否錯誤，還包括數據是否正常執行（如果因為數據無法生産，我昨日的數據對的不是昨日，而是前天的數據，那這也是一種錯誤）、數據是否出現異常（如出現空值等）、數據是否存在二義性（也可以稱為數據孤島，就是相同的指标在不同的業務部門數據源是否一緻？規則是否一緻？如果這些都不能保證，那不同的業務部門就被不能很好的交流了）。

數據錯誤、數據異常、數據執行中斷可以通過調度系統裡的監控模塊進行監控，數據産品經理也可以給大數據開發工程師提供一些方案，如出現空數據、空值，或者相關指标與前一次執行的數據結果差異變化超過某個阈值，就會提醒相應的數倉同學來确認一下問題。針對一些畫像标簽數據，還可以采用數據注入的方式來驗證一下畫像标簽是否準确。

數據二義性就需要數據倉庫工程師統一管理公司所有業務線的數據，保證相同的指标其數據源、口徑都是一緻的。另一方面，這樣做也可以有助于一些指标在公司範圍内進行推廣。

今天就說到這裡，如果内容對你有幫助的話，歡迎分享或收藏。如果你有其他的觀點歡迎在下方留言讨論~

#專欄作家#

兮兮，孤身旅人（ID：gushenlvren），人人都是産品經理專欄作家。關注人工智能、toB産品、大文娛等領域。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部