• 作为技术负责人，主导设计并实现了公司下一代“统一实时计算平台”，基于Apache Flink和自研控制台，为全公司提供从开发、调试、部署到运维监控的一站式流处理服务。平台日均处理实时数据PB级，支撑了1000+个实时作业稳定运行，将实时需求的开发效率提升了300%。
• 带团队攻克了“超大规模状态管理”的世界级难题，通过优化RocksDB本地状态存储、设计“状态拆分与异步快照”策略、并引入“增量检查点”，将大型作业的检查点时间从分钟级优化至秒级，保障了作业的99.99% 高可用性，全年无重大数据延迟或丢失事故。
• 创新设计“智能弹性扩缩容”系统，能够基于流量峰值自动预测资源需求，并在5分钟内完成作业的平滑扩容与缩容，在保障SLA的同时，将流处理集群的资源成本降低了35%。
• 建立的“端到端Exactly-Once”语义保障体系，从Kafka数据源到各种Sink（如ClickHouse, HBase, Kafka），实现了全链路的精准一次处理，为核心金融和计费业务提供了数据一致性保障。

• 负责公司最核心的“实时数仓”的构建，基于Flink SQL和CDC技术，将传统T+1的离线数据模型升级为“实时化”，使业务方能分钟级洞察核心业务指标（如GMV、DAU）的变化，帮助运营部门及公司领导决策延迟降低99%。
• 深度优化的“Flink作业性能”，通过解决数据倾斜、反压定位、JVM调优等问题，将核心作业的吞吐量提升了5倍，延迟降低了80%。
• 实现实时数据血缘与影响分析功能，能够快速定位上游数据源的schema变更或数据质量问题对下游实时作业的影响，将故障排查时间缩短了70%。

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

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

• 项目背景：公司为提升内容运营与算法推荐的实时性，需解决原有离线分析系统「小时级延迟」的痛点——无法及时捕捉用户看剧、弹幕互动、分享等行为的动态趋势，导致热门内容跟进慢、推荐模型迭代滞后。核心目标是通过实时数据处理平台，实现用户行为数据的秒级采集、计算与输出，支撑运营决策与算法优化。我作为项目总负责人，主导从需求调研、技术选型到落地推广的全流程。
• 关键难题：①多源数据实时接入的异构问题——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%。我个人主导的数据质量体系成为公司数据资产的标杆规范，后续被推广至运营、算法等业务线。