在開始介紹數據平臺搭建的流程之前，先簡單說說為什么企業需要搭建數據平臺。

互聯網與智能移動設備的迅速發展，使記錄并保存用戶的每一次日常行為及交易行為成為可能，這些信息以數據的形式保存下來，實現了各行業的商業數據原始積累。為了高效組織和利用海量數據進行商業決策優化，搭建數據平臺是企業的不二之選。

搭建一套切合企業商業模式并高效運作的數據平臺，主要有以下幾個優點：一是可以使原來分散于各業務系統的數據實現體系化存儲，告別取數低效與數據缺漏；二是能夠實時監控業務 KPI，并通過數據分析，發現核心問題與一些依靠經驗不能發現的潛在問題，提出有效建議，輔助決策，驅動業務快速增長；三是確保海量數據抽取、存儲和計算的穩定性與安全性。

下面進入正題，本文將從以下 6 個步驟介紹數據平臺搭建流程：

• 明確業務模式和現階段戰略目標

• 拆解戰略目標，形成各業務環節的“第一關鍵指標”

• 第一關鍵指標再分解

• 數據需求上報

• 數據采集、接入、存儲和計算的實現

• 數據可視化應用與輸出 API

明確業務模式和現階段戰略目標

做事切忌知其然而不知其所以然。搭建數據平臺之前，我們首先需要確定數據指標體系，而數據指標體系又是為企業的商業模式和戰略目標所服務的。

因此，先跟公司管理層敲定業務模式與戰略目標，我們才能知道指標體系怎么搭，數據平臺該滿足什么功能，為什么要滿足這些功能，只有滿足用戶需求的數據平臺，才是好的數據平臺。

在這里補充一下數據指標體系的重要性。有人可能會問，為什么搭建數據平臺之前，要先確定數據指標體系。

這是因為，數據指標體系將直接影響“數據抽取>數據存儲>數據預處理與計算>數據可視化應用”整個數據平臺功能實現流程。如果一開始沒有做好數據指標體系的建設工作，后續將會導致無休止的修改。

對于業務部門來說，可能會經常發現缺少某個指標，然后進行頻繁的數據需求修改，這樣的修改會導致指標體系與報表結構的邏輯混亂，形成數據泥濘，分析師不得不花大量時間去理清指標關系和找數據；對于開發部門來說，頻繁的需求修改會導致冗長的開發迭代周期，浪費人力物力。

拆解戰略目標，形成各業務環節的“第一關鍵指標”

有了戰略目標，接下來我們可以將其分解成更微觀的目標，以便后續落實到數據平臺上去，按照產品業務流程進行拆分是個明智的選擇。

那么如何按照產品業務流程對戰略目標進行拆分？我們需要對產品業務流程進行分解，明確各個環節所涉及的業務部門，可能產生的數據。這些信息我們可以通過對公司各業務部門進行調研得出。

最后我們以戰略目標為中心，結合以上信息，并對業務部門負責人進行訪談，共同把戰略目標拆分為各業務環節的“第一關鍵指標”。

這其實就是搜集數據需求的過程。

下面通過展示一個 SaaS 產品的簡化業務流程來進行舉例說明（圖中內容僅為參考）。

圖 1?某 SaaS 產品業務流程分解圖

明確各個環節所涉及的業務部門，可以讓我們有體系地去確定數據需求，并通過對這些特定業務部門的調研，確保各個環節的數據指標實用且全面。

明確可能產生的數據，可以讓我們了解各環節乃至整個產品流程所產生的數據種類和體量，并啟發我們敲定所需指標。?

而“第一關鍵指標”，來自于《精益數據分析》一書所提出的來的概念——“這是一個在當前階段高于一切，需要你集中全部注意力的數字”，這有助于集中精力與資源解決特定階段最重要的問題。在這里，我們把戰略目標拆分成各業務環節的第一關鍵指標，作為部門核心 KPI。

關于思考業務環節第一關鍵指標的思路，除了與業務部門頭腦風暴外，還可參考 AARRR 模型。對此，我以 AARRR 模型為基礎整理了互聯網產品常用的 38 個原始指標，可以作為指標池，圖 2 列示了這些指標。

