负责公司电商大促及日常场景下的实时数据处理系统全生命周期管理，覆盖用户行为分析、实时风控决策、GMV实时看板三大核心链路，主导从需求拆解到上线运维的技术落地，保障数据流端到端延迟≤200ms、日均处理量超50亿条的稳定性。

• 主导设计实时数仓三层架构（ODS→DWD→DWS），基于Flink 1.17+SQL完成用户点击-加购-下单全链路事件流的标准化处理；针对大促期间Kafka消息乱序导致的窗口计算偏差问题，引入Watermark动态调整策略（允许5s延迟+1s乱序），结合事件时间分区键优化，将订单归因准确率从92%提升至98.6%，支撑双11期间实时GMV看板的精准性。
• 牵头优化实时风控规则引擎的数据供给链路，通过Flink CEP（复杂事件处理）实现跨3个数据源（用户设备信息、交易流水、IP黑库）的多维度关联计算；针对传统规则匹配延迟高（平均800ms）的痛点，设计状态缓存复用方案（减少30%重复状态存储）与异步IO调用外部风控库，将单条风险事件处理耗时压缩至150ms内，支撑大促期间每秒10万+风险事件的实时拦截。
• 构建实时数据质量监控体系，基于Flink Metrics扩展自定义指标（如消息积压量、窗口触发超时次数），集成Prometheus+Grafana实现分钟级告警；通过分析历史故障数据，定位到Kafka消费者拉取速率不均衡问题，优化分区分配策略（采用粘性分区+动态重平衡），将任务重启频率从每周2次降至每月0.5次，保障核心链路SLA≥99.95%。
• 推动实时计算资源效能提升，基于YARN队列动态扩缩容机制，结合业务峰谷特征（如早8点/晚8点流量波峰）设计弹性调度策略；在大促预热期将Flink作业并行度从32调整至64，同时利用Spot实例降低成本，整体资源利用率提升40%，大促期间计算成本同比下降28%。

聚焦本地生活场景的实时数据处理需求，负责外卖订单履约时效监控、骑手调度实时决策、商家实时营收统计三大模块的开发与维护，支撑日均8000万+订单流的实时处理，保障关键指标延迟≤500ms。

• 从0到1搭建外卖订单超时预警系统，基于Flink DataStream API实现订单接单-取餐-配送全流程事件的时间窗口聚合；针对早期Kafka消息堆积导致延迟飙升问题，优化消费者参数（fetch.min.bytes提升至1MB+max.poll.records调整至500），并结合背压监控动态调整并行度，将订单处理延迟稳定控制在300ms内，支撑运营团队实时干预超时订单。
• 参与骑手实时调度系统的特征工程开发，从Kafka实时流中提取骑手位置、当前单量、商家出餐速度等12维特征，通过Flink Window Join关联历史轨迹数据，为调度算法提供秒级更新的特征输入；优化特征存储方式（改用RocksDB状态后端替代内存存储），将特征更新延迟从2s降低至500ms，助力骑手接单效率提升15%。
• 优化商家实时营收统计的准确性，解决跨门店分账、优惠叠加导致的计算误差问题；引入Flink状态TTL机制清理过期订单数据（设置7天过期策略），结合窗口预聚合（每5秒输出一次中间结果）与最终一致性校验，将营收数据修正率从0.8%降至0.1%，满足财务对账的实时性要求。
• 主导实时计算任务的大版本升级，将原有Spark Streaming任务迁移至Flink，同步完成代码重构（适配事件时间语义）与性能压测；通过对比测试发现Flink在反压处理上的优势（背压传播延迟降低60%），迁移后任务资源占用减少35%，同时支持了更高并发的订单流（从5000TPS提升至1.2万TPS）。

协助完成金融交易反欺诈系统的实时数据处理模块开发，参与用户交易行为的实时特征计算与风险规则匹配，保障日均200万+交易流的低延迟处理（≤1s）。

• 参与反欺诈规则引擎的实时数据管道建设，基于Flink SQL完成银行卡交易流与用户设备指纹库的关联计算，通过Lookup Join实现每秒5000+次的外部数据查询，将单笔交易的特征计算耗时从800ms缩短至300ms，支撑风控规则引擎的实时决策。
• 优化交易数据清洗逻辑，解决原始日志中字段缺失、格式错误导致的下游任务失败问题；设计Flink MapFunction+正则表达式校验的组合方案，对10类常见异常数据进行清洗（如手机号格式、金额精度），将数据质量问题导致的任务重启次数从每日3次降至每周0.5次。
• 协助搭建实时交易监控看板，基于Flink ProcessFunction统计5分钟内交易频次、地域分布等指标，通过Redis缓存热点数据，实现前端页面的秒级刷新；上线后运营团队对异常交易的响应时间从5分钟缩短至30秒，有效降低了资金损失风险。

星途社区用户行为实时分析平台研发

