有贊大數據實踐: 敏捷型數據倉庫的構建及其應用

有贊大數據實踐: 敏捷型數據倉庫的構建及其應用

• 有贊大數據實踐: 敏捷型數據平臺的構建及其應用

  • 前言

  • 數據倉庫設計

    • 整體架構

    • 數據倉庫實例

    • 基礎指標層

    • 分層的好處

    • 數倉工具

  • 數據倉庫與數據分析

    • 即席查詢系統

    • 多維分析系統

    • 搜索分析系統

    • 固定報表系統

  • 數據倉庫在信息檢索中的應用

  • 小結

前言

互聯網公司通常發展迅速. 一方面, 業務飛速發展, 當前應用的形式和模型天天都在變化; 企業的產品也在經歷不斷的下線上線過程. 數據倉庫如何擁抱變化, 是難點之一.

互聯網的運營人員從瞭解經營情況轉化爲精細化運營, 這就於要求數據倉庫具備提供高效明細數據能力, 數據倉庫如何在龐大數據量的前提下, 實現知足不一樣層次的數據提出和分析, 是難點之二.

數據通過ETL最終到達使用數據者手裏; 提取數據和提出數據的需求每每來自不一樣的部門和出於不一樣的目的. 這通常會致使數據口徑不一致, 數據含義模糊, 甚至數據正確性很難校驗. 數據倉庫如何保證數據口徑一致, 數據路徑可追溯性, 是難點之三.

數據倉庫的應用領域除了各個業務部門還包括技術部門自己. 因爲海量數據處理, 互聯網的技術架構愈來愈依賴大數據平臺的支持. 一個點上平臺天天都會有數以萬記的店鋪和商品更新, 數以億計的用戶日誌, 訂單數據等. 這些數據在毫無保留的經過消息隊列彙總到數據倉庫中. 若是使用數據倉庫進行再生產是技術架構重點考慮的事情. 數據倉庫擁有其餘數據平臺沒法比擬的橫向擴展和迭代計算能力, 能夠直接或者間接面向用戶提供數據服務. 這也是大數據的機遇之一.

數據倉庫設計

整體架構

存儲層 主要解決ETL問題, 如何正確的埋點, 數據穩定正確的傳輸, 提供可靠的存儲計算環境等等. 這部份內容比較複雜, 本文不重點闡述.

數據倉庫層 主要提供數據模型和數據工具兩個內容. 數據模型解決數據可用的問題, 數據工具解決數據易用的問題. 本文會重點介紹數據模型的設計方法和數據工具的做用.

數據分析層 主要解決各類角色如何使用數據倉庫的問題. 後面有章節舉例說明每一個分析工具的優點和適用範圍.

數據倉庫實例

數據源主要有兩種來源, 文件和DB. 經過消息隊列收集到hadoop平臺. 數據倉庫的第一層是近源數據層, 這一層基本上和數據源保持同樣的字段結構. 咱們看一下一個例子. 這個例子闡述咱們如何構造"訂單商品中間層".

業務層有數十個基本表. 他們經過收集工具, 消息隊列導入近源數據層中. 這個過程須要作以下幾件事情:

1. 將物理分片的分佈式DB映射成一個Hive表

2. 根據表的內容選擇合適的Hive分區鍵

3. 對於緩慢變化維進行處理, 讓數據表能夠反映變化

4. 對於日誌進行基本的處理映射成Hive表

近源數據層不作以下事情:

1. 髒數據處理;

2. 數據表間一致性處理;

3. 不一樣業務表的合併.

咱們對於近源數據層的定位是能夠"快速"的構建基礎數據平臺. 不作業務相關的處理可讓這部分的工做專一在大數據架構正確性和穩定性的問題.

近源數據層出現之後, 實際上咱們已經能夠開始主要的數據分析工做了. 可是咱們引入了"中間層", 它的定位是"操做簡單, 執行快速, 屏蔽錯誤, 統一口徑".

這個過程主要完成以下幾個事情:

1. 合併不一樣業務爲統一過程;
   業務數據有不少獨立的市場或者版本, 他們客戶和用戶不一樣, 可是工做過程是同樣的. 再好比app和pc的日誌獨立記錄, 可是能夠在必定程度上合併.

2. 屏蔽髒數據, 好比典型的測試數據.

3. 冗餘字段. 把經常使用的join操做在中間層封裝.

咱們看一下訂單寬表的實現過程. 訂單寬表是是以訂單爲主鍵的表. 它包含幾方面的信息:

