實時數倉項目需求及架構設計

第2章實時數倉項目需求及架構設計

2.1 項目需求分析

1）采集平臺

? （1）用戶行為數據采集平臺搭建

? （2）業務數據采集平臺搭建

2）離線需求

…

2.2 項目框架

2.2.1 技術選型

? 技術選型主要因素：數據量大小、業務需求、行業內經驗、技術成熟度、開發維護成本、總成本預算等。

數據采集傳輸：Flume、Kafka、Maxwell、Filebeat、Logstash
數據存儲OLTP：MySQL、HDFS、HBase、Redis、MongoDB、
數據存儲OLAP：Clickhouse、Greenplum、TDengine、influxdb
數據計算: Hive、Spark、Flink
數據查詢：Kylin、Clickhouse、Greenplum、Doris
數據可視化：DataV、Superset、Echarts
任務調度：DolphinScheduler、Azkaban、Airflow、Oozie、Xxl-job

2.2.2 系統數據流程設計

數據流圖 略

2.2.4 服務器選型

物理機VS云主機

物理服務器：物理服務器是指獨立服務器，也就是指物理上的單獨服務器，物理服務器的構成包括處理器、硬盤、內存、系統總線等，和通用的計算機架構類似，但是由于需要提供高可靠的服務，因此在處理能力、穩定性、可靠性、安全性、可擴展性、可管理性等方面要求較高
云服務器：云服務器是一種簡單高效、安全可靠、處理能力可彈性伸縮的計算服務。其管理方式比物理服務器更簡單高效。用戶無需提前購買硬件，即可迅速創建或釋放任意多臺云服務器。

	物理機	云主機
投入成本	高額的信息化成本投入	按需付費，無需服務器網絡和硬件維護，0運維成本，有效降低綜合成本
產品性能	難以確保獲得持續可控的產品性能	硬件資源的隔離+獨享帶寬，采用高端服務器進行部署，同時采用集中的管理與監控，確保業務穩定可靠；
管理能力	日趨復雜的業務管理能力	集中化的遠程管理平臺+多業務備份
擴展能力	服務環境缺乏靈活的業務彈性	按用戶需求靈活配置，快速的業務部署與配置、規模的彈性擴展能力
技術方面
安全方面
可靠性方面	而物理機則相對來說硬件冗余較少，故障率較高	云服務器是基于服務器集群的，因此硬件冗余度較高，故障率低
穩定性方面	物理機宕機就是宕機，無法挽救	云服務器可以故障自動遷移

2.2.5 集群規模

如何計算集群規模？

每天日活用戶100W，沒人一天平均100條。100W*100條=1億條數據
每條數據1K左右，每天1億數據。1億/1024/1024=100G
1年內服務器： 100G*360天 = 36T
副本數量：3個副本。 3*36T = 108T
預留20%-30%Buffer。 108T/0.7= 150T
假如每臺服務器8T硬盤 128G內存。 150T/8T=20臺服務器

分倉分層則還需要重新計算。

在企業中通常會搭建一套生產集群和一套測試集群。生產集群運行生產任務，測試集群用于上線前代碼編寫和測試。

2.3 規范

數據倉庫建設命名規范

2.3.1 表名規范

ODS層表名:　前綴為ODS_應用系統名（縮寫）數據表名。數據表名稱必須以有特征含義的單詞或縮寫組成，中間可以用“”分割，例如：ODS_FUN_CUSTOMERINFO。表名稱不能用雙引號包含，表名長度不超過30個字符。如果ODS設計采用貼源設計，數據表名應與源系統一致

集成入庫，一般用這樣的命名規范來表示：
```
imp_ods_{源系統庫}_{源表名}_date
```
表的命名，基本可以遵循以下規范：
```
ods_{源系統庫}_{源表名}_date
```
如果有特殊的時間要求，可在表后面加對應的時間標識，如 1d 或者 1m。
DW事實表表名: 前綴為DW_主題名（縮寫）功能描述。數據表名稱必須以有特征含義的單詞或縮寫組成，中間可以用“”分割，例如：DW_ORD_DETAIL。表名稱不能用雙引號包含，表名長度不超過30個字符。

維度表表名
前綴為dm_ 。數據表名稱必須以有特征含義的單詞或縮寫組成，中間可以用“_”分割，例如：D_ACCOUNT、D_PUB_DATE。表名稱不能用雙引號包含，表名長度不超過30個字符。
元數據表名: 前綴為M_應用名（縮寫）功能描述。數據表名稱必須以有特征含義的單詞或縮寫組成，中間可以用“”分割，例如：M_ETL_TASK。表名稱不能用雙引號包含，表名長度不超過30個字符

第3章用戶行為日志

目前主流的埋點方式，有代碼埋點（前端/后端）、可視化埋點、全埋點等。

****代碼埋點****是通過調用埋點SDK函數，在需要埋點的業務邏輯功能位置調用接口，上報埋點數據。例如，我們對頁面中的某個按鈕埋點后，當這個按鈕被點擊時，可以在這個按鈕對應的 OnClick 函數里面調用SDK提供的數據發送接口，來發送數據。

****可視化埋點****只需要研發人員集成采集 SDK，不需要寫埋點代碼，業務人員就可以通過訪問分析平臺的“圈選”功能，來“圈”出需要對用戶行為進行捕捉的控件，并對該事件進行命名。圈選完畢后，這些配置會同步到各個用戶的終端上，由采集 SDK 按照圈選的配置自動進行用戶行為數據的采集和發送。

****全埋點****是通過在產品中嵌入SDK，前端自動采集頁面上的全部用戶行為事件，上報埋點數據，相當于做了一個統一的埋點。然后再通過界面配置哪些數據需要在系統里面進行分析。

