建設自己的取數平台：背景

背景

• “XXX，看一下這兩份資料為什麼對不上？”
• “XXX，你出的這份兒資料，和上個月XXX出的資料差異很大，你們看一下是什麼問題”
• “這個名額是怎麼算出來的？”“你去問XXX，這個是他做的。”
• ……

對于數倉同學、或者資料分析師同學，這類拉扯一定不陌生。每周都要花費一定比例的時間，在“排查資料為什麼對不上”這個事情上。甚至随着BI的持續建設、産品的持續完善，這類問題越來越多。以至于資料分析師意外地成為了一個流動性很高的崗位。

這背後的問題根源是什麼？我們又如何解決呢？

原因淺析

聽說過這樣一句話：

“資料就像UI一樣，即使再外行的人，也能過來指點幾句”

别看全公司從上到下、橫跨各個部門都在重視資料，但真正能把名額含義講清楚的，可能連10%的人都不到。

可以試試去問問自己公司裡那些重視資料的同僚們，“咱們公司的GMV是怎麼算的”。看看能得到多少個不同的答案。

在不同人心中，對同一個名額有不同的了解，是很正常的事兒。

首先，不是每個人都需要知道名額的含義，他們隻需要知道哪些名額和自己的業務挂鈎，怎樣努力能讓名額上升/下降即可。

其次，名額名稱往往是一個很短的詞彙，大多在十個字以内，甚至有些還是英文縮寫，單從名稱上根本想象不出來它背後有多麼複雜的處理加工過程。

然後，公司業務在持續發展，同一個名額在不同時期的含義也可能會發生變化。例如某項業務是中途新開展的，那早期的資料名額裡就不可能包含此業務相關的部分。換句話說，同一名額在不同時期的含義也會有所不同。

最後，人員流動造成的影響使這一問題變得更加不可控。一批又一批新人的加入、一批又一批老人的離職，把團隊在“事理”和“人理”上的管理的重要性提升到了一個很高的高度。流程、規範、跨部門溝通等，任何一項做的不到位，都會導緻混亂。

我們把以上全部原因放到一起分析之後就會發現，這不是光靠管理上的提升就可以解決的問題。我們需要把能靠系統解決的問題，全部放到系統中，将人為造成影響降到最低。

明确方向

整個取數流程，在需求提出後，可能涉及到的步驟包括：

1. 需求分析；
2. 任務配置設定/确認排期；
3. 開發；
4. 測試/資料校驗；
5. 傳遞；

“需求分析”較為複雜，需要雙方甚至多方進行溝通、會議等途徑來達成一緻，是以必須靠人工。剩下的步驟都可以通過系統解決。

願景

1. 取數平台本身

我們對于取數平台本身的願景，根據不同的使用者角色、以及不同的用數場景，大概分為以下幾類：

1. 中長期周期性關注的資料。

1. 1. 考慮将這類資料做成表格或圖表，固化在BI平台中，一次開發，多人、長期使用；
   2. 考慮制作取數模闆，可以在需求方需要取數時，人工使用模闆取數；或提供周期性自動取數功能；

1. 臨時性取數需求，且需求方沒有資料分析能力。

1. 1. 提供标準化自助取數功能。使用者無須深入了解資料的含義，隻需在界面上填充取數條件、名額等資訊，即可完成取數；
   2. 提供标準化的取數工單功能。數倉或數分同學提供專業的一對一服務，指導需求方使用自助取數功能、或直接提供資料結果；

1. 臨時性取數需求，且需求方有資料分析能力。

1. 1. 提供基于SQL的分析平台。使用者可以在平台上自定義SQL進行資料分析；

我們希望，100%的取數需求可以通過取數工單或自助取數功能解決，其中70%以上的取數需求能由需求方自己操作自助取數功能解決。

2. 全公司的資料輸出

資料的輸出，不止有BI、臨時資料需求這幾個途徑。還會有大量的資料被固化到産品功能中，例如使用者端APP上的某些資料看闆、背景系統上的資料統計模闆等等。按上述方案，雖然能保證BI、臨時資料需求的口徑統一，但還無法保證與其他産品功能中的資料口徑也一緻。

如上圖，我們在“資料倉庫”與“應用層”之間，增加一層DataAPI，所有的取數都通過DataAPI提供服務，即可避免多源頭造成的資料混亂。