1. 基本的訂單統計, 主要是訂單主要信息表提供;

2. 訂單的聚類分析, 好比訂單的城市分佈, 年齡分佈分析, 主要是訂單詳細信息表提供;

3. 訂單風險分析, 這就依靠維權訂單表來提供;

4. 等等

這樣咱們產生的訂單寬表在必定程度上知足絕大多數的數據分析問題.

1. 首先, 是數據口徑的問題, 計算寬表的時候會根據業務需求生成不少冗餘字段, 好比對於疑似刷單交易, 不少業務若是都實現一遍的話, 勢必會致使口徑問題, 在設計訂單寬表的時候咱們根據風控模型加入一個字段是否爲空殼交易. 這樣在統計時候各方的口徑都會一致. 一樣髒數據問題也是經過這種方式解決.

2. 其次, 多表join問題, 訂單寬表必定程度上聚合經常使用的字段, 知足80%的數據分析需求. 加上合理的分區設計, 基本上查詢是很是快速的.

3. 最後須要說明的是, 咱們沒有爲全部近源數據表都封裝中間層. 購物車信息咱們就沒有徹底封裝, 由於他們的分析不經常使用. 訂單寬表的設計須要作一個折中. 一方面設計完備的數據倉庫是不現實的, 另外一方面訂單寬表的前提是足夠經常使用, 對於不經常使用的數據咱們的數據平臺是支持直接操做的. 這符合互聯網設計產品的通常思路.

基礎指標層

基礎指標層放映了對一個實體的基本衡量, 是BI分析的基礎. 如上圖所示, 在訂單寬表的基礎上咱們提取出 消費者指標表, 商戶指標表, 商品指標表 等. 好比在商品指標表中, 咱們會針對商品的銷量, 維權數等對商品作基本的畫像, 這樣應用就能夠很是方便的篩選合適的商品.

分層的好處

咱們能夠看到, 從 近源層 到 指標層 層次越高易用性越強, 層次月底, 靈活性就越強. 這樣的設計能夠保證緊急的分析能夠快速響應, 同事穩定的數據能夠經過高層次的數據模型高質量保證.

同時, 咱們意識到數倉模型是迭代的, 逐步晚上的過程. 數據分析的工做不斷的反饋到數倉建設中.

數倉工具

有了可供操做的數據模型. 基本上咱們能夠解決數據倉庫的主要問題. 數據倉庫另一個問題是溯源問題.

1. 一方面溯源有利於咱們清晰的瞭解數據的血緣關係, 方便數據問題的追查.

2. 另一方面, 是數據質量的問題. 想創建一個穩定的數據質量體系保證數據倉庫常年穩定有效實踐過程當中很是困難. 基礎設施的問題, 業務的變遷, 髒數據的產生都會致使正在使用的數據倉庫的質量問題. 數據倉庫另一個要求是隨時能夠跑全量數據.

咱們看一下咱們設計的數據地圖的樣子:

1. 數據地圖能夠用於查看全部報表的路徑和執行過程. 這樣咱們能夠追查特定字段的數據來源, 普遍用於對帳和對數.

2. 數據地圖能夠提供數據任務間的依賴關係, 從而進行快速的全局數據的修補. 舉個例子, 若是咱們在10.30日發現9.1日的日誌裏面存在大量的攻擊日誌(無效日誌)致使不少中間層, 報表數據不許, 咱們只須要把近源數據表修復, 而後設定開始和結束的日期, 全部依賴它的任務都會從新執行.

數據倉庫另一個組件是元數據管理系統. 它的主要做用:

1. 提供幫助文檔, 給出全部可用表格的規格和口徑說明;

2. 規範報表的口徑, 避免口徑歧義.

數據倉庫與數據分析

互聯網的運營人員從瞭解經營情況轉化爲精細化運營. 精細化 首先體如今深度. 傳統的高度彙總的知識性數據不能知足目前的平常需求, 更須要細粒度的探索性數據. 其次精細化體如今廣度上面, 須要BI支持不只僅是管理層或者決策人員. 普通的產品運營, 市場運營, 產品經理都會分析數據分析產品的受衆, 分佈等數據.

咱們提供4種不一樣的工具來知足BI服務.

1. 即席查詢系統

2. olap系統

3. 定製搜索和報表系統

4. 搜索引擎

即席查詢系統

即席查詢系統 的使用者是專業的數據分析人員. 它的定位是數據倉庫的操做平臺.這是使用最普遍的系統, 由於它不須要開發任何工做. 數據倉庫ready後就可使用. 數據倉庫的良好設計和數據字典的文檔做用使得即席查詢系統很是容易上手.

