在人口流量紅利不再，獲客成本越來越高的時代，精益創業、mvp 的概念已經深入人心，精細化運營也是大勢所趨，而這些背後本質上都依賴資料化運營，那如何根據現有業務，快速從 0 開始打造乙個契合業務的資料產品呢？本文將以某二手交易平台業務為基礎，講述整個資料平台從 0 到 1 的演進與實踐，希望對大家能有所啟發。
1、背景
在某二手交易平台開始大資料平台建設之前，整個資料從需求提出到研發流程再到資料包表、資料產品，也是經歷過一段非常混沌的時期，而且效率和質量往往很難得到保障，主要表現為以下幾個方面：
（1）可用性差
比如經常出現計算延遲、異常，資料指標也常常資料對不上，很多相似的指標不清楚具體差異在哪，即使同乙個指標也可能不同的同學開發的而對不上。另外資料波動無感知，比如日誌格式出錯，結果第二天才發現有問題。
（2）維護成本高
成百上千的日誌模組，不知從何維護，出了問題也不知道從**可以追溯到源頭和負責人。
（3）業務快速迭代，精細化、資料化運營需求和研發資源之間的矛盾
2、目標與方案
（1）目標
資料可管理、可維護、可擴充套件、高可用
及時、準確、直觀的呈現業務資料與問題
降低使用門檻，提公升使用效率
（2）方案
資料倉儲化
資料平台化
3、資料倉儲建設
結構化層次化
主題化模型化：使用者模型/事件模型
etletl 是整個資料倉儲的核心，正如業界流傳的一句話：garbage in, garbage out. 髒活累活都是在這一層完成，以便為上層業務提供口徑、格式、邏輯統一的資料層，提公升資料質量和穩定性，如果這一層沒做好，上層的統計分析與資料探勘無異於空中樓閣。etl常見的工作如下：
無效資料
髒資料轉換
資料模型/業務邏輯預處理
高可用：依賴、重試、告警、優先順序
4、資料平台化與產品化
從資料體系和平台的層次來劃分可以分為標準的五層結構：採集層、傳輸層、儲存層、計算層、應用層
隨著業務的不斷迭代，業務逐漸複雜、資料量也急劇膨脹後，每一層都會遭遇挑戰，比如採集層，如何在高併發的情況下，保證日誌能穩定落地到磁碟而不重不丟不延時？是採用開源的 nginx+lua 方案還是自研元件造輪子？數防止資料的無限膨脹，據倉庫元資料怎麼管理？如何減小維護成本？計算層的任務排程如何解決依賴關係，又如何做到分布式排程高可用？以上這些問題，早期我們大部分都採用開源的解決方案，但在後續的易用性、擴充套件性和維護性都遭遇了不少問題，總體成本一點都不低，因此最後我們大部分還是採用自研的解決方案（這塊話題比較廣，細節比較多，本文暫時不展開詳述，有機會後續將會單獨展開分享）。又如計算層的 olap 引擎我們該如何選取？比如 mr 適合大規模資料集的批處理，hive 適合靈活的探索式即席查詢，kylin 適合多維實時統計分析，storm 適合實時流式計算，spark 適合記憶體迭代型計算，到底該選誰？可以看到的是沒有所謂的銀彈和通用解決方案，需要結合自身的業務場景和需求來技術選型和架構。
整體技術棧與架構如下：
資料產品化方面主要是對資料需求與報表的抽象，最終形成通用的自動化報表工具，比如：
業務需求抽象分類：求和、求平均、top k、最大最小、去重、過濾
多樣性的解決方案：離線、實時、單維、多維
基於這些抽象，我們比較容易實現基於報表、統計項和日誌、日誌行之間的邏輯對映關係，形成通用的自助化配置報表，極大釋放開發資源。
另外產品、運營、boss可能隨時需要關注業務運營狀態、利用資料做各種分析和業務決策，我們需要考慮到平台的移動化與跨終端，這裡我們在技術選型時就考慮到了這一點，利用比較流行的響應式布局框架可以近乎 0 代價實現跨平台，而不用單獨去開發 ios 或 android 客戶端。
5、資料指標體系化、分析框架與方**
資料指標和維度成千上萬，如何基於業務去展開分析，又如何去量化運營效果，評估業務，其實是需要建立一套科學的分析框架和指標體系的，否則只會迷失在資料的海洋裡，或者盲人摸象得出錯誤的結論，以某二手交易平台的業務體系為例，咱們可以看下某二手交易平台的資料指標體系：
另外基於此我們設計了一些常用的資料模型與分析框架，供業務方快速的分析決策，評估效果，比如留存、漏斗模型，精益創業裡的 aarrr 分析框架，基於使用者事件模型，我們還實現了自助化的漏斗、留存分析工具，供業務方自助化的配置任意想關注的路徑漏斗或行為留存。
6、整個資料平台及其體系化的重難點
漏斗透傳機制：這個屬於日誌埋點問題，如果不解決，一些通用的資料模型如漏斗分析就無法進行，因此我們設計了一套 session 級別的透傳機制，確保使用者每個頁面或動作的訪問能夠被串聯分析，追溯**入口，精細化分析改善現有產品和有針對性的運營。
資料治理：資料質量的體系化建設，資料倉儲、實時監控是兩個不錯的解決方案。
業務級別的元資料管理：將元資料細化到業務層次，降低業務方的使用門檻，提公升決策效率。
資料生命週期管理：哪些是熱資料哪些是冷資料，核心和非核心，長期和短期，防止資料的無限膨脹，帶來繁重的儲存、維護成本和計算資源的浪費。
大資料場景下的實時多維分析：比如大資料場景下的實時去重計算，我們會依據不同的場景，選取不同的方案，如bitmap、分布式快取、基數估計等等，在計算代價和時效性、準確性三方面去做 tradeoff。
7、總結：如何根據現有業務，快速從 0 開始打造乙個契合業務的資料產品？
走進業務
抽象業務訴求
換位思考，走在需求的前面
站在巨人的肩膀上
某二手交易平台大資料平台從 0 到 1 演進與實踐
在人口流量紅利不再，獲客成本越來越高的時代，精益創業 mvp 的概念已經深入人心，精細化運營也是大勢所趨，而這些背後本質上都依賴資料化運營，那如何根據現有業務，快速從 0 開始打造乙個契合業務的資料產品呢？本文將以某二手交易平台業務為基礎，講述整個資料平台從 0 到 1 的演進與實踐，希望對大家能有...
二手交易平台2
1.中低保真原型 2.快速原型 3.web 移動端 平板原型 4.線框圖 5.視覺 基於墨刀的原型設計案例 名稱 二手交易平台 功能 使用者在平台上註冊自己的資訊，將自己不需要的東西放在平台，補充說明商品的資訊，有需要得到人看見後可以 將自己不需要的東西與別人交換。介面組成 搜尋頁，轉換介面標誌，部...
賣家在二手交易平台懟人被禁言 法院 平台行為無不當
程式設計客棧 www.cppcns.com 12月24日 訊息 據杭州網際網路法院訊息，近日，杭州網際網路法院對一起涉二手交易平台網路服務合同糾紛案作出判決，駁回原告訴訟請求。被告a公司運營某二手交易平台，原告張某是該平jxhdibr 臺的註冊使用者。張某欲 一台閒置手機，故在平台發帖尋找買家。一名...