圖 2?互聯網產品常用原始指標池

第一關鍵指標再分解

有了第一關鍵指標和了解業務流程所產生的各種數據后，我們需要對第一關鍵指標進行再拆分，拆分標準為各種與當前業務環節及第一關鍵指標有關聯的維度。

當然，我們也要跳出具體環節俯瞰全局，維度的劃分不應脫離整個業務邏輯。?

下面我們以圖 1 的“新增用戶數”來舉例說明，如何對第一關鍵指標進行維度下鉆。

通常我們可以從以下維度對指標進行拆解（如圖 3）。當然，我們要時刻謹記具體問題具體分析，不同的商業模式與產品的不同階段，即使是同一個指標，劃分時參考的維度也不一樣。

圖 3?新增用戶數指標拆分維度

在通過“第一關鍵指標+維度”矩陣敲定所有數據指標后，數據指標體系的建立工作基本完成。

需要重點注意的是，必須與業務部門和開發人員明確每個指標的定義與計算方式，務必讓所有人對此達成共識，否則后續大概率會因為各人對同一指標的定義不明確而造成數據采集出錯與分析結果無效。例如，對于新增用戶，我們定義的是注冊并激活，而不是只是注冊。

數據需求上報

走完前面三步以后，數據需求基本采集完成，數據指標體系成型，這個時候我們需要根據數據指標的定義和計算邏輯，填寫數據需求上報文檔并提交給開發人員。

數據需求上報文檔有兩個重要的作用：一是讓各數據關聯方（如業務人員、分析人員、開發人員）對數據指標有統一的定義認知，避免數據出錯與降低溝通成本；二是其決定了數據如何傳輸、存儲，并被如何分析處理。

數據需求上報文檔應包含的內容如下所示：

圖 4?數據需求上報文檔的主要內容

為了保證數據上報的可行性和準確性，建議與開發人員一同敲定最終的數據采集、存儲和計算方案。

數據采集、接入、存儲和計算的實現

這部分主要是數據開發工程師等技術人員的工作，涉及概念與技術較多，我們分步展開。

1.數據源

先說說數據來源。企業的數據來源可分為內部數據源和外部數據源 。

內部數據源主要是個業務系統數據庫和日志數據，外部數據源主要是一些爬蟲數據或第三方數據。

這些數據按照結構形式又可以分為結構化數據、半結構化數據和非結構化數據。

結構化數據是指可以由二維表結構來邏輯表達和實現的數據，嚴格地遵循數據格式與長度規范，例如用戶基本信息、訂單信息等。

非結構化數據是指不適于由數據庫二維表來表現的非結構化數據，包括所有格式的辦公文檔、XML、HTML、各類報表、圖片和音頻、視頻信息等。

而半結構化數據是結構化的數據，但是結構變化很大，不能簡單的建立一個表和它相對應。如存儲員工的簡歷，不像員工基本信息那樣一致，每個員工的簡歷大不相同。有的員工的簡歷很簡單，比如只包括教育情況；有的員工的簡歷卻很復雜，比如包括工作情況、婚姻情況、出入境情況、戶口遷移情況等。

業務系統數據庫的數據一般是結構化數據，日志數據和爬蟲數據三者均有。

2. 數據采集

數據是采集到數據倉庫的，采集過程的重點是 ETL，ETL 即抽取（extract）、轉置（transform）、加載（load）。

會存在 ETL，是因為數據源的數據通常是以各種不同結構和方式存在的，且包含臟數據與無用數據，把數據源粗暴直接地不作加工就導入數據倉庫是大忌。?

為了更好的理解內容，先補充一下數據倉庫的概念。

關于數據倉庫

我們日常所說的數據庫，是面向業務的數據庫，也稱操作型數據庫，用于支撐業務，主要對業務數據進行增刪改查，典型數據庫有 Oracle、MySQL 等。?

而數據倉庫是分析型數據庫，它把各種數據有條理地集合在一起，供企業多維度進行分析決策。正因如此，數據倉庫有以下兩個主要特點：

