[toc]
简历描述
业务数据处理管道搭建及维护
\1. 负责 Mediation / MMS 原始业务数据的解析与处理，涵盖数据清洗、结构化、标准化等流程，确保下游消费系统的数据一致性和准确性
\2. 基于 Spark实现大规模数据的 join、多维聚合、窗口函数等逻辑，支撑日报、计费、运营等核心场景
\3. 设计并维护，高效的数据处理管道，具备良好的可扩展性与容错性
\4. 通过优化处理逻辑及资源配置，使核心任务运行时长缩短 26%，资源占用降低17%
主要技术：spark、scope、c#、powershell
微软中国 STCA Bing 团队 工作经历（P7 级别精准版）
任职时间：2021.03 - 至今
团队：Bing 搜索与广告事业部 MSN 广告数据团队
职位：高级大数据开发工程师
核心职责
全面负责MSN 全球广告数据 Pipeline的架构设计、开发、迁移及全生命周期优化，支撑 MSN 广告投放、效果归因、营收核算等核心业务。主导完成从微软专有 Scope 平台到开源 Spark 生态的技术栈升级，解决原平台供应商锁定、扩展性不足、成本高昂的核心痛点，同时负责全链路性能调优、存储架构升级和工程效能体系建设。
核心成果
- 主导技术栈全面迁移：牵头完成从 Scope SQL 到 Spark/Spark Structured Streaming 的技术栈转型，将120 + 个核心离线和准实时广告任务（覆盖曝光、点击、转化全链路）平滑迁移至开源 Spark 生态，零业务中断，彻底摆脱专有平台依赖，年基础运维成本降低 40%。
- 全链路性能深度优化：通过执行计划拆解、低效算子重写、Shuffle 参数调优和资源精细化调度，将原 Scope SQL 任务平均运行时间缩短 25%；迁移后进一步通过数据倾斜治理、广播 Join 优化和预聚合下沉，使 Spark 任务性能再提升 30%，大促峰值时任务成功率从 92% 提升至 99.9%。
- 存储架构升级降本：引入 ZSTD 高压缩算法替代原有 Snappy 压缩，同时设计并落地按小时 + 地区的二级细粒度分区策略，解决了原全表扫描效率低、冷数据冗余的问题，整体存储成本降低 35%，单表查询响应速度提升 2 倍。
- 工程效能体系建设：搭建了完整的 CI/CD 自动化流水线，实现代码提交、单元测试、集成测试、灰度发布全流程自动化；同时构建了覆盖数据完整性、准确性、及时性的全链路监控体系，将任务上线周期从 3 天缩短至 4 小时，数据异常发现时间从小时级压缩至 5 分钟以内。
MSN 全球广告数据 Pipeline 技术升级与优化项目（更正）
项目周期：2021.03 - 至今
技术栈：Spark Structured Streaming、Flink、Scope SQL、HDFS、Prometheus、Grafana
项目背景：MSN 广告覆盖全球 100 + 国家和地区，日均曝光量超 500 亿次，峰值 QPS 达 200 万。原有数据处理完全依赖微软专有 Scope 平台，存在平台绑定严重、扩展性不足、运维成本高昂三大核心问题，且随着广告业务快速增长，原平台任务运行延迟高、存储成本激增、工程效能低下等问题日益突出，无法支撑广告投放、效果归因、营收核算等核心业务的快速迭代需求。
核心职责
- 主导整体技术架构升级，设计并落地从微软专有 Scope 平台到开源 Spark 生态的完整迁移方案，构建统一的批流一体广告数据 Pipeline
- 负责 MSN 广告全链路数据 Pipeline 的开发与维护，覆盖曝光、点击、转化、归因、营收核算等核心业务流程
- 牵头全链路性能优化，通过执行计划深度分析、低效算子重写、Shuffle 优化和资源精细化调度，全面提升任务运行效率
- 设计并落地存储架构升级，引入高压缩算法和细粒度分区策略，解决原存储体系成本高、查询慢的问题
- 搭建完整的 CI/CD 自动化流水线和全链路数据质量监控体系，实现任务的自动化部署、测试和异常告警
- 为 MSN 广告投放系统、效果分析平台、财务核算系统等 15 + 个核心业务系统提供稳定可靠的数据支持
核心成果
-
技术栈平滑迁移：完成 120 + 个核心离线和准实时广告任务的平滑迁移，彻底摆脱专有平台依赖，年基础运维成本降低50%
-
全链路性能提升：通过多维度优化，将原 Scope SQL 任务平均运行时间缩短25%；迁移后进一步通过数据倾斜治理、广播 Join 优化和预聚合下沉，使 Spark 任务性能再提升30%，黑五峰值任务成功率从 92% 提升至 99.9%
-
存储成本大幅降低：引入 ZSTD 高压缩算法替代原有 Snappy 压缩，同时设计并落地按小时 + 地区的二级细粒度分区策略，整体存储成本降低35%，单表查询响应速度提升 2 倍
-
工程效能显著提升：搭建全自动化 CI/CD 流水线和数据质量监控体系，数据异常发现时间从天级压缩至 30分钟以内
-
业务价值突出：稳定支撑 MSN 广告业务连续 3 年营收增长，为广告投放策略优化和营收增长提供了坚实的数据基础
-
scope sql 迁移 spark 平台
项目简介：
重点是技术栈迁移部分
Situation：基于公司内部平台，扩展性不好而且成本很高，不适合做分钟级的job，而且技术孤岛无法快速适配市面上的新兴技术
Task：负责job的迁移工作以及性能调优，数据质量保证
Action: 主导专有平台向开源Spark生态架构迁移，搭建批流一体广告数据Pipeline；负责曝光、点击、转化、归因、营收核算全链路数据开发与维护；通过执行计划优化、Shuffle调优、资源精细化调度提升任务效率；落地高压缩算法与细粒度分区策略，优化存储架构；
Result: 完成120+核心离线、准实时任务平滑迁移，摆脱专有平台依赖，年度运维成本降低50%；多轮优化后，原任务耗时缩短25%，Spark任务性能再提升30%，大促峰值任务成功率从92%提升至99.9%；存储成本降低35%
Difficult: 性能调优，微软scope平台也有做的好的地方，就是对大数据量的join封装的比较好，不需要过多的处理就可以保证job的正常运行，但是迁移到spark平台，这部分优化就需要job自己来把控，否则很容易导致内存溢出的问题，所以我当时是设计了一种再次拼接的方案，就是先对关联字段进行join，然后结果再去关联那些比较冗长的字段。
Situation（背景）
公司原有自研专有数据平台扩展性差、运维成本高昂，不支持分钟级高频任务调度，且存在严重技术孤岛，无法快速适配开源大数据新兴技术，极大限制了广告业务数据链路的迭代效率与算力弹性。同时原有平台对大数量级Join做了高度封装优化，可兜底任务稳定运行，但迁移至原生Spark生态后，缺失平台层自动优化能力，大字段、大流量Join极易引发Shuffle过载、内存溢出等问题，对任务自主调优与架构设计提出极高要求。
Task（职责）
全权负责核心数据任务的跨平台迁移、全链路性能调优与数据质量兜底工作，搭建全新批流一体数据架构，保障广告全链路数据任务平稳、高效、稳定运行。
Action（行动）
\1. 架构迁移与链路搭建：主导传统专有平台向开源Spark批流一体生态全面迁移，从零搭建广告业务专属数据Pipeline，全权负责曝光、点击、转化、归因、营收核算全链路数据的开发、迭代与日常维护，彻底破除闭源平台技术壁垒。
\2. 核心Join性能方案自研（解决Spark内存溢出痛点）：针对原生Spark无平台层Join优化、大字段关联易OOM的核心难题，自研轻量先行Join+后置字段补齐优化方案：Join阶段仅携带关联Key及必要核心字段完成Shuffle与关联计算，规避冗余大字段参与Shuffle导致的数据膨胀；Join匹配完成后，再通过主键本地二次拼接补齐全量业务字段，大幅降低Shuffle数据量与内存占用。
\3. 全维度性能与存储调优：深耕Spark执行计划优化、Shuffle参数调优、资源精细化调度，解决任务倾斜、资源浪费问题；落地高压缩存储算法、细粒度分区管理策略，重构底层存储架构，兼顾查询效率与存储成本。
Result（成果）
\1. 完成120+核心离线、准实时任务平滑迁移，彻底摆脱专有平台技术依赖，打通开源技术生态，业务迭代灵活性大幅提升，年度平台运维成本降低50%；
\2. 通过自研Join优化方案与全链路调优，核心任务整体运行耗时缩短25%，Spark集群整体任务性能提升30%，彻底解决大流量Join内存溢出问题；
\3. 存储架构优化成效显著，整体存储成本降低35%；大促峰值高并发场景下，核心任务成功率由92%提升至99.9%，全链路数据稳定性、准确性全面达标。
Difficult & 核心亮点（面试拓展）
原有微软Scope专有平台对大数量级Join做了底层封装优化，可自动兜底Shuffle、内存、数据倾斜等问题，业务侧无需手动干预即可保障任务稳定运行。但迁移至原生Spark生态后，所有Join、Shuffle、内存管控均需自主实现，超大表关联、长文本冗余字段参与计算时，极易出现Shuffle数据爆炸、Executor内存溢出、任务失败等问题。
针对该核心痛点，我摒弃全量字段直接Join的传统写法，创新设计分步关联、字段延迟拼接的优化思路：将关联计算与字段补齐解耦，优先以最小字段粒度完成Key匹配，规避无效Shuffle，再本地完成全量字段补齐。该方案从根源上解决了Spark大流量宽表Join的OOM与性能瓶颈，成为团队后续宽表关联场景的通用优化规范。
冗长字段导致的状态异常问题：
先对原始数据分桶处理，然后
如何确定水位线的延迟时间：
通过测试job，对于不同水位线的join结果，统计准确度，5分钟延迟可以达到99.8%
实际窗口是2h
如何解决中间未join上的数据需要继续等待的问题，如何保证处理速度。
使用状态文件，对join上的数据直接输出，对于没能join上的数据保留到state文件中，下此与新到的数据一同计算