负责电商平台数据中台核心组件（实时数仓、任务调度、数据服务）的架构设计与迭代，支撑营销活动、供应链预测、用户运营等业务线的实时数据需求；同时优化平台性能与稳定性，推动数据能力的自助化与服务化。

• 主导设计实时数仓分层架构（ODS→DWD→DWS→ADS），基于Flink 1.17实现多源数据（线上交易、用户行为、第三方物流）的Exactly-Once同步，结合ClickHouse分布式列存引擎构建实时聚合层；解决大促期间实时订单报表延迟高（原15分钟→优化后1分钟内）与数据一致性差的问题，支撑618大促期间每小时百万级订单的实时营销（如满减凑单推荐），业务转化率提升8%。
• 针对高并发数据任务抢占资源导致失败的问题，基于Airflow 2.4二次开发，引入任务优先级队列（按业务 SLA 分级）与YARN资源隔离机制，同时优化任务失败重试策略（指数退避+依赖链自动触发）；将平台任务成功率从92%提升至98.5%，2023年双11期间未出现因任务失败导致的报表延迟，保障了运营决策的连续性。
• 推动数据平台服务化转型，使用Spring Cloud Alibaba封装数据API接口（支持SQL-like查询与预定义指标调用），对接营销系统的实时人群圈选需求；通过接口限流（Sentinel）、缓存（Redis）优化响应速度，使业务方取数时间从平均2天缩短至2小时内，月均自助取数次数从500次提升至2000次，减少数据团队重复劳动40%。
• 构建数据质量全链路监控体系，基于Apache Atlas管理元数据（字段含义、血缘关系），自定义规则引擎（数据完整性、一致性、时效性）并集成钉钉告警；覆盖实时数仓80%核心表，将数据质量问题发现率从60%提升至95%，2024年业务方因数据错误的投诉率下降40%。

负责零售业务离线数据仓库的开发与维护，整合线上商城、线下门店、供应商数据；参与数据平台初期搭建，支撑运营分析、库存预测等业务需求。

• 主导设计零售离线数仓星型模型（包含商品、用户、交易、库存四大主题域），使用Hive 3.x与Spark 3.1实现ETL流程；整合10+数据源（如POS系统、ERP、会员系统），支撑运营团队周报/月报的快速生成，将报表计算时间从8小时缩短至2小时内，数据准确性提升至99.9%，帮助运营优化库存周转率15%。
• 优化数据同步流程，针对MySQL业务库的全量同步耗时问题，采用Sqoop结合增量日志（Binlog）的混合模式，每日同步时间从4小时降至30分钟；同时引入数据校验脚本（对比源库与数仓的行数、金额总和），使同步数据的一致性从90%提升至98%，减少人工核对工作量60%。
• 推动数据可视化工具集成，对接Tableau Server并封装常用指标模板（如门店销量TOP10、会员复购率）；将运营人员自主制作报表的比例从30%提升至70%，降低数据团队对业务报表的支持压力，同时提升业务决策的灵活性。

负责电商平台基础数据处理与报表开发，搭建初步的数据分析体系，支撑初创期的业务快速增长需求。

• 从0到1搭建用户行为日志采集系统，使用Flume 1.9收集APP端点击、浏览、下单日志，存储至HDFS并按天分区；通过正则表达式与JSON解析优化日志完整性，将有效日志占比从85%提升至98%，支撑用户画像的初步构建（如年龄、性别、兴趣标签），帮助精准营销活动的点击率提升10%。
• 开发基础数据分析报表，包括用户日活、转化率、客单价的日报，使用Python Pandas做数据清洗与聚合，对接公司内部BI系统；将报表生成时间从次日上午10点提前至早上8点，让运营团队能及时调整当日推广策略，如针对低转化渠道优化素材，当月推广ROI提升12%。
• 协助搭建数据仓库ODS层，使用Hive 2.3做简单数据清洗（去重、空值填充），整合线上交易与会员数据；将ODS层数据可用率从90%提升至95%，为后续离线数仓的扩展奠定基础。

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

• 背景：原平台基于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%，减少推荐引擎空值处理成本；主导的“实时画像标签体系”纳入公司数据中台核心组件，支撑电商、内容两条业务线的推荐场景。

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