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

• 主导设计基于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%

• 大二观察到毕业生离校时大量教材被废弃，而新生购书支出占生活费12%，便发起校园书籍教材循环计划。为解决传统二手书交易效率低的问题，我们开发微信小程序实现扫码估价、预约取件功能，并说服快递中心以成本价承接物流。
• 通过建立翻新消毒标准打消卫生顾虑，项目年流通教材1.2万册，累计为同学节省书费38万元。这段经历让我从商业小白成长为能设计闭环模式的实践者，项目不仅获省级创业金奖，更被纳入学校官方服务体系延续至今。

用户行为全链路实时分析平台搭建

• 项目背景：公司为提升内容运营与算法推荐的实时性，需解决原有离线分析系统「小时级延迟」的痛点——无法及时捕捉用户看剧、弹幕互动、分享等行为的动态趋势，导致热门内容跟进慢、推荐模型迭代滞后。核心目标是通过实时数据处理平台，实现用户行为数据的秒级采集、计算与输出，支撑运营决策与算法优化。我作为项目总负责人，主导从需求调研、技术选型到落地推广的全流程。
• 关键难题：①多源数据实时接入的异构问题——APP、小程序、TV端及后台系统的用户行为数据格式差异大，直接接入会导致计算逻辑混乱；②低延迟下的状态一致性——用户连续行为（如“观看→点赞→分享”）需关联分析，传统实时引擎的状态管理易出现丢数据或延迟；③高并发场景的性能瓶颈——峰值时每秒需处理15万+事件，现有集群无法承载。
• 核心行动与创新：1. 设计「统一数据接入层」：基于Avro Schema Registry规范多源数据格式，通过Kafka Connect实现自动化的Schema演化与数据校验，解决了异构数据的兼容问题；2. 优化Flink实时计算链路：采用RocksDB状态后端结合增量Checkpoint机制，保障用户行为序列的状态一致性，同时将窗口函数从「滚动窗口」调整为「滑动窗口（1分钟窗口，10秒滑动）」，既保留实时性又避免重复计算；3. 集群性能调优：通过Flink TaskManager的资源动态分配（基于YARN的Capacity Scheduler），将并行度从32提升至64，结合ClickHouse的分布式表引擎优化查询性能，最终实现秒级延迟。
• 项目成果：平台上线后，数据处理延迟从60分钟降至5秒内，峰值吞吐量达18万事件/秒；运营团队可实时监控「剧集热度趋势」「用户互动热点」，将热门内容推荐调整周期从1天缩短至1小时，单部剧集的点击率提升22%；算法团队基于实时行为数据优化推荐模型，用户次日留存率提升15%。我个人主导的技术方案被纳入公司实时计算标准规范，覆盖后续3个业务线的实时需求。

内容生产全链路数据中台建设

• 项目背景：公司内容生产部门（剧本、拍摄、剪辑、上线）长期存在数据孤岛——剧本管理系统（存储选题、梗概）、拍摄管理系统（记录场次、镜头）、上线系统（统计播放量）的数据无法打通，导致选题重复、制作周期不可控（如某剧集因剧本与拍摄素材匹配问题返工2次）。核心目标是搭建内容生产数据中台，整合全链路数据，支撑数据驱动的内容决策。我负责数据整合、模型设计与质量管控模块。
• 关键难题：①跨系统数据打通——各系统采用不同的数据库（MySQL、MongoDB、SQL Server），数据格式与元数据不一致；②数据质量保障——内容生产数据存在大量缺失值（如拍摄环节的“镜头时长”缺失率达30%）、重复值（如同一剧本的不同版本编号混乱）；③业务语义落地——技术人员需将“剧本相似度”“拍摄效率”等业务指标转化为可计算的数据模型。
• 核心行动与创新：1. 构建「内容生产数据模型」：基于Kimball维度建模，设计「剧本维度表」（包含题材、编剧、IP来源）、「拍摄事实表」（包含场次、镜头数、耗时）、「上线事实表」（包含播放量、弹幕数），整合了5个业务系统的数据；2. 建立元数据管理体系：引入Apache Atlas管理数据血缘与元数据，定义「内容生产元数据标准」（如“剧本ID”为唯一标识），解决了数据不一致问题；3. 数据质量闭环：通过Hive UDF开发数据校验规则（如“镜头时长”缺失则触发补录流程），结合Atlas的 lineage 功能追踪质量问题源头，将数据准确率从70%提升至95%。
• 项目成果：数据中台整合了80%的内容生产数据，形成「选题-拍摄-上线」的全链路数据看板。内容生产团队通过看板发现“悬疑题材剧本的拍摄周期比平均长20%”，调整了拍摄资源分配，整体制作周期缩短18%；选题重复率从15%降至5%，单部剧集的内容成本降低12%。我个人主导的数据质量体系成为公司数据资产的标杆规范，后续被推广至运营、算法等业务线。