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

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

搭建一套切合企業商業模式並高效運作的數據平臺，主要有以下幾個優點：一是可以使原來分散於各業務系統的數據實現體系化存儲，告別取數低效與數據缺漏；二是能夠實時監控業務 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大數據技術》. 清華大學出版社

閱讀更多 神策數據 的文章

關鍵字: 平臺 數據 搭建