• 项目背景：公司为提升内容社区的用户体验与商业转化效率，需实时洞察用户行为（如点击、评论、分享、停留）以支撑推荐算法迭代与运营活动调整，但原有离线分析系统存在小时级延迟，无法满足实时决策需求。我的总体职责是主导平台从0到1的架构设计与落地，对齐产品、算法、运营的核心诉求。
• 解决的关键难题：1）高并发低延迟挑战——平台需承载APP、小程序、Web三端的实时事件（峰值QPS达12万/秒），传统流处理框架难以兼顾吞吐与延迟；2）多源数据 schema 兼容——不同端的用户行为事件结构差异大（如小程序的“分享到朋友圈”事件在APP端无对应字段），易导致数据解析错误；3）实时 session 准确性——用户跨端行为的 session 划分需基于事件时间而非处理时间，传统窗口函数易出现 session 断裂或合并错误。
• 核心行动与技术创新：1）技术栈选型：对比Flink与Spark Streaming后，选择Flink作为实时计算引擎（基于事件时间语义与状态管理能力），搭配Kafka（分区数32，吞吐量达50万/秒）做消息缓冲，HBase（行键设计为用户ID+时间戳）存储原始明细，ClickHouse（预聚合常用指标如实时点击转化率）支撑快速查询；2）schema 兼容方案：自研轻量级 schema 注册中心（基于ZooKeeper做配置分发），要求各端上报事件时附带 schema 版本号，平台通过版本映射自动转换字段（如将小程序的“share_type”映射为通用的“social_channel”）；3）session 划分优化：采用基于事件时间的滑动窗口（窗口大小30分钟，滑动步长5分钟），结合用户最后一次交互时间动态延长窗口，解决跨端 session 断裂问题。
• 项目成果与价值：1）性能指标：平台上线后，实时分析延迟从小时级降至平均500ms，支持秒级查询；2）业务价值：支撑推荐算法团队实现“用户刚浏览美食内容就推送附近餐厅”的实时推荐策略，推荐点击率提升22%；运营团队可通过实时 dashboard 监控活动效果（如话题挑战的参与率），调整策略的时间从T+1缩短至实时，活动ROI提升35%；3）个人贡献：主导架构设计与核心模块开发，解决了高并发下的实时性与多源数据兼容问题，该平台成为公司内容社区的“实时决策大脑”。

短视频内容标签实时同步系统重构

• 项目背景：公司短视频业务的标签（如“美食”“旅行”“宠物”）原通过每日批量任务（Sqoop抽取Hive表→MySQL同步）更新，延迟高达6小时，导致推荐、搜索、广告业务线的标签不准确（如用户刚上传的“猫咪视频”未及时被打上“宠物”标签，无法被精准推荐）。我的职责是重构标签同步系统，实现标签的准实时更新与多业务线一致调用。
• 解决的关键难题：1）海量标签的实时处理——每天新增100万+短视频，每个视频平均带5个标签，传统批量任务无法应对峰值；2）标签一致性——推荐、搜索、广告业务线对标签的更新时效要求不同（搜索需实时，广告可批量），易出现“推荐看到新标签但搜索看不到”的矛盾；3）容错性差——旧系统依赖单节点同步，偶尔宕机会导致标签延迟几小时，影响业务体验。
• 核心行动与技术创新：1）实时同步方案：用Kafka Connect替代Sqoop，将Hive表的变更日志（CDC）实时同步至Kafka，再通过Flink进行标签清洗（去重、标准化）与转换（将“猫”统一为“宠物”）；2）标签版本控制：设计“标签版本号+时间戳”的双维度索引，每个标签变更都生成新版本（如“宠物”标签从v1到v2，新增“包含猫咪、狗狗”的定义），下游业务线可根据自身需求订阅指定版本的标签；3）容错优化：Flink任务开启 checkpoint（间隔5分钟，存储至HDFS），并引入重试机制（失败任务自动重试3次，仍失败则触发告警），同时将标签缓存至Redis（过期时间10分钟），避免数据库压力过大。
• 项目成果与价值：1）性能提升：标签同步延迟从6小时降至5分钟以内，搜索推荐的标签准确率提升30%；2）业务增长：用户点击量因精准推荐提升18%，广告点击率提升12%；3）个人贡献：主导系统重构与核心功能开发，解决了实时性与一致性的平衡问题，该系统至今仍是公司内容标签管理的核心基础设施，支撑了3条业务线的实时调用。

• 因痛心于年轻人对历史的疏离，我在B站创立「古人脱口秀」栏目，用职场梗解构历史事件（如《雍正皇帝的KPI保卫战》）。通过设计「颠覆认知-史料佐证-现代共鸣」三幕剧本模板，单期视频最高收获1.7万条弹幕互动。
• 两年间栏目播放量突破180万，作品被多地中学选为教学素材。这段经历磨砺出将学术内容转化为大众语言的能力，也让我理解到真实用户反馈才是创作者的指南针。