這裏咱們強調一下BI過程和數據倉庫設計的互動性. 對於重要的數據中間層, 咱們提供基本的BI基礎表. 好比訂單指標表和商品指標表.

接着上面的例子, 我看一下BI過程如何利用數據倉庫的. 假如咱們須要分析店鋪的各項指標.

這些指標能夠很是迅速的從訂單寬表中算出來. 不要考慮複雜的交易異常, 髒數據等問題.

另外因爲店鋪指標, 用戶指標等這些經常使用的BI表又能夠做爲基礎指標中間層沉澱下來, 用於更高緯度的數據分析.

所以咱們看到數據倉庫數據整合的3個層次:

1. 近源數據層做爲數據源, 主要是不經常使用的, 簡單的數據.

2. 數據中間層, 使用頻率很高的基於主題的數據.

3. 基礎指標中間層, 基於數據中間層的基礎聚合, 使用頻率更高. 簡化複雜BI過程.

多維分析系統

多維分析系統 的使用者是通常運營人員. 它是特定的中間層圖形化表達. 多維分析系統實現的是對某些指標的特定維度的聚合分析.

多維分析系統咱們是基於kylin引擎作的, 是一種多維度聯機查詢系統. 對於每一個主題(好比訂單主題)提供基於維度篩選和各類聚合功能(好比最大, 最小, 求和等). 並經過表格和圖形化方式展現.

接着上面的例子. 咱們打算作一個訂單主題的多維分析系統. OLAP模型以下:

這樣咱們就能夠輕鬆的回答以下幾個問題.

1. 3C類目的維權訂單趨勢是怎麼樣的?

2. 各類支付方式在每一個省的分佈式怎樣的?
   

多維分析系統的缺點是沒有即系查詢系統靈活. 因爲他須要預加載數據對於維度特別高的查詢支持也不是很好.

搜索分析系統

搜索分析是基於對於緯度創建索引的查詢系統. 他能夠知足對於不一樣指標的多級篩選, 直到篩選出合適的候選集. 以下是一個例子.

咱們須要對商品池進行篩選. 因爲咱們對商品的關鍵屬性創建的索引, 首先能夠根據銷量和維權數篩選出優質高效(A類), 優質精品(B類), 劣質(C類)商品; 再在A類商品的基礎上根據其餘屬性(品類, 客單價, 受衆人羣)等篩選出本次的目標商品集.

在這個過程當中咱們能夠感覺到, 搜索分析系統給咱們的數據分析者一個很大的迭代篩選的平臺, 能夠經過不斷的嘗試和反饋, 提升本身的選品的質量.

固定報表系統

固定報表 通常是針對特徵的數據需求. 這是最多見的BI需求. 好比咱們的GMV報表, 店鋪報表. 在固定報表的基礎上的地動儀系統能夠很好的支持咱們的數據異常點. 好比若是每週一的訂單數據都在100w單左右(舉例), 若是忽然一個週一變成200w單, 就能夠發出報警.

咱們來對比如下經常使用的BI工具.

工具名稱	基本技術	適用人羣	速度	靈活性	適用場景
即席查詢	hive	1. 數據分析人員 2. 有能力的運營人員	慢:10m~1h	強	全部數據分析場景
OLAP系統	olap	產品經理, 運營人員	較快: 10s~10min	中	特定主體的多維分析
搜索引擎	倒排索引	1. 目的性強	快: 10s如下	中	根據條件的主題檢索
報表系統	mysql	報表相關人員	快: 10s如下	低	特定業務數據的查閱

數據倉庫在信息檢索中的應用

數據倉庫不只在用於BI, 數據倉庫實際上充當着企業數據總線的做用. hadoop爲存儲介質的數據倉庫簡化了信息檢索的成本. 包括數據的獲取, 計算和加載.

信息檢索系統應該和業務數據解耦. 咱們迴歸一下傳統的信息檢索系統的構建過程. 傳統的搜索工具通常都是基於倒排索引的, 或者kv的的系統, 通常都是單機模式 + 代理的分佈式方案.

1. 傳統的搜索引擎, kv引擎等數據與業務數據高度耦合. 業務數據通常存儲在DB中, 咱們經歷過搜索引擎數據丟失的狀況, 咱們不得當心翼翼的與業務方配合追查, 一不當心一個sql就把業務服務器整垮了.

