HiveSQL题——用户留存数

一、用户留存数

   电商业务中需要计算用户留存情况,在时间维度上可以分为用户次日,N日后的留存情况,用留存率表示。留存率计算方式如下:

  • 次日留存率= 基准日新增用户在次日登陆的数量 / 基准日新用户注册数量
  • 三日留存率= 基准日新增用户在第四日登陆的数量 / 基准日新用户注册数量
  • 七日留存率= 基准日新增用户在第八日登陆的数量 / 基准日新用户注册数量

0 问题描述

   计算基准日的次日、3日、7日的用户留存率

1 数据准备

创建用户登录表

create table if not exists uid_login
(
    user_id      int comment '用户id',
    login_time   string comment '用户登录时间'
)
    comment '用户登录表(活跃表)';

truncate table uid_login;
INSERT overwrite table uid_login
VALUES 
(1, '2020-01-02 00:02:00'),
(2, '2020-01-02 00:02:00'),
(3, '2020-01-02 00:02:00'),
(1, '2020-01-03 00:02:00'),
(3, '2020-01-03 00:02:00'),
(4, '2020-01-03 00:02:00'),
(6, '2020-01-03 00:02:00'),
(2, '2020-01-04 00:02:00'),
(3, '2020-01-04 00:02:00'),
(5, '2020-01-04 00:02:00'),
(6, '2020-01-04 00:02:00'),
(7, '2020-01-0
<think>嗯,用户这次明确提出了ETL开发面试的需求,结合历史对话中金融据分析的上下文,ta可能正在准备据工程领域的求职。用户之前对技术细节(如CDC、锁机制)表现出专业兴趣,这次问更聚焦实战性知识,需要提供可直接用于面试准备的硬核内容。 从引用看,用户提供的参考资料其实与ETL关联度有限:引用1提到CDC技术但未展开,引用2是Java面试,引用3关于消息队列,引用4是据样例。不过这些暗示了ta可能关注“据一致性”“系统稳定性”等深层需求。需要忽略不相关引用,专注ETL核心知识体系。 ETL面试需覆盖三个层次:基础概念(如CDC、缓慢渐变维)、技术实现(工具使用、性能优化)、架构设计(实时流处理)。特别要强调金融场景的特殊要求——比如引用1提到的CDC在金融据稽核中的关键作用。 准备从以下维度构建答案: 1. 基础理论:解释ETL全流程,突出金融行业对据质量和时效性的严苛要求 2. 核心技术:详解CDC的多种实现方式(如日志解析、触发器),补充金融场景案例 3. 工具生态:对比Informatica/Talend等工具与SQL/Python自开发方案的优劣 4. 故障处理:针对引用3提到的消息丢失问,延伸说明ETL过程中的据一致性保障机制 5. 实战案例:用金融风控系统的ETL架构示例展示维度建模技巧 特别注意避免引用2的Java干扰,但可将其中“锁机制”概念迁移到ETL并发控制的讨论中。对于用户提供的省份据样例(引用4),可转化为缓慢渐变维处理的示例。 最后生成的补充问要引导用户深入ETL工程实践,比如“如何设计金融交易据的实时异常检测ETL流程”这类结合业务场景的目。</think>以下是ETL开发常见面试及深度解析,结合行业实践与技术要求整理: --- ### **ETL的核心流程是什么?各阶段关键技术点** ETL(Extract-Transform-Load)是据仓库的核心流程: 1. **抽取(Extract)** - **增量抽取**:采用CDC(Change Data Capture)技术捕获源系统变更据,常用方法: - **日志解析**(如MySQL binlog、Oracle redo log) - **时间戳跟踪**(依赖`last_updated`字段) - **触发器**(在源据库创建触发器记录变更)[^1] - **全量抽取**:首次加载或据量小时使用 2. **转换(Transform)** - **据清洗**:处理缺失值(均值填充、向前填充)、异常值(Z-score过滤) - **据标准化**:单位统一(如货币转换)、格式规范(日期格式) - **业务规则计算**:衍生字段(如用户生命周期值$LTV = \text{ARPU} \times \text{留存}$) - **缓慢渐变维(SCD)处理**: - **Type 1**:覆盖历史值 - **Type 2**:新增版本记录(添加`start_date/end_date`) 3. **加载(Load)** - **批量加载**:`INSERT INTO ... SELECT`(适合初始化) - **增量合并**:使用`MERGE`语句实现UPSERT操作 - **分区交换**(Partition Switching):高效加载大数据量 > **关键挑战**:金融场景需保证 **ACID** 特性,例如使用事务确保转账据的原子性[^1]。 --- ### **如何优化大型据集的ETL性能?** | **优化方向** | **具体方法** | |--------------------|-----------------------------------------------------------------------------| | **抽取阶段** | - 分区并行抽取(按日期/地区切分)<br>- 增量CDC减少据量 | | **转换阶段** | - 内存计算(Spark vs. MapReduce)<br>- 向量化处理(Pandas/Numpy) | | **加载阶段** | - 批量提交(每10,000条COMMIT)<br>- 禁用索引(加载后重建) | | **资源管理** | - 动态资源分配(YARN/K8s)<br>- 据压缩(Snappy/Zstandard) | **示例代码:Spark优化参** ```python spark.conf.set("spark.sql.shuffle.partitions", "200") # 避免少分区倾斜 df.write.option("compression", "zstd")... # 压缩输出 ``` --- ### **如何处理ETL过程中的据质量异常?** 建立分层监控体系: 1. **前置校验** - 源据完整性:验证记录波动($\left| \frac{\text{今日计}-\text{昨日计}}{\text{昨日计}} \right| < 5\%$) - 据类型校验:字段类型匹配(如身份证长度=18) 2. **转换过程检查** - 业务规则校验:例如“销售额≥0” - 外键约束:确保维度表存在对应键 3. **加载后稽核** - 指标一致性:对比源系统与据仓库的汇总值 - 唯一性检查:主键重复检测 **自动化方案**: - 使用**Great Expectations**框架定义据质量规则 - 异常记录写入`error_log`表并触发告警 --- ### **实时ETL与批处理ETL的架构差异** | **维度** | **批处理ETL** | **实时ETL** | |------------------|----------------------------------|-------------------------------------| | **技术栈** | Hive/SQL + Airflow | Kafka + Flink/Spark Streaming | | **延迟** | 小时/天级 | 秒/毫秒级 | | **适用场景** | 报表分析、历史据归档 | 欺诈检测、实时风控 | | **难点** | 大数据量计算资源消耗 | 状态管理、Exactly-Once语义保障[^3] | **实时ETL示例流程**: ``` Kafka → Flink(窗口聚合) → Redis(维表关联) → Elasticsearch(实时查询) ``` --- ### **如何保障ETL任务的高可用性?** 1. **任务容错** - 设置重试机制(如Airflow `retries=3`) - 检查点(Checkpointing):Flink/Kafka Streams的状态快照 2. **集群高可用** - 主从架构:Hadoop NameNode HA、MySQL主从复制 - 资源隔离:K8s命名空间划分生产/测试环境 3. **灾备方案** - 跨机房据同步(如HDFS Federation) - 备份恢复:每日全备 + binlog增量备份 > **注意**:金融系统需满足**RTO<30分钟**,**RPO<5分钟**的容灾标准。 --- ### **维度建模的核心方法论** **Kimball模型设计步骤**: 1. **选择业务过程**(如“证券交易”) 2. **声明粒度**(如“每笔委托订单”) 3. **确定维度**(时间、客户、证券代码) 4. **确定事实**(交易金额、手续费) **金融场景特殊设计**: - **迷你维(Junk Dimension)**:合并标志位(如“是否融资买入”“是否大宗交易”) - **退化维(Degenerate Dimension)**:交易流水号直接嵌入事实表 **示例模型**: ```sql CREATE TABLE fact_trade ( trade_id BIGINT, -- 退化维 date_key INT REFERENCES dim_date, client_key INT REFERENCES dim_client, stock_key INT REFERENCES dim_stock, amount DECIMAL(18,2), fee DECIMAL(10,2) ); ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值