一是它是面向主題的數據庫，數據按照主題域進行組織，這里所說的主題，指的是用戶使用數據倉庫進行決策時所關心的重點方面，如用戶行為、訂單等。

二是數據倉庫是集成的和匯總性的。數據倉庫的數據來自于分散的操作型數據庫或日志數據等數據源，我們將所需數據從原來的數據中抽取出來，進行加工與集成，統一與綜合之后才能進入數據倉庫。

知道什么是數據倉庫之后，也就不難理解為什么需要 ETL。

ETL 的具體過程如下：一是抽取，我們需要對數據源進行篩選，抽取出有用的數據；二是轉換，此環節主要是數據預處理，也可以叫數據清洗，具體為刪除對決策沒有意義的數據與重復數據、處理缺失值、簡單的匯總計算以及把不同的數據定義方式統一，最終形成符合數據倉庫結構模式且有分析價值的數據；三是加載，即把轉換好的數據加載到數據倉庫里。

3.數據接入

在介紹數據接入工具前，我們先來大致了解一下大數據平臺的架構，這也是為后續介紹數據存儲與計算做鋪墊。

關于大數據平臺架構與 Hadoop

現今大數據平臺采用分布式系統（分布式系統可以通俗理解為，海量數據的存儲和處理是一臺計算機難以實現的，那么可以通過把數據分布在多臺計算機形成一個分布式集群，實現海量數據的存儲與處理），而 Hadoop 是主流的分布式系統基礎架構，讓我們可以充分利用集群的威力進行數據存儲和數據計算。

Hadoop 以 HDFS 和 MapReduce 為核心，HDFS 是分布式文件處理系統，為海量數據提供分布式存儲，而 MapReduce 是分布式數據處理和執行環境，用于對大規模數據集進行運算。在這些基礎上，部署了眾多用于數據接入、存儲和計算的工具，這些工具都是 Hadoop 生態組件，主要有 Hive、HBase、Sqoop、Flume。

對于業務系統數據庫的數據，我們一般用 Sqoop。Sqoop 是一款 Hadoop 和關系型數據庫之間進行數據導入導出的工具。借助這個工具，可以把數據從諸如 Oracle 和 MySQL 等關系型數據庫中導入到 HDFS 中，也可以把數據從 HDFS 中導出到關系型數據庫。

對于業務日志類數據，則需要用 Flume。Flume 是由 Cloudera 提供的高可用、高可靠、分布式，進行海量日志采集、聚合和傳輸的系統，后成為 Hadoop 組件之一。Flume 可以將應用產生的數據存儲到任何集中存儲器中，如 HDFS。

4.數據存儲

數據存儲涉及 Hive 和 HBase，二者都是基于 HDFS 的數據（倉）庫。?

結構化數據存儲在 Hive，并通過 Hive 實現數據離線查詢。Hive 是基于 Hadoop 的一個數據倉庫工具，以 HDFS 為基礎，可以將結構化的數據文件映射為數據庫表，并提供簡單的 SQL 查詢功能，將 SQL 轉化為 MapReduce 進行運算，避免使用者撰寫大量且復雜的 MapReduce 代碼，降低使用門檻。

非結構化數據存儲在 HBase，且 HBase 能實現 Hive 所做不到的數據實時查詢。HBase 是分布式的、面向列的開源數據庫，同樣以 HDFS 為存儲基礎，以 MapReduce 為數據處理基礎。

5.數據計算

海量數據的計算處理涉及 MapReduce 和 Spark。如前文所述，MapReduce 是 Hadoop 兩大核心之一，用于對大規模數據集進行運算，關于其計算原理，涉及內容較多且技術性較強，在此不展開說明。?

那么 Spark 則是 MapReduce 的替代方案，通俗點也可以說是 MapReduce 的升級版，Spark 現今已經成為大數據計算領域的核心，它彌補了 MapReduce 不能處理較為復雜的多重計算需求（如迭代計算、機器學習）問題，且算法性能相對 MapReduce 提高 10-100 倍。

