时间切片特征衍生

当无法使用数据库处理如‘近n个月金额之和/最大值/最小值/平均值’这类变量时,可以借助Python进行特征工程。本文介绍了如何在离线数据处理中,利用Python高效构造时间切片类的特征。

在sql中比较容易处理类似“近n个月金额之和/最大值/最小值/平均值” 这样的变量,使用sum(case when date  then amount else 0 end) 即可,如果是出差在外只能处理离线数据不能使用数据库时,这个时候就要用python去构造时间切片类的特征。整理了自己之前写过的代码,往往都太笨拙和重复。

import pandas as pd
import numpy as np
import time as time
#生成实例数据集
data = pd.DataFrame({'id':['a','a','b','b','a'],
                    'billdate': ['2018-09-01','2018-08-01','2018-08-01','2018-01-01','2018-11-01'],
                    'amount':list(np.random.randint(1,100,5)),
                    'interest':np.random.rand(5),
                    'dt': ['2018-10-01','2018-10-01','2018-11-01','2018-11-01','2018-10-01']
                    })
data

# 首先计算时间差
def month_sub(d1, d2):
    year = int(d1[:4]) - int(d2[:4])
    month = int(d1[5:7]) - i
<think>嗯,用户之前问过关于数据处理中的切片概念,现在又转向数据仓库中全量切片和增量切片的区别。看来用户可能是在做数据仓库设计或者ETL相关的工作,需要理解不同数据存储策略的适用场景。用户引用了站内关于全量表和快照表的描述,说明ta已经做过一些基础调研,但需要更系统的对比。值得注意的是,用户特别要求区分“全量切片”和“增量切片”这两个专业术语,说明ta可能遇到了具体的技术选型问题。先回顾之前的引用材料:引用[1]说明全量表不保留历史变化且每次覆盖,引用[2]提到快照表通过时间分区保留历史全量数据。这其实已经指出了核心差异点——是否保留历史版本。但需要更深入分析:1.全量切片本质是“时点全景快照”,比如每日零点的完整用户数据表,适合变化频繁但数据量不大的场景,比如配置表。引用[2]提到的存储浪费问题确实存在,因为每次要重复存储大量未变更数据。2.增量切片则是“变化量流水账”,比如只记录今天修改过的用户信息。但有个关键点用户可能没意识到:纯增量数据需要配合基础全量表才能还原完整信息,就像git的delta提交需要基于基础版本重构。用户可能还隐含想知道使用建议。比如:业务要求随时回溯历史状态(如金融交易)必须用全量切片+分区;而审计要求不高的日志处理用增量更节省资源。这需要结合ta的具体业务场景,可惜用户没说明。要特别注意术语准确性:“增量切片”在业内更常叫“增量表”或“流水表”,用户使用“增量切片”可能是受前文“切片表”影响。在回答时需要明确这个命名的特殊性,避免混淆。</think> 在数据仓库领域,**全量切片(Full Snapshot)**和**增量切片(Incremental Snapshot)**是两种核心的数据存储策略,其区别主要体现为数据覆盖范围、存储效率和应用场景的差异: --- ### 一、核心定义对比 | **维度** | **全量切片** | **增量切片** | |-------------------|--------------------------------------|---------------------------------------| | **数据内容** | 每次存储当前时间点的**完整数据集** | 仅存储**上次同步后变化的数据** | | **数据关系** | 独立完备,不依赖历史数据 | 需结合基础全量表才构成完整数据集[^1] | | **存储机制** | 按时间分区存储多个版本(如`dt=20240501`) | 通常采用无分区或单分区结构 | | **数据更新逻辑** | 全表覆盖(Overwrite) | 追加写入(Append)或更新变化字段 | --- ### 二、技术特性差异 #### 1. **数据历史回溯能力** - **全量切片**: $$ \text{历史数据版本量} = \text{存储分区数} $$ 通过时间分区(如`dt=20240501`)可回溯任意历史时刻全量数据[^2] *示例:查看5月1日的完整用户画像表* - **增量切片**: $$ \text{完整历史数据} = \text{基础全量表} + \sum_{i=1}^{n} \Delta_i $$ 需基于初始全量表+所有增量变更记录还原历史状态 *示例:用户地址变更记录表仅保存修改记录* #### 2. **存储与计算开销** | **指标** | **全量切片** | **增量切片** | |----------------|----------------------------------|----------------------------------| | 存储空间 | 高(重复存储未变更数据)[^2] | **低**(仅存变更部分) | | ETL计算量 | 每次需全表处理 | **仅处理增量数据** | | 数据冗余 | 未变更数据多副本 | 无冗余(变更数据仅存最新值) | #### 3. **数据一致性保障** ```mermaid graph TB A[数据一致性] --> B[全量切片] A --> C[增量切片] B -->|优势| D[分区隔离 无依赖风险] C -->|风险点| E[需严格保障增量链条完整] E --> F[增量丢失导致数据断裂] ``` --- ### 三、典型应用场景 #### **全量切片适用场景** 1. 数据量小的**维表**(如部门信息表) 2. 需要**高频回溯历史状态**的业务(如金融合规审计) 3. 变更比例超过30%的高频更新表[^1] #### **增量切片适用场景** 1. **事实表**的每日交易流水(如订单日志) 2. 数据量超GB级的**大表**(如用户行为日志) 3. 实时数仓的**CDC(Change Data Capture)同步** --- ### 四、混合解决方案:**拉链表** 为解决全量存储浪费和增量回溯复杂的问题,业内衍生出**拉链表(Zipper Table)**: ```python # 拉链表结构示例 user_zipper = [ {'user_id':101, 'address':'北京', 'start_dt':'2024-01-01', 'end_dt':'9999-12-31'}, {'user_id':101, 'address':'上海', 'start_dt':'2024-05-01', 'end_dt':'9999-12-31'} # 增量更新 ] ``` - **实现原理**:通过`start_dt/end_dt`标记数据生命周期 - **优势**: - 存储量接近增量切片 - 可高效查询任意时间点全量状态 --- > ℹ️ **决策建议**:当数据变更频率低于**15%** 且需要历史追溯时,优先选择拉链表;数据量极小(<10万行)或无需历史追溯则用全量切片;超大规模日志场景首选增量切片
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值