數倉分層 |分層|全稱|譯名|說明|壓縮|列式存儲|分區| |-|-|-|-|-|-|-| |ODS|Operation Data Store|原始層|原始數據|✅|❌|✅| |DIM|Dimension|維度層|合併維度表|✅|✅|✅| |DWD|Data Warehouse Detail|明細層 ...
數倉分層
| 分層 | 全稱 | 譯名 | 說明 | 壓縮 | 列式存儲 | 分區 |
|---|---|---|---|---|---|---|
| ODS | Operation Data Store | 原始層 | 原始數據 | ✅ | ❌ | ✅ |
| DIM | Dimension | 維度層 | 合併維度表 | ✅ | ✅ | ✅ |
| DWD | Data Warehouse Detail | 明細層 | 數據處理、維度建模 | ✅ | ✅ | ✅ |
| DWS | Data Warehouse Service | 服務層 | 去主鍵聚合，得到原子指標 | ✅ | ✅ | ✅ |
| DWT | Data Warehouse Topic | 主題層 | 存放主題對象的累積行為 | ✅ | ✅ | ✅ |
| ADS | Application Data Store | 應用層 | 具體業務指標 | ❌ | ❌ | ❌ |
- ODS：原始數據，日誌和業務數據 放到 Kafka
- DWD：根據數據對象為單位進行分流，比如訂單、頁面訪問等等
- DIM：維度數據
- DWM：對於部分數據對象進行進一步加工，比如獨立訪問、跳出行為，也可以和維度進行關聯，形成寬表，依舊是明細數據。
- DWS：根據某個主題將多個事實數據輕度聚合，形成主題寬表。
- ADS：把ClickHouse中的數據根據可視化需進行篩選聚合
命名規範
庫名：業務大類
表名：分層名_業務細類
臨時表：temp_表名
備份表：bak_表名
視圖：view_表名（場景：不共用的維度表、即席查詢）
| 分層 | 命名規範 | 說明 | 例 |
|---|---|---|---|
| ODS | ods+源類型+源表名+full/i | full：全量同步 i：增量同步 |
ods_postgresql_sku_full ods_mysql_order_detail_i ods_frontend_log |
| DIM | dim+維度+full/zip | full：全量表 zip：拉鏈表 日期維度表沒有尾碼 |
dim_sku_full dim_user_zip dim_date |
| DWD | dwd+事實+full/i | full：全量事實 i：增量事實 |
|
| DWS | dws+原子指標 | 時間粒度有1d、1h… 1d：按1天 1h：按1小時 |
dws_page_visitor_1d |
| DWT | dwt_消費者畫像 | ||
| ADS | ads+衍生指標/派生指標 |
離線數倉：事實表，維度表，都放Hive
實時數倉：原始數據放 Kafka，維度數據 放 HBase，Phoenix
-
離線計算：就是在計算開始前已知所有輸入數據，輸入數據不會產生變化，一般計算量級較大，計算時間也較長。例如今天早上一點，把昨天累積的日誌，計算出所需結果。最經典的就是 Hadoop 的 MapReduce 方式；
一般是根據前一日的數據生成報表，雖然統計指標、報表繁多，但是對時效性不敏感。從技術操作的角度，這部分屬於批處理的操作。即根據確定範圍的數據一次性計算。 -
實時計算：輸入數據是可以以序列化的方式一個個輸入併進行處理的，也就是說在開始的時候並不需要知道所有的輸入數據。與離線計算相比，運行時間短，計算量級相對較小。強調計算過程的時間要短，即所查當下給出結果。
主要側重於對當日數據的實時監控，通常業務邏輯相對離線需求簡單一下，統計指標也少一些，但是更註重數據的時效性，以及用戶的交互性。從技術操作的角度，這部分屬於流處理的操作。根據數據源源不斷地到達進行實時的運算。 -
即席查詢： 需求的臨時性，小李，把兩星期的數據拉給我看下（只在這個時刻需要）
Presto: 當場計算（基於記憶體速度快）
Kylin:預計算（提前算好），多維分析（Hive With Cube)
Sqoop 導入數據方式:
-
增量： where 1=1、
-
全量： where 創建時間=當天、
-
新增及變化：where 創建時間=當天 or 操作時間=當天、
-
特殊（只導入一次）
Flume: -
tailDirSource
優點：斷點續傳，監控多目錄多文件
缺點：當文件更名之後，重新讀取該文件造成數據重覆
註意：1. 要使用不更名的列印日誌框架（logback)--一般logback 也會設置成更名的，每天一個日誌文件，文件名帶上日期，如果寫死文件名，更名後可能會丟數據
2.修改源碼，讓TailDirSource判斷文件時，只看 iNode 值 -
KafkaChannel
優點：將數據導入Kafka，省了一層Sink
Kafka：生產者、消費者
用法：1. Source-KafkaChannel-Sink
2. Source-KafkaChannel
3. KafkaChannel-Sink
邏輯線： 數據流、監控、優化、配置。
Kafka
- Producer:ACK、攔截器、序列化器、分區器、發送流程、事務、冪等性，分區規則-->有指定分區發到指定分區，沒有根據Key進行hash,都沒有進行輪詢（粘性）
- Broker: Topic 副本-> 高可用 ISR LEO、HW ；分區：高併發、負載均衡（防止熱點）
- Consumer：分區分配規則 offset 保存（預設：_consumer_offsets 主題、其它：手動維護Offerset(MySQL)帶事務，精準一次消費
分層的好處
- 複雜問題拆解為多層
- 減少重覆開發（可以去中間層取數，不用每次都去原始層）
- 隔離原始數據，例如：異常數據、敏感數據（用戶電話…）
數據存儲策略
- 原始層保持數據原貌，不進行脫敏和清洗
- 創建分區表（例如：日期分區），防止全表掃描
- 數據壓縮，減少磁碟占用（如：LZO、gzip、snappy）
- 列式存儲提高查詢效率（如：Parquet、ORC）
離線架構：追求系統的穩定性、考慮到公司未來的發展，數據量一定會變得很大、早期的時間實時業務使用 SparkStreaming(微批次)
- 優點：耦合性低、穩定性高
- 缺點：時效性差
實時架構：Kafka集群高可用，數據量小，所有機器存在同一個機房，傳輸沒有問題，
- 優點：時效性好 Flink
- 缺點：耦合性高，穩定性低
