数仓是电商与增长分析的底座，但上线一张业务表往往要跨 MySQL、DataX、DolphinScheduler、StarRocks、飞书多处手工操作：DDL/脚本易拼错、首批数据对不齐、质量问题发现晚、失败靠人盯日志。本项目「数仓智能运维」正是为解决这一断点而生——把「能发布、能核对、能告警、能追责」做成统一产品，让业务表从接入到可分析从「人肉串系统」变成「平台闭环」。典型场景包括：新表/增量表接入与初始化对账、调度失败后的定位与重跑、分区空数/主键重复等质量门禁、以及谁改了什么的操作留痕。
作品一：同步任务四步向导。 登记数据源 → 配置规则 → 规则/AI 生成 DDL·DataX·DS 参数 → 验证发布到调度 → 一键初始化同步，并给出 DataX/视图进度与行数字段比对报告。实例上，发布后即可在平台内完成首批灌数与核对，不必再切多个控制台手工触发、手工对行数。
作品二：数据质量监控。 表规则/模板（含自写 SQL 标题）、试跑、强/弱规则分级；失败走飞书卡片，支持「完成/忽略」，并按 5 分钟复检刷新原卡直至恢复，避免刷屏漏报。实例上，ODS 类核心表可把门禁嵌进日常调度节奏，异常直接触达责任人。
作品三：任务流失败闭环与平台治理。 失败采集、手册/AI 辅助诊断、可配置飞书审批与一键重跑；另有 LDAP 登录与白名单、模型配置、操作审计日志（登录/发布/改规则等写操作可查）。整体把「建任务—跑通—守质量—出事能处置—事后可审计」串成一条产品线，而不是零散脚本。
我主要负责产品主链路的设计落地与上线：同步任务状态机与初始化同步（含停止/终态报告不混淆、大表超时与并发控制）、质量告警飞书闭环、审计日志与安全加固（登录限流、错误脱敏、Webhook 兼容现网）、以及发版与元库变更落地。技术上采用 React+Vite / FastAPI+SQLAlchemy，对接元库 MySQL、StarRocks、DS/DataX、LDAP、飞书。
亮点与难点： 难点在多系统一致性与「不破坏现网」——例如初始化比对曾因读写时区差 1 小时导致字段全红，通过统一 JDBC/timezone 一次修掉；列表热路径禁止 enrich，避免拖慢日常打开；审计异步写入，失败不影响发布。收益上： 新表接入从多工具手工串行，收敛为平台内可重复的标准流程；首批数据有报告可验收，减少「发了但没数/对数不对」的返工；质量异常从被动查表变主动卡片+复检；关键变更可追溯，降低误操作与安全风险。整体直接压缩数仓接入与故障响应的人工链路长度，把工程师时间从「搬砖对接」腾给业务建模本身。
评论