负责电商平台全链路数据资产治理，主导数据质量、元数据、分类分级三大核心模块建设，协同业务、技术、安全团队推动治理策略落地，支撑数据中台对外赋能与合规要求。

• 主导设计电商业务线数据质量闭环体系，基于Soda Core规则引擎与自研校验框架，针对用户行为、交易订单、商品库存3类核心数据，定制120+动态质量规则（含唯一性、完整性、一致性），通过Airflow调度实现小时级监控；针对大促期间数据波动问题，开发异常检测模型（基于孤立森林算法），将质量问题发现时效从T+1缩短至15分钟，大促期间数据质量事故率下降82%。
• 牵头元数据管理平台升级，整合Apache Atlas与自研标签系统，完成2000+数据源（含MySQL、Hive、ClickHouse）的全量元数据采集，设计‘技术元数据+业务元数据+管理元数据’三维标签体系；针对跨部门元数据理解不一致问题，推动制定《电商元数据命名规范V2.0》，明确23类核心实体的属性定义标准，元数据准确率从78%提升至97%，业务团队自助查询效率提升65%。
• 推动数据分类分级落地，依据DCMM（数据管理能力成熟度评估模型）与《个人信息保护法》要求，主导编制电商行业数据分类目录（含用户隐私、交易敏感、运营分析3级12类），设计‘自动打标+人工复核’双轨机制；针对用户手机号、支付信息等敏感数据，联动安全团队实现脱敏规则与访问权限的动态绑定，全年未发生因分级不清导致的合规风险事件。
• 搭建治理效果评估体系，从质量（达标率）、效率（问题定位时长）、成本（冗余数据存储量）3个维度设计18项指标，通过Grafana可视化看板实时监控；推动将治理成效纳入业务部门KPI，促成跨部门治理协作会议机制，全年推动解决跨域数据冲突问题47项，数据共享效率提升50%。

聚焦本地生活服务数据资产盘点与治理，负责餐饮、到店、酒旅3条业务线的数据质量监控规则制定、元数据梳理及分类分级试点，支撑业务决策分析与数据产品输出。

• 核心参与公司首套数据治理体系搭建，主导完成餐饮业务线全量数据资产盘点，通过SQL脚本与元数据工具结合，梳理出12个业务域、45张核心表、2000+字段的业务含义与应用场景，输出《餐饮数据资产目录V1.0》，资产覆盖率从65%提升至88%，业务团队数据查找耗时减少40%。
• 设计餐饮订单数据质量监控方案，针对‘订单状态不一致’‘优惠金额超限’等高频问题，基于Sqoop增量同步日志与自定义规则，开发质量校验脚本（Python+PySpark），实现每日凌晨自动跑批检测；上线后订单数据问题闭环率从55%提升至82%，下游报表数据修正工作量减少60%。
• 试点数据分类分级，参考《金融数据安全分级指南》并结合本地生活场景，将用户地址、支付凭证定义为‘高敏感’，商家资质、评价内容定义为‘中敏感’，制定分级存储策略（高敏感数据加密存于HBase，中敏感存于ClickHouse）；推动技术团队完成存储架构调整，敏感数据泄露风险降低75%。
• 协同数据产品团队优化数据服务接口，针对‘用户消费频次’等高频调用指标，通过治理后的高质量数据源重构计算逻辑，接口响应时间从800ms降至200ms，支撑前端‘猜你喜欢’推荐功能点击率提升18%。

协助完成金融风控数据的基础治理工作，包括元数据采集、数据质量规则初步设计及分类分级文档整理，为后续治理体系落地奠定基础。

• 负责金融风控核心库（含用户征信、设备指纹、交易流水）的元数据补全，通过编写Shell脚本调用Apache Atlas API，批量采集200+表的字段类型、更新频率等信息，修正错误元数据130余条，元数据完整率从81%提升至95%，支撑开发团队快速定位数据来源。
• 参与设计基础数据质量规则，针对‘身份证号格式错误’‘手机号重复’等问题，基于正则表达式与Hive UDF，开发15条轻量级校验规则，嵌入ETL流程；上线后原始数据错误率从12%降至3%，减少下游风控模型训练的脏数据处理时间。
• 协助整理金融数据分类分级初稿，梳理用户身份信息、账户交易记录等8类数据的敏感等级，参考《个人金融信息保护技术规范》标注保护要求；输出《金融数据分类建议清单》，为后续正式分级提供参考依据。
• 优化数据问题反馈流程，设计Excel模板收集业务部门数据质量问题，通过VLOOKUP匹配规则库快速定位根因，将问题处理周期从3天缩短至1天，季度问题解决满意度从70%提升至88%，获部门季度优秀新人奖。

泛娱乐社交用户实时行为-画像融合决策平台

• 背景：公司旗下社交APP用户破1.2亿，但实时行为数据（点赞/评论/礼物打赏）与离线用户画像（兴趣标签/付费层级）割裂，商业化团队依赖T+1报表决策，导致营销活动响应滞后、个性化推荐CTR低于行业均值15%；目标是构建“实时+离线”统一数据平台，支撑营销、推荐、运营的分钟级决策。
• 难点：实时数据湖需兼顾“低延迟写入”与“数据一致性”——初期Flink写HDFS易积压重启，离线同步时schema不一致引发计算错误；业务需关联用户实时行为与30天内历史行为，传统join耗时久无法实时。
• 行动：主导设计“实时-近线-离线”三层架构：实时层用Flink消费Kafka数据，通过Iceberg Upsert模式写入实时湖解决一致性问题；近线层用Spark Streaming基于Iceberg做分钟级行为聚合；离线层预计算实时与历史关联表减少join压力。利用Iceberg Schema Evolution自动同步离线标签体系，消除人工修改成本。
• 成果：平台上线后，实时数据延迟从5分钟降至30秒内，准确性达99.95%；商业化活动ROI提升28%，推荐CTR较之前高35%；支撑会员推送、广告定向等3个核心场景，年节省决策时间4000小时。个人主导跨团队落地，推动平台成为公司数据驱动核心基建。

多源用户行为日志实时处理平台从0到1搭建

• 背景：公司APP/小程序/Web用户半年增长3倍，现有Logstash+Elasticsearch系统无法承载峰值每秒15万条日志，且格式混乱导致实时监控延迟超10分钟、推荐无法用实时特征；目标是搭建高可用低延迟的日志处理平台。
• 难点：多源日志标准化难（端格式不一致）、高吞吐下性能瓶颈——初期单节点Flink吞吐不足，故障恢复需30分钟以上。
• 行动：设计统一Avro schema规范跨端日志，用Flume Agent自动转换为标准格式发Kafka；基于Flink做分布式并行pipeline，按日志类型动态调并行度（APP设32、小程序设16）提升吞吐；采用Checkpoint+Savepoint双机制，将故障恢复时间缩至5分钟内。
• 成果：日志吞吐量从每秒5万条提至25万条，延迟降至1分钟内；解析错误率从8%降至0.1%以下；支撑实时监控与推荐实时特征，推荐实时特征覆盖率从20%升到70%。个人负责架构设计与核心开发，解决多源日志标准化与性能瓶颈，为后续数据平台扩展奠基。

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