2. 數據沒法保證徹底性. 搜索引擎是一個龐大的系統, 數據通過不少環節才進入索引, 通常都是批處理或者實時構建. 補一個步驟都須要保證數據正確性. 不然索引數據就不許. 因爲索引數據的很是寶貴. 搜索團隊還要花費不少功力研究如何備份索引, 以防止之外丟失.

3. 搜索數據與業務數據不一致. 對數據是任何兩個部分在處理同一份數據時候都會經歷的問題.

咱們仍是以訂單相關的業務爲例. 經過"訂單", "維權", "購物車", "狀態變動"等基本事務過程產生相關的DB和日誌數據; 我在在這些基本的數據上搭建"訂單檢索", "訂單導出", "數據報表"等信息檢索的業務. 和左側的業務不一樣, 這些業務不須要交互和事務, 是一個"一寫多讀"的功能模塊.

因爲日誌和DB是基於技術通用性設計的, 沒有考慮各個業務的需求. 各個業務勢必會有各自不一樣的業務處理代碼. 好比訂單檢索和數據報表在理論上應該是能夠進行精確的"對數"的. 可是因爲各自的業務代碼是獨立的, 所以在數據一致性方面會遇到問題.

搜索引擎的搭建是一個龐大的工程, 首先咱們要經過消息隊列訂閱全部的數據, 而後咱們在業務處理層將數據進行整合, 而後創建索引. 這裏咱們會遇到橫向擴展的問題. 咱們不得不根據一個合適的主鍵講消息隊列的數據分流, 分別創建索引.

咱們發現全量索引是昂貴的. 全量索引意味着導表, 咱們不得不提供專門爲搜索引擎使用的備庫, 若是數據庫自己是分片的, 那麼每片咱們都要導入.

若是咱們引入大數據平臺, 就能夠徹底把搜索引擎和DB解耦.

1. 數據平臺是基礎數據的徹底鏡像.

2. 數據平臺很是的皮實. 不只能夠隨時拉去海量數據不影響業務, 並且能夠經過批量計算和迭代計算進行復雜的數據處理.

3. 大數據有逐漸成熟的解決方案體系. 包括批處理, nosql, 和搜索引擎(solr和elasticsearch).

咱們看一下以數據倉庫爲中心的架構.

1. 數據倉庫充當業務數據層. 數據倉庫封裝了重要的數據口徑. 讓業務處理更加關注上層的業務,不須要關注通用的數據處理和封裝.

2. 大數據平臺讓各類數據引擎執行過程簡單可靠. 大數據以透明拓展性和高度可計算性著稱, 可是傳統的搜索引擎, 本質上是單機程序, 他們的分佈式解決方案須要代理層. 如何讓他們享受大數據的優點, 不少人給出解決方案. 咱們這裏給出基於hadoop-elasticsearch的方案, 主要不是介紹相應的技術細節而是強調咱們的思路.

3. 搜索算法能夠有更多發揮空間. 基於數據倉庫的算法平臺, 充分spark等迭代計算的優點, 能夠提供搜索引擎不少算法組件, 好比商品的質量度, 商品的類目, 反做弊數據等.

小結

咱們介紹了大數據平臺下的數據倉庫. 數據倉庫在設計上儘量簡單, 配合BI和信息檢索的應用迭代優化. 爲了保證數據倉庫的可用性, 咱們引入數據字典, 數據地圖等工具. 在數據倉庫上面, 咱們搭建了幾種BI工具, 即席查詢, olap, 數據報表和搜索引擎, 根據不一樣的需求方和場景給出不一樣的解決方案. 最後咱們介紹了數據倉庫在信息檢索領域的應用, 咱們看到利用大數據平臺的分佈式能力, 強大的業務整合能力, 給咱們的信息檢索帶來很大的業務和技術上的便利.

數據是一個企業最重要的資產之一, 如何利用數據價值變得愈來愈重要. 一個優秀的大數據平臺的建設是一個重要的前提. 大數據平臺愈來愈像一個企業的數據總線: 是全部數據的入口, 同時也是全部數據的出口. 像不少企業正在努力的同樣, 咱們但願可以構建一個靈活可靠的數據倉庫. 它像一個企業的基礎設施同樣, 咱們能夠利用它提供的數據上, 工具上的服務來搭建咱們須要的數據平臺, 知足業務需求.

關於做者

洪斌, 有贊大數據團隊負責人, 專一大數據和數據挖掘相關技術. 歡迎交流. 

來自爲知筆記(Wiz)