在 Hive 處理數據時，“半累加數據” 指的是部分字段保留歷史狀態、部分字段隨業務變化累加或更新的場景，這種模式廣泛存在于需要兼顧 “歷史追溯” 和 “增量更新” 的業務中。以下是具體例子，幫助理解其本質：
例子 1：用戶行為維度表（SCD2 模型）
業務場景：用戶信息表中，部分屬性（如注冊時間）一旦生成就固定不變，部分屬性（如用戶等級、積分）需要隨行為累加或更新，同時需要保留歷史狀態。
數據變化過程：
初始數據（2023-01-01）：
用戶 ID 注冊時間 等級 積分 生效時間 失效時間 1001 2023-01-01 Lv1 0 2023-01-01 9999-12-31 2023-02-01 用戶積分增加到 100，等級升級為 Lv2：
不修改原記錄，而是新增一條記錄（保留歷史版本）：用戶 ID 注冊時間 等級 積分 生效時間 失效時間 1001 2023-01-01 Lv1 0 2023-01-01 2023-01-31 （歷史版本） 1001 2023-01-01 Lv2 100 2023-02-01 9999-12-31 （當前版本）
半累加特征：
- 靜態字段（注冊時間）：永遠不變，不參與累加。
- 動態字段（等級、積分）：隨業務更新，新記錄覆蓋舊狀態，但通過 “生效 / 失效時間” 保留歷史。
- 整體數據量：隨變更累加（新增記錄），但單條記錄不被覆蓋。
例子 2：訂單狀態流水表
業務場景：訂單創建后，金額、商品等信息固定，但支付狀態、退款次數等需要隨流程更新，同時需要記錄狀態變更軌跡。
數據變化過程：
訂單創建（2023-03-01 10:00）：
訂單 ID 金額 商品 支付狀態 退款次數 記錄時間 O2001 200 襯衫 未支付 0 2023-03-01 10:00 2023-03-01 10:30 支付成功：
新增一條狀態記錄（不修改原記錄）：訂單 ID 金額 商品 支付狀態 退款次數 記錄時間 O2001 200 襯衫 未支付 0 2023-03-01 10:00 O2001 200 襯衫 已支付 0 2023-03-01 10:30 2023-03-02 09:00 申請退款：
再新增一條記錄：訂單 ID 金額 商品 支付狀態 退款次數 記錄時間 O2001 200 襯衫 未支付 0 2023-03-01 10:00 O2001 200 襯衫 已支付 0 2023-03-01 10:30 O2001 200 襯衫 已退款 1 2023-03-02 09:00
半累加特征：
- 靜態字段（金額、商品）：創建后固定，不參與累加。
- 動態字段（支付狀態、退款次數）：隨流程更新，每次變更生成新記錄。
- 整體數據：按狀態變更累加，可追溯完整流程，但不會覆蓋歷史狀態。
例子 3：每日活躍用戶增量表
業務場景：按天統計活躍用戶，每天的活躍用戶是增量數據，但用戶的基礎信息（如注冊渠道）固定。
數據存儲方式：
- 按天分區（
dt='2023-05-01'、dt='2023-05-02'等）。 - 每個分區存儲當天活躍用戶的信息，包含固定字段和動態字段。
數據示例：
dt='2023-05-01'?分區：用戶 ID 注冊渠道 當日活躍時長（分鐘） 1001 官網 30 1002 應用商店 45 dt='2023-05-02'?分區（新增當日活躍用戶）：用戶 ID 注冊渠道 當日活躍時長（分鐘） 1001 官網 20 （1001 用戶再次活躍） 1003 小程序 15 （新活躍用戶）
半累加特征：
- 靜態字段（注冊渠道）：每個用戶只記錄一次（或重復但值不變），不隨日期累加。
- 動態字段（當日活躍時長）：按日增量記錄，累計計算總時長時需匯總各分區。
- 整體數據：按日期分區累加，每個分區是獨立的增量，不覆蓋歷史分區。
總結
半累加數據的核心是 **“區分靜態與動態字段，保留歷史同時支持增量更新”**，這既滿足了數據倉庫 “可追溯” 的需求，也適配了 Hive 基于 HDFS“擅長追加、不擅長修改” 的技術特性。常見于維度表（SCD2）、狀態流水表、按時間分區的增量統計場景中。
