1. 讲讲实习做的项目:背景、内容、你做了什么、结果
  2. "dwd、dwm、dws这三层的区别
  3. 讲下spark有哪些优化方法
  4. 小文件产生的原因和危害
  5. Sparkjoin分多少种 什么时候用hash join，什么时候得到sort merge join-------
  6. sql题:表名:流量表log(每天有百亿数据)，字段:用户id:uid，设备id:devic id，城市:city，时间:time，日期:date;问题:最近7天中每天活跃的用户数和设备数是多少?(坑:百亿级的每天只有7个分区处理，可能会造成数据倾斜预聚合?)

1. 实习项目：国内服务器向海外服务器数据迁移项目（背景、内容、个人贡献、结果）

考察知识点

  • 跨境数据迁移的技术选型（传输协议、同步工具）
  • 跨国网络环境下的性能优化（延迟、带宽限制）
  • 数据一致性与业务连续性保障（双写、灰度切换）
  • 合规性处理（数据脱敏、本地化存储要求）

参考回答

在某跨境电商企业实习期间，参与“核心业务系统从国内阿里云迁移至新加坡AWS”项目，目标是将国内服务器存储的用户数据、订单信息及商品库迁移至海外节点，支撑东南亚市场本地化运营。

项目背景：

企业计划开拓印尼、马来西亚等东南亚市场，但国内服务器存在两大问题：① 海外用户访问延迟高（平均300ms+，远超国内50ms标准），导致购物车加载、结算等核心流程转化率低；② 受限于跨境数据传输法规，用户隐私数据（如手机号、地址）在国内存储不符合当地“数据本地化”要求，存在合规风险。需在3个月内完成核心数据迁移，确保业务无缝切换。

项目内容：

迁移范围涵盖3类核心数据（日均新增500GB）：① 用户中心数据（MySQL，含2000万注册用户信息）；② 订单交易数据（MongoDB，近1年历史订单8000万条）；③ 商品图片/视频资源（对象存储，约10TB静态文件）。整体采用“分阶段迁移+双写过渡”策略：

  • 准备阶段：搭建新加坡AWS环境（EC2服务器、RDS数据库、S3存储），通过专线建立国内与海外节点的加密传输通道（IPsec VPN）；
  • 迁移阶段：先全量同步历史数据，再通过增量同步工具实时同步新产生的数据（国内写入时同时同步至海外）；
  • 切换阶段：按用户比例灰度切换（10%→50%→100%），监控海外节点性能与数据一致性，确认无误后停掉国内写入。

个人贡献：

  1. 设计并实现增量数据同步方案：
    • 针对MySQL用户数据，使用Debezium捕获binlog日志，通过Kafka跨区域同步至海外RDS，解决“国内修改实时同步至海外”的问题，同步延迟控制在1秒内；
    • 开发Python脚本校验同步一致性，每日对比国内与海外库的用户数、订单量等核心指标，发现并修复因字符集差异（国内utf8mb4 vs 海外latin1）导致的部分商品名称乱码问题。
  2. 优化跨境数据传输效率：
    • 初期全量迁移时，因国际带宽限制（峰值100Mbps），10TB静态资源预计需10天，通过“分片压缩+错峰传输”（夜间带宽空闲时传输）将时间压缩至4天；
    • 对大文件（如商品视频）采用断点续传机制（基于S3 Multipart Upload），避免网络波动导致的重复传输，失败重试率从30%降至5%。
  3. 支撑业务灰度切换：
    • 开发“用户路由”中间件，根据用户ID尾号将10%用户请求导流至海外节点，实时监控响应时间（从300ms降至80ms）和错误率（<0.1%）；
    • 制定回滚预案：当海外节点错误率超1%时，自动切回国内节点，期间通过双写保证数据不丢失，最终实现零业务中断切换。
  4. 处理合规性问题：
    • 按照东南亚《个人数据保护法》，对迁移的用户数据进行脱敏（手机号中间4位替换为*，地址仅保留国家和城市），编写脱敏规则脚本并嵌入同步链路；
    • 配合法务团队完成数据迁移备案，输出《跨境数据传输合规报告》，包含传输链路加密方式、脱敏规则等内容。

