某二手交易平臺大數據平臺從 0 到 1 演進與實踐

在人口流量紅利再也不，獲客成本愈來愈高的時代，精益創業、MVP 的概念已經深刻人心，精細化運營也是大勢所趨，而這些背後本質上都依賴數據化運營，那如何根據現有業務，快速從 0 開始打造一個契合業務的數據產品呢？本文將以某二手交易平臺業務爲基礎，講述整個數據平臺從 0 到 1 的演進與實踐，但願對你們能有所啓發。

一、背景

在某二手交易平臺開始大數據平臺建設以前，整個數據從需求提出到研發流程再到數據報表、數據產品，也是經歷過一段很是混沌的時期，並且效率和質量每每很可貴到保障，主要表現爲如下幾個方面：

（1）可用性差

好比常常出現計算延遲、異常，數據指標也經常數據對不上，不少類似的指標不清楚具體差別在哪，即便同一個指標也可能不一樣的同窗開發的而對不上。另外數據波動無感知，好比日誌格式出錯，結果次日才發現有問題。

（2）維護成本高

成百上千的日誌模塊，不知從何維護，出了問題也不知道從哪裏能夠追溯到源頭和負責人。

（3）業務快速迭代，精細化、數據化運營需求和研發資源之間的矛盾

二、目標與方案

（1）目標

數據可管理、可維護、可擴展、高可用

及時、準確、直觀的呈現業務數據與問題

下降使用門檻，提高使用效率

（2）方案

數據倉庫化

數據平臺化

三、數據倉庫建設

結構化

層次化

主題化

模型化：用戶模型/事件模型

ETL

ETL 是整個數據倉庫的核心，正如業界流傳的一句話：Garbage In, Garbage Out. 髒活累活都是在這一層完成，以便爲上層業務提供口徑、格式、邏輯統一的數據層，提高數據質量和穩定性，若是這一層沒作好，上層的統計分析與數據挖掘無異於空中樓閣。ETL常見的工做以下：

無效數據

髒數據轉換

數據模型/業務邏輯預處理

高可用：依賴、重試、告警、優先級

四、數據平臺化與產品化

從數據體系和平臺的層次來劃分能夠分爲標準的五層結構：採集層、傳輸層、存儲層、計算層、應用層

隨着業務的不斷迭代，業務逐漸複雜、數據量也急劇膨脹後，每一層都會遭遇挑戰，好比採集層，如何在高併發的狀況下，保證日誌能穩定落地到磁盤而不重不丟不延時？是採用開源的 Nginx+Lua 方案仍是自研組件造輪子？數防止數據的無限膨脹，據倉庫元數據怎麼管理？如何減少維護成本？計算層的任務調度如何解決依賴關係，又如何作到分佈式調度高可用？以上這些問題，早期咱們大部分都採用開源的解決方案，但在後續的易用性、擴展性和維護性都遭遇了很多問題，整體成本一點都不低，所以最後咱們大部分仍是採用自研的解決方案（這塊話題比較廣，細節比較多，本文暫時不展開詳述，有機會後續將會單獨展開分享）。又如計算層的 OLAP 引擎咱們該如何選取？好比 MR 適合大規模數據集的批處理，Hive 適合靈活的探索式即席查詢，Kylin 適合多維實時統計分析，Storm 適合實時流式計算，Spark 適合內存迭代型計算，到底該選誰？能夠看到的是沒有所謂的銀彈和通用解決方案，須要結合自身的業務場景和需求來技術選型和架構。

總體技術棧與架構以下：

數據產品化方面主要是對數據需求與報表的抽象，最終造成通用的自動化報表工具，好比：

業務需求抽象分類：求和、求平均、TOP K、最大最小、去重、過濾

多樣性的解決方案：離線、實時、單維、多維

基於這些抽象，咱們比較容易實現基於報表、統計項和日誌、日誌行之間的邏輯映射關係，造成通用的自助化配置報表，極大釋放開發資源。

另外產品、運營、BOSS可能隨時須要關注業務運營狀態、利用數據作各類分析和業務決策，咱們須要考慮到平臺的移動化與跨終端，這裏咱們在技術選型時就考慮到了這一點，利用比較流行的響應式佈局框架能夠近乎 0 代價實現跨平臺，而不用單獨去開發 iOS 或 android 客戶端。

五、數據指標體系化、分析框架與方法論

數據指標和維度成千上萬，如何基於業務去展開分析，又如何去量化運營效果，評估業務，實際上是須要創建一套科學的分析框架和指標體系的，不然只會迷失在數據的海洋裏，或者盲人摸象得出錯誤的結論，以某二手交易平臺的業務體系爲例，我們能夠看下某二手交易平臺的數據指標體系：

另外基於此咱們設計了一些經常使用的數據模型與分析框架，供業務方快速的分析決策，評估效果，好比留存、漏斗模型，精益創業裏的 AARRR 分析框架，基於用戶事件模型，咱們還實現了自助化的漏斗、留存分析工具，供業務方自助化的配置任意想關注的路徑漏斗或行爲留存。

六、整個數據平臺及其體系化的重難點

漏斗透傳機制：這個屬於日誌埋點問題，若是不解決，一些通用的數據模型如漏斗分析就沒法進行，所以咱們設計了一套 Session 級別的透傳機制，確保用戶每一個頁面或動做的訪問可以被串聯分析，追溯來源入口，精細化分析改善現有產品和有針對性的運營。

數據治理：數據質量的體系化建設，數據倉庫、實時監控是兩個不錯的解決方案。

業務級別的元數據管理：將元數據細化到業務層次，下降業務方的使用門檻，提高決策效率。

數據生命週期管理：哪些是熱數據哪些是冷數據，核心和非核心，長期和短時間，防止數據的無限膨脹，帶來繁重的存儲、維護成本和計算資源的浪費。

大數據場景下的實時多維分析：好比大數據場景下的實時去重計算，咱們會依據不一樣的場景，選取不一樣的方案，如bitmap、分佈式緩存、基數估計等等，在計算代價和時效性、準確性三方面去作 tradeoff。

七、總結：如何根據現有業務，快速從 0 開始打造一個契合業務的數據產品？

走進業務

抽象業務訴求

換位思考，走在需求的前面

站在巨人的肩膀上

萬變不離其宗的方法論

更多免費技術資料及視頻