负责直播平台实时计算平台的迭代与核心链路开发，覆盖直播流量监控、订单风控、用户互动分析三大场景，保障毫秒级延迟下的数据处理准确性与系统稳定性

• 主导设计基于Flink 1.17的实时流量监控Pipeline，整合Kafka Cluster（300+分区）与Redis Cluster（热点弹幕缓存），解决原有Spark Streaming方案延迟高（5s→200ms）、状态丢失问题；通过自定义Watermark策略（基于Event Time的滑动窗口偏移量调整）与State TTL机制（设置1h过期），实现乱序推流、打赏数据的精准处理，监控数据准确率提升至99.98%，支撑运营实时调整直播流量分配策略
• 核心优化用户互动行为分析链路，将原有离线的用户弹幕情感分析迁移至Flink ML实时预测，集成BERT轻量化模型（通过TensorFlow Serving部署），实现对“负面弹幕”的实时识别与拦截；优化模型推理延迟（从200ms→50ms），日均处理弹幕1.2亿条，负面内容拦截率提升至95%，降低直播违规风险
• 解决大促期间实时订单支付链路的状态膨胀问题，通过Flink RocksDB状态后端调优（设置Block Cache大小为10GB、Write Buffer数量为4），将状态数据大小从150GB压缩至60GB，Checkpoint耗时从12分钟缩短至2.5分钟，保障双11期间订单支付成功率稳定在99.9%以上
• 主导搭建实时数仓与实时计算平台的联动机制，通过Flink SQL将ODS层的直播商品点击数据实时同步至DWD层的用户兴趣标签表，支撑算法团队实时训练推荐模型，使直播商品点击转化率提升18%

负责电商实时交易链路的数据处理与风控系统开发，支撑双11、618大促的实时订单校验、异常行为拦截，保障大促系统稳定性

• 核心参与电商实时订单风控系统Flink化改造，将原有离线+准实时的规则引擎迁移至Flink SQL+Drools组合方案，实现对“同一设备多账号下单”“短时间高频退款”等异常订单的实时拦截；优化Flink Checkpoint策略（从Exactly-Once改为At-Least-Once+幂等写入），将Checkpoint耗时从8分钟缩短至1.5分钟，大促期间系统吞吐量提升3倍，支撑单日1200万订单的风控处理
• 开发实时GMV计算模块，基于Flink Window（Tumbling Window+Session Window）整合订单、支付、退款多源数据，解决原有离线GMV延迟4小时的问题；通过自定义Aggregate Function（计算去重订单金额），实现GMV数据的分钟级更新，准确率达99.95%，支撑运营团队实时调整促销策略
• 解决用户行为日志乱序问题，针对APP端埋点数据延迟1-5分钟的痛点，通过Flink Event Time处理+Watermark延迟设置（最大延迟5分钟），结合Side Output通道将迟到数据写入HBase做补偿计算，使行为日志的完整性提升至99.8%，支撑用户画像实时更新
• 主导搭建实时数据报警系统，基于Flink CEP（Complex Event Processing）识别“订单支付失败率骤升”“库存扣减超时”等异常事件，通过钉钉机器人+短信实现分钟级报警，大促期间异常事件响应时间从30分钟缩短至5分钟，降低业务损失约200万元

负责实时数仓基础组件搭建与核心ETL开发，支撑运营侧实时指标计算，满足业务对数据时效性的高要求

• 独立搭建基于Flink CDC的实时数仓ODS层，同步MySQL中的用户注册、商品库存、订单创建等数据至HDFS，通过Schema Evolution功能解决表结构变更（如新增“用户来源渠道”字段）导致的数据不一致问题；优化数据同步延迟（从10分钟→30秒），支撑运营团队实时查看活动期间的用户注册量与库存变化
• 开发实时用户活跃度计算模块，基于Flink Keyed Process Function统计“近5分钟登录用户数”“近1小时互动次数”等指标，整合Redis做热点数据缓存，使活跃度数据的查询延迟从5秒→500ms，支撑产品团队实时调整首页推荐策略
• 解决实时ETL中的数据重复问题，针对Kafka消息重复消费的痛点，通过Flink State存储已处理消息ID，结合幂等写入逻辑（将数据写入HBase时校验主键），使数据重复率从0.5%降至0.01%，保障运营指标的准确性
• 参与实时计算平台的监控组件开发，基于Prometheus+Grafana搭建Flink作业监控看板，监控“作业延迟”“Checkpoint成功率”“CPU使用率”等指标，实现作业异常的自动预警，使平台运维效率提升40%

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

• 项目背景：公司为提升内容社区的用户体验与商业转化效率，需实时洞察用户行为（如点击、评论、分享、停留）以支撑推荐算法迭代与运营活动调整，但原有离线分析系统存在小时级延迟，无法满足实时决策需求。我的总体职责是主导平台从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条业务线的实时调用。

支教时发现乡村小学因缺乏实验器材，科学课多停留在课本讲解。返校后联合实验室开发出百元级科学实验背包，内含20个基础实验器材。为确保可持续运营，设计配套视频课程与城乡结对系统，并培训132名大学生担任远程助教。项目覆盖9省47所学校后，学生科学兴趣评分提升35%。这段经历教会我用产品思维解决社会问题，当看到孩子们用自制望远镜发现土星光环时，我理解了教育的真谛是点燃可能性。