项目结果：

  • 完成2000万用户、8000万订单及10TB资源的全量迁移，数据一致性达100%，核心业务切换耗时48小时（零中断）；
  • 海外用户平均访问延迟从300ms降至75ms，购物车结算转化率提升15%，首月东南亚市场GMV增长20%；
  • 沉淀《跨境数据迁移规范》，包含传输工具选型、合规脱敏、灰度切换等6个环节的标准操作流程，为后续拓展菲律宾市场提供参考。

补充注意要点

  • 突出“跨境特性”：强调国际网络限制、合规要求等与国内迁移的差异，体现场景适应性；
  • 量化技术指标：如同步延迟、传输效率、错误率等，用数据证明方案有效性；
  • 关联业务价值：将技术成果（如延迟降低）与业务指标（如转化率提升）挂钩，体现技术对业务的支撑作用。

2. dwd、dwm、dws三层的区别

考察知识点

  • 数据仓库分层的核心逻辑（数据粒度、用途、处理方式）
  • 每层在数据链路中的定位与作用
  • 分层设计的价值（复用性、维护性、性能）

参考回答

dwd、dwm、dws是数据仓库中典型的三层架构，核心区别在于数据粒度、处理程度和服务对象，共同支撑从原始数据到业务指标的转化：

分层 全称 核心定位 数据特点 典型用途
dwd 明细数据层（Data Warehouse Detail） 存储“清洗后的原始数据”，保留最细粒度 ① 基于原始数据清洗（去重、补全、格式统一）；② 与源数据粒度一致（如订单表保留每笔订单的明细）；③ 包含所有业务字段（不做聚合） 为上层提供基础明细数据，支持灵活分析（如查询某笔订单的具体信息）
dwm 中间数据层（Data Warehouse Middle） 做“轻度聚合与维度关联”，承上启下 ① 基于dwd层做轻度汇总（如按小时聚合订单量）；② 关联维度表（如订单表关联用户表获取用户等级）；③ 保留中等粒度（比dwd粗，比dws细） 支撑复杂业务逻辑（如计算“近30天活跃用户”的中间结果），减少重复计算
dws 汇总数据层（Data Warehouse Summary） 面向“业务主题的汇总数据”，直接服务应用 ① 基于dwm/dwd层做高度聚合（如按天汇总门店销售额）；② 数据粒度粗（符合业务指标粒度）；③ 字段与业务指标一一对应（如daily_store_sales） 直接供报表、BI工具使用（如门店日报、月度营收报表）

实例说明（以电商订单数据为例）：

  • dwd层：dwd_order_detail，存储每笔订单的原始明细（order_id、user_id、amount、pay_time等），仅做清洗（如过滤amount<=0的无效订单，统一pay_time为yyyy-MM-dd HH:mm:ss）；
  • dwm层：dwm_order_hourly，基于dwd层按user_id和小时聚合（sum(amount)、count(order_id)），并关联dwd_user表补充user_level（用户等级），供后续计算“不同等级用户的小时消费趋势”；
  • dws层：dws_store_daily_sales，按门店和天汇总（sum(amount)、count(distinct user_id)），直接用于门店每日销售报表。

分层价值：

  • 复用性：dwd层一次清洗，供dwm/dws多层复用，避免重复处理；
  • 维护性：某层逻辑变更（如dwd层新增字段），仅需调整依赖它的上层，降低影响范围；
  • 性能：dws层预聚合减少查询时的计算量，报表查询速度提升10-100倍。

补充注意要点

  • 核心区分“粒度”：dwd最细，dws最粗，dwm居中，这是理解分层的关键；
  • 避免混淆“dwm”与“ods”：ods是原始数据层（未清洗），dwd是清洗后的明细层，dwm是中间处理层；
  • 结合业务场景说明用途，体现分层设计的实际价值（如报表查询直接用dws层提升效率）。

