负责公司核心数据中台的底层平台设计与迭代，聚焦高并发数据接入、多租户资源隔离及云原生架构落地，支撑广告、交易、用户三大业务线日均15PB数据处理需求

• 主导设计基于云原生架构的第二代数据平台，采用K8s+Docker容器化部署替代传统物理机集群，结合Hadoop 3.x与Apache Iceberg构建湖仓一体存储层；通过自定义Operator实现计算任务（Spark/Flink）的自动扩缩容，将资源利用率从42%提升至78%，年节省云服务器成本超200万元
• 针对多租户场景下的资源竞争问题，创新设计‘配额+优先级’双维度隔离方案：基于Alluxio构建租户级缓存池，结合YARN队列动态权重调整，实现关键业务（如大促活动数据）延迟从800ms降至150ms，非核心业务资源抢占率下降65%
• 优化数据入仓链路，引入Flink CDC+Schema Registry实现MySQL/Oracle业务库到Iceberg的近实时同步，解决原有CDC工具断点续传不稳定问题；通过反压感知的动态批处理策略，将同步延迟从T+1缩短至5分钟内，支撑运营实时看板需求
• 搭建平台级监控体系，基于Prometheus+Grafana整合200+指标（含任务失败率、节点负载、存储IO），开发异常检测算法识别慢任务与资源泄漏；上线后故障定位时间从平均45分钟压缩至8分钟，年度P0级事故数从7次降为0

承担数据平台实时计算模块与元数据管理系统的研发，保障订单、用户行为等核心数据流的稳定处理，支撑营销、供应链等业务线的即席查询与BI分析需求

• 重构实时计算引擎层，将原有Storm集群迁移至Flink 1.13，优化状态后端存储（RocksDB+HDFS），解决大促期间状态膨胀导致的作业重启问题；通过算子链拆分与本地缓存策略，将订单明细流处理吞吐量从8万/秒提升至25万/秒
• 主导元数据管理系统升级，基于Apache Atlas实现数据血缘自动采集（覆盖Hive/ClickHouse/Kafka），开发血缘可视化拓扑与影响分析功能；上线后数据问题定位效率提升50%，支撑数据治理团队完成80%冗余表清理
• 设计跨集群数据同步方案，解决异地多活场景下Hive分区表数据一致性难题；采用Canal监听MySQL binlog+Flink SQL路由写入目标集群，结合校验和机制确保数据准确率99.999%，日均同步数据量4PB
• 优化即席查询性能，针对Hive SQL慢查询问题，开发自动物化视图生成工具（基于Calcite解析执行计划），预计算高频查询指标；使营销团队周报生成时间从4小时缩短至20分钟，自助取数使用率提升3倍

参与公司早期大数据平台从0到1建设，负责分布式存储与计算组件的适配优化，支撑日志、埋点等非结构化数据的接入与初步加工

• 完成Hadoop生态组件（HDFS/YARN/Hive）的定制化部署，针对公司自有机房网络拓扑（万兆环网）调整副本策略（由默认3副本改为2+1跨机架），降低存储成本18%的同时保障数据可靠性
• 开发日志清洗ETL流水线，基于Flume+Spark Streaming实现Nginx访问日志、APP埋点日志的实时清洗（过滤无效字段、补全用户标识）；将原始日志存储占比从70%降至30%，清洗后数据可用率提升至98%
• 优化Hive小文件问题，设计‘实时合并+定时归档’双策略：通过Flink消费Kafka日志实时写入HBase，每日凌晨触发Hive外部表合并；使Hive表文件数从百万级降至十万级，查询性能提升40%
• 搭建平台文档与培训体系，输出《大数据平台使用指南》《常见问题排查手册》等12份文档，组织10+场内部培训；新业务接入平台的时间从7天缩短至2天，团队协作效率显著提升

用户行为实时分析平台重构与规模化落地项目

• 背景：原平台基于Apache Storm构建，存在延迟高（平均5s+）、复杂事件处理能力弱、多源数据（埋点/Kafka/MySQL Binlog）schema兼容困难等问题，无法支撑运营团队对活动效果实时监控、用户转化路径实时分析的需求；核心目标是重构至分布式实时计算架构，实现毫秒级延迟与复杂场景全覆盖。
• 难点：Storm拓扑的“ spaghetti code”难以维护，多源数据schema动态变更会导致计算逻辑失效；实时计算中“用户30分钟内连续点击3个商品详情页”这类复杂事件的匹配效率低。解决方案：选用Apache Flink替代Storm（基于其低延迟、Exactly-Once语义与内置CEP引擎）；引入Confluent Schema Registry管理多源数据schema，支持动态兼容；自研基于Flink Java API的复杂事件处理器，通过状态存储用户行为序列实现高效匹配。
• 行动：主导技术选型与全链路架构设计，搭建“数据采集（Kafka+Canal）- 实时计算（Flink）- 结果存储（ClickHouse+Redis）”流程；针对运营需求封装通用指标库（如实时DAU、转化漏斗、页面停留时长分位数），通过Flink SQL实现“配置化指标开发”降低使用门槛；与运维团队协作建立覆盖数据延迟、计算成功率、资源利用率的12项实时监控体系。
• 成果：平台延迟降至800ms以内，支持15万TPS并发，覆盖8条业务线的实时运营场景（如618大促期间实时监控活动页转化率，助力运营调整优惠券策略，活动GMV提升18%）；沉淀《实时数据处理架构规范》《复杂事件处理最佳实践》，个人获公司“年度技术创新奖”。

用户实时画像与标签推荐系统开发项目

• 背景：原用户画像依赖Hive离线计算（T+1更新），无法支撑推荐系统的实时个性化需求（如用户刚浏览商品后立即调整推荐列表）；目标是实现用户画像分钟级更新，提供实时标签供推荐引擎调用。个人负责实时数据处理与标签计算核心模块。
• 难点：离线标签逻辑分散在20+个Shell/Python脚本中，维护成本高；实时计算中用户历史行为的“状态保持”（如近7天浏览的商品类别）会占用大量内存，导致作业频繁OOM。解决方案：梳理现有标签体系（基础属性/行为偏好/实时兴趣三类），将逻辑迁移至Flink；采用RocksDB作为Flink状态后端，将用户行为序列存储至HBase，状态仅保留“当前计算窗口”关键信息以降低内存消耗。
• 行动：搭建“行为数据采集（Kafka）- 实时计算（Flink）- 画像存储（HBase+Redis）”链路，将用户行为数据实时同步至HBase宽表，同时用Flink计算“最近10分钟浏览的手机品类”“近1小时活跃度等级”等实时标签；优化Flink作业并行度与checkpoint策略，将作业恢复时间从15分钟缩短至2分钟；推动标签体系标准化，定义“创建-测试-上线-下线”的生命周期管理流程。
• 成果：用户画像更新时间从T+1缩短至3分钟，推荐系统实时点击率提升22%；标签覆盖率从75%提升至92%，减少推荐引擎空值处理成本；主导的“实时画像标签体系”纳入公司数据中台核心组件，支撑电商、内容两条业务线的推荐场景。

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