3.2 用戶行為日志內容

本項目收集和分析的用戶行為信息主要有****頁面瀏覽記錄、動作記錄、曝光記錄、啟動記錄和錯誤記錄。****

3.2.1 頁面瀏覽記錄

頁面瀏覽記錄，記錄的是訪客對頁面的瀏覽行為，該行為的環境信息主要有用戶信息、時間信息、地理位置信息、設備信息、應用信息、渠道信息及頁面信息等。

第4章用戶行為數據采集模塊

flum安裝配置

kafka安裝配置

數據采集測試

寬表、窄表、維度表、事實表

一、概念

寬表：把多個維度的字段都放在一張表存儲，增加數據冗余是為了減少關聯，便于查詢，查詢一張表就可以查出不同維度的多個字段
窄表：和我們MySql普通表三范式相同，把相同維度的字段組成一張表，表和表之間關聯查詢其他維度數據。
維度表：包含維度編碼和該維度下的多個屬性。

注意 dw(dwd 和dws):存放著明細事實數據、維表數據及公共指標匯總數據，其中明細事實數據，維表數據一般通過ODS層數據加工生成；公共指標匯總數據一般根據維表數據和明細事實數據加工生成。
事實表：包含一個業務事件的相關屬性。

? 事實表就是交易表。
? 維度表就是基礎表。
? 用來解釋事實表中關鍵字緯度的具體內容

二、寬表

2.1 寬表概念

? 寬表，顧名思義，就是比普通的數據表寬的表，比如數據庫表一，在數據庫中是五個字段，表二是四個字段，寬表就是把這兩個有業務聯系的表通過關聯字段弄到一個大表中，這樣列數自然就變多了，表也就寬了，所以就有了寬表。

2.2 為什么要用寬表

業務人員在做數據分析時，所需要的數據往往會存儲在數據庫的多張數據表中，比如訂單表中存儲了訂單編號、商品編號、訂購日期等，商品表中存儲了商品名稱、單價等商品信息，如果要同時查看訂單和商品信息，業務人員不知道數據結構，也很難做表間關聯，所以就要技術人員將兩個表提前關聯好形成寬表。

在olap技術發展過程中主要有MOLAP和ROLAP兩種形式，MOLAP中的數據文件通常叫做“CUBE”，這個名字大家都比較熟悉了，一般是各個olap產品自己的數據文件格式。而隨著數據庫性能的提升，ROLAP 產品逐漸流行起來（本文后續用到的產品潤乾報表就是一個典型的 ROLAP 產品），ROLAP 中數據保留在關系數據庫的事實表中，在使用用途上來說寬表約等于 CUBE。

通過寬表的使用，既能解決多維分析時多表的關聯問題又能提高數據查詢的速度和分析操作的便捷性。

功能模型

元數據管理

基礎事件維護

基礎事件元數據表

字段名	類型	說明
event_id	bigint	主鍵
event_name	varchar	事件名稱
event_mark	varchar	事件標識符
event_group	bigint	事件分組
event_change	int(1)	標記為轉化 0 否 1 是
create_time	datetime	創建時間
attr_ids	varchar	屬性列表

事件屬性維護

屬性表

字段名	類型	說明
attr_id	bigint	主鍵
attr_name	varchar	屬性名
attr_mark	varchar	屬性標識符
attr_type	int(1)	屬性類型 1 文本 2 數字 3 是非
create_time	datetime	創建時間

ods 明細表

ods_pv_event_yyyyMMdd

字段	類型	說明
create_time	datetime	訪問時間
source	varchar	來源
url	varchar	頁面url
client_ip	varchar	訪問ip
uid	varchar	訪客標識碼
client_type	int(1)	設備類型：1 pc 2 h5 3 app
method	varchar	enum ：get post delete put
result_code	varchar	訪問結果狀態碼

dim維度表

dim_省份

字段	類型	說明
city_id	int	id
city_name	varchar	城市名稱
parent_id	int	父id
city_code	varchar	城市編碼
create_time	datetime	創建時間

dim_客戶端類型

字段	類型	說明
client_id	int	id
client_name	varchar	城市名稱
create_time	datetime	創建時間

dw匯總數據

dw_pv_uv_cnt

字段	類型	說明
yyyyMMdd	datetime	日
pv_num	int	pv瀏覽量
uv_num	int	uv瀏覽量
create_time	datetime	創建時間

數據下載

數據治理

元數據管理實踐&數據血緣

? 什么是元數據？元數據MetaData狹義的解釋是用來描述數據的數據，廣義的來看，除了業務邏輯直接讀寫處理的那些業務數據，所有其它用來維持整個系統運轉所需的信息／數據都可以叫作元數據。比如數據表格的Schema信息，任務的血緣關系，用戶和腳本／任務的權限映射關系信息等等。

? 管理這些附加MetaData信息的目的，一方面是為了讓用戶能夠更高效的挖掘和使用數據，另一方面是為了讓平臺管理人員能更加有效的做好系統的維護管理工作。

元數據管理平臺管什么

? 數據治理的第一步，就是收集信息，很明顯，沒有數據就無從分析，也就無法有效的對平臺的數據鏈路進行管理和改進。所以元數據管理平臺很重要的一個功能就是信息的收集，至于收集哪些信息，取決于業務的需求和我們需要解決的目標問題。信息收集再多，如果不能發揮作用，那也就只是浪費存儲空間而已。所以元數據管理平臺還需要考慮如何以恰當的形式對這些元數據信息進行展示，進一步的，如何將這些元數據信息通過服務的形式提供給周邊上下游系統使用，真正幫助大數據平臺完成質量管理的閉環工作。

應該收集那些信息，雖然沒有絕對的標準，但是對大數據開發平臺來說，常見的元數據信息包括：