數據可視化應用與輸出 API

需要有這么一個應用程序，業務人員可以通過簡單的點擊或拖動來訪問平臺中的數據，而平臺計算的數據結果也能以可視化的形式來展現，這就是數據平臺的數據應用層，是做可視化 BI 分析的地方。

這個時候，可以直接對接主流的 BI 系統，如 Tableau。

圖 5?Tableau 操作界面

我們也可以自建 BI 應用，這就涉及應用終端的功能設計與開發。這里所說的應用終端的功能設計，我指的是該應用應包含哪些分析功能、報表和數據看板等，形式上可以參考市面上的一些產品。但有時會存在 BI 系統或者終端應用的功能不能滿足分析需求的時候，或者業務人員想直接獲取數據倉庫內的數據，這個時候通過輸出 API 來實現。

除此之外，很多企業也開始拋棄 BI ，或在 BI 的基礎上引進一些市面上已經非常成熟的集數據分析與用戶行為分析一體的數據平臺（如神策分析），以此省去企業自身建造數據平臺的投入和試錯成本，特別是對于創業型和正在轉型的公司，借力市面上已得到市場驗證和認可的產品減少與資金雄厚的市場巨頭的差距并逐步超越是目前的最佳選擇。

圖 6?神策分析電商 demo（數據均為虛擬）

結語

事實上，前文中的步驟 1-4，有關搭建數據指標體系和采集數據需求的部分，具有通用性。但對于數據平臺的搭建技術，視企業的數據量大小和預算高低，技術方案會有所不同，不能一概而論。

注：本文為 VanessaChao 投稿，文中觀點不代表神策數據立場。

主要參考資料

[1]：蘭軍《實戰案例｜構建產品數據運營體系的11個步驟》

http://www.woshipm.com/data-analysis/708758.html

[2]：李笑繁《數據產品經理如何從0開始做數據平臺》

http://www.woshipm.com/pmd/1073453.html

[3]：黑夜月《數據產品經理，該如何搭建數據指標體系？》

http://www.woshipm.com/pmd/1418055.html

[4]：王鋒《大數據平臺建設實踐與探討》

https://mp.weixin.qq.com/s/QGvzcItmGzF8VSPViCm4UQ

[5]：徐曉鵬《知乎回答：如何創建一個大數據平臺？具體的步驟》

https://www.zhihu.com/question/37627092/answer/74278297?utm_source=wechat_session&utm_medium=social&utm_oi=781249558997925888

[6]：劉彬斌《Hadoop+Spark大數據技術》. 清華大學出版社

喜訊 · 必看

為了給更多神策數據的新老粉絲帶來更多價值，神策數據公眾號特新增欄目【周四話運營/產品/技術/分析】，關于此欄目：

1.如果你有什么好的建議歡迎留言或后臺回復告知，策小編會一字不落的悉心聽取，好的建議，還有禮物哦~

2.如果你文采超凡，希望得到一個展示的舞臺，也可以將你的作品投遞給我們，如果恰好符合我司的口味，可免費在神策數據新媒體矩陣進行發布（微信公眾號要求首發哦），一不小心就成大 V 了呢~

建議&投稿都可以發送至郵箱：wangyajun@sensorsdata.cn

『不容錯過的精彩內容』

▼▼▼

• Hello，SDK！數據采集黑客松大賽重磅開啟，Mac&投影儀任你拿！

• CTO 和你嘮嘮，這 7 個團隊都在干啥 | 神策招人記

• 流量從“海量”到“僵化”，精細化運營是企業最后一根救命稻草
  

• PPT 下載 | 神策數據朱靜蕓：消費者全渠道精細化運營方案
  

• 神策數據攜手綠城服務 筑就幸福綠城數據驅動

• 《Android 全埋點解決方案》預售正式開啟！

收藏★公眾號，及時獲取精彩內容

↙↙↙點擊“閱讀原文”，免費體驗產品

“在看”，你就戳戳我??

總結

以上是生活随笔為你收集整理的6 步搭建数据平台—从指标体系到相关技术 | 周四话数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。