3. Spark有哪些优化方法

考察知识点

  • Spark优化的多个维度（资源、SQL、数据倾斜、序列化等）
  • 不同场景下的优化策略（离线批处理、实时计算）
  • 优化的量化效果与实战经验

参考回答

Spark优化需从“资源配置、SQL语法、数据处理、执行引擎”多维度入手，核心目标是提升计算效率、减少资源浪费，常见优化方法如下：

1. 资源配置优化（基础且关键）

  • 调整Executor资源：根据数据量设置Executor数量（-num-executors）、核数（-executor-cores）、内存（-executor-memory），避免资源不足（OOM）或过度分配（资源竞争）。
    • 建议：Executor核数2-4（过多会导致线程切换开销），内存8-16G（结合数据量），总核数=Executor数×核数，建议为集群总核数的70%-80%；
    • 示例：处理100GB数据，设置-num-executors 20 --executor-cores 4 --executor-memory 16G，比默认配置（2Executor，1核，1G内存）效率提升10倍。
  • 调整并行度：通过spark.sql.shuffle.partitions（默认200）设置Shuffle分区数，建议为总核数的2-4倍（如总核数80，设置300），避免分区过少（数据倾斜）或过多（Task调度开销大）。

2. SQL语法优化（快速见效）

  • 避免全表扫描：添加分区过滤（where dt='2024-09-01'）、字段裁剪（select id,name而非select *），减少扫描数据量；
  • 优化Join策略：
    • 小表（<100MB）用广播Join（/*+ BROADCAST(t2) */），将小表广播到所有Executor，避免Shuffle；
    • 大表按相同字段分桶（bucket by user_id into 100 buckets），Join时仅需匹配相同分桶数据，减少数据传输；
  • 替换低效算子：
    • 用reduceByKey（Map端预聚合）替代groupByKey，减少Shuffle数据量；
    • 用approx_count_distinct替代count(distinct)（允许1%误差时，效率提升10倍）；
    • 用filter + union替代or（where a=1 or a=2→where a=1 union where a=2），避免全表扫描。

3. 数据倾斜优化（解决性能瓶颈）

  • 热点Key拆分：对倾斜Key（如某user_id占比10%）添加随机前缀（0-9），拆分为10个小Key，聚合后合并结果；
  • 空值处理：对大量空值（如user_id is null）过滤或添加随机后缀，避免集中到一个Task；
  • 大表拆小表：将大表按时间/地区拆分，与小表分别Join后合并，降低单表Join压力。

4. 存储与序列化优化

  • 数据格式：使用Parquet/ORC列存格式（比Text节省3-5倍存储空间，支持列裁剪）；
  • 序列化：用Kryo序列化（比Java序列化快10倍，占用空间少），通过spark.serializer=org.apache.spark.serializer.KryoSerializer配置，并注册自定义类；
  • 压缩：对Shuffle数据启用Snappy压缩（spark.shuffle.compress=true），减少磁盘IO。

5. 缓存与依赖优化

  • 缓存复用数据：对重复使用的中间结果缓存（df.cache()或df.persist(StorageLevel.MEMORY_AND_DISK)），避免重复计算；
  • 减少宽依赖：用broadcast替代shuffle join，用mapPartitions替代map（减少Task数量），降低Shuffle开销。

补充注意要点

  • 优化需“先定位后优化”：通过Spark UI查看Stage、Task、Shuffle指标，确定瓶颈（如数据倾斜、资源不足），避免盲目调参；
  • 结合场景选择策略：实时任务（如Spark Streaming）优先优化延迟（减少Executor内存，提升并行度），离线任务优先优化吞吐量（增加资源，启用缓存）；

This post is for subscribers on the 网站会员 and 成为小万的高级会员 tiers only

Subscribe Now

Already have an account?